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

DDTerr said:
Citing other modding gurus:

1) "When working with tagnames always add the tagname in the level editor and not the entity editor, unless your tagged item or recruit is going to be placed in an inventory, or be available via the Recruit or Quarter Master. Because when you place items or actors etc in the map the field 'tagname', above the entities window, overwrites the tagnames given in the entity editor."

2) "When adding tagged items to an actor's inventory (either an actor, vehicle or container) do so via the level editor as inventories added via the entity editor are not part of the map and tagnames will not be imported."
Click to expand...

This is actually very useful information - it should help me find where in the loading / deserialization process the tag name is set. As a short-term workaround, I could set a custom script point at that process, so that items of a particular type can always have a certain tag name initialized if it doesn't already have one. And later I can try to narrow down where in both the level editor, and in-game, the entity file is read, so that it can override a "blank" tagname in the level entity.
 
Melindil said:
This is actually very useful information - it should help me find where in the loading / deserialization process the tag name is set. As a short-term workaround, I could set a custom script point at that process, so that items of a particular type can always have a certain tag name initialized if it doesn't already have one. And later I can try to narrow down where in both the level editor, and in-game, the entity file is read, so that it can override a "blank" tagname in the level entity.
Click to expand...

Fantastic! This, combined with the hex edit to keep tagnames from being erased, will prevent many in-game bugs from happening... Sad bugs that now happen even if the mod/game has been carefully designed and planned.
 
Desired feature: Empty starting inventory

Modders (incl. me) often want to start the main character with an empty inventory, but FOT fills it with some stuff according to traits choosen.

Workarounds:
1) Renaming of all the auto-inserted ent files (entities) and creating new ones with different names - this needs a lot of work on all maps or start creating mod from scratch not using any previously created content
2) Hex-editing bos.exe to rename path/name strings of all the auto-inserted entities to other ent files or directories where these copies would be unlootable, 0 weight and with no icons
3) Hex-editing bos.exe to zero path/name strings of all the auto-inserted entities, but then the engine may behave strangely if there are no path/file names (i don't know if FOT code tolerates it, ignores it or makes some internal exception for missing files??). First seen on openfm.exe (=bos.exe) of the famous OpenFM mod.

I've tried both 2) and 3) workarounds: offsets 498F04-498F24 (money), 49D494-49DA3E (the rest of items), but it is quite complicated and needs to include the modified exe file in my mod which may violate the FOT copyright.

Recommended fix: it would be nice to have only 1 hex patch done by FTSE to remove the call to that auto-equipping routine or just insert a return command at the beginning of that routine.
 
Last edited:
Yess I support the need of such feature, because the 1) solution is far from perfect, it also creates a bug when any non-lootable object is on the ground somewhere (placed on the ground for let say immersion/decoration purposes). When that happen you can still see the item, take it, but nothing appears in your inventory.
 
Hi! I wonder why these fixes presented by TwoEyedYum have not been added to your scripting engine. Can I enter them in FTSE_config.json manually? Is it because they were not tested or don't work correctly? I noticed that because since I installed the scripting engine I still have random pink / blue ugly colors in random encounters and I there was a fix in that list a while ago : http://www.nma-fallout.com/threads/list-of-hex-based-fixes-changes-in-bos-exe-file.202858/

Also, I experienced another bug that is very anoying to me in random encounters, possibly elsewhere but I don't think so. It appears that many entities inventory are altered, most of the time by duplicated (doubled) items. It looks very ugly as you can find the same item separated in two slots many time in the entity inventory. I think that may have something to do with tagname, as almost all my items have one. In a way, maybe the engine load some of the tagnames, or the first one, but not the rest, so he put the items in different slots. A fix to prevent item tagnames from disappearing in random encounters would probably solve this.

fbos0000.jpg
 
Last edited:
Ah, I missed the color change one. Some of the others I didn't include because they were somewhat optional changes (door open range, music in dialog window), but that one should have been included.

