thiso with strings but not variables?
 

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.

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.

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.

you have to do things correctly

That's not really a matter of strictness. It's an error, clearly and unequivocally.

I'd say that GS2's weak typing makes it pretty lenient.

But is that more true for GS2 than GS1?

It is more strict. You have to do things correctly for the engine to comprehend what you're telling it to do/perform. You can get away with things in the old scripting engine that you can't get away with in the new scripting engine. You can't be lazy and expect to properly script while using the new scripting engine.

Yeah, but that's pretty much always been the case. Do you understand what I mean by weak typing?

Yes, GS2 is strict on the rules but it allows a few exceptions to the rules, so as long as they can be comprehended by the system.


Either way, GS2 is more strict.

Actually it is accepted in new scripting engine now :)

That's not what weak typing means.

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!

You're entitled to an opinion, but it seems to me that you are misleading inexperienced scripters by falsely portraying GS2.

Bah! Leave it the strict way! I hate it when bad scripting goes around people. At least when it's strict, they have no choice but to make it properly! >.>

Backwards compatibility is a pretty big focus with GS2, man.

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.

I would also like that, a lot. When will it be implemented? :mad:

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.



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.

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

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?

...what?

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

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.

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.

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 :rolleyes:.



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.

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.

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

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.

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:
Though I believe it best if this feature was available by server option. False at default.

I already said that the new scripting engine is not just about different syntax