The lexicon entry (both off and on line) for the function string VectorToString(vector vec) says -
Essentially a debug function that returns a string representation of the vector parameter formatted as follows:
(xAxis yAxis zAxis)
The actual output looks like this (at least in EE) -
( 7.420290947, 10.219032288, 0.000001833)
Notice that in actuality each number is separated from the next by a comma and each has Seven(!!!) leading spaces. So the formatting that the lexicon says that function returns is quite simply wrong. Can someone please correct this lexicon entry.
Yes, this is an artifact of them only translating the data-types, not doing anything to clean them up/make them presentable. In their place I would have trimmed the leading spaces, that’s for sure.
What they have done is to use a couple of default values (that I didn’t know about until I set about writing my own version of the function in my original post). From the Lexicon -
string FloatToString(
float fFloat,
int nWidth = 18,
int nDecimals = 9
);
Parameters
fFloat → The float to convert into a string.
nWidth → The number of numeric positions to the left of the decimal. If zero, the whole part left of the decimal is displayed without trailing spaces. (Default: 18)
nDecimals → The number of numeric positions to the right of the decimal (precision). (Default: 9)
TBH, I think that function was just quickly slung together when the game was initially being developed and was only meant to be temporary. Then it was forgotten about until after the game first launched when it was too late to delete that function.
Remember, the actual string returned separates those values with commas. On the lexicon page the returned value uses spaces to separate the values. So in that respect the Lexicon is wrong. I spent time having to write debug code to find why my code wasn’t working only to find it wasn’t my code at fault. Yes it may be nit-picking but to me it is important that the lexicon be as accurate as possible.
The comments on the function (it’s not a base function) say that it’s there to debug the LocationToString function only (and it’s only used by that in the base game scripting, didn’t check what that’s used by).
Floodgate nwscript is generally not bad, but the positional functions are a bit shaky anyway: use the math library from squattingmonk, or similar instead.
Not in the Lexicon. Did you mean in the source code? That is not what I am talking about. I am talking about the Lexicon entry for VectorToString(). Anyway, while I have yet to test it, I have written my own function to replace it. Once I am satisfied with that, I will move onto LocationToString().
As Lokey says this isn’t even a base game function. You should be reading the code in the include file if you want to know how it works, not relying on the Lexicon which is patchy at best on them.
Posting an entire thread to nitpick a tiny part of a description of a include function is wild man.
Anytime I edit one of these I add a banner to the page to explicitly call this out, and have been tempted to remove them entirely in the past since they just confuse people apparently and cause me a headache since most of them are wrong in some way.
I’ve edited the page explicitly calling it out as a debug function and even put the code there. Need to find time to banish a few hundred more pages to the “It’s written in an include file” hell so it’s clear.
Btw the lexicon is partly wrong here as parameter nWidth is NOT the number of numeric positions to the left of the decimal but the (desired) length of the returned string (including the decimal and number of numeric positions to the right).
Fwiw, I don’t think the lexicon should be limited to “syscall” functions of nwscript. Removing all the functions documented for include files shipped with the game would be a mistake. And considering them not base game functions even though they ship with the game seems like an odd distinction.
In this case I think it’s “code useful for debugging”. But my comment was more general than for this particular function. There are lots of useful things in the base game include files which really do belong in the lexicon. Saying they are not “base game” because they are in include files is the part I was objecting to. Whether or not this one is a “debug” function is immaterial …
It is, and that’s kind of the point of my tounge in cheek comment. Functions that are actually useful for debugging persist for exactly that reason, and due to that, they’re useful to have good documentation for. Saying they’re “not base game” because they were debugging or temp fix code that was someones include (which was included in said “base game”) misses the fact that these functions are oftentimes useful for people.
(Though in the case of this specific one, I do strain to see the use of it in the way it’s implemented)
I do have a use for a usable version of this, otherwise I wouldn’t have come across it in the first place. But I do agree on your comment otherwise, which is why I have created my own version.
So what does having zero as that parameter do then? Is that still as it says in the Lexicon description? I’ll need to look at the source of that function myself.