2020-07-11 05:30 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004302Subwar2050[All Projects] Generalpublic2020-04-06 23:39
Assigned ToJOTDProject InfoSubwar 2050 (Microprose)
StatusclosedResolutionno change required 
Summary0004302: Problem: Game seems not to be saved after completing a mission. The manual
DescriptionGameVersion: german,pal,2 cd32
SlaveVersion: 1.3 from 08.04.2017

Problem: Game seems not to be saved after completing a mission.
The manual states: "At the end of a mission your game will be saved to the CD32 Save Area. Please ensure that no more than 70 slots are locked...before loading the game for the first time"
I'm running the CD32 install of the game under Wb3.1 on a TF328 with 8MB Fast RAM.
I've set up my system that nonvolatile.library saves into the directory dh0:nv_stores instead using the non volatile memory:
- created the file sys:prefs/env-archive/sys/nv_location
- put the line "dh0:nv_stores" into that file
Now whenever a game is saving to non volatile memory a directory with the game name is created in dh0:nv_stores.
Now the saved items can be explored using some tools from aminet, e.g. nvcontrol or nv_editor.
But after I played the Subwar 2050 CD32 install I noticed that there wasn't anything saved in dh0:nv_stores.
And each time I start the game again I'll have to re-enter the pilot name and start from the 1st mission.
TagsNo tags attached.
ChipMem2 MB
FastMem8 MB
WorkbenchOS 3.1
KickROM45 - Kick 3.1.4
Attached Files



note ~0007686

JOTD (developer)

what about the attached slave? I have changed nonvolatile to Bert implementation, much simpler

note ~0007688

oscott (reporter)

Sadly now it crashes when starting the game for the 2nd time.

I've played the first short mission, then rebooted the CD32 to check if the game state has been saved.

When starting the game again, an exception occurred. I've attached a screenshot of the situation.

note ~0007696

JOTD (developer)

there should be a new file created. Can you attach that one?

note ~0007698

oscott (reporter)

I found one new created file: 'nvram' - see the attachment. It is created by the new slave inside 'data' directory of the game.

I also noticed, that this file always is created inside the 'data' dir, it doesn't matter what is set in:






After renaming / deleting the 'nvram' file, the new slave is starting again for one time without throwing an exception. Then it creates the file again and the next start of the slave isn't possible because the exception is thrown again.

note ~0007699

oscott (reporter)

But maybe the problem isn't due the slave but rather to my 'exotic' configuration..running the game from the Workbench on a real CD32?

Regarding this I noticed the follwoing:

Yesterday I played Reshoot-R. When I started it again today I saw that my yesterdays highscores where displayed. They were saved properly. But I didn't see, where. No 'nvram' file, and no trace of Reshoot-R in my global dh0:nv_stores (which is set in env:sys/nv_location).

They must be saved in the 'real' cd32 nv memory.

I verified that in my other environment, a WinUAE A1200 emulation, the Highscores are saved into env:sys/nv_location.

So, maybe being run a real CD32 might be reason, not so much the slave.

I'll doing some more testing tomorrow.

note ~0007703

JOTD (developer)

Last edited: 2020-02-08 20:14

View 2 revisions

no, whdload doesn't use real nonvolatile library. it's not related to CD32.

BTW: if you reboot (and don't quit cleanly) it's not surprising that the game isn't saved. You have to quit whdload, not reboot.

note ~0007710

JOTD (developer)

Bert fixed an issue with the new nv system. Slave attached. I have tested with your nvram file and it indeed starts in german. Without the file, it asks for language.

And it doesn't seem to be saved unless you complete a mission, as you said. Can you test the new attached slave and report?

note ~0007724

oscott (reporter)

The new version doesn't crash when reloading. But sadly it also doesn't save game after the first mission. I had just started it, entered a pilot name and finishend the first, short mission which is called "Navigation test". After re-starting the CD32 all these infos are gone.

But I made the test on my CD32 where the nvram file had been created by former slave already. (I haven't been asked for language when started the game today). So tomorrow I'll delete that nvram file and give it another test.

note ~0007740

JOTD (developer)

if by "re-starting the CD32" you mean rebooting with the reset button without quitting whdload cleanly, that's expected. Save files are cached and only written when quitting (or at once only if the file didn't exist)

It's a known limitation with whdload (and with Windows, Linux ... :)). You cannot quit by switching off or you may lose info.

Can you confirm that you're quitting whdload BEFORE resetting/turning off the CD32?

note ~0007745

oscott (reporter)

Quitting properly still did't fix it. The following steps I performed:

1) Assigned QuitKey=$100 to be able to exit the game with the left mouse button.

2) Renamed {game_dir}/data/nvaram to nvram.bak

3) Started the game. Have been asked for language, set it to German.

4) Entered Changed name of the pilot from default "Pilot 1" to "Oscott" and changed the face image, too.

