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

nadeauhugo said:
Hi!

Another feature that could be awsome to add to the list... The "variable remote control". Clearly, one can use a detonator ingame to send some number id and start an explosion. Any detonator will work doing so.

What if a detonator code could be catch by the LUA code and flag a variable? That will make the detonator be a remote control to enable many many great functionalities...
Click to expand...
That would be a great idea. It would be great to have items you can use to trigger scripts as in the old Fallout, and Fallout 2.

Another great addition would be a function to advance time by minutes, hours, days, etc.
 
Another problem I experienced using FTSE Melindil: When I add accents "éàù..." using world:CombatLog, it does not display the message at all. Took me a while to figure that out, but yeah, I'm happy I found the problem. Is there an alternative here I could use? Maybe a locale string could do the trick?
 
Okay, a last thing, after that I'll let you some time to catch up he.

I created a script that allow me to detect some specific types of food being eaten, basically by checking the char different resistances. For example, meat give a temporary 1 min. 500 fire resist for me to detect in the LUA code. I don't mind if this is game breaking as long at it is a hidden bonus.

Using LUA code after, I give or remove specific perks based on what is consumed. Eating human flesh for example will give the "cannibal" perk, a true classic.

My problem is with displaying this in the form of a log entry. It works allright, but the message is duplicated dozen, maybe hundreds of time and I don't know why. Could there be a way to make sure this script is only applied ONCE?

Thanks in advance! Here is my code :

Code: 
--Manger de la viande humaine, CANNIBALE!
  if p:GetAttribute("explodeResist", ACTOR_TABLE_CURRENT) >= 300 and p:GetAttribute("masterThief", ACTOR_TABLE_CURRENT) == 0 then
      p:SetAttribute("masterThief", ACTOR_TABLE_PERM, 1)
      if world:GetCampaignVar("Francais") == "non" then
        p:DisplayMessage("<Cr>And what other choice did I have, eh?<C->")
        world:CombatLog(COMBATLOG_FEW, "<Cr>You ate human flesh, you really did it. And do not feel particularily good about it either<C->")
      else
        p:DisplayMessage("<Cr>Et quel autre choix j'avais, hein?<C->")
        world:CombatLog(COMBATLOG_FEW, "<Cr>Vous mangez de la chair humaine, vous le faites vraiment. Et vous ne vous sentez pas tant bien avec ce geste non plus<C->")
      end
  end
 
All,

Apologies for the long delay - I've had a very hard time finding any free time to work on FTSE. The good news is, the past few days, I've had time to finish what I wanted to add to 0.50a. So it's now available from the links on the first post. As always, treat the initial release as somewhat experimental (e.g. keep multiple save files in case something breaks) until it's had a chance to run for a while.

Full changelog is in the first post of this thread. Major changes are the inclusion of all (known) entity types and functions to access type-specific values from LUA scripts, inventory manipulation and change detection, and (still experimental) support for creating entities from the LUA script. The create entity functionality should currently only be used to generate objects to place in an inventory - there's no facility to place an item within a level yet.

My next task will be to post documentation for the LUA APIs, since I expect them to be more stable now that all entities are covered. There will be one more breaking change coming fairly soon - a replacement for the current practice of using the temporary attribute values of perks to store information from the scripts. I have an idea for a more robust and flexible way to handle this, which will also allow me to patch the ApplyBonus and RemoveBonus to add and remove perks on a temporary basis (this will also allow equipped items to have perk bonuses assigned).

I'll also be answering some of the messages I've missed along the way.
 
