Will you fix my game so it's no longer in wizard mode and can be played as a regular game?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 13, 2021 at 2:36:39 PM UTC-8, magicby...@yahoo.com wrote:

Will you fix my game so it's no longer in wizard mode and can be played as a regular game?

Save files are system dependent. You didn't specify what type
of system you're using. I my experience, that usually means
Windows. I couldn't do anything with a Windows save file on
my OSX system unless I had a Windows emulation subsystem
installed; I don't.

On top of that, nethack 3.4.3 has been superseded for five and a
quarter years now, so I probably wouldn't do it anyway.

Here is what needs to be done. (You don't have to do this yourself
if you can find somebody else, but it won't be me....) Run nethack
under debugger control and set a break point at moveloop().
Start the program. When it stops at moveloop, change the value
of flags.debug from 1 to 0 and cancel the break point, then resume
execution. As soon as nethack is ready for a command, save.
Once nethack exits, if the debugger is still running, exit from it too.
Simple.

The "change 'flags.debug'" part pretty much requires that nethack
be built with debugger support enabled. I don't know whether the
binaries for 3.4.3 that were distributed umpteen years ago were
built that way, so it will probably need to be compiled from sources
now. Any configuration changes in config.h and ntconf.h, possibly
others, that were made for the copy you (or whoever modifies the
save file) are running will need to be replicated before re-compiling.
So not necessarily simple after all. If build-time configuration
settings don't match closely enough, the save file will be rejected
and deleted, so keep a copy somewhere, obviously. If a mismatch
complaint occurs, comparing output from the nethack's #version
command for the reconstructed build attempt against that of the
original might help.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, March 14, 2021 at 5:50:40 AM UTC-4, Pat Rankin wrote:

On Saturday, March 13, 2021 at 2:36:39 PM UTC-8, magicby...@yahoo.com wrote:

Will you fix my game so it's no longer in wizard mode and can be played as a regular game?

Save files are system dependent. You didn't specify what type
of system you're using. I my experience, that usually means
Windows. I couldn't do anything with a Windows save file on
my OSX system unless I had a Windows emulation subsystem
installed; I don't.

On top of that, nethack 3.4.3 has been superseded for five and a
quarter years now, so I probably wouldn't do it anyway.

Here is what needs to be done. (You don't have to do this yourself
if you can find somebody else, but it won't be me....) Run nethack
under debugger control and set a break point at moveloop().
Start the program. When it stops at moveloop, change the value
of flags.debug from 1 to 0 and cancel the break point, then resume execution. As soon as nethack is ready for a command, save.
Once nethack exits, if the debugger is still running, exit from it too. Simple.

The "change 'flags.debug'" part pretty much requires that nethack
be built with debugger support enabled. I don't know whether the
binaries for 3.4.3 that were distributed umpteen years ago were
built that way, so it will probably need to be compiled from sources
now. Any configuration changes in config.h and ntconf.h, possibly
others, that were made for the copy you (or whoever modifies the
save file) are running will need to be replicated before re-compiling.
So not necessarily simple after all. If build-time configuration
settings don't match closely enough, the save file will be rejected
and deleted, so keep a copy somewhere, obviously. If a mismatch
complaint occurs, comparing output from the nethack's #version
command for the reconstructed build attempt against that of the
original might help.

You are indeed correct the save game is in wizard mode.

Understood. This information really helps. Thank you for that.

The reason I used 3.4.3 is that in later versions writing is no longer permanent, I think. I wanted to make sure writing was permanent because I left many clues, riddles, and descriptions as writing on the floor. In addition there is a level with an "
Elbereth" maze, (players must confront out of depth monsters, but are given an "elbereth path" to avoid them) so I needed that to be permanent.

Your solution sounds simple to you but I actually don't know even what a "debugger" is, though I have heard "wizard mode" called "debugger mode". In other words I don't even know programmer vocabulary much less how to operate it. But this does seem like
a good and simple solution, so I will consult with other people on how to do it and work on doing it myself.... once I find out what "debugger mode" "break point" and what all these other terms mean.

Anyway your support is much appreciated, I completely understand not wanting to get involved in a project where you don't even use the same operating system, so thank you so much for that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)