Ok, at least some of the things are hopefully answered below.
From: "Mathew Earle Reuther" <graymere@ZIPCON.NET>
<snip>
> 5) Type : SPELLBOOK
> 6) Extra flags : GLOW HUM NO_RENT
> 7) Anti flags : WANDERER APPRENTICE ARMSMAN FAITHFUL URCHIN
> 8) Wear flags : TAKE FINGER NECK BODY HEAD LEGS FEET
> 9) Weight : 5
> A) Cost : 50
> B) Cost/Day : 10
> C) Timer : 0
> D) Values : 50 53 0 0
> E) Applies menu
> F) Extra descriptions menu
> M) Min Level : 0
> P) Perm Affects: NOBITS
> S) Script : Not Set.
> Q) Quit
<snip>
> #1250
> spellbook book~
> a spellbook~
> A spellbook lies here.~
> ~
> 24 abcGHI abcdefgGHIJKLM 0
> 0 50 53 0
> 0 5 50 10
> (null)
> $~
The extra flags in the wear bitvector is probably because GET_OBJ_WEAR is
a 'normal' int. Your sprintascii() function writes 64 bits regardless of
the input type. The 'GHIJKLM' above is bits set in the memory space _after_
the position of GET_OBJ_WEAR(). A solution could be to add another
parameter to sprintascii(), namely the bitwise length of the input.
> Obviously, something has gone horribly wrong here! (Way too many flags,
> things shifting, etc.) So I open up the item again. Everything is in the
> right place, the display is as it was when I exited. So, I reboot. Load
> up the object again:
<snip>
> -- Item number : [1250]
> 1) Namelist : spellbook book
> 2) S-Desc : a spellbook
> 3) L-Desc :-
> A spellbook lies here.
> 4) A-Desc :-
> <not set>
> 5) Type : SPELLBOOK
> 6) Extra flags : GLOW HUM NO_RENT
> 7) Anti flags : WANDERER APPRENTICE ARMSMAN
Let me guess; this is bits n, u and l, right ?
> 8) Wear flags : TAKE FINGER NECK BODY HEAD LEGS FEET
> 9) Weight : 0
> A) Cost : 5
> B) Cost/Day : 50
> C) Timer : 0
> D) Values : 0 50 53 0
> E) Applies menu
> F) Extra descriptions menu
> M) Min Level : 10
> P) Perm Affects: NOBITS
> S) Script : Not Set.
> Q) Quit
> Enter choice :
> The anti flags have changed for one (big shock considering they are saving
> as "(null)" in the .obj files) . . . also, the values have shifted over
> one place: weight is 0 and the others have "acquired" some different
> values.
They have aquired the 'right' values, if you look in the object file.
It's not the read from disk, it's the write that's messed up.[1]
> genobj.c in save_objects I've added a line to be saved as follows:
> sprintascii(buf1, GET_OBJ_EXTRA(obj));
> sprintascii(buf3, GET_OBJ_ANTI(obj));
> sprintascii(buf2, GET_OBJ_WEAR(obj));
Maybe you should log() the objects' anti number a couple of places,
to see where it fails. As a side note, sprintascii should return "0",
if no bits are set. If it returns NULL, you've seen what happens.
>
> fprintf(fp,
> "%d %s %s %Lu\n"
> "%d %d %d %d\n"
> "%d %d %d %d\n"
> "%s\n",
>
> GET_OBJ_TYPE(obj), buf1, buf2, GET_OBJ_PERM(obj),
> GET_OBJ_VAL(obj, 0), GET_OBJ_VAL(obj, 1), GET_OBJ_VAL(obj,
> 2), GET_OBJ_VAL(obj, 3),
> GET_OBJ_WEIGHT(obj), GET_OBJ_COST(obj), GET_OBJ_RENT(obj),
> GET_OBJ_LEVEL(obj),
> buf3
> );
> My asciiflag/sprintb/sprinta routines were posted earlier, I don't want to
> repost them and make this much longer than it already is.
> If anyone has any idea what I'm doing wrong, please let me know. This is
> really starting to frustrate me to no end. :)
Welcor
[1] Apart from the line that reads:
if ((retval = sscanf(line, "%d %s %s %d", t, f1, f2, t + 3)) != 4) {
Shouldn't you scan in a Lu here ? That's what you wrote down, anyway.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT