Dicemaster Slayer Posted January 25, 2008 Author Posted January 25, 2008 Glad my method of designing this provoked such humor among the populace. First let me address the fact that I'm using a 4-D array. It's the closest I could (think of, at least) get to OOP in Autoit, considering there are multiple players, and a lot of information that needs to be handled easily. Yes, there are other ways I could have acheived this. However, it makes enough sense to me, and so far hasn't let me down. I don't know C/++/# to make real objects the way Autoit handles them, nor am I anywhere near proficient enough in any proper database format to use them. Yes, I know the option is there for me to attempt this in some language that does support OOP (i.e. and provoking flames i'm sure, Java). I chose Autoit because of its ease of coding, not to mention everything I need to develop the program is already provided, instead of running around the Internet trying to find something that works. Second, you've probably already guessed this will be a textwall. It's unavoidable. When asking for help, anywhere, I will provide as much information as I possibly can, so that anyone that wants to tackle the problem can have (so I hope) everything they possibly need to solve it. Third, the "sample code" I posted in my first post is actual code that is run. All variables used are declared appropriately in the program ($user starts as 0, is updated when the game is loaded, the $atk_* vars are all declared in the code). It is run after the user has selected an attacker (and updates $atk_attacker) and a target player (updates $atk_targetplayer). Going into the conditional, these values are correct every time. Again, somehow it's getting the actual comparing wrong. Now, a note that I probably should have given before on how the ATK/DEF values are generated. When one loads a game, it loads from a *.ini file that contains all the game's data. The values are stored simply as "M1ATK=6", "M3DEF=12" etc. The game loads these into the $player array directly through IniRead(). Now, if this is creating strings, not numbers, that may be our problem. However, though I am likely mistaken, even if the conditional is trying to compare two strings, why does it get it right most of the time, and sometimes get it wrong. If the problem arises from it comparing strings, shouldn't it get it wrong more often? If that's still a major factor in this bug, then should I be applying Number() to the ATK/DEF values after they're loaded from the INI but before they go into the array?
weaponx Posted January 25, 2008 Posted January 25, 2008 Always convert numbers read from an INI because they WILL be read in as strings. Do it right at your IniRead(), $array[5][5][6][8][9][0][1] = Number(IniRead("someini.ini", "Section", "key", "value"))
PsaltyDS Posted January 25, 2008 Posted January 25, 2008 (edited) When one loads a game, it loads from a *.ini file that contains all the game's data. The values are stored simply as "M1ATK=6", "M3DEF=12" etc. The game loads these into the $player array directly through IniRead(). Now, if this is creating strings, not numbers, that may be our problem. However, though I am likely mistaken, even if the conditional is trying to compare two strings, why does it get it right most of the time, and sometimes get it wrong. If the problem arises from it comparing strings, shouldn't it get it wrong more often? If that's still a major factor in this bug, then should I be applying Number() to the ATK/DEF values after they're loaded from the INI but before they go into the array? As Uten and WeaponX already said -- alway convert. Take a closer look at the code I posted earlier: $x = 5 $y = "14 " If $x > $y = True Then MsgBox(16, "Error", "Einstein was wrong!") The variable $x is an integer, and $y is a string. AutoIt, in most of the native functions, will automatically do a Number() on input parameters. Most UDF functions don't, though. This is one reason for things to work sometimes and not others. If you try it, you will see the 5 > "14" works correctly because AutoIt does the conversion. It also works if you do 5 > " 14", but 5 > "14 " doesn't. Did you notice the difference? That's all it takes in your .INI file to trow it off, unexpected white space. So if you want to read a number from an INI file, remove white space, then do Number: $avArray[1][2][3][4] = Number(StringStripWS(IniRead($sIniFile, $sSection, $sKey), 8)) Here the string from IniRead() is passed to StringStripWS(), which strips all whitespace with option 8. Then that cleaned-up string is passed to Number(). Edited January 26, 2008 by PsaltyDS Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law
Uten Posted January 26, 2008 Posted January 26, 2008 @dicemaster. Provide code to fill arrays that reproduce the error. And get updated on unit testing methods (on wikipedia )fast. You will benefit so much from it..Best of luck. Please keep your sig. small! Use the help file. Search the forum. Then ask unresolved questions :) Script plugin demo, Simple Trace udf, TrayMenuEx udf, IOChatter demo, freebasic multithreaded dll sample, PostMessage, Aspell, Code profiling
Dicemaster Slayer Posted January 26, 2008 Author Posted January 26, 2008 @PsaltyDS and weaponx : ah, i figured the INI would be throwing things off I'll try converting to Number right at the load. If it still doesn't work, well, I'll take a stab at trying the whole management process from a different angle. Thanks for the advice, and humor, everyone.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now