Mazz VI v3 status?

[pompey]

So CP, it's build 5 now? Anybody have comments from the latest version, plans for the next testing time? I'm intrigued to see where it stands now.

[ChrisP]

Status report, let's see...

I've been trying to release a new beta every week by Monday evening. b06 is virtually complete and I hope to test it Monday night around Midnight Eastern. I'll also probably be looking to test Tuesday night at the same time.

There's a nasty Loathing bug/limitiation that is effectively preventing me from adding new scripting. I now think it is related to the excessive number of units placed on the map, but I am only guessing. At any rate, changes are now limited to tags in Fear and changing parameters on existing scripting. This drastically limits the scope of what can be done, but still, I think a lot of very nice tweaks have been added and the plugin is in good shape.

I am hoping Jagman appears soon and would like to contribute a new spell or two for Mazzarin. Barring that, b07 will probably be a release candidate. I am hoping to have the plugin complete by early August.

[Pyro]

There's a nasty Loathing bug/limitiation that is effectively preventing me from adding new scripting. I now think it is related to the excessive number of units placed on the map, but I am only guessing.

If it really is just some sort of limitation with number of units, there is a way around it. I'm surprised you weren't using this for mazz since its addition back in 1.5 or was it 1.5.1, one of those. The way to allow more units with less placed on the mesh is by using respawning. So you can make wave 1 come at this time and after it dies later on, after wave 8 or something you make this wave 1 visible again.

To do this, just select the units you want. Double click on one. Check the boxes "Respawns" and "Respawn via Script". If you have some of these or non respawnable units using their monster entrance when they are made visible on the map, you can use the box "Use Monster Entrance" located in the same area as the Respawn boxes. That would save you some parameters. If you use respawnable units, you can have less units on the mesh as well as less script for all those units you kept adding. This will give you back a chunk of your script back for new usage.

[ChrisP]

Another late reply, but better than never, I suppose.

Yeah, I'm aware of respawning, but have never wanted to use it for Mazz. I prefer that each and every unit has a unique spawn location so as to mitigate any predictability or repetition. Last thing I want to hear in a game is, "Almost time for the NE Myrk spawn between the two trees again!".

I wanted each wave to feel unique, and not so... scripted and automated. I like to think there's a subtle, but important, distinction between, "How many monsters are there!?" and "How many more times is this same wave going to respawn!?"

Of course, it wouldn't be that bad if I MOMA'ed each wave to several random locations, but I'm cautious with my scripting to the point of superstition, and never trusted MOMAs enough. Since the Mazz script is mostly chained together, if one action bugs, none of the following actions trigger.

I've learned the hard way that what works just fine under normal conditions doesn't always work consistently when you're on a map that tries to max out so many limits. I still don't know why some herons can level and others don't - it's the same script for all of them. And I still recall an inexplicable scripting bug with with the Watcher that drove me absolutely nuts till I came up with a long work around.

So yeah, I'm reluctant to try anything new because I don't have the stomach to find out that it doesn't work as planned. Moreso considering that for the minor benefit of adding a few extra lines of script, I'd have to entirely redo hundreds of existing lines. I would like the project to be done in the next few weeks.

However, were I ever to start on something new that again attempted to be more extravagent than ever seen before in Myth, then yeah, I think some clever use of respawning would be the only way to go.

[Pyro]

Of course, it wouldn't be that bad if I MOMA'ed each wave to several random locations, but I'm cautious with my scripting to the point of superstition, and never trusted MOMAs enough. Since the Mazz script is mostly chained together, if one action bugs, none of the following actions trigger.

MOMAs are easy to use, you wouldn't have any issues with them. As for breaking a chain of actions, maybe design the script so it doesn't break? When I make some sort of chain, I make sure its as foolproof as possible. Sometimes that includes having a parameter to activate the next action if this action fails to work. This wouldn't save you a little bit of script... it will save you a lot (depending on how your script is, I can't see it so I can't say how much a lot would be).

[ChrisP]

This wouldn't save you a little bit of script... it will save you a lot (depending on how your script is, I can't see it so I can't say how much a lot would be).

The part of the script that runs the spawning and attacking is actually very compact as all the waves are Mungered. Only four recycled actions per chain (of waves) run the whole show, but each individual wave requires a MUNG action as well as an action to serve as a link to the wave - and it's the link actions that take up a lot of actions which could theoretically be reduced with respawns and a MOMA.

I don't know how well you can read it in this format, but if you can understand the following segment, you can see how it all works.