5) Completed first mission "Navigation test"

6) Checked the pilots roaster and verified that pilot "Oscott" got the $1.500,- reward for the first mission.

7) Exit the game with left mouse buton.

8) Waited a little on Workbench; not rebooting the CD32 this time.

9) Started the game again. Being not asked aked for language anymore. Entered the pilots roaster and my pilot "Oscott" doesn't exist anymore.

Thereby the file {game_dir}/data/nvaram was newly created. I've attached it, in case it could be helpful.

note ~0008013

Wepl (manager)

@JOTD: can you please build/attach a Slave using the latest nonvolatile.s?

note ~0008015

JOTD (developer)

@Wepl done.
@oscott can you test the latest attached slave?

note ~0008018

Wepl (manager)

@JOTD but when saving did not work with the old Slave using disk nonvolatile.library there must be other reason for not saving.
The created nvram contains one slot with Options only. I assume there will be other slots one for each Pilot.

note ~0008020

JOTD (developer)

@oscott how do you quit your game after having saved it? rebooting amiga doesn't guarantees that the last write to the file works.

Did you notice some "flashing" when saving the mission progress?

note ~0008023

oscott (reporter)

Sadly with the new slave the same results as in ~7745.

Over the weekend I'll test some more things, e.g. burning the ISO image file and play the game once from CD. I'll try to find out if the pilot name and mission state is saved at all after the first short 'mission' Navigation test.

@JOTD The flashing I notice only when starting the game for the first time after having deleted the file data/nvaram. Then it flashes right after entering the pilot name and leaving the pilot menu. But not after completing the mission.

note ~0008024

oscott (reporter)

@JOTD PS I quit the game after the first mission from main screen using the WHDLoad quit key which I've set to LMB, as I'm not always having a keyboard connected to the CD32.

note ~0008064

oscott (reporter)

I played the game directly from CD on CD32 with enough free slots for saving the game.

Exactly the same result as with WHDload.

Language selection is saved. Pilot name is not saved after completing the first mission mission Navigation test. So I don't know at which point the game actually does save the pilots name / mission state.

But it seemingly has nothing to do with the whdload slaves.

I'm very sorry but it seems I've wasted your time:-(

note ~0008068

JOTD (developer)

don't worry about this! you can ask for help at eab forum

-Issue History
Date Modified Username Field Change
2019-11-26 10:56 administrator New Issue
2019-11-26 10:56 administrator Status new => assigned
2019-11-26 10:56 administrator Assigned To => JOTD
2020-02-04 22:16 JOTD File Added: Subwar2050.zip
2020-02-04 22:16 JOTD Note Added: 0007686
2020-02-07 11:42 oscott File Added: IMG_20200207_111108107.jpg
2020-02-07 11:42 oscott Note Added: 0007688
2020-02-07 22:54 JOTD Note Added: 0007696
2020-02-08 12:09 oscott File Added: nvram
2020-02-08 12:09 oscott Note Added: 0007698
2020-02-08 13:24 oscott Note Added: 0007699
2020-02-08 20:13 JOTD Note Added: 0007703
2020-02-08 20:14 JOTD Note Edited: 0007703 View Revisions
2020-02-13 18:44 JOTD File Deleted: Subwar2050.zip
2020-02-13 18:45 JOTD File Added: Subwar2050.zip
2020-02-13 18:46 JOTD Note Added: 0007710
2020-02-15 17:28 JOTD Status assigned => feedback
2020-02-15 19:39 oscott Note Added: 0007724
2020-02-15 19:39 oscott Status feedback => assigned
2020-02-16 03:51 JOTD Note Added: 0007740
2020-02-16 03:51 JOTD Status assigned => feedback
2020-02-16 12:35 oscott File Added: nvram_2020-02-16
2020-02-16 12:35 oscott Note Added: 0007745
2020-02-16 12:35 oscott Status feedback => assigned
2020-03-31 09:20 Wepl Note Added: 0008013
2020-03-31 11:23 JOTD File Deleted: Subwar2050.zip
2020-03-31 11:24 JOTD File Added: Subwar2050.zip
2020-03-31 11:24 JOTD Note Added: 0008015
2020-03-31 21:39 Wepl Note Added: 0008018
2020-03-31 22:15 JOTD Note Added: 0008020
2020-03-31 22:15 JOTD Status assigned => feedback
2020-04-01 20:08 oscott Note Added: 0008023
2020-04-01 20:08 oscott Status feedback => assigned
2020-04-01 20:12 oscott Note Added: 0008024
2020-04-06 11:33 oscott Note Added: 0008064
2020-04-06 23:39 JOTD Status assigned => closed
2020-04-06 23:39 JOTD Resolution open => no change required
2020-04-06 23:39 JOTD Note Added: 0008068
+Issue History