tain.totalcodex.net

I tried to disassemble Mazz to figure this out on my own, but when I disassembled and tried to open it in loathing, loathing crashed. So I guess I'll just have to ask here.

What are the graceful steps to take to make a unit respawn invisibly, so that when the entire platoon is dead I can use a TUNI to see that they are gone, and reactivate the wave in an action list, ready to be sent back into battle as nice green troops? I know how to munger the wave back into the action list and all that jazz, my only problem is the respawn at original placement location as an invisible unit. Is it as simple as checking "respawn via script" and then using a unit control to make them visible again?

Edit: Upon further Loathery, I have discovered that I apparently don't know how to "munger, and all that jazz." As of now I am using an action list that selects a wave randomly, and that Wave action activates the reveal, platoon, and munger deletion of the wave. Standard stuff. I realized, though, that deleteing the wave meant I couldn't reactivate it later (right?) so instead I thought I would instead use that munger to delete the wave from the parameter. Then, when the wave dies off, I can use a munger to reinsert the wave back into the action list, thereby creating an endless cycle. Problem: as soon as the munger deletes the wave from the action list, the actionlist ceases to function. The list has a 1 to 80 second delay, and the munger goes off at the very beginning of that trigger time. Ideas?

Thanks for any and all help,
~fildred13

Simply select the monsters in question and Edit Marker> tick Respawns, and also tick Respawns via Script. (A side note, if you have units flagged for difficulty, band selecting them all monsters will re-set all to timid, so if this is the case, avoid it by selecting your units in bands of difficulty groupings if that makes sense.)

If you tick respawns only, the unit will automatically respawn after it dies, like a deathmatch game. Adding Respawns via Script basically turns the dead monster back into a usable marker for scripting with.

I have the wave respawning wonderfully now, thank you Graydon. A new issue, though, has of course arisen.

The wave spawns in for the first time, platoon moves to the hill, and fights as a legion until death. They respawn, and then they just stand there.
IF the wave spawns in for the first time but dies AS it is platoon moving to the hill, then they succeed in respawning and moving to the hill.

It seems that when the platoon move completes, the platoon thinks it has no state and deactivates (as it should.) The problem is, when they respawn, the action still assumes the platoon has already completed that platoon move, and so it assumes it has no state and shuts itself down. I'll include the segment of code and the debug info on this section to help illuminate.

Debug:
2011-10-03 15:40:42 ### MA [ctrl] Reval Center Platoon: succeeded
2011-10-03 15:40:42 ### MA [ctrl] Reval Center Platoon: deactivated
2011-10-03 15:40:42 ### MA [plat] Center Platoon: platoon state set to: Center Move
2011-10-03 15:41:06 ### MA [plmo] Center Move: succeeded
2011-10-03 15:41:06 ### MA [legi] Center Legion: initialized
2011-10-03 15:41:06 ### MA [plat] Center Platoon: no state (deactivating)
2011-10-03 15:41:06 ### MA [plat] Center Platoon: deactivated
2011-10-03 15:41:20 ### MA [legi] Center Legion: deactivated
2011-10-03 15:41:20 ### MA [tuni] Center Platoon dead?: count: 0==0
2011-10-03 15:41:20 ### MA [tuni] Center Platoon dead?: test action successful
2011-10-03 15:41:20 ### MA [tuni] Center Platoon dead?: succeeded
2011-10-03 15:41:20 ### MA [tuni] Center Platoon dead?: deactivated
2011-10-03 15:41:35 ### MA [] Reactivate Center Platoon: can't execute NULL actions
2011-10-03 15:41:35 ### MA [] Reactivate Center Platoon: deactivated
2011-10-03 15:41:35 ### MA [ctrl] Reval Center Platoon: succeeded
2011-10-03 15:41:35 ### MA [ctrl] Reval Center Platoon: deactivated
2011-10-03 15:41:35 ### MA [plat] Center Platoon: no state (deactivating)
2011-10-03 15:41:35 ### MA [plat] Center Platoon: deactivated
2011-10-03 15:41:35 ### MA [plmo] Center Move: deactivated
Quitting single player game...
Closing Myth.

Code:

CENTER PLATOON
{
Activates on Trigger
*****Light Action List ONE*****
Delete Center Plat
Center Platoon
Reval Center Platoon
}

Delete Center Plat [Munger]
deactivates_on_trigger
0.00, 0.00
{
Delete Actions
CENTER PLATOON
}

