Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Tievel
Newbie


Joined: 16 Oct 2005
Posts: 7

PostPosted: Tue Jul 31, 2007 9:35 pm   

'Communicating' between packages
 
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!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: 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
_________________
Asati di tempari!
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed Aug 01, 2007 1:55 am   
 
It's //ModuleOrWindowName/ like Zugg says, not //PackageName/. Apart from that, Tech's right.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Aug 01, 2007 11:06 am   
 
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).
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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}
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Thu Aug 02, 2007 3:40 am   
 
Caled wrote:
this means triggers in one package calling aliases in another

This is the part that leaps out at me as being event-able. Events are just aliases at heart, but you can have as many of them as you like, and they'll all run (and people can plug into them) and if there are zero events for an event that's raised, it'll fail silently, unlike an alias call.

I had the exact opposite idea to you - making a package that's a trigger library for people to plug their own curing systems into. It'd look something like this:

#trig {^A prickly tingling sensation or whatever.} {#raise add_affliction paralysis}

The asleep thing is a bit more complex. Events would allow you to keep a separate asleep variable in each package to avoid going across packages... but that's just a way of hiding the dependency, it doesn't actually remove it. You might as well just use the variable and make the class package dependent - it's not like you're going to use it separately anyway.

And honestly, there's not all that much to get your head round with packages, modules and windows. Windows are just modules with a GUI element attached, but everything inside them isn't visible to anything outside the window. Trying to access a variable in a window from another module or window (even in the same package) will fail (though you can use the explicit @//window/class/var syntax). Same for aliases and whatnot. Events in windows are still called no matter what raises them, though (which makes sense when you think about pre-made events - what's raising them? :S)

You can access things in another package as long as they're in a global or external module. External modules are useful in a few specific cases - it's mostly global that you'll need.

So, basically, when you call a setting, CMUD uses this hierarchy:

Current window or module
Non-external modules (not windows) in the same package
Global and external modules outside the current package

That's pretty much it.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Thu Aug 02, 2007 12:56 pm   
 
Basically think of this structure.

Code:

Package-|                   |-Trigger
        |         |-Class---|
        |-Module--|     
        |         |-Class---|
        |                   |-Alias
        |                   |-Variable
        |
        |                   |-Button
        |         |-Class---|
        |         |         |-Menu
        |-Window--|
        |         |-Class---|
        |                   |-Class---|
        |                   |         |-Alias
        |                   |         |-Variable
        |                   |-Trigger
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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?
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net