Fallout Tactics utility FTSE - Fallout Tactics Scripting Engine (0.56a)

Jucd said:
An issue I experienced during the Kansas City mission was that the burst weapon using SMs would not move closer. They would shoot from maximum distance, only hitting their pipe wielding SM allies and not making a real impact on the difficulty of that mission.
Click to expand...
Interesting. Full disclosure - the same lack of free time that makes FTSE development take longer also means that my latest playthrough is also stalled - my team has been waiting in Bunker Beta to start the Quincy mission since 2018. So I haven't really seen how the burst fix behaves in later missions.

Jucd said:
Is this possibly an issue with applying FTSE during a FT 1.27 campaign save, an unintended side effect of the burst fix, or something else?
Click to expand...

I don't think it's the first point - FTSE doesn't (yet) persist anything in the save file, so I wouldn't expect there to be an issue with existing vs. new saves.

It likely is an unintended side effect. I don't think the AI itself should be impacted - from what I recall, the AI only used the regular chance-to-hit code when deciding what to do, so the FTSE override of the burst secondary hits shouldn't influence the AI decision making. My speculation (very unproven) is that it may be an issue of game balance for this mission - the playtesters would have done this mission with the original burst behavior in place, so the mutants may have always been firing from beyond their effective range, but because of the burst bug they may have been scoring more hits than they should have, so the difficulty may have seemed right. One way to determine this would be to play through the mission the same way with and without the FTSE (or original) burst bug fixes, and keep track of where the mutants are when they open fire. If they always fire from about the same range, but score more hits without the burst bug fixes, then this may be the explanation. If the mutants consistently fire from longer range with FTSE, then it probably is an effect of the burst fix on the AI, which I could then try to track down and tweak.
 
Melindil said:
I don't think it's the first point - FTSE doesn't (yet) persist anything in the save file, so I wouldn't expect there to be an issue with existing vs. new saves.

It likely is an unintended side effect. I don't think the AI itself should be impacted - from what I recall, the AI only used the regular chance-to-hit code when deciding what to do, so the FTSE override of the burst secondary hits shouldn't influence the AI decision making. My speculation (very unproven) is that it may be an issue of game balance for this mission - the playtesters would have done this mission with the original burst behavior in place, so the mutants may have always been firing from beyond their effective range, but because of the burst bug they may have been scoring more hits than they should have, so the difficulty may have seemed right. One way to determine this would be to play through the mission the same way with and without the FTSE (or original) burst bug fixes, and keep track of where the mutants are when they open fire. If they always fire from about the same range, but score more hits without the burst bug fixes, then this may be the explanation. If the mutants consistently fire from longer range with FTSE, then it probably is an effect of the burst fix on the AI, which I could then try to track down and tweak.
Click to expand...

Good suggestion on comparing with or without FTSE. Without fixes I found that the ghouls died earlier and the heavy weapons SMs advanced further than with fixes. The big guns SMs began firing from a similar location with and without FTSE. Checking the extracted mission files was incredibly frustrating. The waypoints seem to be poorly planned so that the melee units would always be bunched in front of the ranged units. I would agree with your assessment of the mission being "balanced" around the burst bug and relying on the big guns SMs to whittle down the melee SMs during their advance.

Also, using FTTools to look at the extracted Entities/Actors/Mutants .ent files shows the SM with big guns only have 7 AP and 200 rounds. That's a burst and a reload and probably another reason they take so long to move forward.

Thanks for the input :)
 
Immense thanks to you @Melindil for your hard work on FTSE! It helped me immensely to realise my 2.0 version of The Sum! :D I have so much fun to play with lua codes.

I have a small question :)

I'm attempting to add a simple function to deal with those weapons that are fragile and breaks while being used, but I don't want them to break every single time. I would like to change them from being destroyed instantly (set in the entity editor) to have a XX% chance of being destroyed, and sometimes leave an item, like the glass bottle could leave broken glass upon destruction.

I understand that the VTable "ApplyAttackResultToEntity (param1)" and its CombatMessage table could be used by me to program this, but how would I define and use this CombatMessage table? Let's say I created a function similar to the VTable 83 (OnEntityUse), how can I access and play with the CombatMessage table?
Code: 
function OnEntityUse(ent,e,target)


