at first, thanks for this great library. im developing my rpg and it works really well and its easy to use.
but i encoutered a very strange bug and had to search 2 hours until i had found the "reason" for it (which makes no real sense).
if you have a record on your map and in this record some variables (2d arrays), then at some point starcode will stop working. it will say "devide by zero" when it should compress/encrypt/... code.
i have created a new map, imported the starcode library, created some test trigger and implemented a record to show you the bug.
this are the characteristics of the bug:
- if you deactivate or remove the record, starcode will work again
- if you remove one of the 4 array variables in the record, starcode will work again
- if you move all 4 variables out of the record, starcode will work again
- if you replace the 4 100*50 arrays with one 100*250 array (which should be equal), starcode will work again
- it does not have any effect to rename the variables or the record
- when you start a new code with starcode and show a text message with the current code in it, it will not show "0" like its expected after "start new code", it will just show nothing
- additionally, the code output after storing the intergers is totally different when the record is in the map, even if you save exactly the same values
- compress code, encrypt code and hash code will throw a trigger error with message "devide by zero". havent tested the other functions yet, but getcode, startnewcode and store integer still works
try it out yourself and you will see it. i dont know if it helps you to find the mistake or if its some strange engine bug, but its very bad for my rpg because for my item/quest/spell systems i need a lot of multidimensional arrays in records and i always have to reduce the array size to avoid the "devide by zero" bug of starcode.
its very important for me that you look over my testmap and tell me what causes this problem.
I see what you mean, this is indeed strange. The system should never ever divide by zero unless given bad input, which isn't the case here.
My best guess till now is that the sheer number of initializations (20000 variable sets) of the record is too much too handle. It seems to neglect Starcode's variable init then.
I'll look into it in full detail tomorrow.
Right, the division-by-zero bug is caused by faulty variable initialisation. That can be fixed (although should never happen in the first place).
However, there are even more severe problems. The variable arrays somehow influence the result of mathematical calculations!
Changing the default value of one of the arrays will change the result of some of these functions.
In addition at least one wrapper function magically stops working.
This is impossible since the struct and all variables have absolutely no connection to this. That can mean only one thing,
These aren't bugs caused by Starcode - they are caused by Galaxy itself or the underlying C script.
Right now my best advice is to change the variable arrays to prevent that from happening.
Simple answer.... dont use star code.... Just save to bank with out encryption..... Nobody is really gonna take the time to hack thier banks for an rpg .... and if they do let them... at least thier playing and like your map enough to mess with it right?
first, i dont spend any time on ecryption because starcode does it for me :)
second, i dont believe that anyone will be able to hack the codes since they would have to hack hash + password whats nearly impossible for normal people. the much bigger problem is that it would be possible to create backups of your characters AND exchange your character with other players since there is no possibility to compare player names or anything to ensure the bank is only loadable for a specific player
third, banks are perfectly usable for rpgs because they removed the size limit (hopefully), and in a few weeks ull see whats possible with banks (if there dont appear new strange errors in development process xD)