Saved won't load - CTD!

MarkShot · 01-28-08, 12:57 PM

Yes, I know the save was taken at 200M while in contact with the enemy. Yes, I have read that saving while submerged is a known issue.

But I don't really care!!! I saved, since I didn't have another hour or two to complete evading and get back to the surface.

Yes, I know we are suppose to be complimentary and defferential to the devs. But I am sorry, I worked in Systems for something less than 30 years. Saving an applications state to disk and reloading with the same application is Programming 101. There is nothing hard or tricky about it. Programmers who cannot program a save and load function in an application are simply incompetent. Just because they are game programmers doesn't make inability to handle a basic programming task more acceptable than if they worked for Sun, Intuit, or Microsoft.

Finally, this is not the only game to ever experience save/reload problems. I think if I decide to teach in my retirement, the first programming assignment will be how to write a save/load function.

So pathetically sad.

TomcatMVD · 01-28-08, 01:03 PM

I've never EVER had the "save while submerged" issue on stock SHIII... nor did I have a single Save/Load problem or error.
I understand your frustration though... but I don't know if saying such things without proper research would be appropriate... Just a thought there.

Hanomag · 01-28-08, 01:51 PM

GASP !!!

Jimbuna · 01-28-08, 01:55 PM

I understand where your coming from, and at times have experience the same frustration

The simple facts of the matter are, we can only work with what we have. The problem is inherent to what has been hard coded and without the SDK, I presume it is currently not possible to fix this annoying feature

Dronston · 01-28-08, 03:43 PM

How many times did we all have to start a new campaign because something crashed, got released or was f**Ked up by ourselves?

Me at least 6 times...if not 10...

MarkShot · 01-28-08, 06:19 PM

I used to play SH2/PA. Like GWX, PA was an amazing piece of work. The PA Team took a linear campaign and turned it into a dynamic campaign. However, ultimately there was one thing which killed it for me. You could save and reload. I could not get whole patrol played in one sitting. So, I gave up on it.

Granted I can back track here, but I want to simply be able to pick up a game where I left off. It is really not too much to ask for.

---

Save/reload is not that hard. You simply need two representations of data area:

Game Representation: This is what most programmers think of as variables, arrays, stacks, etc ... They are your subs, ships, map, crew, ...

Storage Representation & Threads: This is simply a pointer to start of all game data locations and the length of allocated data. Additional, as part of preamble it the list of active tasks and current execution points.

Save: You dump the SRT structure to a disk file. In this forms, it is just a long string of bytes.

Load: You read the SRT structure back into memory. Reset the active tasks and transfer control from a systems image process to the application handling. Thus, it becomes simply a game once again.

---

The beauty of doing the save/load as a systems function is that you can add new variables, buffers, and data structures. None of this has any impact on save/reload, since to those basic functions it is just one long string of serialized bytes. Once you have it working, it should continue working for all new patches and builds of the game. Not only is it maintenance free, but it is the fastest on saving and loading. Why? Because there is no need to traverse or rebuild complex data structures, it is just a big block of bytes. Only when control is transfered back to application handling, the game, does it begin to have a more sophisticated meaning.

If you fail to use the above approach, they you must make sure to capture each every bit of data about every simulated object in any given state and capture it to disk. Then, later you must rebuild the a very complex state of execution from little pieces of data captured on disk. If you neglect even one thing, then you get glitches. Any time, you make the smallest change to the code, you have to go back in and work on the save/reload functionality.

---

I know I just wasted my time, but maybe someone is reading this who aspires to be a game developer one day. Maybe they just discovered the right way to do save/reload. I can only hope.

