Page 1 of 3
/id issue
Posted: Sat May 24, 2003 4:40 pm
by TheColonel
Works great, 'cept for negative stats, unsigned vs. signed, or a different sign convention, dunno. but 226 isn't -30
Posted: Sat May 24, 2003 5:19 pm
by dont_know_at_all
Specific example?
Posted: Sat May 24, 2003 8:37 pm
by Amadeus
Bug with /identify? This would interest me as well since I've not found an item with a problem.
Posted: Mon May 26, 2003 10:22 pm
by TheColonel
/id on my Kobold's Jester's Crown USED to give
Code: Select all
[Dec 10 2003] Item: Kobold Jester's Crown (Tiny slot, Weight 0.0, Value 0cp)
[Dec 10 2003] Lore Name: Fool's Crown
[Dec 10 2003] Flags: LORE
[Dec 10 2003] Item: AC15 -5DEX 5AGI -30INT 30CHA
Now it gives
Code: Select all
[May 24 2003] Item: Kobold Jester's Crown (Tiny slot, Weight 0.0, Value 0cp)
[May 24 2003] Lore Name: Fool's Crown
[May 24 2003] Flags: LORE
[May 24 2003] Item: AC15 251DEX 5AGI 226INT 30CHA
The 251 and 226 look like they're the unsigned equivilent of -5 and -30 in a one byte variable, I didn't look at the struct myself, I suppose... I'll do that and post back.
{EDIT: TRIMMED TIME/DATE STAMPS}
Posted: Mon May 26, 2003 10:37 pm
by TheColonel
That's really odd... looked at struct, it's all BYTES, doesn't matter, the sprintf's are all %d which SHOULD print a signed dec. Maybe it's just my compiler that's off the standard, I've been using NMAKE on the makefiles, VC6... I'm quite unsure what's wrong, I'll goof around and recompile see if it likes %i better.
Seems like you're gonna need the 'h' qualifier in front of the 'd' '%hd' to specify that it's a short rather than a word.
Posted: Tue May 27, 2003 12:57 am
by Amadeus
That may be true ...I havn't checked back to see how the previous COMMON structure was laid out and how it would be different today. Your fix may be required for negative values to work properly....whatever DKAA says :)
Posted: Tue May 27, 2003 1:19 am
by TheColonel
Hehe, I've been playing with it, and I can't seem to get it to change how it's displayed, tried '%i' to no avail... tried '%hd'
Code: Select all
if (pCharInfo->Cursor->Common.INT) {
sprintf(szTmp,"%hdINT ", pCharInfo->Cursor->Common.INT);
strcat(szMsg,szTmp);
}
and I even type-cast the Common.INT to (int)
Code: Select all
if (pCharInfo->Cursor->Common.INT) {
sprintf(szTmp,"%dINT ", (int)pCharInfo->Cursor->Common.INT);
strcat(szMsg,szTmp);
}
So, I dunno, I
had some old .h's floating around, but recently cleaned house. I'll probably find out that I'm doing something retarded. But, I'll be up all night, goofin' with it, I'll post when I figure it out.
Posted: Tue May 27, 2003 7:27 am
by kaz
just an fyi, the definition of BYTE is unsigned char, so that explains your problem.
change BYTE to char in the struct and the problem should go away.
Posted: Tue May 27, 2003 1:58 pm
by Amadeus
I don't suppose %c would work? Otherwise, yea, it should be changed to CHAR in the struct. Hmmm....I didn't realize that BYTE was unsigned by default....oops!
Posted: Wed May 28, 2003 2:16 am
by TheColonel
I actually found an old .h and they were stored as BYTEs as well... but they were all... what is word? right after on antoher... either way, in the new struct they're all over the place, dunno if that has anything to do with it, shouldn't, but, I dunno, I play more with ASM than C++ so most of the stuff I do is type independant, not used to having these issues. I'd assume CHAR would work. How long is a SHORT in C++ these days? 2 Bytes I'd assume. But either way, I hacked at the printf things for a whiel and couldn't get it displaying properly, although the mana and HP display correctly, they're LONG's in the struct. I hope this helps, I can't do much more, got a job today, start tomorrow so I can't stay up all hours of the night hacking away anymore.
Posted: Wed May 28, 2003 3:22 pm
by kaz
Amadeus wrote:I don't suppose %c would work? Otherwise, yea, it should be changed to CHAR in the struct. Hmmm....I didn't realize that BYTE was unsigned by default....oops!
ok answer is simple, cast to CHAR
Code: Select all
BYTE x = -30;
printf("%d", (CHAR)x);
I used this test code just to make sure and it works fine and displays x with the proper sign.
Posted: Wed May 28, 2003 5:09 pm
by Amadeus
That might be the best thing since it's really easy to see it as a BYTE value in the struct if you don't have a negative value to work with. However, the proper answer would be to adjust the struct to CHAR instead of BYTE so that it is correct.
Next time I do a crapload of struct changes for DKAA, I'll be sure to remedy this.
Posted: Wed Jul 09, 2003 2:55 am
by AMadMonk
A cast of an unsigned value has no implicit sign-extension.
So, BYTE -20 is same thing as BYTE 230. Same data.
However,
BYTE b = -20;
printf("foo: %d", b);
Will NOT sign-extend the value into 32 bits, because, as kaz said, BYTE is an unsigned data type. So you get (+)230 zero-extended into 32 bits which is (drumroll) 230 -- instead of -20 sign-extended into 32 bits which is... uh 2^32-20.
So like kaz said, put in an explicit cast to a signed data type if you want the compiler to do sign-extension. We can't read minds, you know.
Re: /id issue
Posted: Mon Sep 22, 2025 5:49 am
by xyilla
Re: /id issue
Posted: Mon Sep 22, 2025 5:50 am
by xyilla