#ironsphere

[kyred808-blog]

Leveling and Big Numbers

Tribes 2 has a problem when it comes to big numbers.  After a point, the engine starts to represents the numbers in scientific notation.  For example, 2.86543+e08.  Unfortunately, decimal precision is thrown out the window when this happens.  Typically, this is fine, because the difference between say 2,000,000 and 2,000,000.01 is insignificant in the grand scheme of things.  But for some applications, the precision is needed.  Determining EXP for levels in TRPG is one of those applications, where a precise and consistent value is nice to have.

This has an impact on calculating exp required for the next level in Tribes RPG.  I think Tribes 1 had this problem too, because the code defines an OldGetLevel() and OldGetEXP() methods which are similar to the methods used in T2RPG.

I’d rather not have the max level be 110, which is where the old method breaks down.  So I ported over the new method to T2RPG.  The difference is that now all levels require 1000 exp, but the exp received from bots rapidly scales down as you pass them in level.  This helps keep the numbers small.

Edit:  Tribes Next has created a workaround for the big number issue (more info here http://www.tribesnext.com/forum/index.php?topic=2359.0;wap2) by packaging their patch with a Ruby interpreter.  Problem is that calls to this interpreter from Torque Script occur on the order of milliseconds.  Which is slow compared to microsecond time span that Torque normally operates.  While this isn't that big of an issue for calculating levels, it is far from ideal.  I’m afraid of someone writing a script that checks their level every second and then 20 people use it and slow down the server.

[kyred808-blog]

The Smell of Zones

One feature from T1RPG that I found neat was the “lastScent” data that the server stored for each player.  The idea is that every so often, the player will leave a “scent”, which is used when other players are trying to track them (with the #track skill).  But the higher a player’s SenseHeading skill, the less likely you are to leave a new “scent.”  The idea is that you are better at covering your tracks, since you are an experienced tracker yourself.  And if the player is actively hiding, then they never leave a new scent, regardless of their SenseHeading skill.

The server only stores one “lastScent” value per player.  So the #track ability only locates the last scent a player has left.  So if someone was trying to hunt you down, you could try to deliberately leave a scent somewhere (using #track on yourself to check) and then use #hide to stop leaving scents.  Sending the pursuer on a wild goose chase.

I added this functionality back into T2RPG.  In doing so, I found that T2RPG did not make calls to ZoneUpdate() (but has comments saying that they didn’t use it because they couldn’t get it to work), which is where the storeData for “lastScent” occured.  So, in order to get “lastScent” to work, I ended up implementing the RecursiveZone() function, which called ZoneUpdate() on all players ever 2 seconds.  Yay, scope creep.

ZoneUpdate() in Tribes 1 performed several things:

Update the player’s current zone

Perform environmental damage to player

Decrease ticks for temporary stat bonuses

Check to see if the player has moved, and potentially leave a scent

For Tribes 2, I left out 1 and 3.  Setting the player’s zone is now handled by entering and leaving trigger boxes around zones.  I think this is better than the old method.  And stat bonuses are handled be a work around, which was created because ZoneUpdate wasn’t working.  I’ll have to see if that method is better or not.

In the past few days (before starting this blog) I’ve made quite a bit of progress.  Once I get the backend fixed up, I can start work on the more obvious bugs.