Activate next I group pt 1 [Action List]
initially_active
deactivates_on_successful_execution
0.00, 0.00
{
Actions to Activate
Insert I wight 1a
Insert I thrall 2a
Insert I ghol 4a
Insert I styg 5a
Insert I soul 6a
Insert I thrall 7b
Insert I fetch 9b
Insert I styg 11b
Insert I thrall 12c
Insert I soul 13b
/...etc...
Activate Only One
}

group I visable [Unit Control]
deactivates_on_trigger
0.00, 0.00
{
Link
Visible Flag
Tain Visibility Flag
Activates on Success
group I attack!
group I dead?
}

group I attack! [Attack]
no_initial_delay
deactivates_never
7.00, 7.00
{
Link
Attack All Enemies Flag
Attack Nearest Flag
}

group I dead? [Test Unit]
deactivates_on_successful_execution
5.00, 5.00
{
Unit Count Less Than
1
Link
Deactivates On Success
group I attack!
Activates on Success
Activate next I group pt 1
}

Insert I wight 1a [Munger]
activates_only_once, only_initial_delay
deactivates_on_trigger
0.00, 40.00
{
Replace Parameters
group I visable
Link
-- wights 1a --
Replace Parameters
group I attack!
Link
-- wights 1a --
Replace Parameters
group I dead?
Link
-- wights 1a --
Activate Actions
group I visable
}

-- wights 1a --
{
(subj, monster_identifier)
10109 ( M wight)
10099 ( M wight)
10088 ( M wight)
/...etc...

How would you insert MOMA's into this structure to save on actions? Mind you, to keep spawn locations from becoming predictable, each monster type (thrall, ghols...) should have at least four random spawn locations, eight would be better and twelve would be best. However, non-melee waves (wights, locks, fetch) would require less random locations. In any case (and here's the tricky part) monsters of different types shouldn't share the same spawn locations, or else a lot more than 4 to 12 spawn locations would be required. Yes, I realize this is a style thing more than a must, but I think it's the attention to the little stylistic touches that makes Mazz stand apart from its imitations.

These are also very big waves, up to 61 units, that take up a lot of space on the map. When MOMA'd, I imagine a lot of care would have to given that none of the units get stuck on impassible terrain or on top of another unit from a different wave spawning at the same time. Currently, all the unit locations are layered in a way so that getting stuck on one another (and thus immobilized) during a spawn is extremely rare.

Finally, there's an issue where some waves have unique behaviors. It's not shown in the above script, but just to keep things lively, there are special waves, for example, where half the mob attacks the intercepting melee and tanks while the other half goes around to chase softer targets like archers and dwarves. In other words, not all the waves can be "recycled" with the same set of actions.

[Pyro]

Yes, I can read it in that format. Since it is only a portion of the script, I can only give an example that matches with that. For waves that have to die before more of the same type can show up you could do the following.

Instead of having for example "Insert I ghol 4a" and any other ghol waves. You have just one or two (depends) on the actual mesh. You would have less "Insert" actions as well as less Mungering because of it. You would have less containers with the units that waves contain. Using an Action List you can make it pick randomly where the wave should be MOMA'ed. So it randomly picks from whatever number of points you choose to have like 20 or whatever. You won't even run the risk of getting them stuck because units don't stay still after spawning and you can have certain spots for thrall, others for ghols, etc. Basically you can make a point of where they are now and take away most of those units.


So the Inserting Munger would activate to "Setup wave I ghols 1" instead of "group I visible". The munger can also be the one that replaces the Destination of this MOMA.

Setup wave I ghols 1 [Move Marker]
deactivates_on_execution
0.00, 0.00
{
Link
-- ghols 1 --
Destination
::: a munger will add this from a given list:::
Activates on Execution
group I visible
}


So I decided to look into the script of Mazz 5 since there is bound to be some similarities from that and Mazz 6. Here are a few stats of Mazz 5:

Map Actions: 684/1024
MA params size: 55584/65536

Which has 380 map actions for the waves including the unit containers themselves, mungering them, making them visible, making them attack, and checking if they are dead. As well as 170 map actions for smaller waves consisting of units like Myrk giants, Trow, ur-Viles, Maraliths, Liches, Wraiths, ghost morts, Beholders, and Dragons. There is also about 57 map actions for black thrall.

There are 9 sections for the 380 actions for waves. The first section has 38 actions dealing with mungering and the unit containters. This can be reduced to 20 actions using MOMA and respawable units. It can even be reduced to 14 actions if you were to replace all thrall types in this section with just one type. That section uses 4 thrall types. Sections 2, 4, 6, and 8 have mostly ghost dwarves, ghost archers, wights, warlocks, and fetch. These four sections combined have 130 actions for unit containers and mungers alone. Using MOMAs and respawnable units they can be trimmed down to 22 actions.

