Outpost Universe Forums

Projects & Development => Outpost 2 Programming & Development => Topic started by: Darien on January 13, 2026, 08:11:11 AM

Title: Campaign - stopping the blight?
Post by: Darien on January 13, 2026, 08:11:11 AM
Hi all,

I'm new this game. I typically enjoy RTS games and TBS games (big fan of Total Annihilation, and the Dune game for PC and Sega Genesis that played more like Command and Conquer than the equally good but very different Dune game for Sega CD which was more RPGish, and Heroes of Might and Magic on the TBS side).

TL:DR - what is the memory address in the .exe for the Blight, so I can stop it the same way I did to stop the lava (using info in another thread from this site - details below)?


Long version:

After having the Lava wipe me out a few times in the first few campaign missions, I said "There has to be a way to stop this." and found this site. Specifically, this thread is where I started: https://forum.outpost2.net/index.php?topic=4535.0

It was very helpful, and from reading other threads I see that Hooman is definitely one of the SMEs around here. I installed OllyDbg, and after backing up the .exe and MUCH fumbling around with trying to get it to find the memory address/script line that Hooman posted for lava, I found it, followed his directions, and it worked. There was much rejoicing!

I'm now at the campaign where you have to have your first Rare Ore miner, and create the RPG Lynx. I was doing pretty well. I had enough microwave lynx and turrets that the random attacks from Eden were manageable (once I learned how to use the Garage to fix my vehicles), and was to where I just had to finish building enough vehicles - that required Rare Ore, which was slowing me down - to finish the mission. My total game time was a few hours in, game speed was at 6 or 7.

Then the blight rolled in. Flattened me. Now, I can see the other solutions to this: "set the game speed slower."  "build more resource mining facilities"  "rely on turrets more so you're not burning resources on repairing vehicles as much." all valid. An for various reasons, especially the setting the game speed slower, I'm politely rejecting those paths at this time.

I found another thread that talked about "SetVirusUL", but I couldn't find that in the .exe, maybe that's in a .dll someplace? Though it seemed the .dlls are for specific maps, and not for the core game engine / campaign.

So if anyone could let me know the Blight memory address, and if I would use the same Ret4 trick to lock it out, I would appreciate it. Thank you!

Title: Re: Campaign - stopping the blight?
Post by: Sirbomber on January 15, 2026, 09:22:09 AM
If you're going to cheat anyways, save yourself some time REing the game and just use the built-in cheats.  Press enter and type in
Quote
Dan's dog could make more ore.
then press enter again for a full ore refill.
Title: Re: Campaign - stopping the blight?
Post by: Darien on January 16, 2026, 10:44:47 PM
Nice, thank you!

I didn't look to see if they had any in-game prompt cheat codes. I don't know why I didn't think of that. Now that you put the idea forward, I went ahead and did a search for such codes. For anyone else that's looking for help like this, here's what I found so far:
Cheat List

    Fill all smelters and storages with max. metals: Dan's dog could make more ore.
    Population increases by a certain % : Dan's car could hold more people.
    Increase rate of fire of all ranged weapons: Dan's bike could backfire more often

Note: To enter cheat, you must press the [Enter] key. Cheats only work when typed correctly, which will trigger the message: Woof Woof!

To Bolster factory production, left-click and right-click on it.

That last one seems odd and more like a glitch than a cheat code. I'll try it out though. Thanks again for the pointer!
Title: Re: Campaign - stopping the blight?
Post by: Sirbomber on January 17, 2026, 08:24:53 AM
That clicking thing was just a result of the game's original refresh rate, since clicking would force a screen redraw it "looked" like the progress bar filled up faster.
There's a fourth cheat that was never actually discovered but we brute-forced a collision and the nonsensical phrase
Quote
Dan's truck could crate more stormy.
will increase weapon damage.
I'd be careful using anything other than the ore refill cheat, you can use them all multiple times to stack the effects but you can easily put yourself in an unwinnable situation with the other cheats (too many people to feed, rate of fire/damage overflow).
Title: Re: Campaign - stopping the blight?
Post by: Hooman on February 27, 2026, 12:11:16 PM
Sounds like the built in cheats solved your problem.

At any rate, in case you're curious about `SetVirtusUL` (from Outpost2.exe):

Code: [Select]
00476EA0 .text Export ?SetVirusUL@GameMap@@SIXULOCATION@@H@Z

I should mention that when you press (Ctrl + N) it opens the names window for the current module (EXE or DLL file). Hence when the Outpost2.exe module is active, you should expect to see the title "Names in Outpost2". If instead you've opened a DLL file, such as "e01.dll", then the CPU disassembly window will default to the DLL module, hence pressing (Ctrl + N) will open a list of names from the DLL module, and will have a title such as "Names in e01".

If you're not seeing the name "SetVirusUL", it might be because Outpost2.exe isn't the current module.

If you open the Memory Map window (Alt + M), it will show all loaded modules. If you loaded a level DLL, it will reference the Outpost2 EXE file, so both modules will be loaded. If you were to select the ".text" section of Outpost2.exe you can "View in Disassembler" (Enter), which will change the module displayed in the CPU window. Pressing (Ctrl + N) will then show names in the newly selected EXE module.

You can also change the currently displayed module through regular code navigation. For instance, you can select a call instruction and press (Enter) to "follow" the code to the call destination. If the called code is in a different module, it will change the currently active module, and so affect what names will be shown by the names window. This is often the most likely reason for the current module to change, and perhaps show unexpected entries in the names window. Such inter-module code navigation can also be triggered by hardware breakpoints.


As for the return instruction, the `SetVirusUL` function has more parameters that need to be popped off the stack, so it would be `RET 8` rather than `RET 4`.

If you follow the address for `SetVirusUL` (00476EA0) in the CPU disassembly window, you'll see the function ends with `RETN 8`. Hence, to gut the function and make it do nothing, that's what you'd need to replace the first instruction with.