I jumped through a Castle trapdoor and landed with the usual Valley
level arrival message in a Juiblex level that was partly lit and
that hosted some soldiers, two effects from other already finished
games.

I was completely confused how that could have happened and did some
restore experiments to get clarity. Luckily I found the source of
the issue; a 'recover' wrapper script that I wrote to simplify the
recovering in case of crashes. I had forgot to clear the temporary
working directory where the script copies all the level files to
before I copy the ones from the current game that needs restoration
(or rather I had not forgot it, but had the clearing deactivated).

So it happened that newer restorations also incorporated the deeper
levels from earlier crashed games but not the shallower levels that
were overwritten by the current game.

The bad thing of that incident is that I had to manually select the
correct save files and need to replay a not trivial portion of the
game again after the correct recovery. The interesting thing, though,
is that the Nethack/Slashem game restoration mechanism is quite
resilient; you can assemble level files from different games and it
at least seems to still work correctly. (See the convoluted example
above.)

Immediately that recent game project posted here came to my mind.
(Don't ask me why I had the association.)

I wonder whether another type of quasi-bones levels (but without
the remains of bones levels) could be incorporated in a game.
When the games ends some random level files could be saved for
random incorporation in subsequent games. This is not an idea
that is thought through, and, given the effects that I initially
described, absolutely unpredictable. We see that the Valley can
be completely replaced by another level, and imagine the Wizard
tower would not get generated. But it was anyway a funny effect,
and to observe how Nethack or Slashem create their dungeon from
unrelated dungeon fragments as well, that was interesting.

Janis

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

On Sun, 28 Mar 2021 05:13:53 +0200, Janis Papanagnou wrote:

['recover' wrapper script effect]

So it happened that newer restorations also incorporated the deeper
levels from earlier crashed games but not the shallower levels that
were overwritten by the current game.

Couldn't this also result in 2 player characters existing in one game?
Which one would get the focus on startup (the one at the lowest level?)
and what would it be like meeting yourself? (Your second self would
probably be "just another monster"?

Seems like each level file needs a unique (encrypted) game-specific
GUID (or sth. like that). In case of restoration from a crash, only
continuous level files with the GUID of level 1 should be assembled.
Maybe, restoration should even fail with loss of all level files,
when files with wrong GUID are encountered. - To hamper scumming...

Immediately that recent game project posted here came to my mind.
(Don't ask me why I had the association.)

Huge effort with semi-static result. Maybe it was an interesting
pastime for the one doing the project. And some incorporated ideas
might be utilizable as a blueprint for the /real/ ongoing game
development (= mockup sketches). - I haven't checked the outcome.
All in all, the approach seemed really odd to me, though...

I wonder whether another type of quasi-bones levels (but without
the remains of bones levels) could be incorporated in a game.
When the games ends some random level files could be saved for
random incorporation in subsequent games.

<Snipped some counter-arguments>

But it was anyway a funny effect

Hm, I'm not a fan of bones levels, in the first place. I think I like
this new idea even less. - Which makes it more likely, that it /will/
be incorporated in one way or another, sometimes... ;-)

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===

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

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

the issue; a 'recover' wrapper script that I wrote to simplify the
recovering in case of crashes. I had forgot to clear the temporary

What's the point of such a script?
The game does the recover automatically if it is started after a crash
and finds the level files of an ongoing game.

That said, I haven't encountered many crashes but if I do, I just copy
the levels to /tmp before letting the game recover, so I can copy them
back and try recover explicitly if something goes wrong. Don't think I
have ever needed to use the copied levels, though. Just some precaution,
I don't even remember which year I experienced the latest crash..

--
Jukka Lahtinen

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

On 28.03.2021 11:03, Jukka Lahtinen wrote:

Janis Papanagnou <janis_papanagnou@hotmail.com> writes:

the issue; a 'recover' wrapper script that I wrote to simplify the
recovering in case of crashes. I had forgot to clear the temporary

What's the point of such a script?

Crashes were rare in Nethack, and in Slashem there also were just a
few that I encountered, so I always forget how to recover from them.
But a simple call of 'recover' didn't work for me...

The game does the recover automatically if it is started after a crash
and finds the level files of an ongoing game.

...and (in case of crashes) on startup I only see a message whether
I want to destroy the old existing game or start a new one. (I don't
know how the NH-36x release works here, but I am speaking of NH-343
and Slashem that is based on NH-343.)

That said, I haven't encountered many crashes but if I do, I just copy
the levels to /tmp before letting the game recover, so I can copy them
back and try recover explicitly if something goes wrong.

That's what my script also does just for the case.

But also some steps that are (unnecessarily) required to do manually,
like gzip'ing the resulting file or moving it to the correct location
before you can restart the game. (This may or may not be necessary in
Vanilla, but the Slashem I use from my standard Linux distribution is
buggy in that respect.)

Janis

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

On 28.03.2021 09:32, B. R. 'BeAr' Ederson wrote:

On Sun, 28 Mar 2021 05:13:53 +0200, Janis Papanagnou wrote:

['recover' wrapper script effect]

So it happened that newer restorations also incorporated the deeper
levels from earlier crashed games but not the shallower levels that
were overwritten by the current game.

Couldn't this also result in 2 player characters existing in one game?

Don't know, haven't pondered about that. Maybe it's impossible to
create such an inconsistency, maybe you get the same effect that
you have if you polymorphed to a splitting monster; who knows.

Which one would get the focus on startup (the one at the lowest level?)
and what would it be like meeting yourself? (Your second self would
probably be "just another monster"?

Seems like each level file needs a unique (encrypted) game-specific
GUID (or sth. like that). In case of restoration from a crash, only continuous level files with the GUID of level 1 should be assembled.

Yeah, something like that.

Maybe, restoration should even fail with loss of all level files,
when files with wrong GUID are encountered. - To hamper scumming...

Effective means to prevent scumming are good if the game reliably
restores from all sorts of crashes. (It's often a trade-off.)

Immediately that recent game project posted here came to my mind.
(Don't ask me why I had the association.)

Huge effort with semi-static result. [...]
All in all, the approach seemed really odd to me, though...

Odd enough that the Unpredictable Save-file Assembly might fit? :-)

I wonder whether another type of quasi-bones levels (but without
the remains of bones levels) could be incorporated in a game.
When the games ends some random level files could be saved for
random incorporation in subsequent games.

<Snipped some counter-arguments>

But it was anyway a funny effect

Hm, I'm not a fan of bones levels, in the first place.

I think bones are a nice concept. In practice there's of course
some special handling of bones situations necessary, ranging the
span from "Heureka!" to an effectively unsolvable problem.

I think I like this new idea even less.

Before all the consequences are thought through it's certainly a
no-go. But yet I am ambivalent, maybe it has potential, maybe not.

- Which makes it more likely, that it /will/
be incorporated in one way or another, sometimes... ;-)

Don't be too pessimistic; the world is not that bad. - Though...
;-)

Janis

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