Possible bugs with String Control Codes and Counters

So I noticed a few bugs. I didn't see these mentioned anywhere...

Firstly in the Item Pickup tab, for "Increase Counter Max" and "Increase Amount", it doesn't let you put in a value higher than 32767 while the max for a counter is 65535. I noticed that this is almost exactly half of what the max counter too. The box "But not above" however allows you to go up to 65535 just fine. It may prevent you with other boxes too, but I haven't tested all of them out.

Second, for some reason around 30,000 on a counter with String Control Codes, it seems that ZC doesn't count properly. I had a counter that was at 30,000, and had the String set via string control codes to change when that counter was at 35,000. Upon activating the string, it changed even though the counter was at 30,000 and not 35,000. I continued to test and 40,000, 45,000, 50,000 and 60,000 values also changed even though the counter was at 30,000 and not the proper values.

I have a feeling these two bugs are related but I'm not positive.

I don't know how many people use counters on such a high value, but it'd be very nice to be able to use this for my Bank.

This is all in the ZC 2.5 Stable Windows build.

Quote:

---

Originally Posted by HylianGlaceon

I don't know how many people use counters on such a high value, but it'd be very nice to be able to use this for my Bank.

---

I wouldn't even consider this a bug in ZC. 65,xxx isn't a far cry away from 30,000 compared to a number such as 654,654,679,249,284,264,219,249 or something.

Anyway, if you take a look at some of the things I've done in the Zim's Debugger program that's floating around somewhere, you could get an idea of how to make counters pretty much indefinitely bigger, and I will describe the method of how to do so for you here as well, it's very simple:

Every time said number gets to 1,000, make a different counter, best to do so as an array, add plus 1, and subtract the 999 from the last digit.

Code:

---

int MYCOUNTER[100]; //This would give you an array of 100 numbers, that's 100 000,000,000,000,000's place values, which is a fairly large number.

if(MYCOUNTER[0]>=1000)//This statement says that the first three place values have been exceeded, and that the first triple digit counter has went beyond a thousand.
 {
 MYCOUNTER[1]+=(MYCOUNTER[0]%1000-MYCOUNTER[0]%100)/1000; //The next three digit place values are increased by the amount that the first three digit counter
//has exceeded three digits with this statement, which is an easy way to do this as long as the counter doesn't go over the next place value digit more than 999,999 at a
//time.  If that happens you'd just need to make sure that there's some way to compensate for that instead.
//So this says:  The thousands place value is increased by how much the ones - hundreds place values have exceeded the hundreds place.
MYCOUNTER[0]-=MYCOUNTER[0]%1000-MYCOUNTER[0]%100;}
//This next line says that the original ones, tens, hundreds place values have the thousands place values subtracted from them, since the goal
//is to add onto the next place values in the thousands and keep the every place values equal to or below 999, and add to or borrow from the next 999 place value
//just like elementary school mathematics.
}
//This system works for any amount of numbers until ZC runs out of array space, so technically one could make a counter that would actually fill up the whole entire screen
//with tiny digits.

---

https://skydrive.live.com/embed?cid=...BJfF_1zCHN1Msw
This file has scripting that you might like to check out.
Instead of using the tiles when it says DrawTile(yada, yada, etc. 65180, etc.) for the various displaying of the counter digits, you could also use a DrawInteger instead for your counters, because when I made those counters I wasn't even aware there was such thing as a drawinteger function.

Counter adjustments have to be signed so they can either increase or decrease a counter. That gives them a range of -32768-32767. It would be possible to increase the range, but that would involve a change in the quest file format, which we're trying to avoid for 2.50.1.

The control codes I'm not as sure about. They could only take four-digit arguments originally, and it may well be that I overlooked something when expanding it. It might be a similar issue; that 35000 may actually be -30536.

Quote:

---

Originally Posted by Saffith

Counter adjustments have to be signed so they can either increase or decrease a counter. That gives them a range of -32768-32767. It would be possible to increase the range, but that would involve a change in the quest file format, which we're trying to avoid for 2.50.1.

The control codes I'm not as sure about. They could only take four-digit arguments originally, and it may well be that I overlooked something when expanding it. It might be a similar issue; that 35000 may actually be -30536.

---

Alright, if it's that much of a problem for #1, I'll just use my workaround which is basically giving you 4 of the same items in the pickup string to set the value like I wanted. I just felt it was really odd to be unable to do that in those boxes.

With #2 If that's true, it seems strange. I would assume if ZC can have counters function elsewhere at 35k and up, there'd be a way to tell with String Control Codes. If it's too much of a problem though, I can settle with 30k for my bank.

Well, it was kind of a similar problem. it was casting from char to int in a way that was doing some weird things.
Should be fixed now; it'll need some testing to make sure I didn't break something else.