Replies: 5 comments · 14 replies
|
Override line. |
|
In general, the concept of the engine is not designed for multi-mods. I'd rather concentrate my efforts on making the engine more modifiable for a single global mod than introducing support for compatible connection of different mods. |
|
It's just a random idea I had this morning, not something I totally need right now. I think it would be useful for smaller mods which don't try to overhaul half of the game and aren't worth the effort of releasing a new repack. The "main mod author" (for UPU / RPU as example) could just provide a few placeholders which then can be "hooked into" by other mods. No need to directly integrate them (most mod authors wouldn't do this anyways, let's be honest). |
|
Back when I was still modding FO2 I had exactly the same idea about modularity. Yes, the original engine is not suited for multi-mods, but sfall IS. They way hook scripts and global scripts are made - they support multiple smaller mods working together. So I wouldn't simply brush this discussion aside as "non important". If you want to focus on one large mod - that's fine, but don't assume everyone has the same goal. |
|
I'm all pro multi mod, but I don't quite understand the idea yet. |
|
Main mod has placeholder scripts, protos, etc that can be used (overwritten) by other mods. It's really that simple. You can already do it now, but it's not very practical, because then the sub-mod still has to constantly update certain files if the main mod changes something and it is pretty much impossible to keep compatibility with other smaller mods. See it as odd hooks or something that can be used by other mods. With my above stated idea, it would - for example - be possible to add new NPC scripts and dialogues into the main mod without having to actually touch the main mod. You just use one of the placeholder scripts and variables. I'm not saying this is the best idea ever, but it could be suitable for smaller things, which then - if the mod makers don't all use the same placeholders - would remain compatible to each other. However, considering the Fo2 modding community is pretty much just us at this point, it's also a matter of "is it really worth it" -- I can't answer that question. |
|
What exactly bothers you, adding entries to scripts.lst? scrname.msg? Creating a bunch of scrips that include a common template?
when is that? |
|
Isn't current |
|
это не глобальный скрипт, чтобы он имел "gl" префикс, и такие вещи желательно дифференцировать. |
|
I'm not saying the new script should start wit |
такие вещи желательно дифференцировать. |
|
Что от чего дифференцировать-то? |
|
This idea sounds very useful. I remember years ago thinking about different solutions to this a lot. Will need some hackery though, as the concept of LST files is so deeply integrated with the engine. |
|
See my idea from this issue, it covers scripts as well as all other assets that use LST indexing: #289 (comment) |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I just realized, this is probably something that is better suited for the new "discussions" than the issue tickets...
Random idea for a bit better mod compatibility: (if gl scripts can't be used) Can't we do something like a new lookup table that basically says "script name ModXScpt.int is line 50 in scripts.lst"?
Example of Use:
We are adding a placeholder script entry to MainMod's script.lst file
test.int ; Reserved for ModX- it is on line 50.MainMod could have 100 or more of such placeholders as reserved for other mods.
Then in Fallout2\mods\ModX\ folder we have a new file called ModScripts.ini that says ...
Script01=50|ModXScpt.int... which is the supposed line number of the script, and the script name.
Then, when booting up the game with MainMod and ModX together, the
ModScripts.inifile will be read and automatically assigns ModXScpt.int file to the line number 50 of MainMod.Is a bit complicated, but would enhance compatibility, imo. Just a random thought I had when thinking about overriding scrname.msg ... The NPC / Object / Whatever with the new script attached could then be spawned via global script and we wouldn't even have to touch map files.
All reactions