end

Would it be similar to this?

Code: 
function OnAttack(CombatMessage)

  if CombatMessage[weapon]:GetName() == "Broken glass" then

  end

end
 
nadeauhugo said:
I'm attempting to add a simple function to deal with those weapons that are fragile and breaks while being used, but I don't want them to break every single time. I would like to change them from being destroyed instantly (set in the entity editor) to have a XX% chance of being destroyed, and sometimes leave an item, like the glass bottle could leave broken glass upon destruction.

I understand that the VTable "ApplyAttackResultToEntity (param1)" and its CombatMessage table could be used by me to program this, but how would I define and use this CombatMessage table? Let's say I created a function similar to the VTable 83 (OnEntityUse), how can I access and play with the CombatMessage table?
Click to expand...
I think something similar to the example you gave should work, but I can't currently sit down and test to be sure. What happens if you add a log message as the sample code for your example case? Does it get printed at the right time?

Actually destroying and replacing the object may be tricky. I haven't gone through the full process for how a CombatMessage is fully resolved, but I know there are at least three steps:

1. The ApplyAttackResultToEntity vtable function will damage the target, apply critical effects, etc.

2. The ResolveCombatMessageForAttacker vtable function will update the attacker entity based on the combat event. This does things like use ammo and deduct AP. (The fact that these two steps are separate is very likely what causes the mode-switch bug; e.g. switching mode while firing allowing a burst attack to use 1 ammo and less AP. But I still need to really walk through these two to find exactly why and how that occurs.)

3. Somewhere I haven't found yet, the CombatMessage struct is used to build out the message that goes to the combat log.

The trick is, if the weapon entity is destroyed at the end of step 1 (e.g. you call the original vtable function first to apply effects to the target, then destroy and recreate the new weapon entity), I don't know how it will impact steps 2 and 3. Best case, it could give a missing weapon name in the combat log. Worst case, it could crash because it expects a weapon in that ID slot and instead finds a null entity. It might be necessary for ApplyAttackResult to flag something in the attacker when the weapon needs to be destroyed, then have a vtable override for ResolveCombatMessageForAttacker actually destroy and replace the weapon (again, probably best to call the original vtable first, to make sure step 2 completes correctly).

If I can somehow find time, I can try to run through the above and see if it works, and if not then maybe come up with another workaround.
 
Melindil said:
I think something similar to the example you gave should work, but I can't currently sit down and test to be sure. What happens if you add a log message as the sample code for your example case? Does it get printed at the right time?

Actually destroying and replacing the object may be tricky. I haven't gone through the full process for how a CombatMessage is fully resolved, but I know there are at least three steps:

1. The ApplyAttackResultToEntity vtable function will damage the target, apply critical effects, etc.

2. The ResolveCombatMessageForAttacker vtable function will update the attacker entity based on the combat event. This does things like use ammo and deduct AP. (The fact that these two steps are separate is very likely what causes the mode-switch bug; e.g. switching mode while firing allowing a burst attack to use 1 ammo and less AP. But I still need to really walk through these two to find exactly why and how that occurs.)

3. Somewhere I haven't found yet, the CombatMessage struct is used to build out the message that goes to the combat log.

The trick is, if the weapon entity is destroyed at the end of step 1 (e.g. you call the original vtable function first to apply effects to the target, then destroy and recreate the new weapon entity), I don't know how it will impact steps 2 and 3. Best case, it could give a missing weapon name in the combat log. Worst case, it could crash because it expects a weapon in that ID slot and instead finds a null entity. It might be necessary for ApplyAttackResult to flag something in the attacker when the weapon needs to be destroyed, then have a vtable override for ResolveCombatMessageForAttacker actually destroy and replace the weapon (again, probably best to call the original vtable first, to make sure step 2 completes correctly).

If I can somehow find time, I can try to run through the above and see if it works, and if not then maybe come up with another workaround.
Click to expand...
Fantastic! can't wait to test this out. And this syntax would be appropriate?

"CombatMessage[weapon]:GetName()"
 
You must log in or register to reply here.
Back
Top