[2.xx] Custom Global Pointers (The Easy Way)

If you add the ability to declare other data types (lweapon, ffc) at a global level, we could build our own quasi-objects, as custom pointers.

As an example, I was trying to declare lweapon Player at a global level, so that I could make a custom player object with a pointer that I could call from anywhere.

Is it possible to reference a pointer inside a script, from a global function in the same way that a script at local scope can call a function from elsewhere with :

Code:

---

scriptname:function()

---

?

Code:

---

scriptname:Pointer

---

I suppose not, because the pointer isn't valid until it's executed...so, right, a decent amount of global pointers would be very helpful.

Your forgetting one key component here. Everything is compiled into ZASM. So custom objects aren't happening till the total 3.0 rewrite.

Quote:

---

Originally Posted by Tamamo

Your forgetting one key component here. Everything is compiled into ZASM. So custom objects aren't happening till the total 3.0 rewrite.

---

I'm also remembering that 2.60, is at least a partial engine re-write. I don;t know how much of ZASM Saffith plans to tough in 2.60, but it would be a good time to add things of this nature, that don't require full engine replacements. It would require expanding the assembly language to permit it, but it [the datatype and structure] would otherwise function in the same manner, as it does at present.

That applies to the existing datatypes, of course. You couldn't expand them, or modify their structure, but you may be able to use them to define object-like behaviour. That's why I was specific, to the existing datatypes, and didn't request full-blown custom object definition.

Falls under custom scripted types, really, ..and I agree that it would be nice.

