QUOTE(Zarquan @ Mar 7 2005, 11:03 PM)
It's more painful to script in Python, in my opinion, simply because I have to preface so many things with "world." to make them work. When you add in the fact that you have to pass in your world variable to every class you use, you now have to do "self.World." (or something similar, depending on what you call the member variable). I had to make use of complex metaclass instances and shuttle data back and forth between plugins with these complex methods. Just looking at the code gave me a headache and then trying to decide the behavior of each plugin and how to keep them separate was more than I wanted to do, at least until I know more about all the MUSHclient scripting.
Basically, the boundaries between plugins isn't always cut-and-dried. Sometimes you'd like to mark a defense down when you see an affliction, but do you want the afflictions plugin to know about your defenses? Do you duplicate triggers and use sequences to take care of it? Are your triggers included with the script in the plugin or do you just slap the triggers, aliases, and everything besides scripts into your main world settings file?
There are just so many options in MUSHclient that it can be confusing. It's flexible and powerful, but confusing just the same.
Basically, the boundaries between plugins isn't always cut-and-dried. Sometimes you'd like to mark a defense down when you see an affliction, but do you want the afflictions plugin to know about your defenses? Do you duplicate triggers and use sequences to take care of it? Are your triggers included with the script in the plugin or do you just slap the triggers, aliases, and everything besides scripts into your main world settings file?
There are just so many options in MUSHclient that it can be confusing. It's flexible and powerful, but confusing just the same.
68119
QUOTE(Zarquan @ Mar 7 2005, 10:03 PM)
It's more painful to script in Python, in my opinion, simply because I have to preface so many things with "world." to make them work. When you add in the fact that you have to pass in your world variable to every class you use, you now have to do "self.World." (or something similar, depending on what you call the member variable). I had to make use of complex metaclass instances and shuttle data back and forth between plugins with these complex methods. Just looking at the code gave me a headache and then trying to decide the behavior of each plugin and how to keep them separate was more than I wanted to do, at least until I know more about all the MUSHclient scripting.
Basically, the boundaries between plugins isn't always cut-and-dried. Sometimes you'd like to mark a defense down when you see an affliction, but do you want the afflictions plugin to know about your defenses? Do you duplicate triggers and use sequences to take care of it? Are your triggers included with the script in the plugin or do you just slap the triggers, aliases, and everything besides scripts into your main world settings file?
There are just so many options in MUSHclient that it can be confusing. It's flexible and powerful, but confusing just the same.
Basically, the boundaries between plugins isn't always cut-and-dried. Sometimes you'd like to mark a defense down when you see an affliction, but do you want the afflictions plugin to know about your defenses? Do you duplicate triggers and use sequences to take care of it? Are your triggers included with the script in the plugin or do you just slap the triggers, aliases, and everything besides scripts into your main world settings file?
There are just so many options in MUSHclient that it can be confusing. It's flexible and powerful, but confusing just the same.
68119
I think you just haven't tried plugins enough, you'll be back to them before long, trust me
Most of your concerns are most probably due to not having decided upon a specific design for your combat system, which is why you don't know where to put what and what should know about what. Once you code it in the world, you are most likely to see that it is easily distributed across plugins in a very clean way. Basically, here's how I design my combat systems:1. AfflictionStatus plugin - responsible for tracking afflictions and defenses, contains hundreds of triggers with minimum code.
2. Curing plugin - responsible for curing, contains lots of code with virtually no triggers.
3. Autosipper plugin - responsible for health, mana (ego, wounds) curing specifically, mostly self-sufficient and contains triggers and code in a more or less equal proportion.
4. PromptCatcher plugin - responsible for capturing the prompt and keeping its stats updated, few triggers, even less code.
That way, if I need to completely redo the affliction tracking part, I can just replace the AfflictionStatus plugin with a different version without worrying about much else, since I know that AfflictionStatus only exposes the list of current afflictions (corrected for illusions or whatnot) and a list of balances (corrected for the same illusions, lag, etc). If I want to change the way the prompt is handled, I go to the PromptCatcher plugin. And so on. The point to that being that all my systems are isolated into separate chunks, which are easier to modify than a single script space, where you have to worry about scripts and triggers that don't directly relate to what you are trying to focus on. With plugins I can presume that all other parts of the system are static when changing one specific part. With included files or one monolithic world file, you always have to worry about various parts of the system (mostly triggers) getting in each other's way. Plus, at least for me, since you can easily interconnect things that are in one script space, I will always tend to do just that, driving further up the rate to which different parts depend on each other directly, rather than through data sharing or whatnot. Been there and it wasn't pretty with all the interdependencies making the whole system go up in flames due to a single small bug that crept up in the last hacking session because I forgot that the curing function gets a certain affliction value directly from a certain trigger, instead of looking for it in a variable. Or better yet - having to disable the whole damn thing because you forgot to add a reset for a pipe counter and your pipes are driving you insane by constantly trying to refill themselves whenever you get balance back. Right now, with 12 different plugins (most of them utilities of various kinds), I have a total of 1 alias and 20 lines of OnWorldConnect related code in my world file.
As for Python and PyAchaea, you never should need to worry about where the script is running, since you should never attempt to directly affect something in one plugin from another plugin without doing it through the Avatar instance. Nor do you need to pass the world object to class instances - the World is in global space and is visible everywhere.