01-28-08, 12:57 PM	#1
MarkShot Ace of the Deep Join Date: Jul 2002 Posts: 1,134 Downloads: 93 Uploads: 0	Saved won't load - CTD! Yes, I know the save was taken at 200M while in contact with the enemy. Yes, I have read that saving while submerged is a known issue. But I don't really care!!! I saved, since I didn't have another hour or two to complete evading and get back to the surface. Yes, I know we are suppose to be complimentary and defferential to the devs. But I am sorry, I worked in Systems for something less than 30 years. Saving an applications state to disk and reloading with the same application is Programming 101. There is nothing hard or tricky about it. Programmers who cannot program a save and load function in an application are simply incompetent. Just because they are game programmers doesn't make inability to handle a basic programming task more acceptable than if they worked for Sun, Intuit, or Microsoft. Finally, this is not the only game to ever experience save/reload problems. I think if I decide to teach in my retirement, the first programming assignment will be how to write a save/load function. So pathetically sad. __________________ War games, not wars! --- Only a small few profit from war (that should not stand)!

01-28-08, 01:03 PM	#2
TomcatMVD Weps Join Date: Dec 2007 Location: MVD, UY Posts: 359 Downloads: 7 Uploads: 0	I've never EVER had the "save while submerged" issue on stock SHIII... nor did I have a single Save/Load problem or error. I understand your frustration though... but I don't know if saying such things without proper research would be appropriate... Just a thought there. __________________

01-28-08, 01:51 PM	#3
Hanomag Grey Wolf Join Date: Jul 2007 Location: LI NY Posts: 964 Downloads: 13 Uploads: 0	*GASP !!!* __________________ "Only if I can save first..."

01-28-08, 01:55 PM	#4
Jimbuna Chief of the Boat Join Date: Feb 2006 Location: 250 metres below the surface Posts: 190,525 Downloads: 63 Uploads: 13	I understand where your coming from, and at times have experience the same frustration The simple facts of the matter are, we can only work with what we have. The problem is inherent to what has been hard coded and without the SDK, I presume it is currently not possible to fix this annoying feature __________________ Wise men speak because they have something to say; Fools because they have to say something. Oh my God, not again!!

01-28-08, 03:43 PM	#5
Dronston Lieutenant Join Date: Jan 2008 Location: Netherlands Posts: 263 Downloads: 68 Uploads: 0	How many times did we all have to start a new campaign because something crashed, got released or was f**Ked up by ourselves? Me at least 6 times...if not 10... __________________ Live to fight another day!

01-28-08, 06:19 PM	#6
MarkShot Ace of the Deep Join Date: Jul 2002 Posts: 1,134 Downloads: 93 Uploads: 0	I used to play SH2/PA. Like GWX, PA was an amazing piece of work. The PA Team took a linear campaign and turned it into a dynamic campaign. However, ultimately there was one thing which killed it for me. You could save and reload. I could not get whole patrol played in one sitting. So, I gave up on it. Granted I can back track here, but I want to simply be able to pick up a game where I left off. It is really not too much to ask for. --- Save/reload is not that hard. You simply need two representations of data area: Game Representation: This is what most programmers think of as variables, arrays, stacks, etc ... They are your subs, ships, map, crew, ... Storage Representation & Threads: This is simply a pointer to start of all game data locations and the length of allocated data. Additional, as part of preamble it the list of active tasks and current execution points. Save: You dump the SRT structure to a disk file. In this forms, it is just a long string of bytes. Load: You read the SRT structure back into memory. Reset the active tasks and transfer control from a systems image process to the application handling. Thus, it becomes simply a game once again. --- The beauty of doing the save/load as a systems function is that you can add new variables, buffers, and data structures. None of this has any impact on save/reload, since to those basic functions it is just one long string of serialized bytes. Once you have it working, it should continue working for all new patches and builds of the game. Not only is it maintenance free, but it is the fastest on saving and loading. Why? Because there is no need to traverse or rebuild complex data structures, it is just a big block of bytes. Only when control is transfered back to application handling, the game, does it begin to have a more sophisticated meaning. If you fail to use the above approach, they you must make sure to capture each every bit of data about every simulated object in any given state and capture it to disk. Then, later you must rebuild the a very complex state of execution from little pieces of data captured on disk. If you neglect even one thing, then you get glitches. Any time, you make the smallest change to the code, you have to go back in and work on the save/reload functionality. --- I know I just wasted my time, but maybe someone is reading this who aspires to be a game developer one day. Maybe they just discovered the right way to do save/reload. I can only hope. __________________ War games, not wars! --- Only a small few profit from war (that should not stand)!