Reval Center Platoon [Unit Control]
deactivates_on_trigger
0.00, 0.00
{
Link
Center Arcs
Center Warriors
Center Dwarf
Ignores User Control Flag
true
Visible Flag
true
Activates on Success
Center Platoon dead?
Debug Flag
}

Center Platoon [Platoon]
deactivates_never
0.00, 0.00
{
Initial State
Center Move
Initial Squads
Center Archers squad
Center Warriors squad
Center Dwarf squad
Centerpoint
98.936, 186.690
Facing
267.19
Allies
scout ghols 1 plat
Debug Flag
}

Center Arcs
{
(subj, monster_identifier)
10469 (bowman)
10470 (bowman)
10471 (bowman)
10472 (bowman)
}

Center Archers squad [Squad]
deactivates_on_trigger
0.00, 0.00
{
Facing
0.00
Centerpoint
99.081, 187.682
Formation
1
Link
Center Arcs
}

Center Warriors
{
(subj, monster_identifier)
10460 (warrior)
10461 (warrior)
10462 (warrior)
10463 (warrior)
10464 (warrior)
10465 (warrior)
10466 (warrior)
10467 (warrior)
10468 (warrior)
}

Center Warriors squad [Squad]
deactivates_on_trigger
0.00, 0.00
{
Facing
0.00
Centerpoint
99.016, 187.264
Formation
4
Link
Center Warriors
}

Center Dwarf
{
(subj, monster_identifier)
10459 (dwarf)
}

Center Dwarf squad [Squad]
deactivates_on_trigger
0.00, 0.00
{
Facing
0.00
Centerpoint
99.047, 185.004
Formation
2
Link
Center Dwarf
}

Center Move [Platoon Movement]
deactivates_on_trigger
0.00, 0.00
{
Waypoints
93.924, 168.057
87.575, 155.315
100.364, 140.172
96.249, 128.590
95.553, 110.645
Waypoint Radii
10.001
20.000
Radii
10.001
24.000
Interpolate Flag
true
Interpolant Spacing
5.000
Activates on Success
Center Legion
Debug Flag
}

Center Legion [Legion (defensive)]
deactivates_never
0.00, 0.00
{
Group Count
3
Line
96.059, 123.909
96.364, 99.706
Group Centerpoint Array
94.170, 99.305
96.626, 100.858
96.686, 102.272
Group Unit Container Array
Center Dwarf
Center Warriors
Center Arcs
Debug Flag
}

Center Platoon dead? [Test Unit]
only_initial_delay
deactivates_on_successful_execution
3.00, 3.00
{
Link
Center Arcs
Center Warriors
Center Dwarf
Unit Count Equal To
0
Activates on Success
Reactivate Center Platoon
Deactivates on Success
Center Platoon
Center Legion
Center Move
Debug Flag
}

Reactivate Center Platoon
{
Activates on Trigger
Reval Center Platoon
Center Platoon
Center Move
Debug Flag
}

Uh.... Second* action. Munger. You delete the action you try to activate later. Since you've deleted it, the trigger is now linking to nothing, and you get the NULL error in your debug log.

I don't think you need to be MUNGing anything in this scenario. If you're using respawns via script, just leave all the monsters in their respective containers, and reactivate the PLAT when they've respawned. It should automatically find them and put them into positions.

Edit2: And this is just a generalized tip that I learned from some knowledged scripters years ago, and have stuck with ever since.... when using TUNI tests to check values of units, never use Equal To when you don't have to.... apparently it doesn't always work accurately. If you want an equal to 0 test, use Less Than 1.

Edit3: For organizations sake, NEVER name two different actions with the same name! Especially if they're two different kinds of actions! Was trying to read through and kept getting confused at which Center Platoon was doing what. name your ACLI "CENTER PLATOON STARTER" or something along those lines..... it'll make your life easier when you've got 400 lines of script and need to track down a bug with your debug log. If it's pointing you to an action name that isnt actually the right action, you could just screw the script up more accidentally

Edit4: (And this is now becoming a small tutorial lol) Can I also suggest scripting efficiency in regards to map action use and map action param size counts?
For any action that requires a link to a subject container (as demonstrated in many bungie maps) there's an easier, cleaner way. For the action in question, lets take a SQUA for example, instead of adding a link param to the Squad and making a whole separate container with the squad units, click Add in the SQUA and select Monsters from the drop menu. (If the action in question doesn't have Monsters as an option, you can create it by clicking custom, typing 'subj' and picking monster_identifier from the customs drop menu.) Add that squad's monsters directly to this container - Removing a whole subject container, and a link from the squad.

