Bone compatibility

G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Could we get the ten lowest bits of version_data->struct_sizes (it
stores VERSION_SANITY2) cleared in bone files, please? It stores the
size of the "you" structure, and with no player to save, it's irrelevant
in bones.

While this change would have little effect on the official binaries, it
would allow patched versions to retain bone compatibility if the only
modified structure was a part of "you".

Backwards compatibility can be achieved by simply ignoring this data
when loading bones.

1KB
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Adam Borowski <kilobyte@mimuw.edu.pl> writes:

> Could we get the ten lowest bits of version_data->struct_sizes (it stores
> VERSION_SANITY2) cleared in bone files, please? It stores the size of the
> "you" structure, and with no player to save, it's irrelevant in bones.
> While this change would have little effect on the official binaries, it
> would allow patched versions to retain bone compatibility if the only
> modified structure was a part of "you".

That sounds reasonable to me..

> Backwards compatibility can be achieved by simply ignoring this data when
> loading bones.

For bones from official binaries to be compatible with a patched game,
ignoring the data when loading bones should be enough.
For bones from a patched version to be compatible with official 3.4.3, you
could fake the lowest bits of version_data->struct_sizes to be the same as
in the official version, not cleared.

I have a patched version that is bones compatible with the official 3.4.3
even though I have SCORE_ON_BOTL defined and the official version doesn't.
I reset the bit when saving bones (because it is not set with the official
version), and ignore it when loading bones.
http://www.netsonic.fi/~walker/nethack.html#showscore
shows how to fake the feature bits, and my makedefs diff linked to the
same page shows how you can ignore them when loading files.

It probably only takes little changes for these patches to make the game
fake some bits in struct_sizes in bones files and ignore the same bits
when loading bones, but I don't have time to test it before next weekend.
If you do it, I'll gladly update my patces.

--
Jukka Lahtinen
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Jukka Lahtinen wrote:
> Adam Borowski <kilobyte@mimuw.edu.pl> writes:
>
>>Could we get the ten lowest bits of version_data->struct_sizes (it stores
>>VERSION_SANITY2) cleared in bone files, please?

> For bones from official binaries to be compatible with a patched game,
> ignoring the data when loading bones should be enough.
Check.
> For bones from a patched version to be compatible with official 3.4.3, you
> could fake the lowest bits of version_data->struct_sizes to be the same as
> in the official version, not cleared.
Check.
It would be nicer to have it cleared to 0 in 3.5.0, to keep people from
faking the data. The bogus value needs to be kept in sync with the
official version, and that makes patches less portable.

> I have a patched version that is bones compatible with the official 3.4.3
> even though I have SCORE_ON_BOTL defined and the official version doesn't.
> I reset the bit when saving bones (because it is not set with the official
> version), and ignore it when loading bones.
I see. Well done.
The problem is, you can hide SCORE_ON_BOTL from both save and bone
files, while sizeof(struct you) _is_ relevant for regular saves, and can
be ignored only for bones. This means, the functions need to be aware
if they are handling a save or a bonefile.

> It probably only takes little changes for these patches to make the game
> fake some bits in struct_sizes in bones files and ignore the same bits
> when loading bones, but I don't have time to test it before next weekend.
> If you do it, I'll gladly update my patces.
A tested and debugged version of a _specific application_ of such a
patch is at http://nethack.angband.pl/conbon.patch -- it's tailored for
a particular patch it's accompanying, though. Too bad, it's the only
way until we manage to convince the DevTeam to get these bits zeroed --
every time you modify struct you, you need to update the signature length.

To turn it into a generic patch, one would need to delete all chunks
which mention FAKEBONEDIFF. In struct version_info,
VERSION_SANITY2-FAKEBONEDIFF needs to be replaced by
VERSION_SANITY2&(-1<<10).

I'm not uploading a modified version of the patch to not fool anyone
into thinking the generalized version is tested :p

1KB
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Adam Borowski <kilobyte@mimuw.edu.pl> writes:
> Jukka Lahtinen wrote:

> The problem is, you can hide SCORE_ON_BOTL from both save and bone files,
> while sizeof(struct you) _is_ relevant for regular saves, and can be
> ignored only for bones. This means, the functions need to be aware if
> they are handling a save or a bonefile.

