The converter just crashed because it could not find a file, which is odd because the hashlist creator should have found all mission files. I had never encountered such an error before and did not manage to find a fix. I suppose I can try it once again during the weekend with a newer hashlist and hope for the best. I really don't have the time for large-scale debugging.

Yeah, it's for the reinforcement units, which is deprecated. Though I have just noticed that there is another pathway for enemies to be assigned to such a place.

GroupAIStateBesiege:on_cop_jobless assigns an enemy to such a reinforce spot (if it has room) and with various additional requirements. It is only called by CopLogicAttack._chk_exit_attack_logic if the wanted reaction is not "attack" anymore and CopLogicBase.is_obstructed returns true,false which only happens when

if not objective or objective.is_default or (objective.in_place or not objective.nav_seg) and not objective.action

and is_default happens when an objective is done (success or fail). But it should not apply here at all, because the assignment only happens if the enemy happens to stand on the reinforce spot already. And the enemy is never in the attack logic.


Anyway, I would just disable it for good:
And then find the real culprit.

Do you mean the mission scripts? I'll get to it after updating the hashlist (which should be done in an hour or so).

It is 18 m and 58 m.

VR gets *1.3 movement speed for sprinting. The stamina cost is 3 per distance that can be covered in 1 s; which is basically equivalent to the ordinary "cost per s" system.

So e.g. with 50 base stamina and all kinds of other smallish effects, non-VR can sprint for 25 s and cover 5.75*25 m = 143.75 m. VR can sprint for 16.7 s and cover 124.6 m. VR then has 8 s to run the missing 20 m, which easily works out with a speed of 3.5 m/s. Then VR is ~10 m ahead and has fully regenerated stamina whereas non-VR has fully depleted stamina and is already lagging behind.

I don't use Lua for the mission files so my approach is more fundamental, but I don't know if there is not a better function already implemented.

The root of a mission is world.world. It should say world_data.continents_file = "x", which refers to "x.continents". Anyway, I think it is always continents.continents.

continents.continents then has the names of the individual folders in that mission. E.g. if one entry is mt_temp, then there usually is a file "mt_temp/mt_temp.mission" and "mt_temp/mt_temp.continent". There is no guarantee that continents.continents points at valid files only, so you must check for existence. At this point I also filter out editor_only stuff.

The scripts mostly stand on their own, but can interact with each other using ElementExecuteInOtherMission, which behaves the same as a simple MissionScriptElement but its on_executed elements are from another script. The id of each element is unique across scripts of a mission anyway, so this is purely for encapsulation; I personally keep a list of all mission elements mashed together for bookkeeping.

I had tried plain HTML for the mission scripts. It was very ugly and very useless. I'm afraid I haven't looked further into this.

Originally posted by Hassat Hunter:

I was under the presumption Chibi meant the debug lines running during missions, like the XP values given (even if often wrong from actual values) when certain things are supposed to run or rolls fail, that kind of stuff.

Debug messages are already accessible. You just need to enable the console in base.lua of BLT. And BLT saves all the output in the logs folder. But that does not contain every single line of course but only whatever the log function is supposed to print. But adding log functions is usually really simple (except for functions that are not decompiled properly).

Originally posted by The Least Interesting Chibi...:

Additionally, I went back in YaPhyl's depositary (u66) and pretty much nothing has changed in regards to 'tactics'. So... could the unused tactics be something designed for but never implemented?

They have not changed. But so have other things like those dynamic lasers. So that does not mean anything.

Are those tactics not implemented? Yes. They have no effect.

Guys, what the heck?

Originally posted by Hassat Hunter:

I know Deathguard is enemies trying to path to downed teammates in order to prevent them being revived by teammates.

There is more to that, as already mentioned in the guide. Being tased is also a status so it is affected the same as bleedout.

Originally posted by Hassat Hunter:

If you figure out how to do so I would be much interested in having said mod ;)

The Lua hook is probably just as powerful as whatever debug utility they have. (I do realize that James Wilko is responsible for the hook and an Overkill dev.)

What is the debug mode supposed to do anyway? I can turn enemies blind with one line; turn them deaf with another line. That way I am invincible already. I can call managers.groupai:state():set_debug_draw_state(true) to see the enemy groups and their waypoints.

Originally posted by Finale:

Here's the thing- I'm still trying to set up a test with modified values, but we're pretty sure that at least some of these, like shield_cover, are actually working.

shield_cover working? Nope. It's never used; never seen anything like that in the game either.

Originally posted by Finale:

All of the tactics we've been able to find are, according to dev file annotations.

What dev file annotations? If you cannot find something, try http://www.sowsoft.com/search.htm

Originally posted by The Least Interesting Chibi...:

Curious what does tactics_map do?

They just convert the data into an easier-to-use format.

before = {"shield","ranged_fire","provide_support "}
after = {shield = true, ranged_fire = true, provide_support = true}

That way they can check

if after.shield then ... end

(before.shield is nil)

That's because they are never used. The tactics are essentially all handled in the same function. Just figure that out and you are done.

This is the only way that I navigate the Lua files: http://www.sowsoft.com/search.htm

It's just so ridiculous considering that cameras check every 0.1 s. If performance with lots of enemies was an issue, they could make a check every 0.1 s when the alarm has not gone off and 2 s or whatever time afterwards (it does not matter much at that point anyway). But they have never cared about performance or they would not have ramped up the max enemy count several times throughout the years.