Fallout 2 mods compatibility distribution tool

[etast]

Questions (for now) about a multi-mod compatibility tool for the Fallout 2 campaign.

Questions I have about it:

• Am I missing something that makes this a lot more complicated than it seems?
• If I were to write something like this, I'd use python as that's what I know. To be used via command line (like weidu). Would that limit the user base to almost nothing, if you need to install python to use it?
• This would need a reference development platform (e.g. F2 or F2+sfall ?), would that defeat the purpose of aiming for compatibility.
• Does something like this already exist?

General overview: The goal for the tool is easy installation of multiple mods for the F2 campaign on a single install, but using a total conversion as base could be possible, too. The goal is to have any mods distributed with it be compatible with each other.

General approach: instead of replacing any files, extend them and add new files. Use modder prefixes where needed to avoid conflicts.

• Develop a mod with the usual tools, modifying your F2 setup as usual (using modder prefix).
  
• Collect your mod files you want to distribute with the tool.
• For most text files (scripts.lst, maps.txt, *.msg, etc) the tool installs new entries using mapping tables. E.g. if the last entry in target file is "505", the mod wants to add "455", map "455" to "506" (505+1) and keep track of this. Re-apply to the newest unused number for every mod that modifies that file.
  
• For scripts, patching with mapping tables would be needed. Lines would be added mostly at end of a script (as above), but not only there.

A definition first: "mod file" is the file version already including the mod (file to be distributed), "target file" is the file on a system where we want to install the mod.

How it's supposed to work (these are for an npc mod):

* Extend target SCRIPTS.LST
- read latest x lines at bottom of developer mod SCRIPTS.LST
- append these to target SCRIPTS.LSC unchanged (no conflicts if prefixes used)

* Copy + rename critters proto files to target install (or "remap-copy" them using mapping tables)
- read latest line of target critters.lst (e.g. 00000700.pro)
- make a mapping for the mod .pro file (e.g. 00000550.pro) to first available name (00000701.pro)
- append names to critters.lst, using lookup table (e.g. 00000550.pro is added as 00000701.pro, etc)
- copy files from mod critters folder to target critters folder, renaming them according to mapping table
- keep mapping table and use it anywhere .pro files are referenced during installs
# similarly use mapping in any file

* Extend pro_crit.msg
- read new lines from mod file
- adjust numbers with above lookup table (55000 (for proto 550) to 70100, etc)
- append updated lines to target pro_crit.msg

* Extend VAULT13.GAM
- remap-copy new lines from mod file to target file, using first unused number:
- use modder prefix in GVAR names
- save lookup table for GVAR referencing in other mod files (?, I don't know if they are used by name or number)

* New maps
- copy new map files (prefixed names; should lookup_name in MAPS.TXT and area_name in CITY.TXT need to be unique (?))
- extend maps.txt, city.txt, map.msg with "remap-copy" for nubmers and save mapping table

* Dialogue .msg patching
- Copy newly created .msg files, if any (names should use prefix, e.g. XXmynpc1.msg)

* Extend existing .msg files
- adding new lines in existing dialogues:
-- remap-copy new lines from mod .msg file, using sequential numbers starting from highest used (+1) in target .msg file
-- keep mapping table for reference in dialogue script and other mods that modify the same dialogue
- changing existing original F2 lines can break compatibility! (but could be done if desired)

* Dialogue script patching (complicated...)
# ssl files of both mapper scripts (original F2 scripts) and all installed mod scripts would be helpful
# so would be distributed instead of .int files
# mod install-time compiling of incremental scripts needed, so custom header files need to be provided
# (prefix, e.g. zXX-----.h where z is reserved for mods distributed in this way, XX is modder prefix)
- decompile target dialogue script (or use F2 original ssl scripts, incrementally patched by mods)
- include custom headers to script for recompiling
# new options (NOption, etc) would need to have been marked in the mod ssl files somehow (e.g. with some custom "extend_top" or "extend_bottom" comments) for next action
- (existing Nodes adjustment) patch target Nodes by adding mod lines as first or last option after Reply (using mapping tables for new Nodes numbers and .msg lines)
- (new Nodes) remap-copy new Nodes at end
- # in theory multiple mods can adjust the same conversation Node by adding NOpion (etc), as well as add new Nodes; possible to not see all options if many mods add NOptions to the same Node

* Any script patching
- supposedly, similar to dialogue script patching/extending?

* Adding creatures, items
- creating objects with scripts by patching existing map scripts, or adding (or patching) global scripts, instead of replacing .map files

 

[Lexx]

Script and proto ID are baked into maps. If you change the order of scripts or protos, the map will load the wrong files. If you change the order of defined maps, all exit grids will move you to the wrong maps.

Proto ID is also saved inside .pro files, so just renaming files won't do it.

As soon as you change any ID or variable define, all scripts related to that need to be recompiled. If a mod doesn't release its sources, you can already forget about that one.

 

[etast]

Thank you for having a look and pointing things out! And crap, I should have know if it was that easy somebody would have done it already.

A few more questions on the comments. And I'm not arguing with any of is, I'd just like to figure out if some of them can be solved.

"If a mod doesn't release its sources" - The below quesions presume the mods are distributed as source (not compiled) and they are all compiled at install time. The point of such a tool is increased activity by new modders and this should only help. I agree that without sources the whole thing would be pointless.

"Script and proto ID are baked into maps" - that stumps the whole thing... Is it not possible to have a new mod map with no critters and to "create" the critters with a global script upon loading the map, if I could reference the correct .pro files?

"If you change the order of defined maps, all exit grids will move you to the wrong maps." - Wouldn't that be taken care of adjusting the map number for all scripts at install time (the mapping tables mentioned)? E.g., on the target pc the map is number 53 (it was number 40 on yours) but all scripts and files are adjusted to use "53" as well.

"Proto ID is also saved inside .pro files, so just renaming files won't do it." - Would it be possible to hex-edit the PID in .pro files? I mean, is there a file format resource somewhere, something like this?

 

[Lexx]

"Script and proto ID are baked into maps" - that stumps the whole thing... Is it not possible to have a new mod map with no critters and to "create" the critters with a global script upon loading the map, if I could reference the correct .pro files?

Sure, but this is more work and the generic beginner modder will likely not do the additional work.

"If you change the order of defined maps, all exit grids will move you to the wrong maps." - Wouldn't that be taken care of adjusting the map number for all scripts at install time (the mapping tables mentioned)? E.g., on the target pc the map is number 53 (it was number 40 on yours) but all scripts and files are adjusted to use "53" as well.

No, the exit grids of the map need to be edited. This is not related to scripts.

You'd have to convert a map file into txt, then do corrections and then convert the txt back to map. No idea how easy / hard that is.

"Proto ID is also saved inside .pro files, so just renaming files won't do it." - Would it be possible to hex-edit the PID in .pro files? I mean, is there a file format resource somewhere, something like this?

Sure. Can be hexedited, but no idea where the docs are.
/Edit: https://falloutmods.fandom.com/wiki/PRO_File_Format


One more thing: Stuff in .lst files is read / recognized by line number and not filename.

 

[etast]

Thank you, it doesn't seem completely hopeless, so I'll spend some time tinkering and see what happens.

Edit: Ok, it does seem hopeless/pontless.