Patches can be added to the FTSE_config.json file, and will take effect on next startup. One caveat - the address of the patch is an in-memory address, rather than an EXE offset address. Because BOS.EXE is loaded at hex address 400000, the address given in the JSON file must be hex 400000 greater than that for a typical hex edit.

For this fix, a proper JSON entry would be:

{
"name": "Encounter color fix",
"apply": "true",
"changes": [
{
"offset": "6ae3f4",
"patch": "33c990"
}
]
},

I'll add this one in the defaults as well for next release.
 
Ah.. I was wondering about the differences in the adresses from one patch to another, thanks for the explanataion, and also for the code. It works fine thanks! Can't wait to see what you will come up with next :D I'll stay tuned.
 
hello @Melindil

This is about set variable hook.

First my script.

Code: 
-- Modifiable functions begin below -----------------

function OnVariableChanged(key,val,campaign)
  
   if campaign ~= true then
       if key == "andy" then
      
           if val == "12" then
               SetMissionVar("umbra", "323")      
           end
      
       end
   end
  
end

In a mission map I would make a trigger with condition Always, but no Preserve, and make the trigger's action to be "set a mission variable".
This way a variable gets set and only once.

I know the variable name from the trigger so I can have LUA check for this variable's name.
In this case it's "andy". I also set the value to "12".

With LUA I proceed to set another variable called "umbra" to a value "323" as a test.

Am I correct in thinking after this point another trigger would find the variable "umbra" as having the value "323"?

IMPORTANT: are the parameters correct and in correct order? I had to guess from reading the source code both function name and parameters.
 
The only issue I see is that SetMissionVar is a member function of the "world" global object, so you need to refer to that object in the call:

SetMissionVar("umbra", "323")

becomes:

world:SetMissionVar("umbra", "323")

Other than that, your script looks correct, and should do as you describe.

And thanks for the reminder - I still haven't finished the documentation for the class member functions. A number of them are present in the examples, but the SetMissionVar and SetCampaignVar weren't included. I'll try to get docs for some of those in the Wiki over the next week.
 
It works! For the record you have to set every variable of interest once using editor's trigger setup before attempt SetMissionVar. Meaning in real time the game must set the var before attempting to use LUA to.

Attached is mission file and lua script for those who want to test!


@Melindil do you think you could add a thread suspending sleep with millisecond resolution to the lua functions?


Or otherwise provide an event like OnGameFrameTick?

afaik MsecToDayHMS isn't actually called at any regular subsecond interval.
The other functions seem to wait a full 10 seconds.
 

Attachments

ItsaMen said:
@Melindil do you think you could add a thread suspending sleep with millisecond resolution to the lua functions?


Or otherwise provide an event like OnGameFrameTick?
Click to expand...

I have a candidate location for a more-frequent timer call, but I need to confirm if it's a per-frame or per-time-interval call (important to know since varying frame/refresh rates will affect timing for the former but not the latter). My notes say it's 250 millisecond resolution, but I don't remember how I checked that.
 
Melindil said:
I have a candidate location for a more-frequent timer call, but I need to confirm if it's a per-frame or per-time-interval call (important to know since varying frame/refresh rates will affect timing for the former but not the latter). My notes say it's 250 millisecond resolution, but I don't remember how I checked that.
Click to expand...

250ms sounds fair. When's the next release?


Could we get a GetEntityByTagName function?
If you don't want to go through the trouble of creating a branch for this right now, you can just post the source code for GetEntityByTagName here.
 
Last edited:
ItsaMen said:
250ms sounds fair. When's the next release?
Click to expand...

I usually time releases around when I have some substantial new functionality. Right now I've been working on putting hooks into the combat calculation routines - determining chance to hit, damage, critical effects, and spread for burst and cone weapon types. Research for all of those is done, and coding for burst attacks (the hardest) is also almost done. But if there are other quick things I can add, that would be useful right away for a mod, I am certainly open to adding them in and running a build.

