Zugg Software :: View topic

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Ok, new thread for a new concept. This relates somewhat to the heated discussion in the other thread titled 'cmud questions/issues/something'.

Background:
Zugg needs 'default.pkg' to setup various default settings and upgrade said package with each revision of CMUD.

This default.pkg should be invisible to the user, nobody needs to edit it, it's a "System File". Call it default.dat or something if you think it would help.

Problem:
Me, vitae and a few other people would like to be able to override/delete some of the defaults - in particular some of us don't want diagonal directions, whilst others don't want any keypad at all.

Additionally, there may be some aliases/etc that I want common between every single MUD I ever connect to. I would have used to put these in the default mud file on zMUD, but this has been taken away from us.

Solution:
Create a separate package called 'userdefaults.pkg' (or .dat so we don't get confused that it really isn't a package to include/exclude manually) and have this loaded in the same way that the CMUD Defaults get loaded - transparently.

This package however will be modifyable, and won't be overwritten by a new installation, yet at the same time will allow us to override certain things - disable diagonals, set global aliases, that kinda junk.

Reasoning:
I know it's possible to set this up manually every time I create a new MUD connection, but let's face it:
1) I'm lazy so don't want to manually set up the package inheritance for every MUD connection I make
2) it's not very user friendly to have to manually set up and manage the package inheritance (having to go edit the connection and add packages from there etc... might not be as bad if you can do it from the settings editor)

Further enhancements:
Could we flag certain packages as 'default for x type of MUD' so for example if we created a 'dikudefaults.pkg' and a 'tinyfugedefaults.pkg' we could tell CMUD to always use 'dikudefaults' when connecting to a MUD that is defined as type 'Diku' and those defaults are rightly completely different to those which you would use for a tiny-based MUD/MUSH.

Personally I only MUD on one MUD usually, and visit 4-5 semi-regularly so doing it manually isn't a big hassle for me, I just think it would be a nice optional enhancement to have for those who do like going on a MUD-crawl.

Magician Joined: 29 Nov 2005 Posts: 482

i think about this over and over.. And everytime i reach the same conclusion.

The base defaults were made for a reason. They were also hidden based on a discussion in this forum. Now you want to make "ANOTHER" defaults package that still contains the same types of things that were hidden in the first place.

To my knowledge while editing them etc is out of the question AND I THINK IT SHOULD BE.

I just dont see how hard it is to disable the "Defaults" classes. even when upgraded they would be disabled

IN YOUR USER DEFAULT PACKAGE <-- which you create anyways and would have to anyways
#t- whateverclassisindefaultsyoudontwant

Why should zugg make a new users file. <-- which you will have to edit and add

When you can just make one yourself and add it yourself anyways.

It doesnt take that long to click edit session and the plus sign.

I think the reason its on the outside and not in the settings editor is what happens if you screw up and add a package or it gets corrupted (THIS HAPPENED TO ME JUST TWO DAYS AGO) i would have lost everything. Since i could edit session and remove the defunked package the only thing i had to redo was that package and i was still able to get into the session to fix what went haywire. If i had to go to the settings editor to do it then i couldnt have repaired the session i would have had to rebuild it completely. I dont like the idea of that.

As to the "Further Enhancements" i havent checked so forgive me on this one. If there isnt maybe zugg could add a %mudtype or use the selection in the session

Then you could easily script it
#SWITCH (%mudtype = 'diku') {COMMAND TO LOAD THE PACKAGE HERE} (%mudtype= 'tinyfuge') {COMMAND TO LOAD TINY PACKAGE}

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Posted: Fri Sep 01, 2006 6:42 am

This is pretty funny. I was out of the office for most of the day, and while I was gone, I came up with a solution to this "Default Settings" issue. So I log into the forums to post, and here is Rainchild with a similar post already in the forums.

Rainchild, sometimes I think you have some sort of spyware inside my head reading my mind or something ;)

Let me ignore Rainchild's post for a second and tell you what I thought about today. All of this discussion, so far, as been mostly focused on the Keypad macros. The problem with that "task" is that there were several ways to overcome the issue: a) create a seperate "user defaults" package, b) create an AtStartup event that disables the macros, c) add some "special" preferences that would toggle these classes, etc.

But today I thought about a different "task" that is actually a much bigger and more common issue: The Default Directions! The Default Directions (n,s,e,w) are stored in the Default Package. But these directions only work for *English* MUDs. If you play a German MUD, then you need to completely change the directions. Not even the single character names of the directions are the same.

So, in the case of a German MUD, you can't just "override" the default settings. You really need to edit them, or delete them and create your own directions. So, *NONE* of the previous suggestions would work for this. You would need a combination of solutions.

