Member
Join Date: Jan 2006
Location: Iowa City, IA
Posts: 78
|
An update:
I finished implementing the armor swaps across the board (the LT was of course only an example; the same problem came up often). This is what wound up happening in the Eval script on one of the armor suit options: var size as number var cc as number var target as number var save as number var killer as number var traits as number var armor as number size = unit.delete[size.?] size = unit.assign[size.sz3] cc = unit.delete[cc.?] cc = unit.assign[cc.2d10] target = unit.delete[target.?] target = unit.assign[target.t7] save = unit.delete[save.?] save = unit.assign[save.s3] killer = unit.delete[kill.?] killer = unit.assign[kill.k10] traits = unit.assign[traits.th4] traits = unit.assign[traits.tpercing1] traits = unit.delete[traits.tjump?] traits = unit.assign[traits.tjump8] armor = unit.delete[armor.powersuit] armor = unit.assign[armor.m8] Then the options on the parent LT (which include that suit) got live statements that look a bit like this: (roster.MIPL02 | roster.MIPL03) & armor.powersuit That statement limits that option to being either of 2 "priority levels" (Think race) and must include the tag armor.powersuit (the default set of armor) before the option is visible and selectable. (For instance, a grenade you can take in armor.powersuit, but not armor.m9). I'm hoping I can save someone else trying to do the same thing some headache by putting that example up. As for me, thats quite a bit more "code" then the option based, exclusion group method I had earlier...but the rewrite was totally worth it. The suits now behave...well....exactly as I had hoped they would . And, I suspect more importantly, there is now *one* place to maintain the M9 suits and such, rather then specific units that repeat frequently...which I'm sure will cut down on errors. Thanks again Rob, and I now go on to tortue you in the next thread... |
#11 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 8,232
|
I'm glad things are now working the way you want them to. You are absolutely right about this method cutting down on errors, but it will also save you time. Centralizing your code into a few places instead of duplicating it everywhere will make a HUGE difference. Mongoose will be releasing all sorts of new material, so the localizing of logic will make things much easier to adjust as the game evolves. You'll have lots of new conditions to handle, but they'll be in a few places instead of distributed everywhere, so adding support for new material will be much easier. :-)
One thing you can easily do is eliminate the multiple variables. Just have a single "result" variable that is assigned the result of each "delete" and "assign" statement. Second, if you find that there is a fair bit of duplication in the behaviors for both the M8 and M9 suits, you might consider culling out a bunch of the delete/assign pairs into a separate procedure. You can then call that procedure from the appropriate Evaluate scripts, eliminating even more duplication. The above technique will REALLY come in handy if Mongoose adds new armor options (e.g. M7 or M10). Instead of duplicating things, you'll be able to re-use the procedures and only deal with the differences. For the same reason, you might want to change the Live statement in your example slightly. For example, you might change it to utilize "armor.power?" or exclude "armor.m?" instead of the explicit "armor.powersuit". Why? Because if Mongoose adds new armor options, you'll have your Live tagexprs hard-wired to a specific suit. By changing to a general class of armor (via the wildcards), you'll be able to add new armor (e.g. "armor.m10" or "armor.powerxyz") without having to change everything throughout your data files. Hope this helps, Rob At 05:15 PM 3/4/2006, you wrote: Quote:
|
|
#12 |
Thread Tools | |
Display Modes | |
|
|