AngelScript: The Revenge

[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.

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.

Edit: relevant section of ghost.zh:

CODE: Show

// Remember all the global variables

// Initializing the array is faster than setting it up afterward...
// but the difference is probably negligible, realistically
float tempGhostData[24] = {
Ghost_X, // 0
Ghost_Y, // 1
Ghost_Z, // 2
Ghost_Jump, // 3
Ghost_Vx, // 4
Ghost_Vy, // 5
Ghost_Ax, // 6
Ghost_Ay, // 7
__Ghost_PrevX, // 8
__Ghost_PrevY, // 9
Ghost_CSet, // 10
Ghost_Dir, // 11
Ghost_Data, // 12
Ghost_TileWidth, // 13
Ghost_TileHeight, // 14
__Ghost_Flags, // 15
__Ghost_Flags2, // 16
__Ghost_InternalFlags, // 17
__Ghost_FlashCounter, // 18
__Ghost_KnockbackCounter, // 19
Ghost_HP, // 20
__Ghost_XOffsets, // 21
__Ghost_YOffsets // 22
// 23 is for either drawingData or tempGhostAdditionalCombos;
// update DrawGhostFFCs if that changes
};
int tempGhostAdditionalCombos[21]; // Same size as __Ghost_AdditionalCombos
// Change it in the loop below, too
if(__Ghost_AdditionalCombos[0]>0)
{
for(int i=0; i<21; i++)
tempGhostAdditionalCombos[i]=__Ghost_AdditionalCombos[i];
}

// Give ghost an array pointer so its data can be found by other scripts
if(ghost->isValid())
ghost->Misc[__GHI_NPC_DATA]=0x10000|tempGhostData;

[ZoriaRPG]

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.

Oh, yes, you do. Have you never seen me do this with ffcs or items? I also do it with itemdata now. :/

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.

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.

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.

So, compatibility of 40% now? Huzzah, huzzah. I often hate the accuracy of my predictions.