Fun with game_event_simulate_battle

Users who are viewing this thread

Since we don't necessarily want to trust the top guy in a stack to be representative of everyone in the stack... can we spawn 100 parties of that template, and then average out the top guy in each stack, and then throw away those stacks?  Is it fast enough to do that (use a disabled flag or something so that they don't trigger anything else)?

Thoughts?

Also - is there really absolutely no facilities in this module system for iterating through the party template tuples directly?

Is there another modder out there with enough experience to answer whether it would be possible to (reasonably) extend the module system code to allow you to do so?

In fact, do the primitives that the module system uses come from python, or are they part of the game engine, or (as I suspect), a combination of both?
 
Mordachai said:
Since we don't necessarily want to trust the top guy in a stack to be representative of everyone in the stack... can we spawn 100 parties of that template, and then average out the top guy in each stack, and then throw away those stacks?  Is it fast enough to do that (use a disabled flag or something so that they don't trigger anything else)?

Why not?

There is no reason to assume they're not representative. Currently normal troops don't get items during the course of the game, so the top unit should be the same as all of them. As far as I know anyway. The difference during combat comes from whether or not they equip items in their inventory, as far as I know. Either way, this is only speculation until you actually run the the tests on the inventory, but I'm pretty sure it works that way.

Spawning 100 parties will not necessarily help (quite apart from slowing the game down since you'd have to do that for conceivably up to 32 different unit types per party, in battles involving 6-7 parties, that could add up) if units do acquire new items.
 
MartinF said:
Perhaps the constants idea is the way to go.. but it would be a bit complicated and messy since it would be up to the author of the mod to correctly define the units there. Maybe rig something with the item value? You could scan a whole bunch of items using this and then look at item value vs in-game strength. Take out the extremes and then work that out into a formula of sorts. I think armor especially should be considered since that really makes a big difference to unit durability. As for global unit type (infantry/ranged/cavalry), there's troop_is_guarantee_horse and troop_is_guarantee_ranged. While those aren't always used for ranged units, they should be.
I inspected the autoloot code and didn't think it was a good direction.  It's a fine work-around but requires that item values grow in a predictable way.  I've found that in many mods that item values for new and more powerful articles are rarely consistent with the old Native set if they're even consistent with themselves.  You can get around this with some guesswork and hackery like most engineering problems, but it adds a precondition to the system in a place that you might not expect.

I dunno.  It might just be because I've been doing this for too long.  I tend to not trust anything which I can't independently verify myself that requires someone else to get something right :smile:


[quote author=Mordachai]
Since we don't necessarily want to trust the top guy in a stack to be representative of everyone in the stack... can we spawn 100 parties of that template, and then average out the top guy in each stack, and then throw away those stacks?  Is it fast enough to do that (use a disabled flag or something so that they don't trigger anything else)?
[/quote]
You could probably do this at startup where the cost woudn't be as noticeable.  This is most likely the least intrusive solution.

[quote author=Mordachai]
Also - is there really absolutely no facilities in this module system for iterating through the party template tuples directly?
[/quote]
I've taken up the hobby of spellunking in the operations header source which lists out all the functions available in script.  If it's there, I haven't been able to identify it.

[quote author=Mordachai]
Is there another modder out there with enough experience to answer whether it would be possible to (reasonably) extend the module system code to allow you to do so?

In fact, do the primitives that the module system uses come from python, or are they part of the game engine, or (as I suspect), a combination of both?
[/quote]
I'll let someone else field this one for real, but IMO, the simplest thing is probably to hack up the compiling process and add whatever data you need at that point. 

I think each primitive is a part of the executable.  I haven't seen anything in the python code or compilation process to lead me to believe otherwise.  I've been poking around in there a bit.

> Edited for clarity and because I probably like the world "probably" too much.
 