Corpse said:
This tool is amazing.
Have been modding this game on and off for many years, and was wondering if it would be possible to override certain entity parameters through this scripting engine.
For example, some settings on weapon entities such as "Spread (Arc)", "DefaultBaseDamage", "Damage Radius","Maximum Range", "Minimum and Maximum damage" (individually rather than as a whole) to be modified according to the ammunition variant used; rather than be defined by the weapon.
This would be useful for shotguns to fire different types of ammo like buckshot, slugs, or explosive rounds.
As it is, I have gotten around by adding different fire modes you select according to the ammo loaded, but this is rather awkward, and doesn't work for NPCs. It would be nice for the game to automatically use the "Cone" spread, when firing buckshot and the "Straight" when firing slugs; not to mention apply modifiers to its range, and individually change minimum and maximum damage (ie. buckshot decreases Maximum range and damages by x percent, or slugs increase it; explosive rounds add a damage radius. etc.)
It would be also nice if the damage done by any explosion was different from that done by the kinetic damage of the projectile, and allowed you to deal more than one type of base damage (normal, energy, fire, etc.)
Take rocket launchers for example; any target hit directly by the rocket, would sustain the full kinetic impact of the projectile, plus the damage of the explosion. Targets within the blast radius, would only get hit by the shockwave, and fragments (if any) depending on the ammo used. HEAT rounds would have very small blast radius as they are shaped charges, but deal more damage to the target; HE rounds on the other hand, would have a much larger blast radius, but the explosion would do less damage.
Anyway, these are just some of my ideas to improve the way weapons are represented in the game.
There are more things I could think of, but will leave it at this for the time being.
Click to expand...

This is a great idea. I'll need to check to see if manipulating the weapon settings will work correctly - from the way the code uses them, I think they will. Unfortunately, I don't yet know if I can change enough in the Ammo entity type to make the new parameters visible in the editor - so it may be a Lua-only feature. But otherwise, I think it is very possible to get this to work.

FatMerc said:
Is it possible to get a version of this that doesn't require .NET or mono. I'm running on wine with Exagear RPG and its been a bi@tc# to get that to work...
Click to expand...

There's a way to do it, but it's a little bit of a manual process. The FTSEInstaller.exe in the Github repo can still apply the patch to the BOS.EXE file - you'd then need to copy over the .DLL and config files manually. If that fails, I can also provide hex changes to modify BOS.EXE directly.

nadeauhugo said:
Another feature that could be awsome to add to the list... The "variable remote control". Clearly, one can use a detonator ingame to send some number id and start an explosion. Any detonator will work doing so.

What if a detonator code could be catch by the LUA code and flag a variable? That will make the detonator be a remote control to enable many many great functionalities...
Click to expand...

This one is already on my to-do list, actually. I want to add a trigger/hook for when any item is used (double-clicked or used from inventory). This could allow custom behavior for anything, not just the remote trigger.

nadeauhugo said:
Another problem I experienced using FTSE Melindil: When I add accents "éàù..." using world:CombatLog, it does not display the message at all. Took me a while to figure that out, but yeah, I'm happy I found the problem. Is there an alternative here I could use? Maybe a locale string could do the trick?
Click to expand...

Question: When you save the FTSE.lua file, do you know what character encoding it is using? FTSE currently expects all strings coming from LUA to be in UTF-8 encoding; it will convert to UTF-16/UCS-2 as necessary.

nadeauhugo said:
Okay, a last thing, after that I'll let you some time to catch up he.

I created a script that allow me to detect some specific types of food being eaten, basically by checking the char different resistances. For example, meat give a temporary 1 min. 500 fire resist for me to detect in the LUA code. I don't mind if this is game breaking as long at it is a hidden bonus.

Using LUA code after, I give or remove specific perks based on what is consumed. Eating human flesh for example will give the "cannibal" perk, a true classic.

My problem is with displaying this in the form of a log entry. It works allright, but the message is duplicated dozen, maybe hundreds of time and I don't know why. Could there be a way to make sure this script is only applied ONCE?
Click to expand...

From your description, it sounds like you've added this in the OnLongTick hook. This hook is called for all entities on a periodic basis, so it's possible that, if you use world:GetPlayer to get the player entity, and do the check without validating that the entity object passed to OnLongTick is actually the player, the script may end up being applied to the player once for every entity in the level. (Note that there is a delay between setting an attribute in PERM and when it is finally reflected in CURRENT, so multiple entities triggering close together may still fire off the log message multiple times even if the PERM value for the perk is set.) If this is the case, you'll want to add something similar to the below to the start of that script:

Code: 
function OnLongTick(ent)
    if ent["id"]==world:GetPlayer()["id"] then
        -- your code here
    end
end

If that still doesn't work, I can take a look at the full script, to see if I see any issue. I also have checking the calculations for PERM to CURRENT on my list.
 
JohnnyCasey said:
So you knew that in order to utilize Sniper perk, one must wield a weapon with proper Range Class. You knew that, but decided not to mention anywhere. You decided to keep that as a secret that only you know.

