UP and RP updates

burn

A Smooth-Skin
Modder
So I spent some time plowing through RP bug reports and packaged an update. In fact, it turned out that most of the issues were actually related to vanilla/UP, so I decided to package that one too.

As you know, these are not my mods. Both UP and RP are works of many people, most notably killap, but others made significant contributions too. I simply stepped up to do what I could because no one else did.
The reason to name new packages UPU/RPU is to avoid unnnecessary confusion.

There are no plans for RP expansion. The mod is largely complete. Though if you do find something else worth restoring, and willing to do the work yourself, it may be discussed.

What changed
There's about a hundred fixes overall, plus spelling standartization and typo corrections. And a new sfall version with engine fixes brought to us by our sfall overlords. That's on the outside.
On the inside, there's also a lot of changes: various optimizations, some scripts were missing from the published sources, others weren't matching, build scripts were failing etc etc. All that had to be taken care of.
Many fixes were made by @NovaRain, many by me, also there are fixes submitted by other people.
Detailed changelogs: UPU, RPU. (Each RPU version includes fixes from the corresponding UPU version)

How to install
Instructions are in the corresponding readmes: UPU, RPU.
You should not install UP before UPU, or RP before RPU. Both UPU and RPU are complete, self-contained packages.
RPU ships with the same additional mods as RP: Hero Appearance, Party Orders, etc.
UPU doesn't ship the extra mods, but you can download them from github and install manually. They are all compatible with UPU.

Update mid-game
In general, you should be able to update from UP to UPU and from RP to RPU and continue your game. This is untested, however. So take necessary precautions: backups of at least the savegames, and better yet, the entire game directory.

Translations
Both mods ship with various translations. They are complete to different degrees. You can see the progress and help translating them here, and your work will make it into the following UPU/RPU releases. (And while you're there, don't be shy to translate other projects in the system. Every little bit helps.)

Report bugs
Go to github issues: UPU, RPU. Attach saves, screenshots/gifs/videos to illustrate, describe steps to reproduce.
There is no use reporting issues here in this topic. Forums are not a suitable tool for tracking bugs, and I do not check NMA regularly.

