FT Improver - a way to improve Fallout Tactics

[jarekfall]

I think I recall that Random Encounters had an odd behavior, or that some of the values in the table had debatable effects in the campaign. Maybe that's your bug. Can you describe it a bit more?

It's certainly a different bug because it's only present in new campaign editor. It causes the random force names to be not displayed in the list of random forces and imported incorrectly to the CAM file. I analyzed the random forces section for you and here is its complete description:

Defines single random force definition.
<random_force> section:
1	"<random_force>" - C string, ASCII encoding, section name
2	"2" - C string, ASCII encoding, section's version
3	int CharacterCount - Number of characters in the next character string, not including null terminating character.
4	char ForceType[CharacterCount] - ASCII string, not C string
5	int CharacterCount - Number of characters in the next character string, not including null terminating character.
6	char Alignment[CharacterCount] - ASCII string, not C string, for example: "critter", "bad", "good"
7	int MinCount
8	int MaxCount
9	char Enabled - 1-yes,0-no
10	int EntPathCount - number of paths to entity files
Path definitions:
1	int CharacterCount - Number of characters in the next character string, not including null terminating character.
2	char FilePath[CharacterCount] - ASCII string, not C string
... ; next definitions
11	int LevelDefCount
Table of level definitions. The order of elements must be identical as in FilePath list.
12	int Levels[LevelDefCount]
13	int AppearanceChanceCount
Table of appearance chance definitions. The order of elements must be identical as in FilePath list.
14	int AppearanceChances[AppearanceChanceCount]
15	int NumberOfBytesToNextSection - number of bytes to the next section since beginning of the next field
16	char CD_code - for example: 'A','D','E','Z'. These are probably the letters attached to packed file names, such as: loc-mis_A.bos
End of section.

When I will release FT Improver SDK I will also release the documentation I've created, among others, description of <TriggerManager>, <Trigger>, trigger's action, trigger's condition, <esh> and other sections.

Also thank you for the detailed description about world map movement rates. Recently I've accidentally came across a method in the BOS code that imports campaign world map image data and I noticed a reference to "_move.png" string, my first idea was that it must be related to world map movement rates. I tested it and it works. If you have 24 bit png file with world map image named NAME.png and 24 bit png file with world map mask named NAME_move.png of the same size (mask is an image in grayscale but in 24 bit mode) then you have only to load the NAME.png image into campaign editor and that's all. 100% white pixels in world map mask means that movement rate is highest, the darker are white pixels the slower is the movement rate. 100% black means STOP.

Some new information:
I also found two hardcoded names of triggers. You should know one of this names, it's from the first campaign mission. I will describe them when I will analyze their meaning.

I think that the game has another two editors, currently I'm not able to run them, the method which starts them requires proper context and 8 parameters. Class name is "SquadWindow".

I also know that the game has another two editors. Class name of the first editor is LiveTriggerMenu and the class name of the second is LiveVarMenu. I successfully run them in the context of trigger editor, but they don't work correctly and the game crashes. I think that they should be used during gameplay. The first is probably used to fire a trigger or just to see the list of triggers. The second is used to edit campaign and mission variables.

 

[Vault Maker]

WOW. That's much nicer than inserting the movement map in a hex editor. I just tried it on my speed trials worldmap and it works.

Clarification on importing:
1. You want to have the Worldmap Image and the Movement Rate .png in the same directory.
2. You then use "Import Image" and point it to the Worldmap Image. The Movement Rate .png is imported at the same time automatically.

For the values in the Movement Rate .png, I've only tested with grayscale values. Some observations:
* The 12 lightest values (F3 thru FF) are all no movement
* Palette value of 01 is a rate of about 45 minutes per pixel.
* Palette value of F2 is a rate of about 8 hours per pixel.
* Values in between increase at a fairly constant rate (a few percent each).

Odd bugs I found testing the other day (with only one test run so far):
* Palette values (hex format) ending in 9, 0, and A unexpectedly spike down in travel time by maybe 10% compared to values just before and after. I have other anomalous results as well, but these formed a mostly consistent pattern.
* Using all 256 colors of grayscale for the Movement Rate .png I found the clock "month" display won't flip from November to December. It counts to Nov. 30th fine, then from Nov 1st to 31st, and then flips to January 1.

You can probably avoid the calendar issue by using the palette from BOS.cam's Movement Rate .png. I don't think the spike issue is eliminated by BOS.cam though, since it uses lots of x0 and xA values in the palette. I'll post more testing results on this in the next few days.

 

[jarekfall]

For the values in the Movement Rate .png, I've only tested with grayscale values. Some observations:
* The 12 lightest values (F3 thru FF) are all no movement
* Palette value of 01 is a rate of about 45 minutes per pixel.
* Palette value of F2 is a rate of about 8 hours per pixel.
* Values in between increase at a fairly constant rate (a few percent each).