Then, later when you're making a fix for Sniper perk, again, you decided not to mention anywhere that only a weapon with proper Range Class would be affected by this perk, so that people who downloaded your fix and hoping that Sniper perk would be fixed and work as how it has been in past 2 Fallout games would be hit in the back of their heads by the fact; "Oh by the way, only certain weapons will work with Sniper perk."

What really makes me uncomfortable is the fact that you've known this 'apparently intended feature' all along, and decided to keep it unchanged while you're making your own patch, but while doing so, you also decided to NOT mention it. Like... why? Why did you think that would be a good idea to NOT inform anyone who download your patch that only a certain weapon will work with the perk? Did you conveniently believe that people would know "Oh, this Sniper perk must only work with certain weapons, not all ranged weapons like how it's been in past two games." ?

But that's enough of that.

Yes, you should definitely apply the effect of Sniper perk to ANY ranged weapons, including the ones with 'Short' Range Class. The perk description says "(...) any successful hit in combat with a ranged weapon (...)" - It doesn't specifically says "some of the ranged weapons"

You should also add this info; only certain weapons will be affected by Sniper perk - in the setup file as well. It's an information that everyone who downloads your patch should know. It should be informed, and should not be kept as a secret that only certain individual knows.
Click to expand...
Checked the latest FTSE, still don't have any description regarding this. Is there any reason why?
 
JohnnyCasey said:
Checked the latest FTSE, still don't have any description regarding this. Is there any reason why?
Click to expand...

I'll include details on the existing patches, plus any discoveries inside the BOS code, with the documentation. No ETA on when it'll be done, but it's the next item to work on.
 
Hiho,

I really can't try these new features now hehe because I'll spend days and days modifying items and playing around the possibilities! Amazing new update, you have my thanks!

2/2 for the problems I had too...

Accents : I checked the file encoding and it was in ANSI. I reverted it to UTF-8 and it worked thanks! Because of .txt file specifications I guess, I normally put every .txt file in ANSI because other encoding are turning the accents to goo.

Duplicated log message : Again, that worked. Thanks!

As soon as I can experiment with the new engine, I'll give you a full report.
 
Good job here! I was awaiting that. :D

Please tell me, with the new engine codes and stuff, can we actually use them to heal the main character? Let's say after a chat with a doctor? I pretty sure we can use it to remove temporary poison points, but as for healing I am not sure.

Hugo
 
nadeauhugo said:
Good job here! I was awaiting that. :D

Please tell me, with the new engine codes and stuff, can we actually use them to heal the main character? Let's say after a chat with a doctor? I pretty sure we can use it to remove temporary poison points, but as for healing I am not sure.

Hugo
Click to expand...

Healing and damage I don't have working yet. I did an experiment with manipulating the current HP of actors, and it caused odd issues when the actor was killed. Once I find the in-game code to do damage and healing, I can add functions to call them. Hopefully, if it's a C++ vtable function, I can add the functions to the Entity class, and they'll apply to everything (vehicles, breakable objects, etc.).
 
Wonderful. I'll wait for some updates about that, but for me this is really not an urgent feature to work on. I am way more interested at this point in a way to invent some kind of quest log. What can you tell me about the possibility to update :

1. An item description in items.txt for it to show active quests
2. A locale holotape log in generic_mission.txt for it to show actives quests on double click
3. Any other locale entry in generic_mission.txt, allowing for a world text to be shown

Could any of these be done eventually?
 
nadeauhugo said:
Wonderful. I'll wait for some updates about that, but for me this is really not an urgent feature to work on. I am way more interested at this point in a way to invent some kind of quest log. What can you tell me about the possibility to update :

1. An item description in items.txt for it to show active quests
2. A locale holotape log in generic_mission.txt for it to show actives quests on double click
3. Any other locale entry in generic_mission.txt, allowing for a world text to be shown

Could any of these be done eventually?
Click to expand...

The quickest way to do something like this would be to use a Holotape object with a defined locale string, that is then updated as quests update.

