tain.totalcodex.net

Got a funky little error, and though I see a workaround I hope someone can offer a better one.

So I did basically as Pyro said. Reset the container actions, test each flag for lights and darks using a series of TUNI's and for each SUCCESS, run ADD LIGHT POINT or ADD DARK POINT, as appropriate. I put a light warrior at every flag and debugged. The TUNI's detect the units just fine, but only the LAST one runs the ADD LIGHT POINT as it is supposed to on success. They are succeeding, they are detecting the one unit just fine, but they only activate the ADD LIGHT POINT action once, and it is the final TUNI. I looked at the TUNI's, they are carbon copies of one another so it isn't some typo on my part.

Why is this happening? I know I can just create duplicates of the ADD LIGHT POINT action for each flag, but that is terribly wasteful. ???

EDIT: Further weirdness. I tried putting the ADD LIGHT POINT and ADD DARK POINT actions ABOVE the TUNI's for shits and giggles. I got shits. The ADD LIGHT POINT action runs even before anything calls it? It is NOT initially active. The last TUNI DOESN'T successfully call it, it just runs no matter what, even though it isn't active? Not to mention, the ADD DARK POINT action which is a carbon copy of the ADD LIGHT POINT action and is right next to it doesn't get called? Wtf?

Can you export the scripting and upload that text file for me to see? You can upload it as an attachment in your post. You can private message it to me if you prefer.

its best if it is in the public sphere. Someday this may help someone. The Endgame stuff is right at the top, just after sounds stuff, easy to find.

Okay I see the problem. The way the script system works doesn't allow you to activate the same action while it is running. Open up all those TUNIs and add a delay of 0.07 to 0.07 and it should work. That seems to be the smallest value it allows other than 0.0 which is why I went with that number.

Also, while it doesn't seem to cause any trouble that I can spot, your Mungers shouldn't have "Activates on Execution/Success/Failure" type of parameters. The reason is that they get triggered after that Munger. So after it replaced the parameter as you wanted, it then triggered what was in that parameter. Which if you take a look at the log shows up as twice.

Next time you want a Munger to replace those types of parameters do the following. Have the action with the parameter activate an Action List that activates what you want. An example will be easier to understand:

ACLI.Next Step
Actions to Activate
MATH.All Flags Taken By Light?

TUNI.LF Have C Flag?
(a bunch of params)
Activates on Execution
ACLI.Next Step

MUNG.Time's Up?
Replace Parameters
ACLI.Next Step
action_identifier acti
MATH.Did Light Win?

This way the Action List's "Actions to Activate" parameter is altered.

EDIT: Actually after talking to Melekor about the issue and possible work arounds, the Lock MA was explained to me. I don't have enough time to post it now, but tomorrow I will explain another way to do the above using the Lock MA with a few less actions and less delays. The above will work of course if you rather go with that.

Putting the delay in worked perfectly, thanks!

As for the munger, yeah I just forgot to munger an ACLI rather than an activates on execution directly. Your solution is waht I normally do, if you looked at other mungers in my code, I just forgot there. That's what I get for taking long breaks from working on mything! I'm curious though, what is this "other" solution? I always love hearing about new ways to do things, if you have the time to explain it.

Unrelated question, but related to making code graceful (sort of.) 1.) is there a limit to the number of INVISIBLE units on a map? I don't think there is, but I wanted to be sure. 2.) Is it possible to change a unit's type using a map action? If I have a group on invisible bonemen sitting around on the battlefield, can I suddenly turn them into soulless, and then make them appear per usual but, hey, now they're souless? Im about to look at Mazz which I think MIGHT do it since there are so many repetitive waves, but I'm curious if anyone just knows so I don't have to dig.

Thanks again!
~fildred13

There is no simple action to replace a group of units from one type to another. Mazz doesn't do this, it just has a lot of invisible waves to call upon. As for the limit of invisible units, I don't know what the limit is, but it is something really high (thousands or tens of thousands maybe). If you load up Mazz in Loathing you will see it has a lot of invisible enemies. Even if you somehow reached or was about to reach the limit, you can use respawning to make use of the units you already have to make more.

You could however, make a script that grabs one boneman and use the Move Marker (MOMA) action to place a random soulless in that spot. So you would need a GEOM to look for a random boneman to get it as a "subj" and its location as a "dest". Then a CTRL to make it invisible which is where the "subj" comes into play. A 2nd GEOM to grab a random soulless and send that 2nd "subj" to the MOMA. The MOMA with the "dest" of the boneman and the "subj" of the soulless will place it in the spot the boneman was located. You will need both the boneman and the soulless to have been visible as some point before MOMAing them. So you can use a CTRL to make them visible and another CTRL to make them invisible right after the other. This way you don't even spot them as it happened very quickly, if that mattered. You'd have to do that for every boneman you wanted to replace.

