Thursday, November 10, 2011

Some more info/updates on alpha 25 (update)

Well, besides a ton of problems and my GUI framework making trouble instead of helping me, etc, there are some good things as well.

For example, I added two splitters as you can see here, and you can also show/hide the categories. Oh yeah, and I made a small, ugly icon to show whether the items are displayed ascending or descending. Sorting is only (partially) implemented for the inventory so far.

You could hide the stuff you don't need. :)

However, all these things that we may take for granted, don't come without problems. For example, the small icons changes their position, right-aligning does not work anymore, and when you have hidden the the stuff with the splitter, they pop out again (just a bit) when you resize the window. I'll blame wxWidgets, only again (I guess it's not supposed to be easy.)

Update:
As you may have noticed, this release is taking some time to get ready for release. I have had tons of problems just so that I could actually start working on the stuff I wanted to work on.

For instance, I decided to upgrade wxWidgets (to get rid of bugs, I hope(d)). That meant that some of my code wouldn't be compatible anymore. That's one thing I have been working on (making it compatible).

Now, I was lucky(?) enough that my GUI editor (wxFormBuilder) made incompatible code as well! Luckily (really), it was just a small thing, and the GUI editor is open-source, so I managed to fix it by myself eventually.

So far, so good! At least until I saw that the splitters I added earlier now made the background color just gray (not white, like it should). Nothing made it use the Windows theme's white color. Not even setting the color manually. So... I did a pretty big makeover which caused lots of organizing code and what-not.

Sorry for my bad english i'm french. So i've goods news for you guys.I finally understood how to edit the weapons properties. For "dur/han" you can put 65535, it's the max. For "Level", that's where it gets tricky. First,You have to do x8 the number of the level you want. For example if you want a weapon lv50 you put 400...Then you have to add to that number +0 to +7 to edit the color of the weapon (which means to increase weapon's power). white : +0 or +5, blue : +1 or +6, green : +2 or +7, purple : +3, orange : +4(the best).To sum up if I want the best weapon properties, put 404=lv50 and orange. For example, if I want an orange weapon lv20 I'd put 8X20+4=164...

Still the french guy doing the math.To have a white weapon lv30, put the number 8x30+1=241 or 8x30+5=245 in "Level" (propeties...To have a purple weapon lv10, put 8x10+3=243...Let me know if what i'm saying is not understandable.

Ok i tried it out what the other guy found out, it works so far, as it creates a weapon of that level, and the said color.

Yet the current durability bar looks a bit weird if you put 65535.. it is half empty... yet the weapon sais it is 100% repaired. So there may be a need to find out how this value really works....

What i also noticed: the damage for orange weapons seem to be low.. i have green weapons that i normally found in the game, that do more damage. So i am assuming that this value in "level" can somehow also influence damage, so we may still have to figure out how to do that.

Ok i tried to reverse engineer a number from a found weapon, having this newly found out knowledge.

A green weapon lvl 24 with the "level" value of 47297. In Hex that is B8C1 and bitwise it is 1011 1000 1100 0001.

With what was found out above, green+24 is 193. And now guess what, 1100 0001 or C1 translates exactly into 193 - so the lower 8 bit are the weapon level + color.

The said weapon in question has 405dmg and 205force. But i am unsure yet how to get this into the upper 8 bits. The upper 8 bits translate to 47104 in decimal, or if you just take the the 8 bits for themself into 184 decimal. Now if we can figure out how to get 405dmg and 205force into this we may have finally found out how this value exactly works.

Maybe the dmg+force work in some sort of levels? That each of them has x possible levels, that are then bitwise in there again? Like 4 bits=lvl dmg and 4 bits=lvl force? It for sure seems impossible to put 405 and 205 into this somehow, so it seems to be coded differently.

Yet when i changed one of those 4 bit pairs for testing purposes, the resulting weapon was lvl 60 (i didn't touch the lower bits at all), with 0dmg 0force 0durability - why the heck did the durability value change, wasn't that one supposed to be in the other value? And why was the weapon suddenly lvl 60 when the lower bits were not changed at all?

Looks like this is a bit more complicated than you may guess on a first glance. But i bet what was found out will help us out in the long run a lot

After another "bitchange" in the "level" value, the weapon changed dmg+force+durability+handling

What makes me guess that the comple thing, is one huge bitwise number somehow? So the level+durability/handling isn't 2 16 Bit numbers, but instead one huge 32Bit number? At least this would explain why all 4 values changed this time, and why the bitchange before caused such chaos.

This time the weapon stayed lvl 24.. green.. the damage went down to 397, the force down to 185, the durabilit up to 46 from 37, the handling from 63 to 66, and the durability bar from full to about 75-80%

So this really screams "i am one complete 32 bit number" to me, and also explains while the setting to 65535 gave this "weapon is 100% repaired, but durability bar is only to 70%" kind of behaviour.

I am assuming this 32 bit number has level+color+dmg+force+current durabilit+max durability+handling in it somehow

Oh and sorry for spamming the comments.. lol.. i just think we may be close to something there, to me it seems that the values are in there bit wise, the level data having 5 bits.. and the color data 3 bits - what just gives this behaviour that other one found out, as the lvel data is "shifted up". But as the values are not just 4 bit wise (the level would be 12 then instead of 24, only when 5 bits are used it becomes 24), it may take some time to figure which bits represent what.

So far the last 8 bits of the "level" number (the C1 or 1100 0001 from the above example) are 5 bits for the level (11000 what is exactly 24) and 3 bits the color (so i am guessing 000 is white, 001 blue, 010 green, purple 011, and organge 100 - what also explains why green, purple and blue have 2 values, as the "orange" bit seems to be ignored in such a case)

So 8 out of 32 bits identified, now to find out what the other 24 bits means - the unfair part is, that the developer seems to just use the number of bits needed, and why lvl 60 is max now... 5 bits allows for a max value of 63....

What means the other values can take up any number of bits in there - and i am still wondering why changing one single bit changed all values of the weapon in one of my tests.. maybe there are also some "unused" bits in there that cause trouble

Wow.. Hey don't worry about the spamming here because it helps a lot :OActually, the value is indeed read from the game-save as a 32-bit number.There' a lot of new info here so I'll look more into it a bit later (since I am so busy fixing things up in alpha 25 right now). (And I'm making extra efforts!)

I think the level info are actually at least 6 bits, as you need 6 bits to represent the value 60... wondering if they maybe put an extra bit in there for later level increases? That could mean that actually 6-7 bits are used for the level, what means that 9-10 bits out of 32 are identified then.

I just noticed that the next two bits after those 5 always seems to be 00 in my savegames.. my weapons are all around 18-29, so one more is needed for lvl 60.. and maybe the other is a reserve bit for possible level increases? Just guessing here though.

even though the mcall's and other pistol I added was orange they was actually inferior with roughly the same stats as each other as followed mcalls:DAM: 440, ACC: 86, RoF: 150, Rld: 20

So ya there must be something else to it, additionally i've noticed this behavior in game legitimately, i've ran across white weapons that beat orange colored weapons even if they was the same level.. or even below.. for example I found a nice (white) short shotgun at lv45 that did not get surpassed until a green one at lv56, even though there are a purple and a green one as rewards "lab/prison"

or a prefect example is mantutero in the jungle gives you a green auto rifle but has never beaten regular white ones that I've already picked up of the same level.

so it's weird how even legit in the game items color doesn't always mean better.

(french guy talking)Yes a legitimately found weapon has 5 numbers in "Level" propertie... And I didn't figure out why, but with only 3 numbers I can edit lv and color.If you do the math the way I said before : 8x(Lv you want)+4(orange) it works.And I guarantee you, for the melee weapons you'll get the best properties.

I assume that it didn't work as well for firearms...

Speaking of "dur/han" if you put 65535 and then you go to repair your weapon normally it works.

Sure there is still a lot to do if we want to edit dmg+force+current... But untill someone figure out the 5 numbers explanation, 3 numbers is enought to edit lv and color.

Again... you cannot see the "level" and "dur/han" as 2 different numbers, i just have proven yesterday that those are no 2 16 bit numbers... but a single 32 bit number... well not really a number, more like a "blob" that is used bitwise.

What you found out works, cause it is the very lowest 0-8 or 0-9 bits that store the leveldata and color of the weapon. You using this *8 is basically a bitwise shift, that pulls the leveldata to the upper 4 bits, what makes it work. But overall it was a huge "by chance" thing that you are doing, one that helped me figuring out a little bit more.

Basically techland divided the number into several "storage bits", that just are like true/false, or "on/off" for special properties, or that have values like level or color in there.

I have also found out, that the leftover bits are too less to store the direct dmg/duration/force/handling values. So those may be a bit harder to decipher, how they are hidden in there.

But your initial work helped me to find out more about it - it is a big and huge luck that it works this way, but as i said this is cause your *8 thing means a bitshift on the bit level.