Feedback, questions, discussions
Not for bugs. Bugs go to github.
Discord | Telegram | IRC | Forum
(Also, please don't send me private messages or emails about these or any other mods. I do not even read them. These are community projects, and communication better stay public. Use forums and chats.)

Coders wanted
If you want to help, and you're not afraid of coding, raise your hand. Fallout 2 code is a pile of dung, and although I've shoveling it for 2 years now, there's still much to be done.
 
Last edited:
I may have completely misunderstood the install directions... That said, I was under the impression this patch is easy to remove (i.e. it doesn't overwrite anything of RP), it only adds a folder called “mods/rpu.dat...” which is used over “data”.

I tested this and I can't load my old saves, nor can I save a game. Actually it triggers an “error”, then does save the game anyway but won't let me load it again. (This happened once, when I tried to reproduce it it wouldn't even let me do that, however, the save still does appear in the Savegame folder, just not in-game).

Part 2 (I tested RPU) on a clean install (well, not exactly install, I just threw the basic files the game needs to run into a folder. That's excluding anything else like hi-res etc., just the fundamentals) and then included RPU (as “mods/rpu.dat...”). I know RPU is used (I can tell by the used text files etc.), but I can't save (again). But again it creates a save file. I just can't see or load it in-game.

Part 3 (I then put all the RPU files into data) and then I can save the game and load (“ding”). However, I was under the impression that I can put “mods/rpu.dat...” into Fo2 and have it run (and I know that it works) but apparently it won't let me save (?).

Or did I completely misunderstood the “just extract into Fo2” and “it can be easily removed again” part, and it was never supposed to be included as “mods/rpu.dat...” only, but always supposed to overwrite stuff in data? Although it does work when included as “mods/rpu.dat...”, except for the save/load thing...

May be my fault for misunderstanding.
And it does work (now), but it will overwrite more than just ddraw.ini.
Anyway, perhaps the installation instruction could clarify that I can't just extract rpu_v1.7z into Fo2 but need to integrate the contents of “mods/rpu.dat...” into data. At least that seems to be the only way saving/loading works for me.

P.S. When adding RPU to data I can now save/load, but when I want to load my old 2.3.3 saves I need to delete “sfallfs.sav & sfallgv.sav” from the save first.
 
I think the content of upu.dat/rpu.dat should be packed into real .dat files instead of folders with fake filenames.
Note: Files (scripts, maps, etc.) with the same name in your normal 'data\' folder are ignored by the game, since the files in upu.dat/rpu.dat have higher priority. Just like back in the day with patch000.dat.

If you have smaller mods that would replace original UP/RP files and still want to use them with UPU/RPU, the easiest way is to treat UPU/RPU as direct patches to UP/RP: overwrite ddraw.dll/ini and move all files from mods\upu.dat\ or mods\rpu.dat\ folders to your 'data\' folder and overwrite existing UP/RP files. But you won't be able to roll back to original UP/RP easily (have to reinstall).
 
Last edited:
Yeah, that's strange. @NovaRain any idea why wouldn't it save?
No idea. It's the same if you rename the "upu.dat" folder to "patch000.dat" and without sfall (UP can start without sfall, of course some scripts would break during the game but it's not the point of my test). Probably it's the vanilla engine behavior.
One interesting thing is if you load an existing game you can re-save the game to other empty slots normally. But if starting a new game you can't save it.

Personally I don't recommend naming "folder" as .dat files to trick the engine into loading its content. If I want to use patch files, I'll pack them into .dat properly. Maybe that trick works for main .dat (master/critters.dat), but I wouldn't do that for patch files. Maybe it's possible to add packing all stuff in .dat with dat2.exe to your auto build script on repo?
 
Last edited:
Personally I don't recommend naming "folder" as .dat files to trick the engine into loading its content. If I want to use patch files, I'll pack them into .dat properly. Maybe that trick works for main .dat (master/critters.dat), but I wouldn't do that for patch files. Maybe it's possible to add packing all stuff in .dat with dat2.exe to your auto build script on repo?
Possible of course, in fact I was going to do that in the beginning, but settled for dirs, because I planned to add readmes later, and readmes do no good inside .dat files.
I'll add packing to .dat files for now, will think what to do with this after.
 
Possible of course, in fact I was going to do that in the beginning, but settled for dirs, because I planned to add readmes later, and readmes do no good inside .dat files.
I don't know why readmes would be in .dat files. Maybe just exclude them from the packing process?
 
Note: Files (scripts, maps, etc.) with the same name in your normal 'data\' folder will be ignored by the game, since the files in upu.dat/rpu.dat have higher priority. Just like back in the day with patch000.dat
If DataLoadOrderPatch is enabled, the data load order will be: master_patches > critter_patches > PatchFileXX > mods > sfall.dat > patchXXX.dat
 
Last edited:
Updates pushed to github.
When adding RPU to data I can now save/load, but when I want to load my old 2.3.3 saves I need to delete “sfallfs.sav & sfallgv.sav” from the save first.
Try with new version.

Anyone knows how to pack a directory with dat2 recursively? I can't seem to find the right combination.
 
No idea. It's the same if you rename the "upu.dat" folder to "patch000.dat" and without sfall (UP can start without sfall, of course some scripts would break during the game but it's not the point of my test). Probably it's the vanilla engine behavior.
One interesting thing is if you load an existing game you can re-save the game to other empty slots normally. But if starting a new game you can't save it.

Personally I don't recommend naming "folder" as .dat files to trick the engine into loading its content. If I want to use patch files, I'll pack them into .dat properly. Maybe that trick works for main .dat (master/critters.dat), but I wouldn't do that for patch files. Maybe it's possible to add packing all stuff in .dat with dat2.exe to your auto build script on repo?

i may be way off base here but the cannot save bug is something i ran into before,it may be related to the base proto of party members not being in /data or the master dat,had prblems with it in ProcessDat2 program,i think it is related to the engine handling of base party member protos,it is finicky

Anyone knows how to pack a directory with dat2 recursively? I can't seem to find the right combination.

use dat2 frame,little outdated ,but it works,does all the work
 

Attachments

Updates pushed to github.

Try with new version.
It's yes & no now.
I can now save & load without having to overwrite data.
But old 2.3.3 saves can't be loaded without deleting “sfallfs.sav & sfallgv.sav”.
And I can't overwrite old 2.3.3 saves either, btw. No matter if I delete “sfallfs.sav & sfallgv.sav” or not.
Isn't this possibly a compatibility problem of switching from sfall 3.3a to 4.1.8? For example the save files are named differently. Changed from “sfallfs.sav & sfallgv.sav” to “sfalldb.sav & sfallgv.sav”.
Anyway, I can save and load now so I guess it works, just old saves are semi lost (although it seems to work to delete the files “sfallfs.sav & sfallgv.sav”, load the save and just save it again (creates “sfalldb.sav & sfallgv.sav”). Not sure, however, if that will cause any problems down the line.
 
Back
Top