Since I've finally got an active forum account, I'll share with you guys some stuff that I've noticed in GS over the years that I felt didn't make sense / didn't behave as expected. I would consider them "Gscript glitches," if you will. Some of these will be useless to you (just for fun/interesting), while others might actually matter someday!
NPC Code:
client.flag--; //On the clientside, won't update serverside
BUT
client.flag = client.flag - 1; //This will
NPC Code:
this.attr[] = DBNPC.x; //Assumes you want to write DBNPC.attr
BUT
temp.x = DBNPC.x;
this.attr[] = temp.x; //Knows you want to write this.attr
NL's can be saved in strings. Can't be saved in string arrays. I am pretty sure this also applies to "\n" - this came up a long time ago when I was thinking about making a function for say2 that determined the line size (I ended up doing a line size system that works great instead of a wrap system), and I noticed that NL's weren't saving in line arrays. At the time, I just decided to put #b's in there (lol).
I've also noticed that if you attempt to write a showcharacter()'d DBNPC's nickname and several other personal features ('character' appearance: hat, head, maybe AP, etc), you cannot do it too quickly. If you attempt to write it more than like once a second or so (I forget) it just prevents you from writing it.
Similarly, ANY object without a default name (a new TStaticVar(); a temp.img = showimg(); etc) will allow you to write its .name once, but after that, its .name becomes read-only!
putnpc2 NPCs on a level default to having a level index of 300 (and increasing). This isn't a bug, I just thought it was interesting.
When last I checked, attempting to do a scheduleEvent() loop inside of a gani broke the entire gani script (even parts of the script that were unrelated!). You must stick to using onTimeOut's
NPC Code:
function onCreated() {
this.attr[5] = "100Zero100";
temp.a = this.attr[5];
}
//#CLIENTSIDE
function onCreated() {
temp.b = this.attr[5];
temp.c = this.attr[5] @ "";
}
temp.a (serverside): 100Zero100
temp.b (clientside): 100
temp.c (clientside): 100Zero100
Generally speaking: If you attempt to pass a this.attr[] (and maybe player.attr[]'s too?) from server to client (and maybe also client to server), and it BEGINS with a number, the game will assume the entire .attr[] is an INTEGER (and will truncate after the first period, comma, or text). Setting something to this.attr[] @ ""; apparently changes its datatype and fixes it.
Related to:
NPC Code:
temp.a = "";
temp.b = 0;
(a == b): true
(@a == @b): false
^ Similar to having to do "@ """ to fix the datatyping of client-passed this.attr[]'s earlier, it seems you must use @ in front of a variable for the system to datatype and realize that "" (string) is NOT 0 (var). Knowing this, earlier putting "@this.attr[5]" probably would've fixed that.
if (true || undefined) { // Yields FALSE, despite true || ANYTHING should be true. "undefined" being in this case any non-logical operator (eg, this.hi = 2).
temp.a = {0,0};
temp.b = {{1,1},{2,2}};
Say you want to turn that into:
temp.c = {0, 0, {{1, 1}, {2, 2}}};
You would think .add() or .addarray() would work. But nope!
temp.a.add(b)
yields:
{0,0,{{{1,1}},{{2,2}}}}
temp.a.addarray(b)
yields:
{0,0,{1,1},{2,2}}
To get the effect you want:
temp.c = a @ "," @ b;
This last one is truly bizarre:
NPC Code:
//#CLIENTSIDE
function onCreated() {
with (npcs[0]) {
player.chat = this.name SPC thiso.name;
}
}
^ In a weapon NPC ("test").
What I would expect: MY (player) chat to be set to the name of npcs[0] (probably "" or "level_npc_34626" or some other text like that) followed by "test" (the name of the weapon)
What I got: A random NPC in my level (presumably npcs[0]) had ITS chat set to "test test"
However, once I changed the script to:
NPC Code:
//#CLIENTSIDE
function onCreated() {
with (npcs[0]) {
playero.chat = this.name SPC thiso.name;
}
}
Yes, playero.chat. Once I changed the script to playero.chat, MY (player) chat was set properly, but "this.name" still yielded "test"
I'm still stumped by that. I suppose it only even makes sense if npcs[0] was considered to be a player in my level. Even so, then it should be setting a player's chat and not a random NPC's chat. And I don't think playero. is an official prefix anywhere, so I have no idea.