10. February 2018, 15:46:43

#5

voodoo47Quote

as far as I know, EE is completely based on Shlink, no SS1 source code stuff is involved. and bugs like this one slipping in is pretty normal - if they don't stop progress, they are hard to spot, unless you have a tester that is pretty much obsessed with the game.

11. February 2018, 07:54:13

#6

dertsehaQuote

Quote by JDoran:

I agree that this should be fixed, though if you Dertseha make it as some sort of patch for the .exe (or whatever files) then people can make their own mind up whether to use it to fix the bug, or if they'd prefer it to always be the same to make the game easier for them (I don't see why, but I believe anyone should be allowed to play a game how they like*, except for cheating in multiplayer, of course).

From a technical perspective, I settled for a patcher for save-game files. This would allow for retro-fitting a random code to any save out there. (Only if it is a resource file, and if it is a save game file)
And from a "purist" perspective I'm with you to say that content-wise this is not the same game as the original.

Yet from a practical perspective, I'm still at my realization from my above text: What for?
My reasoning - all in my opinion - goes: Regardless of the capabilities of the engine, as soon as you learn about the importance of the digits, you'll "always" write down the digits as soon as you clear the respective CPU nodes in any future game session. You've spoiled yourself this revelation and avoid the necessary backtracking. And the possibly very, very few people that are so immersed to still "role-play" this revelation could also go the extra mile and go back to each screen. Such people already made the mental effort not to "know" what these digits are for, so they could ignore the fact that they'd find always the same digits.
Learning that the engine has this bug, that the code is always static, implicitly also tell you the importance of the digits, making you a player that would write down these digits like noted above.
And for the most part, you'll have to either destroy the nodes anway to progress, or they are so conveniently on your path that it's irrelevant whether you turn aside to destroy them with a few shots.

Trying to describe this patch then without a spoiler would go like this: "Run this patch on your newly started game in order to restore a necessary back-tracking that you'll most likely avoid anyway when you know about the reason." or "...in order to make you remember stuff."

Then again... I've spent over two years writing a game editor that has hardly any uses, why not also trying my hand on a small patcher

11. February 2018, 08:24:12

#7

voodoo47Quote

pretty sure I'll get to it sooner or later. also, if the reactor fix is something that can be patched into the exe or other game files (making the code random for anyone who starts a new game), then there is no reason to not go ahead - GOG/steam have no problems deploying our patches.

Quote by dertseha:

What for?

why do men like us do anything - because we can.

Acknowledged by: dertseha

21. February 2018, 17:33:22

#8

dertsehaQuote

Ah, these little experiments help to better understand the engine.
I've started with a new tool that would patch existing savegame files to receive a new random code.
Things that I considered so far:
* Changing the random number in the game variables
* Changing the codes that the panel on reactor level expects. This panel is loaded with the random code on first level entry.

Trying it out for the first time by checking the first digit on level 1, I realized the following:
While I've already identified the action that lets a screen display its level-specific digit, so far I thought it would just tell it "show whatever your digit is". Yet in fact it loads the actual digit into the screen object. So, changing the code after the fact does not change what might already be displayed.
This means the patcher needs to walk all relevant levels and check/modify the screen state. Oh well.

Acknowledged by: voodoo47

22. February 2018, 20:29:01

#9

JDoranQuote

Quote by dertseha:

Ah, these little experiments help to better understand the engine.
I've started with a new tool that would patch existing savegame files to receive a new random code.
Things that I considered so far:
* Changing the random number in the game variables
* Changing the codes that the panel on reactor level expects. This panel is loaded with the random code on first level entry.

Trying it out for the first time by checking the first digit on level 1, I realized the following:
While I've already identified the action that lets a screen display its level-specific digit, so far I thought it would just tell it "show whatever your digit is". Yet in fact it loads the actual digit into the screen object. So, changing the code after the fact does not change what might already be displayed.
This means the patcher needs to walk all relevant levels and check/modify the screen state. Oh well.

Maybe instead of a save-game patcher, then, you could just make a save-game maker, one that always makes the same identical save-game, a save-game of the start of the game (where you start at when you start the game properly), but the save-game creator let's you first specify the skill levels you want, then it creates a random code number for the game, and produces a game-save for the user, called "Start-1" (or a similar name).

I can't remember, are things like key configuration (as in the keyboard control configuration), and the screen resolution stored in the save-game files? If so, then the save-game maker could read these in from the System Shock data files, and incorporation them into the new game-save, for the user's convenience.