thiso with strings but not variables?

[EmpireOwnsYou]

I tried accessing a variable is thiso inside of a get npc, and it would not work, but it worked fine with a string. Why is this? (I fixed my problem already with a differant solution, just wondering why?)

[Admins]

Originally Posted by EmpireOwnsYou

I tried accessing a variable is thiso inside of a get npc, and it would not work, but it worked fine with a string. Why is this? (I fixed my problem already with a differant solution, just wondering why?)

In the old scripting engine there are thiso. string variables but not thiso. numeric variables. In the new scripting engine both work.

[EmpireOwnsYou]

Originally Posted by Stefan

In the old scripting engine there are thiso. string variables but not thiso. numeric variables. In the new scripting engine both work.

I'll have to try learning the new scripting engine some time.
Is it very powerful? Like can do more with it than regular gscript?

Btw thanks for moderating the post...

[Gambet]

Originally Posted by EmpireOwnsYou

I'll have to try learning the new scripting engine some time.
Is it very powerful? Like can do more with it than regular gscript?

Btw thanks for moderating the post...

It's object oriented and it is strict. A lot stricter then the old scripting engine.


....Yes, you can do more with the new scripting engine.

[Kaimetsu]

Originally Posted by Gambet

It's object oriented and it is strict. A lot stricter then the old scripting engine

In what way?

[Gambet]

Originally Posted by Kaimetsu

In what way?

setshape ,32,32;

would not work in GS2, but would work in GS1, rather


setshape 1,32,32;


would work in both.

[Evil_Trunks]

Originally Posted by Kaimetsu

In what way?

you have to do things correctly

[Gambet]

Originally Posted by Kaimetsu

That's not what weak typing means.

That's what I was taught in my computer class (not programming exactly..just the basics on computers and typing and such). I was taught that it is a strict system that only allows a few exceptions (meaning lazy scripting) to the strictness (if that is a word?) of the system, so as long as the system can understand what you are trying to command it to do/perform. If that is not the definition, then please educate me.

Originally Posted by Kaimetsu

I think that's the third time you've repeated yourself. You claim doesn't become any more persuasive just because you've reiterated it. So far you've given only one example to support your statement, and we've already seen that it is factually inaccurate!

My example was accurate. It seems recently Stefan made the system less-strict. Nonetheless, I think it's fairly obvious that GS2 is more strict. Why? Because unless Stefan made it less strict(er), then you wouldn't be able to pull off things you can on GS1 to GS2. GS2 is a more strict system, so that would make it strict(er) than GS1.

[Kaimetsu]

Originally Posted by Gambet

That's what I was taught in my computer class (not programming exactly..just the basics on computers and typing and such). I was taught that it is a strict system that only allows a few exceptions

I will charitably assume that it is the fault of your school, and then tell you that your school sucks.

My example was accurate

Whether or not it previously was, it certainly isn't any longer. The point is that GS2 is supposed to be backwards-compatible. Meaning that, in principle, it should accept anything that would be acceptable in GS1. How can it possibly be more strict?

I think it's fairly obvious that GS2 is more strict. Why? Because unless Stefan made it less strict(er), then you wouldn't be able to pull off things you can on GS1 to GS2

...what?

GS2 is a more strict system, so that would make it strict(er) than GS1.

Nice tautology there. But it's still rooted in an unsupported assertion.

[Gambet]

It is backwards compatible, but not EVERYTHING works.

Did you see what happened to Era? When they moved everything from their dev server to their main server (when they added GS2), they had to close Era down because not everything worked as it should. The GS2 system is strict, and although it is backwards compatible, it is backwards compatible only to GS1 commands that were scripted correctly.

setshape ,32,32;

That is not correct. GS2 would not understand that, yet GS1 would.


NOW it's different since Stefan made the system less strict. Just not sure how less strict he made it.

[Kaimetsu]

Originally Posted by Gambet

It is backwards compatible, but not EVERYTHING works

By design? The Graal client is still being developed. The incompatibilities are not parts of the language; its syntactic and semantic features are wholly distinct from its software implementation.

setshate ,32,32;

That is not correct. GS2 would not understand that, yet GS1 would

1) Untrue. I don't know why you're making this claim after it's been so unequivocally disproven.
2) To speaking of GS2 "understanding" an expression is meaningless. It's a language, not an interpreter.

[Gambet]

Originally Posted by Kaimetsu

1) Untrue. I don't know why you're making this claim after it's been so unequivocally disproven.
2) To speaking of GS2 "understanding" an expression is meaningless. It's a language, not an interpreter.

Oh, yes, I forgot who I was talking to. My mistake on using the wrong word, even though you knew what I meant .



Anyways, my example WAS true. I don't believe it's been announced anywhere that GS2 has become less strict, so before Stefan posted what he did, I was still correct.

[Kaimetsu]

Originally Posted by Gambet

Oh, yes, I forgot who I was talking to. My mistake on using the wrong word, even though you knew what I meant

Don't be stupid. If you don't state your beliefs in a precise, meaningful manner then I'm forced to guess at what you mean. That kind of thing only leads to misunderstandings. If you'll learn to express yourself properly then there won't be a problem.

Anyways, my example WAS true

No, because you're still conflating the language with the implementation of the interpreter. Do you not understand the difference?

[Admins]

There are a few things that are incompatible between the two scripting engines, which make it sometimes look more strict. The main problem are variables like "this.x". While in the new scripting engine you can access everything in an object-oriented manner, meaning "this." could be replaced by "thiso." if not inside a with-clause, by other objects or be removed if you just want to access variables of the object the script is running for, in the old engine it was a special construct which only redirects to the dynamic (non-built-in) scripting variables of the npc the script is running for.
I wouldn't say the new scripting engine is more strict though, it's just not running 100% of the old scripts in exactly the same way the old engine would do it. The new scripting engine is also about more than just a different syntax description, it is also running scripts in a more optimized way, allowing scripts running other scripts, allowing the C++ engine to directly call script functions and doing something with the return values, is producing byte code so that the data sent to clients is smaller and needs less processing power and less updates on the client.

[Inverness]

Is it possible to return a variable name with a function to be used with an opperator?
Function Script:

NPC Code:

---

return makevar("clientr." @ this.flag @ "item_" @ getitemvar(archetype,"count"))[0];

---

NPC Code:

---

getitemvar(archetype,"qty") += 2;

---

Doesn't work for me in the way I would like.

Also it would be nice if GS2 was only activated in a script by header like Kaimetsu has stated:

Originally Posted by Kaimetsu

I'd personally like a system where the two languages are completely distinct, and the scripter announces that he wants to use GS2 by use of a special header. Like, one of those //#HEADER things.

Though I believe it best if this feature was available by server option. False at default.