ItsaMen said:
Could we get a GetEntityByTagName function?
If you don't want to go through the trouble of creating a branch for this right now, you can just post the source code for GetEntityByTagName here.
Click to expand...

That's definitely doable, and not too hard to add - I'll get that in and committed to the Git repo as soon as I'm able. One minor concern is that, to my awareness so far, I don't know of any in-game index for tagnames, so I'll need to scan the full active entities list to find them. This may be a little expensive, so it might have a small performance hit if run repeatedly in a tight loop (probably not too likely for this type of function, though). Also be aware that I don't yet have decoding for entity types other than Actor - this was my next target after the combat mechanics release. You can probably get entityid, name, and position, but not sure how much else.
 
It's good that Actor's properties are accessible. I don't care too much about other entities properties except for:

Getting the object's Script State. (for entities this does not qualify for, just return false)


Also is there a way to enable/disable an entity without it being garbage collected or rendered permanently unusable (atleast within the mission map).
By disabled I mean the game doesn't think the object exists on the map.
 
upload_2018-10-21_16-53-34.png


Hi there! I am still playing a bit with random encounters and really wonder why (despite the hex patch to remove random colors in encounters), I still have really funky wolves colours like yellow and red.. I think I managed to remove red colour dogs from my encounters (with some tweaking with their color in the editor), but no matter what I try with the wolves, it stays this way. Do somebody know why this could be happening? A missing coulour patch hex edit? Most of the other colours seems okay. Thanks in advance!
 
DDTerr said:
Desired feature: Empty starting inventory

I've tried both 2) and 3) workarounds: offsets 498F04-498F24 (money), 49D494-49DA3E (the rest of items), but it is quite complicated and needs to include the modified exe file in my mod which may violate the FOT copyright.
Click to expand...

Hi! So I've seen your offsets and would like to implement them in my current version of FTSE, how can I do that? I am right assuming that we have offsets here for now but no patch adresses yet?
 
nadeauhugo said:
Hi! So I've seen your offsets and would like to implement them in my current version of FTSE, how can I do that? I am right assuming that we have offsets here for now but no patch adresses yet?
Click to expand...

According to my calculations and the modified OpenFM Demo exe file, you should use

1) offset: 898F04, patch = 33x 00 byte
2) offset: 89D494, patch = 1450x 00 byte

Melindil will correct me, if I am wrong, but the proper JSON entry should look something like this:

{
"name": "No starting inventory mod",
"apply": "true",
"changes": [
{
"offset": "898F04",
"patch": "000000000000000000000000000000000000000000000000000000000000000000"
},
{
"offset": "89D494",
"patch": "0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
]
},
 
Oh it seems to work! My god that really changes everything to me. I can now determine starting armor and items for my prefab characters, and they are not dropped into the inventory, but stay in place thanks!!!!!
 
Hi all,

Is the hi-resolution patch on the list of future updates to the Scripting engine? I found myself without it since I started back with the original BOS.exe and finally reinstalled it. Here are the offsets as documented in the patch :

BOS.EXE
offset / original / changed to / asm

B345E / 75 / 7C / jnz -> jl
B3466 / 74 / 7D / je -> jge
254638 / 75 / 7C / jnz -> jl
254640 / 75 / 7C / jnz -> jl
25464C / 75 / 7C / jnz -> jl
254654 / 75 / 7C / jnz -> jl


FT Tools.exe
offset / original / changed to / asm

B0CCE / 75 / 7C / jnz -> jl
B0CD6 / 74 / 7D / je -> jge



offset / original

495A4C / 2F 63 3A 2F 62 6F 73 2E 63 66 67
/c:/bos.cfg

Changed to
62 6F 73 2E 63 66 67 00 00 00
bos.cfg
 
You must log in or register to reply here.
Back
Top