Zugg Software :: View topic

Newbie Joined: 16 Oct 2005 Posts: 7

Right now I'm trying to figure out what the best hierarchy for my system in CMUD will be with the new package system. Before I really started to code it, though, I wanted to if packages can split their functionality, as is hinted at in the feature description. I know of the inheritance the main package has with all of the subsidiary packages, but I'm really interested in whether or not those other packages can share (particularly variables) scripting between each other.

Thanks in advance!

Posted: Tue Jul 31, 2007 11:07 pm

If the package is marked as "Shared" in it's package properties, and you create a Module within the package that is Global, then yes, you can access the variables from within this module. You can use the syntax @//Modulename/Classname/Varname to access variables within a specific class of a specific global (or external) module.

Creating packages that are dependent upon each other isn't really a good idea though. It requires the player to make sure that they have all dependent packages loaded into their session. The whole concept of a package is a standalone set of functionality (literally like a wrapped package or black box). So yes, you can split functionality into packages, but if the packages all depend upon each other then you might want to consider making them modules within a single package. Either way it works, it's just less complicated if you plan to share your packages with others if you minimize the dependencies.

Posted: Wed Aug 01, 2007 1:37 am

In short, yes the can. To access a variable in a separate package you use the syntax

#show @//PackageName/ClassName/Variable

or

//PackageName/ClassName/Name = Cat

Posted: Wed Aug 01, 2007 1:55 am

It's //ModuleOrWindowName/ like Zugg says, not //PackageName/. Apart from that, Tech's right.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'm building packages and modules that use events to signal each other of specific things that happen and their values. For example, when my main prompt trigger fires, it basically just raises the OnPrompt event with all the prompt values as parameters. That allows me to build modules that simply handle the OnPrompt event to do their various tracking things. Events are really the best way, in my opinion, to decouple modules and still allow you to communicate from one to the other(s).

Posted: Wed Aug 01, 2007 11:31 am

I agree. It's also useful because should you later share the scripts with anyone, they can use your events as an interface instead of creating new (and probably duplicate) triggers.

Back when the @//module/whatever syntax was broken and always creating new variables even if old ones existed, events were a good workaround too.

Posted: Thu Aug 02, 2007 12:59 am

I still haven't wrapped my head around packages, modules and whatever else there is :( I went and created a bunch opf packages which are not independant of one another, though I did come up with a set of rules for myself about what can cross the lines and what can't.

For example, I really wanted to put all of the triggers which flag incoming afflictions, from the aliases, variables and other stuff which manipulate that data to keep me cured. The reason being that I wish to be able to offer the backbone of the curing system to people without giving them all the affliction messages as well. Yet by necessity this means triggers in one package calling aliases in another. I've tried to keep variable manipulation within the packages though again, not always possible.

I have all the settings for the use of my class skills in a separate package, which is quite logical since one of the most obvious uses of the package system is to be able to organise settings easily between different characters of the same player. Some of those class settings depend on variables that are part of the affliction curing package though. For example, if I am asleep, there is no point trying to stab someone.

Should I then replace the following with an event? I'm not really sure how I could go about doing that, nor what advantage it would have.

#TR (You fall asleep} {asleep=1}
#TR {You wake up} {asleep=0}

Posted: Thu Aug 02, 2007 3:40 am

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

Basically think of this structure.

Posted: Fri Aug 03, 2007 2:15 am

I understand the structure, I just find it difficult to choose, at times, when to use a separate package, and when to use a module within a package. Actually, when to use a separate module at all. I have a few packages and they are all 'module-type' but I have not bothered to create any packages with multiple modules within them. I just use classes.

Though to be honest, I can't even figure out how to create them according to the above structure. When I create a module, it always appears to be in the same level of the hierarchy as the packages, though when I navigate to a specific package using the tabs, it will only appear in the tab for one of the packages. Confusing much?

Using #raise add_affliction paralysis is a good idea I suppose.. but it still requires them to tune their curing system to work off events. How is it any different in function to using "addaff paralysis" in those trigs, and in the package for the curing system, having #al addaff {whatever they do with incoming afflictions} ?

Both ways are still dependant on the other package.

In the above image, "testmodule" is the module I created. It appears in the "Concoctions" tab when I click on that one, but in the root structure it appears to be equal in the hierarchy to the packages?

Posted: Fri Aug 03, 2007 2:30 am

Modules you can just use like classes, like you have, just to separate different kinds of scripts. You should only really create a new package for something you want to share, and all the scripts in a package should ideally be able to stand on their own. Organising packages by topic's perhaps a good idea too.

Really, the only times you need packages are for sharing scripts and for easy multiplaying. Other than that, you can just use modules to separate your scripts by type.

The difference between using an event and using an alias is that they fail gracefully. For example, that trigger library I was talking about could potentially have many, many different events in it. Dying, taking damage, taking afflictions, things that'd need to be coloured (or that COULD be coloured). If you're using aliases the user either has to disable the triggers they don't want or make an alias for every one.

And finally, the "Concoctions" tab represents a package called Concoctions.pkg. That's what the tabs are. Inside the tabs are the settings contained inside that pkg file. If the Concoctions package was current when you created the testmodule module, it'll be inside the Concoctions package file. The All tab is just a list of all modules and windows inside all loaded packages. I personally don't use that view for creating modules and windows exactly for this reason - there's no easy way to tell which file it's going to end up in.

And finally, you'll notice that Arminas' diagram only includes packages and windows at the root of the package (each package, each tab, has its own root). This is deliberate - modules and windows can only exist at the root of the package. If you have any that aren't, it'll cause problems.

Posted: Fri Aug 03, 2007 2:57 am

Thats a good point about events failing gracefully. I knew that but kind of hadn't considered it as a proper bonus. That's given me a bit to think about. If I delete the "addaff" alias from the Curing Backbone package, and recreate it in the Curing package (which is the one with the triggers in it), and change its command to something like..

#al addaff {#raise add_affliction %1}

..then I should be able to retrofit that idea without having to change the commands in all of my triggers. I'll still have to modify some more aliases and stuff in the backbone package, but that shouldn't be too big a job (not compared to what changing every command in every trig would have been heh).

I think I have the right package structure. I have one for the affliction triggers. One for the actual curing-exectution. The "Concoctions" one is interchangeable with another I have on other characters, called "Reanimation" (a different set of cures for living/undead). The "Syssin" one is for my class specific abilities, and the 'Misc' is for the non-class-specific stuff Aetolia has.

But thankyou for explaining it all so patiently, until now I haven't been sure I had it all right.