What became clear to me is that the existing "Default Settings" really needs to be split into several different packages.

1) The actual settings that initialize all of the initial values of the preferences. This is the stuff that gets screwed up if you just delete or disable the default settings. This stuff should be invisible to the end-user and should be hard to change. It's needed for the internal operation of CMUD and isn't something that players should mess with. Let's call this the "DEFAULT.PKG" package, and have it hidden like it is now. But this package does *not* contain keypad macros or any directions.

2) Then we have the "EnglishDirections.Pkg" package. This defines the n,s,e,w directions (and possibly diagonals) for English MUDs. Each different language would have it's own Directions package. So there might be GermanDirections.pkg for example.

3) Once the directions are defined, now we can load the EnglishKeypad.pkg. Again, this is language specific since the direction letters assigned to the keypad are different in other languages.

OK, now wait...I can already hear the whining. Everyone is going to start complaining about how this is even more complicated than Rainchild's "UserDefaults" package (which you would also still have containing all of the common aliases, macros, etc that the player always wants). And yes, it would be a pain to add all of these packages to every new session that you created.

But here is the other feature: a preference page that gives the list of packages to be loaded into *new* sessions. In other words, there would be a list of packages, such as "Default.pkg, EnglishDirections.pkg, EnglishKeypad.pkg", and whenever you create a new session icon, this list is used to populate the initial list of packages loaded by that session. You would still be able to edit the package list for each session...this would just set the initial value.

So, by default, new CMUD sessions would load packages 1,2,3 as mentioned above. But Vitea could edit this list *ONCE* and remove the Keypad package, and then every new session icon would only load 1,2 and not 3. And Rainchild could add his "UserDefaults.pkg" to this list so that new sessions automatically load his customized package.

I think this is a clean and simple way to handle it. a) novice users don't have to do anything...they get the defaults as intended, including the keypad. b) it's easy to customize for users who know what they are doing without potentially messing up any critical system settings. c) it allows changing the language-specific settings in a straightforward way.

As far as tying this to the MUD "type", that just isn't going to work. There is no clear-cut list of "standard MUD types". Sure, it's easy to call a MUD "Diku" or "LP", but over the years there have been too many variations of this. The "MUD Type" field in the MUD Connector list is a free-form text field. CMUD tries to parse this into categories and tries to group similar looking types, but it's not perfect. Just look at the MUD Connector tab in CMUD and look in the Type pulldown to see all of the types. It just doesn't make sense to tie anything to something that is so poorly defined.

I think it is better to leave this up to the player. It's still easy for you to create your own "Diku.Pkg" package and have it loaded with your Diku sessions. Also, my own experience has shown that even if you start with a generic "Diku" package, you end up customizing it for a specific MUD with specific paths, triggers, etc. Every MUD is different and unique so there is really no way for CMUD to set this up "automatically" for you. The best that I can do is set up specific PKG files for the 10 paid MUD icons so that new players using one of these icons get a customized set of aliases, triggers, etc.

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Zugg, sounds fine.
I'm another of the users that previously would delete stuff from the default.mud and would be happy enough if I could untick the package that contains directions and the look on keypad-5 command etc and include my own instead, while leaving the critical stuff that CMUD needs unchanged (and kept hidden and locked).

As for the mud types, I've never played a Diku, LP, Circle mud for more than 5 minutes so I'm not really one to talk with any authority on it, but I'd expect that people who know enough to know that they want a certain set of controls for a Diku would then be able to create a Diku.pkg and just use it when required.

Maybe allow a user defined list of muds, so I could create a Diku.pkg and StdDirections.pkg and assign it to a 'Diku' option that I could assign to a connection? So that way people can pick a group of packages to load based on their own tastes?

Posted: Fri Sep 01, 2006 1:18 pm

At the risk of sounding syconphantic, that's a brilliant solution Zugg. Of course it required changing perspective and addressing the problem and not the symptoms. It clearly shows why zMUD is so good and CMUD will be even better.

Wizard Joined: 14 Aug 2004 Posts: 1269

Sounds great, Zugg. Although, in zMUD 7.x anyway, the directions are in a class: System|Directions and System|DirectionsDiag, so it would be possible to disable them in CMUD with #T- System|DirectionsDiag, wouldn't it? Or is this not allowed? [Edit: Tried Disabling this class in zMUD and it returns enabled next time I open my session- so I guess it would have to be overridden in the atconnect alias.] Your solution sounds much better anyhow.

Plus, now I know why the diagonal directions return from time to time in zMUD - it must be when I upgrade. I've deleted them a few times as they mess up mapping when mapping in a mud without diagonal directions.

