Author Topic: Padding a string - best practices? (Read 335 times)

Legacy_henesua · « **on:** October 23, 2012, 03:14:17 pm »

I am working on my own persistent cache system. A player, using a shovel, can dig a hole, put something in a hole, and then anyone digging in roughly the same spot can dig it up again. That is the idea.

One problem is how to store the location as a label in the bioware database. The BioDB has a limit of 32 characters for the label. Presently I am using NBDE's Hash function as a fail safe for that, although I will want to learn how to generate a unique Hash of my own soon enough. I don't understand what Knat did with all those bitwise operators.

The second problem is that I want to limit the x and y coordinate information to 3 characters each in the string. And to limit location to a 2meter by 2meter square. As long as someone digs within the 2x2 area, they dig up the same hole. Here's how I generate an ID for that:

[color="#00ff00"]string GetCacheID(location lHole)
{
    // generate ID of cache from location
    vector vHole    = GetPositionFromLocation(lHole);
    object oArea    = GetAreaFromLocation(lHole);

    string sX       = IntToString(FloatToInt(vHole.x/2.0));
    int nsX         = GetStringLength(sX);
    if(nsX<2)
        sX  = "00"+sX;
    else if(nsX<3)
        sX  = "0"+sX;
    string sY       = IntToString(FloatToInt(vHole.y/2.0));
    int nsY         = GetStringLength(sY);
    if(nsY<2)
        sY  = "00"+sY;
    else if(nsY<3)
        sY  = "0"+sY;
    string sCoord   =   "HL"+GetTag(oArea)
                        +sX  // X position in area divided by 2 - max 3 characters
                        +sY; // Y position in area divided by 2 - max 3 characters

    return IntToString(NBDE_Hash(sCoord));
}[/color]

The part I want help with right now is how I am handling padding. Is there a better way to do this? Presently I am checking length of the string of each coord, and adding zero's in front to ensure that the coord is 3 characters long. Any recommendations on a better way to do this?

                     ModifiÃ© par henesua, 23 octobre 2012 - 02:16 .

Legacy_acomputerdood · « **Reply #1 on:** October 23, 2012, 05:46:13 pm »

               FloatToString lets you specify how "wide" the string should be as well as how many decimal places. since you go float -> int -> string, i would imagine you could do FloatToString(sX, 3, 0).

the rounding might be different from how FloatToInt handles it. i'm not sure, and you might not even care.

http://www.nwnlexico...p/FloatToString

other than that, there's no real reason why you can't do it your way. other than to suggest a "helper function" to pad for you instead of doing the same padding routine twice in the code.

                     ModifiÃ© par acomputerdood, 23 octobre 2012 - 04:47 .

Legacy_henesua · « **Reply #2 on:** October 23, 2012, 05:54:11 pm »

               Wow... i had no idea float to string could do that. I'll check it out. Thanks, acomputerdood!

Legacy_meaglyn · « **Reply #3 on:** October 23, 2012, 10:27:06 pm »

               I suspect the width is a limit. I'll be surprised if it zero pads.

Often easiest to do it as an int and check the value.
int foo = FloatToInt(vHole.x/2.0);
string res;
if (foo < 10)
res = "00" + IntToString(foo);
else if (foo < 100)
res = "0" + IntToString(foo);
else
res = IntToString(foo);

Which is basically what you're doing already... oh, and assumes the coords are all >= 0...

Cheers,
Meaglyn

[fixed bad grammar]

                     ModifiÃ© par meaglyn, 24 octobre 2012 - 01:24 .

Legacy_henesua · « **Reply #4 on:** October 23, 2012, 10:36:48 pm »

               Coordinates in a location are always positive numbers and I believe can not exceed 320.

I haven't had a chance to check to see what Float to String does yet with the width.

                     ModifiÃ© par henesua, 23 octobre 2012 - 09:37 .

Legacy_acomputerdood · « **Reply #5 on:** October 23, 2012, 11:08:33 pm »

               (and perhaps you can add a note to the lexicon with your results)

Legacy_henesua · « **Reply #6 on:** October 23, 2012, 11:15:07 pm »

heh.. nice nudge there. '<img

'>

Legacy_meaglyn · « **Reply #7 on:** October 24, 2012, 12:35:41 am »

henesua wrote...

Coordinates in a location are always positive numbers and I believe can not exceed 320.

I haven't had a chance to check to see what Float to String does yet with the width.

Z can be negative can't it?

Legacy_henesua · « **Reply #8 on:** October 24, 2012, 01:32:48 am »

               i am only using x and y. but you may be right about z. sorry i was only thinking cartesian plane for this.