So in 5 sections combined out of the 9, you can trim out 126 actions. In there place you would add a few actions. Make an Action List per section with a list of new Mungers dedicated to the destinations. So say this section originally had 12 areas it would have its units occupy, you can reuse those same 12 areas and more.

[GodzFire]

I'd check out Mazz 6. It was a big change.

[Pyro]

I'd check out Mazz 6. It was a big change.

Yes naturally there was change... but not everyone can check it out. Loathing crashes if I tried.

[GodzFire]

Yea mine too, I think Chris has a special version :-/

[Graydon]

ChrisP had Myrd build him a special build of Fear and loathing to build the plugin file and tags with, in such a way that users wouldn't be able to extract all the tags, plop them into a local, and read the script to figure out the 'key' to the secret level. This enabled him to only give out the key when the normal Mazz 6 had been beaten on leg.

[ChrisP]

Pyro, thanks much for the explanation. I haven't replied earlier since I went camping the last few days, but I'm intrigued. Soon as I have time to wrap my head around it, I'll probably have another question or two.

[Pyro]

Yeah no rush of course. I did forget to mention... you said about certain special waves where they target the player differently... this can be randomized as well. So that say 10% of the time a wave does this or that.

Another way to do this with respawning but without MOMAs would be to have a bunch of units in each section of each edge. Let us say 16 fetch all spread out to cover the whole edge of the map... all 4 sides. And you only want 4 fetch per wave. Let the script randomly grab 4 and make those visible and attack. This way no MOMA, and it is respawnable and therefore reuseable... plus random.

[ChrisP]

Just a few quick questions for now, Pyro. Again, I'm still rusty and at the moment I don't even have loathing open and am just relying on the generosity of your time.

1. The setup action, or MOMA, happens prior to the visibility control? I have some vague recollection of there being some sort of issue of moving units prior to spawning them. Or am I just remembering incorrectly?

2. Monsters are set to 'respawn via script'. Every time these respawning monsters - or rather the monster_identifier link to them - is mungered into the visible action, they respawn?

3. Do you happen to know how many actions an ACLI with a random flag will reliably run? I seem to remember it being lower than the number of actions it lets you insert.

4. Say I have an action list to spawn, in random order, the same group of ghols three times and the same group of myrms two times, and it looks like this:

Setup Ghols
Setup Ghols
Setup Ghols
Setup Myrms
Setup Myrms

In the action parameters, it is set to 'activate only one' and 'random selection flag'. How do I link to the next action in the script once all five of the "Setup ghols/myrms" are depleted?

Thanks again for your time, Pyro!

[Pyro]

Just a few quick questions for now, Pyro. Again, I'm still rusty and at the moment I don't even have loathing open and am just relying on the generosity of your time.

No problem.

1. The setup action, or MOMA, happens prior to the visibility control? I have some vague recollection of there being some sort of issue of moving units prior to spawning them. Or am I just remembering incorrectly?

You remember correctly. You will need to make units visible and then invisible before MOMA. However if you do that back to back, visible and then invisible, you won't even see the units appear. So this would be part of the setup if you choose to use a MOMA method. You could even make an initial setup set of actions if need be, so that while the player is giving out units you start making groups of units visible and then invisible. This way you don't have to do it once the MOMA-ing begins.

2. Monsters are set to 'respawn via script'. Every time these respawning monsters - or rather the monster_identifier link to them - is mungered into the visible action, they respawn?

If they are marked as respawn via script, this means they will show up each time you make that unit visible via a CTRL. So yes, if mungered into a CTRL to make them visible, they should respawn when the CTRL activated.

3. Do you happen to know how many actions an ACLI with a random flag will reliably run? I seem to remember it being lower than the number of actions it lets you insert.

I am unsure. Perhaps Myrd would know or even check in the code.

4. Say I have an action list to spawn, in random order, the same group of ghols three times and the same group of myrms two times, and it looks like this:

Setup Ghols
Setup Ghols
Setup Ghols
Setup Myrms
Setup Myrms

In the action parameters, it is set to 'activate only one' and 'random selection flag'. How do I link to the next action in the script once all five of the "Setup ghols/myrms" are depleted?

The "Activates on Failure" should do it. If that doesn't then using it with "Inhibitions" will do the trick. I can't recall if an Action List (ACLI) can be made to fail. Some actions will always succeed even if something goes wrong like a CTRL. In a CTRL you can set it to give a proj to a unit but it will always succeed even if the unit is dead or the proj is already gone. Which is why having a CTFL expire on success is the same as on execution for that action. If the ACLI can't fail, or can't fail the same way then Inhibitions can be used to make it fail. It makes the action fail if all the actions in the Inhibitions parameter have succeeded.