You can even take this one step further by going into Fear, opening up the Templates folder and opening up Squad template. By tweaking 'optional' to 'required' you can make Monsters show up as one of the default values you must fill when you create a new SQUA action. No extra clicking and drop menus, just pure scripting efficiency With this tip in mind, you can make other subtle tweaks to your scripting templates; for example, I've gone into my Attack template and tweaked it's deactivation to 'never' by default as that's almost always what I set it to. (I figured with the number of time's I'd moved my mouse clicking and editing ATTA actions, I'd probably wasted cumulative hours of my life... screw that if you can!)

I'm not sure that that is the problem. The Munger deletes the wave starter which triggers everything the first time. The reason it does this is so that the action list that randomly chooses this wave can't then try to select it again. The Munger stops there.

The problem has something to do with the Platoon and Platoon Movement actions. When the group dies and respawns (which happens flawlessly everytime,) they just stand there because the Platoon action believes the Platoon Movement was already completed (in a past life, so to speak.) Why is that happening?

In regards to Edit 1: Noted, I shall do so

In regards to Edit 2: this is the sloppiest script I've ever put together. Normally my nomenclature is very clear, I just threw this together a bit too fast as I am trying a hundred new techniques all at once. My bad =P

Check Edit 3. Are you _sure?_ you're Munging the starting script and not the platoon itself? I've made dumb mistakes like this a hundred times before. Check, double check, then triple check.

Nevermind, it seems you are, just noted the capslock difference between the names. I think your suspicion is correct, the PLMO has succeeded and deactivated. Tried reactivating the PLMO along with the PLAT on respawn?

I just went into loathing and made absolutley sure. The munger definitely deletes the wave starter, not the platoon itself. I even deleted the munger and set it up again and tested it: it deletes the wave. You can see (even through my crappy labeling) that the starter is all capped, the platoon itself is not.

I would be the first to admit to a mistake like that - I spent about an hour trying to get a group to just PLATOON MOVE ALREADY!!!!!!11!111!! before realizing I had linked the inital squads to the data containers instead of the squads - but, in this case that isn't the mistake it would seem.

The debug log seems to shed light on where the problem is arising: the platoon believes the move has already completed, and so it shuts itself off.


I'll go make a quick test mesh that does nothing but has a wave spawn, pmove, die, repeat and see if i can duplicate the error. Maybe that will shed some light on the problem, though I can't believe that something like this isn't already done on Mazz or some similar map...

You do not need a Munger to get rid of an action from an Action List. When you double click on an action there is a box for "Activates Only Once". So you can even use this so that an Action List only triggers one action at a time when used with the Activates Only One parameter.

Mazz uses no Platoons at all. Instead it uses a bunch of Attack and some Melee actions that make the waves come at the player all the time. It also uses lots and lots of Mungers to switch out monsters. MazzVI v2 can't be opened in Loathing due to some scripting limitations. However, an update is in the works which has the script optimized and can be opened in Loathing. You can find the latest build of MazzVI v4 here.

As for Graydon's suggestion to alter existing template tags. Be advised, Fear does not load addons and therefore shows outdated templates. So editting one of those will override the updated ones found in the Patch 1.7 Templates addon that Loathing does load. If you do desire to alter your templates, it would be best to disassemble the Patch 1.7 Templates into the local folder and then Fear can load them. I suppose you should also keep track of any possible changes to the templates as they have been updated in each of the 1.7.x updates, and the next update will likely have it updated yet again.

@ Graydon: Yes, my first instinct was to reactivate the PLMO along with the PLAT. No effect =/

@ Pyro: Thanks for the tip on the wave lists, I use them EXTENSIVELY in a plug I am working on that pushes the script limit per map to it's limits, so saving a munger for EVERY wave is great news

also @ pyro: I have no idea about anything about templates. Sounds too deep for me, so I don't plan on messing with them.

Also @ both of you: Thanks for your help so far, I'll make that test map and see if I can't make this simple action take place. It is critical to my plug, so I have to keep trying until I figure out how to get a respawning platoon to do it's actions repeatedly.

Edit: I just saw Graydon's Edit4, so I now know what you are talking about. That is potentially useful, but I will heed Pyro's warnings. Here is the reason:

First off, Graydon, I don't mind that it is a tutorial, I absolutely defer to you and the other masters here. The help you guys have provided over the years now has been both deeply appreciated and massively helpful, so thank you and tahnk you again (you too, Pyro. that necromancer has seen about 17 re-revisions. I think I may have him working finally! and the script is MUCH more graceful.)

