/id issue

[TheColonel]

Works great, 'cept for negative stats, unsigned vs. signed, or a different sign convention, dunno. but 226 isn't -30

[dont_know_at_all]

Specific example?

[Amadeus]

Bug with /identify? This would interest me as well since I've not found an item with a problem.

[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}

[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.

[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 :)

[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.

[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.

[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!

[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.

[kaz]

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.

[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.

[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.

[xyilla]

детя

[xyilla]

156.3