Saved won't load - CTD!

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.

GlobalExplorer · 01-28-08, 07:18 PM

Quote:

Originally Posted by MarkShot

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.

Maybe not. I am trying to figure out what you mean. I dont know what you mean by "dymping the SRT structure". Are you talking about serialization? I used to think direct memory to disk strategies are not that robust.

Anyway. The problem is not that the guys at UBI can't program. I think SHIII is a damn fine piece of software. (Though some things DO look ancient, for instance the file with the crew data which looks a bit amateurish and 80's style). It's just a shame that the product was rushed and locked at 1.4b - a lot of problems could be fixed if a single programmer worked on the code for 1-2 weeks (weather / savegame bug). Of course, it takes longer the longer the guy has worked on other things and forgot about how things work.

Alas, if this was not UBI but an indie company we would have seen a dozen or so patches which would have fixed all these things a long time ago .. well, but it isn't going to happen ..

MarkShot · 01-28-08, 07:34 PM

For Java programming, I believe it was called serialization.

01-28-08, 01:03 PM	#1
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	#2
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	#3
Jimbuna Chief of the Boat Join Date: Feb 2006 Location: 250 metres below the surface Posts: 190,539 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	#4
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	#5
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)!

01-28-08, 07:34 PM	#7
MarkShot Ace of the Deep Join Date: Jul 2002 Posts: 1,134 Downloads: 93 Uploads: 0	For Java programming, I believe it was called serialization. __________________ War games, not wars! --- Only a small few profit from war (that should not stand)!