The hookexecutor:AddLocaleString can be used from Lua to edit the text for a locale-defined string. (See the Hulk Smash example for how I used this to get the perk name and description in the game without editing the .text files.) One thing I haven't tried is to call this from outside of OnLocaleLoad - if that works, then the current FTSE can be used to update the holotape text. If not, I can probably add a function to the Holotape entity to update its text, and hold the contents in FTSE memory so that the game just needs a pointer into that.
 
I... think I tried that function as I know it from your example, but I need to make a new test to really make sure it did not work for me. I remember trying this in OnLongTick with no success, but he, let me try it again and I'll come back to you with more solid proof.
 
Do you plan to add fixing of the following bugs to your TODO list? Or some kind of hooks/LUA solution? Thanks
1) Sentry mode bug after changing Player Index
2) Electronic lockpicks
3) # alive in a zone
4) Chems on machinery

Also nobody replied to my FT Improver questions in its thread, so maybe I will try to ask you or modders reading this thread:

I want to go very deep in triggers programming. This thread seems to contain the most detailed info regarding trigger's behaviour (thanks to the jarekfall's analysis of GOTOMISSION trigger). The most important thing for me is:
1) How often is a particular trigger started? Does it depend on types of its actions?
2) I suppose it is not possible to have the same trigger started for the second, third etc time before the previous run have been finished. Is it true?
3) Does "B" (blocking) have a real effect on any other action besides WAIT? Or are they so fast it isn't meaningful? Actions seem to be started one after each other from the list without B so there is a non zero probability of timing problems (e.g. when a sequence of Give Item... actions and checking actions for presence in someones inventory are present there) without checking that the previous has been completed ina separate trigger.
4) I suppose that the sequence of first start of every trigger is defined according to their position in the triggers menu.
5) I wish there exists a good programmer with a plenty of free time to recreate a new triggers editor or to hack the existing one with adding more user comfort for fast moving of triggers by a mouse (at least the standard Windows editing features), not jumping to the first page after deleting/copying one trigger etc. It is really a pain to work with more than 200 triggers for more complex maps.
 
DDTerr said:
Do you plan to add fixing of the following bugs to your TODO list? Or some kind of hooks/LUA solution? Thanks
1) Sentry mode bug after changing Player Index
2) Electronic lockpicks
3) # alive in a zone
4) Chems on machinery
Click to expand...

These are all on my to-do list, though some will take me longer to get to than others. Specifically:

1) I'm pretty sure this is being caused by a lack of an associated SentryAI entity being created whenever an NPC is transitioned to the player's group. In order to fix this properly, I'll need to find and hook the code that switches entities into or out of the group, and add a call to the constructor for SentryAI and properly associate it (need to find the right constructor as well, best bet would be to search for where SentryAI's vtable pointer is referenced in the code). If I find the right constructor, I might experiment with what happens if I check for and add the SentryAI in the OnLongTick hook, or something similar. That could at least be a workaround, though making the change right when the entity changes group would be far cleaner. Longer-term, I may be able to help the opposite direction too, and allow a BaseAI to be constructed, configured, and added whenever an NPC leaves the player's group.

2) I've just been looking into the active secondary skills, and found the routine for locking/unlocking doors. I don't recall seeing anything related to electronic door/lockpick, but I'll read through that area more thoroughly. If I can confirm that there's nothing checking that, it would be pretty simple to just add a patch there to check those flags, fail the attempt if the wrong lock pick type is used, and give a proper status in the log.

3) I haven't done anything with triggers or actions yet, so this one will probably take the longest for me to get to.

4) The next area I'm going to be looking at, after skills, is activating items, including consumables. Can likely add a check to the consumable class to call the target's vtable function identifying living vs non-living Actors, and no-op the consumable if it shows as non-living.

Re: Triggers, that will take me a while to get to. But it's definitely on the list, because some of the fixes/features I'd like to add will depend on having visibility and control of that system.
 
Okay, I'm starting to take a look on your new Engine. Happy to see all this documentation!

Is there a way with it to know the filename or file path of a collectable inventory item? Didn't see anything like this in the docs. What I would like to try with it, would be to use OnInventoryAdd (receiver, item, quantity) to see if a specific filename item is about to be added, and add a specific Tagname item in the inventory if it is not already present. Then OnInventoryRemove (receiver, item, quantity), remove the said tagname. I want to do this because my mod contains hell of a lot of ressource items (wood, mostly, etc.) added directly to the maps, but they automatically lose their tagname when placed on the ground, and I didn't took the DAYS needed to assign the tagnames back manually... Thank you! :D