Normally, Graydon, I do put the monsters as subjects directly into my squads. However, and you can tell me if I am wrong, I have a good reason in the case of this plug. The meshes are huge AI controlled battles that have a large number of weak, medium, and strong Waves of troops. Each wave have various paths they can follow and such. Also, each wave can vary each time. It may be a squad of thrall, soulless, and a fetch one time, and then the next time be a huge squad of archers, a small squad of ghols, and a dorf mortar hero. The variation in units is easy thanks to a few mungers and action lists. With enough waves and enough variation within them, the battles play out VERY differently each time (they are essentially territories matches.) The player, then, controls only a handful of units which he must decide how to use to best help his team, which is always slightly disadvantaged. By having each group of units in its own container, I use a munger to swap out the units IN that container during a variation, and then automatically my Dark Forces as Subjects gets updated, along with the Squads and Legions associated with that group because they all reference the same container. Tell me if I'm wrong, but I think in this case using data containers for each group of units makes sense, right?

So the mungers contain the units (a subj in the mung?) that will get swapped in the data container? Do you have a lot of data containers?

Yeah, like this:

*****Light Action List TWO***** [Action List]
initially_active
deactivates_on_execution
30.00, 120.00
{
Actions to Activate
BASE DISRUPTORS
AMY'S THRALL
Random Selection Flag
true
Activates on Failure
=====LIGHT TACTICS=====
}

BASE DISRUPTORS
{
Activates on Trigger
*****Light Action List TWO*****
Which Wave?
}

Which Wave? [Action List]
deactivates_on_execution
30.00, 120.00
{
Actions to Activate
Switch to Warriors
Activate Wave
Random Selection Flag
true
}

Switch to Warriors [Munger]
deactivates_on_trigger
0.00, 0.00
{
Replace Parameters
Base Disruptors
(subj, monster_identifier)
10655 (warrior)
10657 (warrior)
10658 (warrior)
10656 (warrior)
10659 (warrior)
10664 (warrior)
10663 (warrior)
10662 (warrior)
10661 (warrior)
10660 (warrior)
10665 (heron guard)
10666 (heron guard)
Activate Actions
Reveal Disruptors
Base Disrupt Platoon
}

Activate Wave [Action List]
deactivates_on_execution
30.00, 120.00
{
Actions to Activate
Reveal Disruptors
Base Disrupt Platoon
}

Reveal Disruptors [Unit Control]
deactivates_on_trigger
0.00, 0.00
{
Visible Flag
true
Link
Base Disruptors
Ignores User Control Flag
true
}

Base Disrupt Platoon [Platoon]
deactivates_never
0.00, 0.00
{
Initial State
Base Disrupt Left Flank Loop
Initial Squads
Base Disrupt Squad
Centerpoint
103.645, 189.163
Facing
266.48
}

Base Disruptors
{
(subj, monster_identifier)
10454 (thrall)
10449 (thrall)
10444 (thrall)
10455 (thrall)
10446 (thrall)
10445 (thrall)
10450 (thrall)
10451 (thrall)
10456 (thrall)
10457 (thrall)
10452 (thrall)
10447 (thrall)
10448 (thrall)
10453 (thrall)
10458 (thrall)
}

Base Disrupt Squad [Squad]
deactivates_on_trigger
0.00, 0.00
{
Facing
0.00
Centerpoint
103.751, 189.487
Formation
2
Link
Base Disruptors
}

Base Disrupt Left Flank Loop [Platoon Movement]
deactivates_on_trigger
0.00, 0.00
{
Waypoints
125.342, 200.739
144.831, 200.432
150.235, 186.278
166.934, 186.963
178.715, 172.213
174.672, 156.563
172.372, 137.801
171.956, 115.379
174.208, 96.501
169.422, 80.733
168.233, 69.672
146.956, 67.174
143.915, 57.038
145.475, 28.245
136.022, 21.430
117.274, 31.911
97.198, 34.215
Waypoint Radii
Radii
10.001
20.000
Loop Flag
}

{}-----------------------------------------------------------------

That is a very simple set up, but it can go even further. Now that that is all set up, all have to do is create one new munger per variation and plug it in. I could set up another level of munger that chooses different paths, too. This seems silly when it is a wave of a single squad of melee units marching along the left flank, but for instance that center platoon, with three squads that enter into a legion... I could have a huge variation of troop types marching all over the map and setting up camp...all with just a few extra mungers. And if they are respawning, that means a huge amount of troops and variation at the cost of just a few map actions.