I assume that these values are RGB colour intensities. If yes then this information is at variance with your own description in this thread (section H.4) and with my current observations about the relation between grayscale colors and movement rates.

 

[Vault Maker]

I assume that these values are RGB colour intensities. If yes then this information is at variance with your own description in this thread (section H.4) and with my current observations about the relation between grayscale colors and movement rates.

No, you and my old tutorial are both right. What I posted above were supposed to be normal grayscale values, 00 meaning 00-00-00 (=black) and FF=white. But, this is what happens when I forget that bitmaps start drawing at the bottom!

I'm still putting together some speed test maps. I did 3 but they are bugged (hopefully not upside down) and

ARGH! I saved them out of Photoshop v.5, and I know that causes issues...like I say in my tutorial...maybe I should read it again...

Ok, correction to my previous post is below:

For the values in the Movement Rate .png, I've only tested with grayscale values. Some observations:
* The 12 darkest values (00 thru 0B) are all no movement
* Palette value of FE is a rate of about 45 minutes per pixel.
* Palette value of 0C is a rate of about 8 hours per pixel.
* Values in between increase at a fairly constant rate (a few percent each).

When I say "per pixel" I mean on the Worldmap Image.

Odd bugs I found testing the other day (with only one test run so far):
* Palette values (hex format) ending in 4, 5, and 6 unexpectedly spike down in travel time by maybe 10% compared to values just before and after. I have other anomalous results as well, but these formed a mostly consistent pattern.
* Using all 256 colors of grayscale for the Movement Rate .png I found the clock "month" display won't flip from November to December. It counts to Nov. 30th fine, then from Nov 1st to 31st, and then flips to January 1.

You can probably avoid the calendar issue by using the palette from BOS.cam's Movement Rate .png. I don't think the spike issue is eliminated by BOS.cam though, since it uses lots of x6 values in the palette.

 

[jarekfall]

Is there any way to manipulate game time to implement a time advance trigger?

I've found the timer that controls the absolute virtual game time among other four most important game timers. Game timers don't control the application interface, they are created only at mission loading time and handle all of the game aspects related to time flow.
It was very hard to make sure that I've found the right timer, the only information I had, was a time information displayed in the window with saved game states, I could not see the visual effect of night. However after about 30s I noticed something weird, the game started darkening the light (in some degree) and it was repeating this process at 7s time interval. After about 3 minutes it was completely dark, as should be.
I could not find a variable or method containing time interval that controls the process of darkening, there are tens of methods that make use of the most important timers and have hardcoded time intervals. There are also tens of other timers in different objects that depend on these five most important timers. Of course this is just a matter of time, until I will find this variable or constant, modders can use GOTOMISSION action to reload the map so that the visual effect of night will be instant and to move player's tagged units to the right place on the map they should use MOVEUNIT action. When I will fix the bug related to "SinglePlayerSpawn" entity, modders will be able to move the "SinglePlayerSpawn" object (tag names of units won't be removed), so that entire player team can be put on any place on the map.

By the way, all timers have their time intervals hardcoded, for example absolute game timer which also controls the virtual game timer, has its precision set to 0.07s.

How about game start date, any plans to add a patch that lets you change it?

If I will add a trigger action that changes virtual game time you will be able to increase the time. Currently I don't plan any patch that lets you change the game start date.

And in regards to your suggestion to fix the special encounters; if you get the missing encounter before any others, would it skip to the next encounter or would it keep trying to execute?

It won't be executed from several reasons.

Just thinking if the second is true this would stop your chance of getting any further encounters.

It won't block any of other special encounters. It's inversely, all other special encounters will block the appearance of the missing special encounter and even in case you will find all of the real special encounters.
If you are really interested in the description of this solution, please inform me. I haven't written it here because it's quite a lot of text.

 

[TwoEyedYum]

Oh, nice to see such serious progress! All things that can improve storytelling in mods are good things

By the way, looks like you got deep into bos.exe, so can i ask about some possibilities?
Let's say, some modder wants to disable display of hit chance % (both on cursor and in "aiming" window), and weapon damage in inventory. Is it possible for you to catch these numbers and hide them in one or another way?

 

[jarekfall]

The patching should be easy, but the hacking may be difficult or also easy. I can't say precisely because I've never worked in this area of code and currently have no spare time for testing.

Why would you like to have such patch?
Does this patch have to be permanent or controlled through the game interface?

 

[TwoEyedYum]

Well, as always - russian modding community wants to add MOAR realism by removing those nasty hit chance numbers. And they asked me to ask you about this idea