Yes, that's true. You probably need to add a parameter to the function
call to tell the difference, unless the filename is already passed to the
check function and you can deduce it from the name (I haven't checked how
it works). This adds some complexity to the patch.

> > It probably only takes little changes for these patches to make the game
> > fake some bits in struct_sizes in bones files and ignore the same bits

> A tested and debugged version of a _specific application_ of such a patch is at http://nethack.angband.pl/conbon.patch -- it's tailored for a particular patch it's accompanying, though. Too bad, it's the only way until we manage to convince the DevTeam to get these bits zeroed --

We may start from that patch and see what needs to be done to make it more
general.. I suppose the value of those bits in the official setup should
be defined in a compiler macro. If it is different for different
platforms, we also need to make the macro definition different for different
platforms..

> every time you modify struct you, you need to update the signature length.

Most patches need updating when they are ported to a new game version..

--
Jukka Lahtinen
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Jukka Lahtinen wrote:
> Adam Borowski <kilobyte@mimuw.edu.pl> writes:
>> The problem is, you can hide SCORE_ON_BOTL from both save and bone
>> files, while sizeof(struct you) _is_ relevant for regular saves,
>> and can be ignored only for bones. This means, the functions need
>> to be aware if they are handling a save or a bonefile.
> Yes, that's true. You probably need to add a parameter to the
> function call to tell the difference, unless the filename is already
> passed to the check function and you can deduce it from the name (I
> haven't checked how it works). This adds some complexity to the
> patch.
My patch already does this. I add an argument "bone" to the relevant
functions (0 for saves, 1 for bones). It makes the patch long as it has
to update about 4689468974368 FDECLs as well, but it's fine.

>> A tested and debugged version of a _specific application_ of such a
>> patch is at http://nethack.angband.pl/conbon.patch
> We may start from that patch and see what needs to be done to make it
> more general.. I suppose the value of those bits in the official
> setup should be defined in a compiler macro. If it is different for
> different platforms, we also need to make the macro definition
> different for different platforms..
My patch is of little use, as it indeed requires the macro to be
changed, but if we can have these bits zeroed...

1KB
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Adam Borowski <kilobyte@mimuw.edu.pl> writes:
> Jukka Lahtinen wrote:

> > setup should be defined in a compiler macro. If it is different for
> > different platforms, we also need to make the macro definition
> > different for different platforms..

> My patch is of little use, as it indeed requires the macro to be changed,
> but if we can have these bits zeroed...

#ifdef UNIX
# define VALUE=something
#endif
#ifdef WIN32
# define VALUE=something_else
#endif
#ifdef OS2
# define VALUE=something_different
#endif
#ifdef VMS
# define VALUE=other_value
#endif

I wouldn't call that TOO useless..

--
Jukka Lahtinen
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

Jukka Lahtinen wrote:
> Adam Borowski <kilobyte@mimuw.edu.pl> writes:

>>>>[clearing 10 least-significant-bits in VERSION_SANITY2 in bones]

>>My patch is of little use, as it indeed requires the macro to be changed,
>>but if we can have these bits zeroed...
>
> #ifdef UNIX
> # define VALUE=something
> #endif
> #ifdef WIN32
> # define VALUE=something_else
> #endif
> #ifdef OS2
> # define VALUE=something_different
> #endif
> #ifdef VMS
> # define VALUE=other_value
> #endif
>
> I wouldn't call that TOO useless..

Not really.
sizeof(int) works the same among all of the platforms, regardless if the
int in 16, 32, 64 or 1e38 bits wide.

What I mean is:
#ifdef ELBERETH
#define FAKEBONEDIFF (sizeof(long)*7+sizeof(time_t)*2)
#else
#define FAKEBONEDIFF (sizeof(long)*6+sizeof(time_t)*2)
#endif

Every time you add new variables to "struct you", you need to update the
above number. It's feature-dependant, but almost entirely
platform-independant (except for overflowing a 16/32/64 bit boundary on
bitfields, but this can be worked around with macros, too).

However, this value is completely useless except for making Hearse
happy. As _save_ compatibility is broken anyway, this patch can't be
applied to 3.4.4, and for 3.5, we can put zero into these bits and thus
allow future patches to play with "struct you" the way they want.

1KB