You really don't need to know what every soldier is carrying. Trying to factor each individual into a battle that can contain upwards of a thousand (this is auto-resolve, there's no reinforcements here) will just bog the game down to all hell and may end up crashing it. It's a far better solution to assign properties like "Mounted", "Archer", "Pike", etc. and go from there. If you can find the damage values and armor values of their equipment then great, that's more detail at little cost to the engine. But if you can't, it's not the end of the world.

The key thing here is to take that giant blob that's in my current model (I can post it if anyone wants to see the math) and divide it up into as many smaller blobs as possible. If there's some way to identify heroes or the party leader, maybe tactics can be factored in a roundabout way, but it'd probably be just as well to use it as a check against the other party's leader and give a slight advantage.
 
Kon Ichikawa said:
You really don't need to know what every soldier is carrying. Trying to factor each individual into a battle that can contain upwards of a thousand (this is auto-resolve, there's no reinforcements here) will just bog the game down to all hell and may end up crashing it. It's a far better solution to assign properties like "Mounted", "Archer", "Pike", etc. and go from there. If you can find the damage values and armor values of their equipment then great, that's more detail at little cost to the engine. But if you can't, it's not the end of the world.

The key thing here is to take that giant blob that's in my current model (I can post it if anyone wants to see the math) and divide it up into as many smaller blobs as possible. If there's some way to identify heroes or the party leader, maybe tactics can be factored in a roundabout way, but it'd probably be just as well to use it as a check against the other party's leader and give a slight advantage.

While I generally agree with that, I think you do underestimate the influence of armor and such. With native it won't make much difference since their troops are fairly consistent.

And if you want to be able to differentiate pikemen from normal infantry (and that is a big deal, when you're giving mounted units more points, after all) you're going to have to scan the inventory anyway, since there's no way to know if a non-mounted, non-ranged unit is any different from another one without doing that.

As stated before by kt0, you could do it at game-start. There are not that many troop types and you can run a script at game-start, similar to what autoloot does for item difficulties, that runs through them and assigns them a slot, say slot_troop_auto_resolve_value. Doing something like that will take the game virtually no time at all.

I agree it's not easy, and perhaps something that can come in a later release of the script, but it does make a big difference imo as it's a large part of the reason that a small group of well equipped units can wipe out 50 peasants without losing a single unit when you're commanding them. At the very least, you can easily factor in skills like ironflesh and (more importantly) powerstrike.

And if you could post your model that would be great, I'd love to see it.
 
You can process all the items in troop inventory, distribute them in groups with item_get_type, add skill, stats, proficience, troop type (mounted, ranged), level. Stir and you'll get "troop_strength" and "troop_type".
For example, the mounted troop with guarantee_ranged will be mounted archer; the troop with biggest weapon group = "itp_type_polearm"  will be spearman or similar (x2 damage against cavalry) and the troop with group "itp_type_shield" = 0 will take x2 damage from missile attacks...
 
I just realized something. Instead of starting with a whole and breaking it up, you could just run through each stack of an army calculating how much damage it could potentially do to each stack in the opposing army, multiply it by a random number, and set that to a stack_n+1 value so that you could go through the same with the other army using the original numbers. It'd definitely solve the problem I was facing with non-arbitrary casualty assignment.

*edit*
I'll try to post a white paper on it by Wednesday.
 
Sorry for bringing back old topic, but I found this on searching tool so I don't want to make a new topic. I'm happy with kt0's formula for battle simulated result, but I want to get rig completely, all simulated result for every single battle in my module. I've  done for 'order your troops to charge without you', 'order your troops to join attack without you', and 'order your troop to join siege without you' menus. All's done by death cam. I use mission template for normal battle, giving the player invisible armor, and kill him instantly when the mission start.
But I am in trouble with "game_event_simulate_battle" script. I guess this script's responsible for battle between 2 AI sides. I notice the script's called every hour until one side's destroyed. The params for the script are ":root_attacker_party" and ":root_defender_party". How can I retrieve the parties included in the war from both params? Any idea?
Thanks before.
 
Back
Top Bottom