Re: Digging is finally here! (was about time)
Posted: Jan 26th, '10, 13:59
It is a set value + a random number for each material you find.
Kingdom of Knuffel
-= A place for all Knuffel lovers =-
https://kingdomofknuffel.com/
Digging is finally here! (was about time)
Page 9 of 12
Re: Digging is finally here! (was about time)
Posted: Jan 26th, '10, 16:23
Yay, today I found 12 materials (if I counted right)! That's awesome! =D
Re: Digging is finally here! (was about time)
Posted: Jan 27th, '10, 00:23
Er... I'm still getting a message that I have an invalid KID.
I've refreshed the stats and the page multiple times and have tried digging in different sites, and I only have the one knuffel.
I dunno. Someone know what's wrong?
:/
I've refreshed the stats and the page multiple times and have tried digging in different sites, and I only have the one knuffel.
I dunno. Someone know what's wrong?
:/
Re: Digging is finally here! (was about time)
Posted: Jan 27th, '10, 03:45
Hey, i just realized that the island is shaped like a candy! 
Re: Digging is finally here! (was about time)
Posted: Jan 27th, '10, 08:09
Posie1200 wrote:Hey, i just realized that the island is shaped like a candy!
I didn't realized that until you pointed it out so thanks. XD The name of the island makes more sense to me now.
Re: Digging is finally here! (was about time)
Posted: Jan 27th, '10, 13:09
Firehorse wrote:Er... I'm still getting a message that I have an invalid KID.
I've refreshed the stats and the page multiple times and have tried digging in different sites, and I only have the one knuffel.
I dunno. Someone know what's wrong?
:/
We are aware of this (and you are not the only one who gets this error) and still trying to figure out what is causing this because when we test the Knuffel it works fine for us. ;_;
Re: Digging is finally here! (was about time)
Posted: Jan 28th, '10, 01:02
It's okay Firn :) I know you guys are working hard on all this pretty epic stuff.
And HA I totaly missed the fact that the island is candy-shaped. XD
And HA I totaly missed the fact that the island is candy-shaped. XD
Re: Digging is finally here! (was about time)
Posted: Jan 28th, '10, 04:58
All this "flash files" and "invalid KID" and "errors" and what not confuse me. @A@ i don't see how you guys can handle it
Lol, yea i was like "Candy land...? reminds me of charlie the unicorn... i wonder why it's called that? -stares at screen for a while- OMG IT'S CANDY SHAPED!!!" xD
Lol, yea i was like "Candy land...? reminds me of charlie the unicorn... i wonder why it's called that? -stares at screen for a while- OMG IT'S CANDY SHAPED!!!" xD
Re: Digging is finally here! (was about time)
Posted: Jan 28th, '10, 05:44
Wow, I sure do missed a lot of updates. xD I'm back to check in here with everyone. Please, don't bite me. D:
Re: Digging is finally here! (was about time)
Posted: Jan 28th, '10, 06:56
Big update to the still new digging system already.
I think I fixed the issue with some Knuffel that would always produce a "Invalid KID" error (KID stands for Knuffel ID, as you may have guessed). I had to rebuild most of the communication code to fix it, and I built a mode to assume other user's IDs in the digging page for debugging this, and in the process created a lot of other bugs I had to fix...
But on the other hand, I also got the SWF optimization issue done, meaning the SWF file is considerably smaller now and shouldn't take a lot less time to load.
You may all have to manually reload the Digging page next time you try to use it, but the new code is working better at least on my machine. Please go and give it a try.
For the seemingly unprobable case of having other newbie flex coders in the community out there interested in the details of the problem and the solution, for it was an issue with ActionScript/Flex I had to do rather long and tiresome research to solve:
The problem was caused by the automatic result handling done by the HTTPService class. The default result handling mode tries to convert XML response to an AS Object, which allows for named variable returns accessed as object properties, very nice indeed on first glance. The catch was that AS tries to be smart when interpreting the returned XML CDATA and won't let you choose the type casting it does, meaning: Strings that could be interpreted as numbers are interpreted as numbers, and there's no way of preventing this behaviour.
Now we have a new type of Knuffel IDs with the new Knuffel, which is an 8-character string representing an 8-digit hexadecimal number, and AS typecasting didn't recognize this in most cases, which is why it seemed to work well at first glance. The problem was with IDs which consisted of decimal digits and a single digit E: For instance, "1943E021" was read as scientific notation number and converted to 1.943*10^24, and the toString() returned "1.943e+24" accordingly.
Sadly, the only solution I could find is to use the result type e4x, which treats the result as an XML Object. Which has to be treated somewhat differently when using the result object, which is why I had to rewrite most of my communications code (well, at least the result handling part). I didn't try, but I'd almost assume that FlashVars would do similar typecasting on this kind of result. To conclude this whole issue, the lesson learnt is this: Never use the default result type of object with the HTTPService class.
I think I fixed the issue with some Knuffel that would always produce a "Invalid KID" error (KID stands for Knuffel ID, as you may have guessed). I had to rebuild most of the communication code to fix it, and I built a mode to assume other user's IDs in the digging page for debugging this, and in the process created a lot of other bugs I had to fix...
But on the other hand, I also got the SWF optimization issue done, meaning the SWF file is considerably smaller now and shouldn't take a lot less time to load.
You may all have to manually reload the Digging page next time you try to use it, but the new code is working better at least on my machine. Please go and give it a try.
For the seemingly unprobable case of having other newbie flex coders in the community out there interested in the details of the problem and the solution, for it was an issue with ActionScript/Flex I had to do rather long and tiresome research to solve:
The problem was caused by the automatic result handling done by the HTTPService class. The default result handling mode tries to convert XML response to an AS Object, which allows for named variable returns accessed as object properties, very nice indeed on first glance. The catch was that AS tries to be smart when interpreting the returned XML CDATA and won't let you choose the type casting it does, meaning: Strings that could be interpreted as numbers are interpreted as numbers, and there's no way of preventing this behaviour.
Now we have a new type of Knuffel IDs with the new Knuffel, which is an 8-character string representing an 8-digit hexadecimal number, and AS typecasting didn't recognize this in most cases, which is why it seemed to work well at first glance. The problem was with IDs which consisted of decimal digits and a single digit E: For instance, "1943E021" was read as scientific notation number and converted to 1.943*10^24, and the toString() returned "1.943e+24" accordingly.
Sadly, the only solution I could find is to use the result type e4x, which treats the result as an XML Object. Which has to be treated somewhat differently when using the result object, which is why I had to rewrite most of my communications code (well, at least the result handling part). I didn't try, but I'd almost assume that FlashVars would do similar typecasting on this kind of result. To conclude this whole issue, the lesson learnt is this: Never use the default result type of object with the HTTPService class.