WHDLoad MantisBT - NewZealandStory
View Issue Details
0004831NewZealandStory[WHDLoad Installs Games] slavepublic2020-10-25 14:022021-02-06 10:50
ReporterHungry Horace 
Assigned ToJOTD 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
ChipMem2 MB
FastMem0 MB
WorkbenchOS 3.0
KickROM40 - Kick 3.1
Summary0004831: Highscores and Version Number
DescriptionHi Jean

I notice you have changed the scoreboard filename back from 'NewZealandStory.highs' to 'high's

This was changed on 'v2.0' in order to mean there was no clash between NZS and other (older) slaves that use the plain 'highs' file name, if the save output share a directory.

This can happen when using the WHD savepath/savedir option with WHD booters/apps etc.

Also, i notice the latest release is badged as '2.1' , but there were already minor changed on 2.1 and 2.2 (myself, then StingRay who fixed a bug I created in error) - are those changes still implemented in the newest version?

It might be a good idea to release as a '2.4'for absolute clarity that the newest version is in use.

TagsNo tags attached.
Attached Files

2020-10-25 17:44   
First, I had fixed all issues without even noticing Stingray upgrade. I made the same fixes as he did.

I merged some code optimizations from his sources, but in the meanwhile I had added back the title screen which fixed some stuff too.

About the name of the savegame, I don't understand how a different save game dir can work when the game _loads_ highscore data. I understand that it can be written some place else, but then how to load it back?
Hungry Horace   
2020-10-25 20:03   
The previous code (v2.0) would
- if no NZS.highs présent, use the original memory block
- if NZS.hugs present it would load this file
- save back to NZS.highs

This name certainly worked previously as I regularly pick this game up on my machines and find old high scores loaded!

Becuase the load/save is a memory block read/write, this is all handled by Whdload and so it will load/save from whatever dir is set. There were no issues raised since 2009 saying this function didn’t work and I am confident it worked with the renamed file, which has its name set in the slave somewhere.

If this could be restored for a potential 2.3 version I’d be happy to test it is working as intended
Hungry Horace   
2020-10-25 20:10   
Apologies for the phone-related typos!
2021-02-06 10:50   
yeah, you're right. all done, just wait for 2.4

Issue History
2020-10-25 14:02Hungry HoraceNew Issue
2020-10-25 14:02Hungry HoraceAssigned To => JOTD
2020-10-25 14:02Hungry HoraceStatusnew => assigned
2020-10-25 17:44JOTDNote Added: 0009212
2020-10-25 20:03Hungry HoraceNote Added: 0009213
2020-10-25 20:10Hungry HoraceNote Added: 0009214
2021-02-06 10:50JOTDStatusassigned => closed
2021-02-06 10:50JOTDResolutionopen => fixed
2021-02-06 10:50JOTDNote Added: 0009528