View previous topic :: View next topic |
Author |
Message |
Grumalg
Joined: 04 Nov 2005 Posts: 70
|
Posted: Sat Dec 16, 2006 16:50 Post subject: Stock sSpacer size should be larger |
|
|
When I first looked at the nwnx4 stuff I noted in passing that 128 bytes for sSpacer was going to be too small to pass locations and made a mental note. Unfortunately, I had lost that note when the 'Encode Function truncating long strings?' thread appeared. This problem was found to be a result of the 128 byte size of sSpacer.
I think the stock sSpacer size should be 256 bytes. Beyond locations, CHAR and VARCHAR large fields which can be up to 255 (MySQL 5.0.2 and down) would then pass without end user encountering a problem. This would eliminate a lot of 'newbie' end user frustrations.
TEXT, BLOB and VARCHAR (MySQL 5.0.3 and above) would still require adjusting the local string buffer size. This should be prominantly noted in the nwnx docs.
A side effect of auto init is that there is no longer a nice place to set up larger than stock buffer size. I think it would be a good idea to add a
NWNXSetBufferSize(<multiple of stock size>)
function to nwnx_include. Such a function would allow dynamically changeing the buffer size whenever required while still keeping it small most of the time.
<edit added> Such a function could also be used to restore buffer size after useing NWNXGetPluginDescription, which does not restore the size after it's been used.
--- Grumalg --- |
|
Back to top |
|
|
Grinning Fool
Joined: 12 Feb 2005 Posts: 264
|
Posted: Sat Dec 16, 2006 20:17 Post subject: |
|
|
Quote: | NWNXSetBufferSize(<multiple of stock size>) |
But that would also require storing the buffer on a local variable as opposed to a string constant; my concern with that we'd now be incurring an additional local variable access for every SQL* command. _________________ Khalidine, a NWN2 persistent world
Looking for volunteers. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Sat Dec 16, 2006 22:37 Post subject: |
|
|
While I don't see the point of passing a persistent location through the encode function, it surely makes sense to support the largest varchar column size with the small column buffer. Agreed. _________________ Papillon |
|
Back to top |
|
|
Kallistor
Joined: 09 Dec 2006 Posts: 13
|
Posted: Sat Dec 16, 2006 22:46 Post subject: |
|
|
Yep the location doesnt need to be passed through the encode function but as long as a single function of SetPersistentString is used as the way to write the majority of items to the database then the location has to go through the Encode function. I dont mind the smallColSpacer being extended, I have already done that up to 169 chars, but if it is only the location string that we are extending it for then I suggest that the length of the location string be reduced and I would first suggest the number of decimal points that are stored. Even when I am being super particular in the toolset placing a placeable I will only ever go to 2 decimal places so why do we need 9 decimal places on X, Y, Z and orientation? There is 28 chars saved right there |
|
Back to top |
|
|
Grumalg
Joined: 04 Nov 2005 Posts: 70
|
Posted: Sun Dec 17, 2006 0:49 Post subject: |
|
|
Grinning Fool wrote: | Quote: | NWNXSetBufferSize(<multiple of stock size>) |
But that would also require storing the buffer on a local variable as opposed to a string constant; my concern with that we'd now be incurring an additional local variable access for every SQL* command. |
It wouldn't be used every time, only when you needed to pass a large value.
--- Grumalg --- |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Sun Dec 17, 2006 10:29 Post subject: |
|
|
Pap, why don't you just make a new string (new str[len]) in NWNX and give it to the SetLocalString function? |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Sun Dec 17, 2006 11:24 Post subject: |
|
|
Grumalg wrote: | Grinning Fool wrote: | Quote: | NWNXSetBufferSize(<multiple of stock size>) |
But that would also require storing the buffer on a local variable as opposed to a string constant; my concern with that we'd now be incurring an additional local variable access for every SQL* command. |
It wouldn't be used every time, only when you needed to pass a large value.
|
Like with SQLGetDataText, i.e. a dedicated function that uses a larger buffer that is stored on the module after first use ? SQLEndcodeText ? Since switching dynamically from small to large buffer based on the amont of data (i.e. strlen) would slow things down considerably. Anyway, I am expecting a solution to the whole buffer Set/Get thingy soon, so I suggest the discussion should be postponed a bit.
virusman wrote: | Pap, why don't you just make a new string (new str[len]) in NWNX and give it to the SetLocalString function? |
Because the original (nwscript) string buffer would then be unreferenced and the server would start to leak memory. _________________ Papillon |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Sun Dec 17, 2006 23:35 Post subject: |
|
|
Papillon wrote: | virusman wrote: | Pap, why don't you just make a new string (new str[len]) in NWNX and give it to the SetLocalString function? | Because the original (nwscript) string buffer would then be unreferenced and the server would start to leak memory. | You can free() it.. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Tue Dec 19, 2006 0:08 Post subject: |
|
|
virusman wrote: | Papillon wrote: | virusman wrote: | Pap, why don't you just make a new string (new str[len]) in NWNX and give it to the SetLocalString function? | Because the original (nwscript) string buffer would then be unreferenced and the server would start to leak memory. | You can free() it.. |
Uh... it might be the case that you never fiddled with the heap of the server. Freeing the memory of a different heap (remember, we are inside a DLL here) is something I am not trying to do. I was thinking about doing it some time ago, but then depraved that thought, because it became to complex IMHO. _________________ Papillon |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Tue Dec 19, 2006 8:02 Post subject: |
|
|
Papillon wrote: | Freeing the memory of a different heap (remember, we are inside a DLL here) is something I am not trying to do. | Why? |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Tue Dec 19, 2006 21:57 Post subject: |
|
|
virusman wrote: | Papillon wrote: | Freeing the memory of a different heap (remember, we are inside a DLL here) is something I am not trying to do. | Why? |
Because my attempts crashed the server, no matter how or where I got the heap from. _________________ Papillon |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Wed Dec 20, 2006 13:06 Post subject: |
|
|
Papillon wrote: | Because my attempts crashed the server, no matter how or where I got the heap from. | There is another way, then.
- char *output = new char[len];
- Call the original function using "output" variable
- delete output;
- The original variable would be freed by the script VM.
It's just an assumption, though. I don't have enough time to analyze the disasm now. |
|
Back to top |
|
|
caloup
Joined: 29 Sep 2006 Posts: 59 Location: albi (france)
|
Posted: Thu Dec 21, 2006 9:17 Post subject: |
|
|
Just an idea...
Why do you want to increase the spacer for location ?
Just "cut" your location in two persistent string !...
For exemple in place of :
Quote: |
string SQLLocationToString(location lLocation)
{
object oArea = GetAreaFromLocation(lLocation);
vector vPosition = GetPositionFromLocation(lLocation);
float fOrientation = GetFacingFromLocation(lLocation);
string sReturnValue;
if (GetIsObjectValid(oArea))
sReturnValue =
"#AREA#" + GetTag(oArea) + "#POSITION_X#" + FloatToString(vPosition.x) +
"#POSITION_Y#" + FloatToString(vPosition.y) + "#POSITION_Z#" +
FloatToString(vPosition.z) + "#ORIENTATION#" + FloatToString(fOrientation) + "#END#";
return sReturnValue;
} |
put 2 functions :
Quote: |
string SQLLocationToStringPart1(location lLocation)
{
object oArea = GetAreaFromLocation(lLocation);
vector vPosition = GetPositionFromLocation(lLocation);
float fOrientation = GetFacingFromLocation(lLocation);
string sReturnValue;
if (GetIsObjectValid(oArea))
sReturnValue =
"#AREA#" + GetTag(oArea) + "#POSITION_X#" + FloatToString(vPosition.x) +
"#POSITION_Y#" + FloatToString(vPosition.y);
return sReturnValue1;
} |
and :
Quote: |
string SQLLocationToStringPart2(location lLocation)
{
object oArea = GetAreaFromLocation(lLocation);
vector vPosition = GetPositionFromLocation(lLocation);
float fOrientation = GetFacingFromLocation(lLocation);
string sReturnValue;
if (GetIsObjectValid(oArea))
sReturnValue =
"#POSITION_Z#" +
FloatToString(vPosition.z) + "#ORIENTATION#" + FloatToString(fOrientation) + "#END#";
return sReturnValue2;
} |
And you SetPersistentLocation should be :
Quote: |
void SetPersistentLocation(object oObject, string sVarName, location lLocation, int iExpiration =
0, string sTable = "pwdata")
{
SetPersistentString(oObject, sVarName1, SQLLocationToStringPart1(lLocation), iExpiration, sTable);
SetPersistentString(oObject, sVarName2, SQLLocationToStringPart2(lLocation), iExpiration, sTable);
}
|
...
Then when you want to Get your Location...:
Quote: |
location GetPersistentLocation(object oObject, string sVarName, string sTable = "pwdata")
{
return SQLStringToLocation(GetPersistentString(oObject, sVarName1, sTable)+GetPersistentString(oObject, sVarName2, sTable));
}
|
Now you dont have a truncked location ! |
|
Back to top |
|
|
Gryphyn
Joined: 20 Jan 2005 Posts: 431
|
Posted: Thu Dec 21, 2006 10:08 Post subject: |
|
|
"#AREA#" + GetTag(oArea) + "#POSITION_X#" + FloatToString(vPosition.x) +
"#POSITION_Y#" + FloatToString(vPosition.y) + "#POSITION_Z#" +
FloatToString(vPosition.z) + "#ORIENTATION#" + FloatToString(fOrientation) + "#END#";
This always bugged me...
Here's 40+ characters removed
"#A#" + GetTag(oArea) + "#X#" + FloatToString(vPosition.x) +
"#Y#" + FloatToString(vPosition.y) + "#Z#" +
FloatToString(vPosition.z) + "#O#" + FloatToString(fOrientation) + "#E#";
At any rate you only need a single seperator, #?# simply makes it easier to read.
Cheers
Gryphyn |
|
Back to top |
|
|
caloup
Joined: 29 Sep 2006 Posts: 59 Location: albi (france)
|
Posted: Thu Dec 21, 2006 18:51 Post subject: |
|
|
yes ! It's more simple ! |
|
Back to top |
|
|
|