A while back I wanted to add a new scripting language to ZC, angelscript, along with a full-blown c/c++ preprocessor, but nobody really seemed interested. :(
It would have supported everything, basically, from user defined types to inheritance, inferfaces, mixins, function pointers, and on...

There was that whole 'OMG no more new stuff, we want 2.5 released and bugfree now." ...and this reply is going nowhere, so....

Quote:

---

Originally Posted by Tamamo

Your forgetting one key component here. Everything is compiled into ZASM. So custom objects aren't happening till the total 3.0 rewrite.

---

How would running ZASM affect using objects?

Quote:

---

Originally Posted by Gleeok

Falls under custom scripted types, really, ..and I agree that it would be nice.

A while back I wanted to add a new scripting language to ZC, angelscript, along with a full-blown c/c++ preprocessor, but nobody really seemed interested. :(

---

:O

That's because people are stupid.It's never too late, you know!

@Gleeok

If you say it's possible and we can go about implementing user defined pointers and pointer functions. Then I'm all for it. Let's do this shit, but we're still waiting for opensource. :p

I'm tired of waiting for open source too. TBH I don't see myself fixing the ZC qsu problem so I might as well put up ZQ. :shrug:


It would be an interesting experiment though!! -Put in another script language and let the two duke it out and see which one people start using more. XD :P

I still gotta fix wizzrobes though @Gleeok .

Quote:

---

Originally Posted by Gleeok

I'm tired of waiting for open source too. TBH I don't see myself fixing the ZC qsu problem so I might as well put up ZQ. :shrug:

---

What is the qsu problem? I don't see a point in waiting for it to be perfect. It's not like it can't be fixed later.

I am actually leaning toward Angelscript, but I haven't tried doing much with it yet. Just seems a bit premature, y'know? I've got some ideas, but I don't know to what degree it will work the way I want it to.

Yeah, I hear you... Tell you what: I'll put up the script engine sources at some point and you can take a look. Adding something like custom enemy scripts shouldn't be too hard after that.

Were you thinking of making a cross-compiler, or providing any kind of bridge between ZScript, and whatever else new you devise?

I think that not having the ability to use, and integrate both languages, would be an initial detraction from offering a new language. The codebase of what exists in ZScript, is pretty vast, and getting people to shift would be a pain in the arse. If it was possible to utilise both, without everything breaking, that would be brilliant; but I still feel that the main assembly language needs refinement in the future.

Other than that, would it be horribly difficult to implement the other datatypes at a global scope, as things stand?

Oh! You just want to declare pointers at global scope. Never looked at it at all. heh. Probably as easy as a one line fix in the lexer.

Now finding it and figuring out why they couldn't be declared that way to begin with is another story... :P

Quote:

---

Originally Posted by ZoriaRPG

Were you thinking of making a cross-compiler, or providing any kind of bridge between ZScript, and whatever else new you devise?

I think that not having the ability to use, and integrate both languages, would be an initial detraction from offering a new language. The codebase of what exists in ZScript, is pretty vast, and getting people to shift would be a pain in the arse. If it was possible to utilise both, without everything breaking, that would be brilliant; but I still feel that the main assembly language needs refinement in the future.

---

Or (best idea ever!) we put in every possible script language suitable for games and make people learn all of them, one for each type of script! :highfive:

Heh. That would be awesome. Too bad it's as far from practical as possible; but yes, I would like to declare the following at global scope:

lweapon (importance: very high)
eweapon (importance: very high)
npc (importance moderate, may be tricky?)
ffc (Importance, high, but may be too difficult)

I don't think that I missed a datatype.

That way, I can make code to use them from anywhere, as pseudo- self-defined pointers.

If you could add that, it would be fantastic.

On a side note, when you think that the latest experimental build will be public (or at least, when might I try it), as I would love to test some of the bugfixes, and the new script error reporting.

@Gleeok

I've been looking at the zasm and zscript code anyways. Might as well do it I guess.

Quote:

---

Originally Posted by Saffith

I am actually leaning toward Angelscript, but I haven't tried doing much with it yet. Just seems a bit premature, y'know? I've got some ideas, but I don't know to what degree it will work the way I want it to.

---

I haven't used AngelScript but I like the look of it and hear good things. I forget why Gleeok ditched it for his game. On a related note I imagine implementing C# isn't going to happen :rude: Been really liking C# in Unity. A more capable language is all I am interested in. Really the true kicker is better integration which I imagine is a nightmare.

Tamamo didn't like my idea to strip out everything but the core of ZC and rework it.

Quote:

---

Originally Posted by SUCCESSOR

I haven't used AngelScript but I like the look of it and hear good things. I forget why Gleeok ditched it for his game. On a related note I imagine implementing C# isn't going to happen :rude: Been really liking C# in Unity. A more capable language is all I am interested in. Really the true kicker is better integration which I imagine is a nightmare.

Tamamo didn't like my idea to strip out everything but the core of ZC and rework it.

---

C# is under consideration for ZC3, but then again, so is everything else.

I read some of the AngelScript docs, and the C++/C cross-modes are a fantastic feature. It should be possible to retain compatibility with ZScript, and make object-oriented instructions using it as a base.

I just want to bring this up again:

As pointers are ints, is there any reason that making them legal at a global scope would require a save file format or quest file format change? If not, perhaps getting this minor change into the next update would be good. AFAIK, the only reason this doesn't work, is because a compiler directive actively prevents it (i.e. the declaration).

There is one concern with that. After saving a global pointer and reloading, it's not unlikely that at some point, the ID would come up again and the pointer would appear valid. It obviously wouldn't refer to the same object, which is bad enough, but it might not even be the same type, in which case it could crash the game. We don't have a means of detecting which global variables are pointers in order to reset them when they're saved.
I'm not certain, but it might also take a bigger change to the compiler. It would have to be able to load gdXXX into a reference register, which currently never happens. I'm not sure it would know how to do that.

Hmm... I'm somewhat saddened, but ZC + memory handling aren't exactly a happy coupling. I would have expected that a pointer that is in use, couldn't be reissued, and would be passed over for the next legal value.

How is detection of array pointers, for global arrays handled? I'd think that would carry over to handling other objects, but IDK. I suspect they're handled differently on the stack, then; or is it that array pointers are assigned at declaration, and ffc/weapon/etc pointers at initialisation? No, they can't be at init, they must be at decl, but if they're just raw ints....sigh.

Is it possible to manually typecast from an object type to int, to read its pointer, and then back again? Being able to do that would at least help, as it'd make it possible to make global functions to use a typed object declared in a script, from anywhere else.