Posted: Sat Sep 02, 2006 11:35 pm

RainChild and Guinn, I'm glad to finally see that someone else edit's pretty much the same things I do, and feels the same way about wanting to have control over them. Started to feel like the only one around here.

Zugg, Just to make it clearer for myself, are you saying that EACH thing would have a seperate package? Like ONE package for they Keypad, ONE package for Diagonals and ONE package for Cardinal directions? ALL uncheckable from the settings?
If so, then that would be GREAT!

Actually Zugg? With regards to the diku.pkg, merc.pgk etc.
there IS a way I think. When you enter the Mud address there is that drop down thing that asks the type of MUD that you are connecting to. I've never used it cause i've never figured out how it worked or if it was just there for the user to remember the type of mud that it is.
Would you be able to code it so that IF the user puts down the type of mud AND there is a package for it that it loads up?

Like Aardwolf is a Diku variant. I select Diku in the drop down. I already HAVE a diku.pkg. when I start the session it can load it up as well.
I go and check out another mud. It too is a Diku. I enter the addy, select Diku from the dropdown, and boom diku.pkg loaded.

K, maybe I DON'T want my diku.pkg to load up just cause I am testing a new mud. Check box under the Selector. "Enable pkg?"

I know ya said there wasn't an easy way to do it, but you said to leave it up to the user. In a sense this way it is.

At least my whining might have help come up with a solution.

Posted: Sun Sep 03, 2006 1:38 am

Yes, each thing will be a seperate package. This is obviously necessary because you will always need to load some sort of Directions package, or else the mapper and speedwalking will break. But you would only add the Keypad package if you wanted the keypad macros. These are two completely different functions, so they will be in completely different packages.

The drop-down list for the MUD type that you are talking about is left over from zMUD and has actually been removed from the next version of CMUD. It was a fixed list and had nothing to do with the MUD Connector list. It was something that you had to set manually. And setting this drop-down manually is no different than adding the appropriate package to the package list.

In other words, you don't select "Diku" from the dropdown list, but you go to the Files tab and add the Diku package to the package list.

The reason for this is that the package list is integrated with the Shared Package Library, so if some wierd new MUD type gets added, someone can easily write a package for it and put it into the shared library. Or, there might be several "Diku" packages that have different features that you can choose from. The point is that the package library is dynamic and can change over time as new MUD types are added, whereas the dropdown list was a stupid fixed list that had nothing to do with real MUD types.

For the most popular MUDs, I'd expect that you'll eventually find packages already defined and in the shared library. So, when you create a session for Aardwolf, you go to the Files tab, click the Edit button to bring up the Shared Library and look for a package for Aardwolf that has the features you want. This is a lot more flexible that having a single package per MUD type and a fixed list of MUD types.

Posted: Sun Sep 03, 2006 4:03 pm

yeap, i know. was just an idea Very Happy

With the diff types of muds coming out I know it would be hard.

Still wondering tho, will diagonals be in one package and cardinal directions in another? (kinda hope so, if not then aw well)

Magician Joined: 29 Nov 2005 Posts: 482

seb did you tick the box to disable class on connect for those you wish to have remained disabled. *ZMUD*

Wizard Joined: 14 Aug 2004 Posts: 1269

No. My bad! But tried it now and it gives me a message saying can't edit an inherited setting. atconnect alias is the solution.

Posted: Mon Sep 04, 2006 2:55 am

Yeap, it's part of the default.mud and can't do that box cause of it.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

First

Posted: Thu Sep 07, 2006 4:37 pm

I'm not sure I understand what you mean by "dynamic list". This "list of default packages" will certainly be user-customizeable. So even though the default list might be "Default.Pkg, EnglishDirections.Pkg, EnglishKeypad.Pkg" you can certainly edit it to add your own package. The user interface for this list is the same as the File tab in the session screen. So you can add *.pkg files to the list, or you can click the Edit button to load packages from the Shared Library to the list.

But there is only a single list. When you create a new session icon, the current value of this list is used to initially populate the list of packages to be loaded by that session. Of course, you can then edit the specific list for that session if you want to modify it in the future.

A conflict checker would be much too complicated. In general, packages are self contained and do not manipulate the same variables. That's why you've been seeing all of these new concepts like Windows and Modules. The intent of the design is to allow packages to be more modular and self-contained. There will eventually be a way to specify "dependant" packages, which would allow you to specify other packages that are needed.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Gotcha.

The answer makes sense even if my questions didn't.

The packages list in the files tab is exactly what I was asking for/about when I said dynamic list. I haven't played with cmud much yet. Just upgraded to XP again so I could play with CMUD.