Oh, yes, you do. Have you never seen me do this with ffcs or items? I also do it with itemdata now. :/Originally Posted by Grayswandir
I just wanted to mention that I picked up the array thing from reading through ghost.zh. So, blame Saffith.
Of course, seeing that ghost uses it, you'd end up breaking quite a lot of things if you don't support it.
The heart of the problem is that ZScript treats int and int[] as the same thing. You can do the same trick for the other types as well, but I don't know of anybody doing that.
If we end up compiling ZScript to AS (still not sure what the exact plan is), it shouldn't be too hard to fix. Just treat ZScript's arrays as their own "thing", separate from actual AS arrays. Just keep a table of them, and look them up anytime you do an array dereference. So, just compile them to eg. ZS_Array_Get(int id, int index) and similar instead of actual array references.
I second this suggestion. I mentioned earlier, that we should just treat all of the ZScript types as special cases to handle them and avoid all of this incompatibility nonsense.
Precisely. My second option, is parallel operation, with no direct communication. I suppose the ZScript messaging and AS messaging could be used as an interface, but if you are going to do that, you may as well implement all the types in some fashion.If we're having ZScript and AS side by side, it's a non-issue. If we want ZScript and AS to be able to interact with each other - well, that was gonna be a mess anyway.
So, compatibility of 40% now? Huzzah, huzzah. I often hate the accuracy of my predictions.
Reply With Quote