Another option would be to just have a soulless wave you can MOMA as a whole to a spot within the boneman group. This won't get you an exact one for one exchange in the same places but will get you a group replaced a lot easier.

////////////////////

As for the other method to go about your flag testing, you can use the Lock map action. You create a Lock action which I will call "Light Tests" with the "Keys" parameter having the 5 different TUNIs for the Light team being near the 5 flags. (You won't need a delay of 0.07 for this method to work, so you can use 0.0.) The "Actions to Activate" parameter will have the "Add Light Point" Math action 5 times. The "Actions to Deactivate" parameter will have a slightly different version of the Math action except using subtraction. So let's call it the "Subtract Light Point" Math action. You will have that listed 5 times.

When the Lock MA is triggered, it runs those 5 TUNIs all at once. If the 1st action in the "Keys" succeeds, it activates the 1st action listed in the "Actions to Activate" parameter. If the 3rd succeeds, then the 3rd matching is activated and so on. Add a custom parameter to the Lock MA as the type being "action_identifier" with the name/id of the param being "___5" (that is 3 underscores). In this parameter add "Light Victory". What this param will do is trigger whatever is in it when all 5 keys have succeeded. You can replace the 5 with any number between 0 to 8. The Lock MA has a limit of 8 "keys". (These "___x" params have a limit of holding up to 2 actions each.)

Using this method will not require resetting the points of each team. Say 3 keys have succeeded and the Lock action is triggered again. If those same 3 keys succeed again, there is no change with the Lock MA. It will act as if nothing changed. Say one of those actions that had succeeded is now failing. Then the "Actions to Deactive" that matches that key is activated. Since its a subtract Math MA, it will adjust the score as it should.

So you have 2 Lock MAs. One for Light tests and one for Dark tests. You can have them run in series if you like so that it is Light then Dark then Light, etc. with their "___5" param for their victory actions. After the map's time is up and it must go into sudden death mode, you can have the Munger add/replace a "___3" param so that which ever Lock MA reaches 3 first wins. You can leave the "___5" in there as that is still higher than 3. With this method you dont even need any Math MAs, in fact you could probably use some dummy actions instead of adding and subtracting to a container you aren't even using. The Lock MA will know when you have enough keys to trigger whatever is in the "___x" params.

I thought so, I just wanted to make sure before I did anything. Basically my waves choose different unit sets each time it spawns, and that is as simple as creating ONE munger that replaces a bunch of parameters with the new unit containers. Since the waves always respawn in the same spot from invisible, I don't have to worrying about MOMAing.

The lock stuff is interesting! IF I start to run into MA limits I'll give it a go, since I think that will definitely save MA, if not MA params. Looks like when it comes to making code graceful it just took a few months to boil it down to the simplest possible calculation!

I have a question about MA params. Is it documented what makes them go up and down? It seems to me to be everything you TYPE within a Map action, like integers, param names, etc? Other thing I noticed: in loathing my MA params is at like 38000. In game when i use shift-pgdwn tho it is like 42000. Any idea why? Just curious.

Even the names of the actions will make the MA params size to up, so try not to make each action have really long names. Yes, adding more parameters and adding more elements to those parameters will increase the params size. I don't know how it gets calculated since some will take up more than others.

For example, in Mazz the scripting was getting to close to the max. I made an none/empty action that had the parameters for the Unit Control actions used in the script. These were "Visible Flag" and "Tain Visibility Flag" parameters into that one none action. Then for all the CTRLs using these parameters I added the "Link" parameter pointing to that action. This freed up a nice chunk of the MA params size. Doing this is only good for scripts that will have a lot of a specific action. Not all parameters will work if linked in this way.

As for why the limit was higher in game. The scripting has the ability to create new parameters (like when a GEOM finds results and adds them somewhere). If you have units on the map that have a map action linked to them through its monster tag in Fear that could also increase it in game. Examples of these would be units with Chicken, Deer, Peasant, and Soaring linked to them.

an invisible monster will take up an Object mesh limit, just like scenery, projectiles, etc. This limit is about 8000, so theoretically you could have upwards of 7000 invisible units, but that would leave you no room for scenery, body parts or attacks.

hahahahaha yeahhhh i dont think I'll be getting anywhere near 8192. Maybe...4000....on a good day.