PDA

View Full Version : Random Neat GScript Stuff


100Zero100
01-14-2014, 05:07 PM
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!

client.flag--; //On the clientside, won't update serverside
BUT
client.flag = client.flag - 1; //This will

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

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:

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:

//#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:

//#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.

Emera
01-14-2014, 07:34 PM
As far as your examples demonstrating issues with scope go, I've had some weird ass issues with scope too. For example, calling a function from a single scope that involves using with() or something else that should temporarily switch to/back from a specified object scope and have it return a value will also return the object's scope, switching the entire code's scope from that point onward (1 for every time I said scope)

These are cool though. Thanks for bringing them into public light.