In regards to your question, yes I have many, many data containers. For every squad on the map I have a matching data container that is linked to by the Subject List (so I can check for territories captures, among other things.) It is also linked to by the squad it is a part of, as well as any legions, guards, or harass actions it may enter into. Unless I am missing something, it is easier to update that one data container with a new monster list, rather than mungering ALL of those things that that container is linked to.


P.S., that respawning platoon still refuses to budge if it had completed it's platoon move before it died.

I'm pretty sure that either PLAT or PLMO can't be recycled, even with the same units respawned. I'd suggest using either a Movement and then an Attack, or just an Attack as soon as the enemies appear.

If you have a wave of enemies complex enough to require a Platoon in the first place, it probably doesn't make a lot of sense to respawn them. I'm guessing you have a wave consisting of one or two enemy types attacking in a cluster, in which case simpler actions will do fine.

If you do want an identical platoon to appear more than once, it's easier to duplicate the units and the script in Loathing than it is to do what you're trying to do. The only reason you'd want to Munger a platoon to recycle it is if you have so many map actions that adding more will break the engine--that's about 680 map actions, by the way. Just duplicate the script, rename it so there aren't any instances of two actions using the same name, and go through and change the links to old data containers so they use the new units.

To all those interested, I did solve the platoon issue. I doubt this is the best solution, but it works and since I'm mungering stuff anyways it makes sense for my purposes.

When the platoon completes it's move, dies, respawns, and is then told to follow the original move, for some reason the platoon action thinks "You can't possibly want me to do the same action again? I ALREADY DID THAT!!! I'm ignoring you." BUT, if you instead, before the platoon action is reactivated, Munger the platoon move action right back into the initial state - that's right, put the action where it already is in the platoon action - and BAM! it works like a charm.

No idea why. But hey, it's working.

Thanks to Graydon and Pyro who helped me work through it

Oh and A-Red I guess you, too, since you wrote like THE tutorial that taught me how to munger . "What could happen? Maybe nothing. Maybe flying houses."

@A-Red: I really love platoons. I use them whenever I can. I think they look neat and have a lot of potential when you play around with them enough. Moreover, they are the most independent with the least amount of map actions. I can use Moves along with TUNI's and attacks, but it takes a lot of map actions, and i like seeing a platoon of warriors, arcs, and duffs manage to react well enough on their own to a fetch and 10 ghols. I also like that i have basically unlimited waypoints to work with. Most of all, though, like I said this plug is basically a random battle and there is no way for me to predict the situations they'll have to face. Unless I do a whole lot of scripting to give them a lot of different reactions (Fetch nearby? Warlock nearbY? combined power of X or more nearby? react like this, this that and then this) then a move/atta combo leaves them vulnerable. Surprisingly, the platoons have been doing very well in those situations without much micro. They aren't brilliant, but they usually do okay.

That being said, there are waves taht are pure attack/move attack waves, and they are fun in their own way

And to answer your question more directly: the waves that are respawning are the waves that move as a group to the various flags around the map (it is a terries match) and who then establish legions at those flags. I keep them respawning so that throughout the match there is constant conflict at or heading to the critical areas of the map, without needing to program countless waves. I respect your opinion, though, and I think that in most singleplayer levels, you would be quite right!

thanks for everybody's help,
~fildred13

Ah, I see. Yes, if this is for your terries map then I can see why you want to reuse the same platoons instead of duplicating the map actions. I'm pretty impressed by your success.

In fact, you found something I never knew. In the past, I've never been able to recycle PLMOs, and as far as I know nobody else had figured out how to do it either. I believe this is because a PLMO will remember where it was before all the units died, and then when you respawn the units in a different place it gets confused. By Mungering the PLMO back into the action, you must have managed to reset it, so that it would begin the PLMO from the beginning again. Very useful.

I am flattered, but I am here to report an issue.

Upon further testing, I -SORT OF- recycled the PLMO. The units don't follow the waypoints, they just go to the last one. They still react to enemies as if they were a platoon, and they get to the same place in the end, but they don't march along the way points and interpolate and all that jazz. It is like a glorified movement action with one waypoint. Or a dumbed down PLMO. Whichever way you want to look at it.


I just feel like I'm so close, I can figure it out. I'm not giving up yet, though I literally haven't eaten all day as I've tried to do this, so I need to go at dinner, but WHEN I GET BACK... imma try mungering in new waypoints, messing with expiration and deactivation and stuff...I think I can get them to do what I want...I think....