Legacy_Lightfoot8 · « **Reply #9 on:** October 24, 2012, 03:44:22 am »

I guess I am Just feeling left out.

Here is my version.   For the padding question.   Even though if you are using NDBE I dont know why you are worried about the length of the lable.     I can only guess that you are only using the Hash function from NDBE.

#include "nbde_inc"
string GetCacheID(location lHole)
{
    // generate ID of cache from location
    vector vHole    = GetPositionFromLocation(lHole)/ 2.0; // Do the division here.
    object oArea    = GetAreaFromLocation(lHole);

    // Just go ahead and place them in the same number and convert to a string.
    string sXandY = IntToString(FloatToInt(vHole.x)*100 + FloatToInt(vHole.y));

    // Pad the string.
    int nLen = GetStringLength(sXandY);
    if (nLen <6) sXandY = GetStringLeft("000000",6-nLen) + sXandY;

    string sCoord = "HL"+GetTag(oArea)+ sXandY;

    return IntToString(NBDE_Hash(sCoord));
}

Legacy_henesua · « **Reply #10 on:** October 24, 2012, 04:14:34 am »

               Lightfoot, I'm a little confused by what you are doing here.

First, I did not consider dividing the entire vector by 2, but should have. Nice.
Second, I am confused by the multiplication of x by 100. and yet y is unchanged. Why did you do this?
Third, why pad x and y together?

The reason why I was padding x and y is that I wanted to guarantee that the coordinates were consistent. My intention is to use them as a key into the database. Every 2 meter square in a digable area will potentially have a cache in the database. If a PC or NPC digs in the same 2x2 square where something was buried earlier, they'll find it.

I might not need to be as careful as I am, but... I figure if I am as careful as possible I figure I am eliminating the possibility of ambiguity.

Does your code achieve the same results? Is it impossible to arrive at ambigous results with the code you posted?

Legacy_Lightfoot8 · « **Reply #11 on:** October 24, 2012, 04:41:10 am »

               Yes I understand what you are tring to do. the code I posted does the exact same thing that your original code does.    It is already given(from the posts above) that none of your areas are larger then 32 X 32. you will end up with numbers for x and y that are in the 0- 160 range.   hence the reason that you chose to use 3 digit numbers.

I see your confusion,   oops,   Change that 100 to 1000.

so if x = 50 and y = 20 XandY will be 50X1000 + 20 = 50020. The same number you where getting before.   all that is left is to pad it.

I gave the option to pad up to the 6 characters just incase x was equal to 0. right?

if x = 0 and y = 1 then XandY = 0*1000 + 1 = 1 You need to pad 5 zero's onto it for your paked cord.

if (nLen <6) sXandY = GetStringLeft("000000",6-nLen) + sXandY; // will pad them all in at once without a long (else if) chain.

----------

Also, If you want to be carfull, Don't use the HashCode from NBDE, I will guarantee that you will end up having colission using it.

Legacy_henesua · « **Reply #12 on:** October 24, 2012, 04:47:38 am »

               ah got it. thanks.

I'll look into the hashing later. At present I've changed how and when i use the hash. I am now only using it when my area tag is too long, and only on a portion of my area tag.

Legacy_Melkior_King · « **Reply #13 on:** October 31, 2012, 10:22:59 am »

               string sResult=GetStringRight("00"+IntToString(iNum),3);

This assumes that your result will never be more than 3 digits. If it does become more than 3 digits, only the lowest 3 digits are kept.

Legacy_meaglyn · « **Reply #14 on:** November 01, 2012, 12:07:15 am »

Melkior_King wrote...

string sResult=GetStringRight("00"+IntToString(iNum),3);

That's elegant. I like it!
I bet it's faster to do the numeric compares and just a single function call. But it's hard to argue with one line simplicity '<img

'>

Bioware Archive

News:

Author Topic: Padding a string - best practices? (Read 335 times)

Legacy_henesua

Padding a string - best practices?

Legacy_acomputerdood

Padding a string - best practices?

Legacy_henesua

Padding a string - best practices?

Legacy_meaglyn

Padding a string - best practices?

Legacy_henesua

Padding a string - best practices?

Legacy_acomputerdood

Padding a string - best practices?

Legacy_henesua

Padding a string - best practices?

Legacy_meaglyn

Padding a string - best practices?

Legacy_henesua

Padding a string - best practices?

Legacy_Lightfoot8

Padding a string - best practices?

Legacy_henesua

Padding a string - best practices?

Legacy_Lightfoot8

Padding a string - best practices?

Legacy_henesua

Padding a string - best practices?

Legacy_Melkior_King

Padding a string - best practices?

Legacy_meaglyn

Padding a string - best practices?