And, lastly, how to I call the AddInventoryItem function. I saw it somewhere, but can't find it anymore.
 
nadeauhugo said:
Is there a way with it to know the filename or file path of a collectable inventory item? Didn't see anything like this in the docs.
Click to expand...

I'll add this in 0.55, along with any other interesting every-entity information that I can find.

nadeauhugo said:
And, lastly, how to I call the AddInventoryItem function. I saw it somewhere, but can't find it anymore.
Click to expand...

An example would be (assuming "ent" is the entity to give the item to):

Code: 
local newent = world:CreateEntity("entities/items/money/scripBOS.ent", 100)
ent:AddToInventory(newent)

Note that I just now noticed, and fixed, a typo in the docs - I had the wrong name for AddToInventory.
 
Oh yeah, thank you. I'll give these a try when the .55 will be out. That will solve some pretty nasty bugs I have, and simplify many many scripts :D
 
Changelog:
Code: 
0.50a: May 9, 2020

Bug fixes (FTSE):

* Modified the AP value in ActorStatus to properly handle it as a floating point value

Scripting additions/changez:

* Added all remaining entity types (too numerous to list here)
* Added functions to retrieve, add to, and remove from inventory
* Added function to create an entity (non-actor so far)
* Added function to destroy an entity
* Added hooks when items are added to or removed from inventories (Actor, Vehicle, Container)
* Added hook for LUA to control whether items can be equipped/used

0.45a: August 30, 2019

General changes:

* Added a new UI for installing the FTSE.dll loading patch, and selecting hex patches
* Added FTSE_config_base.json and FTSE_base.lua files which contain default changes, so that new installations don't overwrite user customizations
* Changed build properties to lower CPU requirements (should improve compatibility)

Bug fixes (FTSE):

* Fixed burst attack hook to properly remove crouching allies in front of shooter

New hex patches:

* Added hex patch to fix melee/unarmed critical hit bugs (left leg punch bug)
* Added hex patch to fix Bonus H2H Damage perk's 15% bonus
* Added hex patch to fix crash when game runs out of special encounters

Scripting additions/changes:

* Substantial refactoring: Objects passed to Lua scripts now have proper entity hierarchy
* Added the following hooks:
  * OnChanceToHitCalc
  * OnConeAttack
  * OnSprayAttack
  * OnStraightAttack
  * OnRadialAttack
  * OnAreaAttack
  * OnProjectileAttack
  * OnChanceToCritical1
  * OnChanceToCritical2
  * OnCriticalEffect1
  * OnCriticalEffect2
  * OnDamageCalc
* Added the following classes:
  * Actor (significantly updated)
  * Ammo
  * Breakable
  * Collectable
  * StateBreakable
  * Trap
  * Vehicle
  * VehicleWeapon
  * Weapon (significantly updated)
* Added calls to Entity class to use game built-in vtable functions where available/useful


0.32a: November 15, 2018
* Added OnBurstAttack for burst bug fix
* Added hex patch for high-res support (default on)
* Added hex patch for color fixes in encounters (default on)
* Added hex patch to blank starting inventory (default off)
* Disabled hex patch for burst bug (replaced by scripting fix)
0.30a: August 29, 2018
* Added hook + function to add locale strings from Lua script
* Added hook to time calculations, so that scripts can customize (e.g. to change start date)
* Added world:CombatLog to allow scripts to write to combat log
* Added actor::GetField for other actor values (non-attribute)
* Added world:GetPlayer and world:GetSquad
* Added support for getting and setting mission and campaign flags
[/QUOTE]

Hi there when i apply this(version 0.50) and start a new game the game craches instantly even when the instalation is brand new. I think is related to the version(even though in the in game screen says 1.27, the setup that i used was 2.0.0.8 if that means anything)

I got no error installing the patch and it shows in the in game screen. (any inserted fix is causing crach so i think the crach is related to how the patch make the changes)

the only thing i can think of is that maybe the patch needs something else installed(software/dll) to work. Like the FT improver or something. (i don't have improver instaled)

If u can think of something to work around the issue would be greatly apreciated.
 
Last edited:
You must log in or register to reply here.
Back
Top