I realize that you pretty busy for now, and especially I don't want to stop your precious work on trigger patching. Maybe in some distant future...
Simple patch would be enough, but ability to tick box in "Options" to turn on/off all mentioned numbers would be ever more appreciated, as much as more BJ'n'whores

I wish you good luck with your current work, and thank for answer!

 

[jarekfall]

OK, added it to my list of future patches.

 

[TwoEyedYum]

Ah, and also one question, which bothers me for last year (you maybe remember "burst bug" story in my mod's topic). Would be good, if NPC enemies would have minimum limit for shooting at any target. Let's say, 1% instead of 0% (why the hell robots shoot at 0%? What about some robotic-mega-analyzing thing?)

I understand that there may be no "limit value" at all, and that is a reason for NPC to shoot at any chance. But if you ever find such value, please, try to change it! Thanks in advance

 

[jarekfall]

FT Improver v2.0.0.1 has been released. FT Improver v2.0 and all patches have been completely rewritten. FT Improver is now faster and more secure.

Please read the information from "Readme.htm" file to learn what has been changed in current version of FT Improver, it's very important.

Next, I will release FT Improver 2.0 SDK.

 

[Ardanis]

Another request, in addition to dead robots - enable skill requirements on entities. As far as I can tell, only primary stats (STR, INT) are being checked, but skills, as well as tags/traits/perks, are completely ignored.


While I'm here, big thanks for the armor component. It allows for one devious turn of events

 

[jarekfall]

Player skill requirement check in almost all situations must be programmed by a mod maker by using game triggers. Please, specify your request precisely.

 

[Ardanis]

Entity item files, when opened in editor, have a block called 'Requirements'. All weapons have a minimal STR value set there, characters who don't meet that requirement can't use the item (it's redded out if equipped). Entries in that block are not limited to stats, they also include skills, traits, perks, derived values, etc., however anything else besides seven primary stats appears to be ignored by the engine when determining whether a character can use an item.
My request is to enable checks on skill reqs, so that I could, say, forbid to wear Power Armor unless the person has 50% in Piloting skill.

 

[TwoEyedYum]

Yeah, imagine FT, in which you have to purchase special perk (let's say, "Sniper specialization"), before you can use any sniper rifle. Possibility of skill requirements also sounds good.

 

[Corpse]

You did a great job with the last patch, removing the item limitations is letting me add some more varied weaponry for the big robots and gun turrets.

Just wondering if you had any plans to remove other race limitations like climbing or changing stance on future patches.

BTW, would it be possible to make the base and team colors of an armor entity override the color setting on the character entity wearing it? I know is something trivial but thought I would just throw it there in case you wanted to look into it.

 

[jarekfall]

My request is to enable checks on skill reqs, so that I could, say, forbid to wear Power Armor unless the person has 50% in Piloting skill.

OK, added it to my list of future patches. I will also consider TwoEyedYum's suggestion.

Just wondering if you had any plans to remove other race limitations like climbing or changing stance on future patches.

I didn't know about such limitations. I carried a few tests out and noticed the same problem. I think that it should be quite easy to remove these limitations. Which races are you interested in?

BTW, would it be possible to make the base and team colors of an armor entity override the color setting on the character entity wearing it?

Currently can't say precisely because I have never worked on code operating on individual actor entities and their inventory, the same refers to patches for actor skill checking. I think that it shouldn't be very complicated.

 

[Corpse]

Scribe, elder, the citizen races (alpha, thin, medium and vault) and pipboy come to mind for the changing stance and climbing. The deathclaw baby and security robot races could also do just with climbing.

Would it be too much to ask for Windows 98 support?
Reason I ask is my XP machine has so many resources tied up, its a bloody slug compared to my older machine which runs 98.

 

[LinuxLiesLove]

Could we explore the possibility of added special effects? For example making some tile's, which are flagged as shallow water, produce some sort of disturbance when units enter it.

For average bipedal men or women, their foot steps produce small ripples. Further when they step back into dry land they leave behind rich footsteeps for a duration of time.

Similarly, vehicles crossing shallow water would produce a fairly wide disturbance in the water and a procedural timed restlessness in the water.

This may give some advantages to the player to spot enemies in the water.

These ideas call for a level of intricacy that I think would be fair for the game to have given that its roots is primarily tactical and sophisticated rpg-elements would be a more controversial addition anyhow.

 

[Ardanis]

If it's not time-consumable, I would also want to ask to enable items to grant bonus perks while equipped (i.e. power armor gives 1-2 Bonus Move for free).
Theoretically, it may cause a little mess when selecting perks at level-up, but considering that engine only checks for natural stats (not boosted by drugs), I think it may ignore 'equipped' perks too.