User Tag List

Page 9 of 12 FirstFirst ... 7 8 9 10 11 ... LastLast
Results 81 to 90 of 115

Thread: AngelScript: The Revenge

  1. #81
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Tamamo View Post
    @ZoriaRPG please just stop, that is and has always been nothing but foolishness, it's why i stopped scripting in the first place. I just couldn't handle having to write bad code to do the shit I wanted to do.
    Hmm... You're the one who dubbed me the 'ambassador' to the ZC community. If you don't like me doing that job, shut it, and blame yourself.

    Or perhaps both of you could knock it off.
    -KA-

  2. #82
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    78.95%
    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;


    Last edited by Grayswandir; 02-03-2017 at 11:17 AM.

  3. #83
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Grayswandir View Post
    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.

  4. #84
    Here lies mero. Died by his own dumbassitude.
    Join Date
    May 2011
    Posts
    929
    Mentioned
    102 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    5,527
    Level
    23
    vBActivity - Bars
    Lv. Percent
    13.96%
    @ZoriaRPG
    Why don't we go for 0% compatibility and you learn to deal with it. Gleeok already pretty much decided he is not dropping support for ZScript. "since that's crazysauce"
    There is therefore no reason for AS and ZScript to be compatible. Pick one or the other, or may'be both who knows.

    Therefore every argument you make is invalid. Hence why I am annoyed at you.
    Sorry if this makes me sound like a bitch.
    @Gleeok
    Any chance I can convince you to ditch the AS compiler for ZScript, i would rather we play it safe and not have zscript and as interacting with one another... Too much can go wrong.

  5. #85
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    37
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,560
    Level
    30
    vBActivity - Bars
    Lv. Percent
    51.7%
    the answer for the zscript thing is already "no, that's dumb". It will take significantly more work for significantly less gain. It seems obvious.

  6. #86
    Keese
    ZC Developer

    Join Date
    Jan 2007
    Age
    34
    Posts
    52
    Mentioned
    27 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    778
    Level
    9
    vBActivity - Bars
    Lv. Percent
    78.95%
    Quote Originally Posted by Tamamo View Post
    Any chance I can convince you to ditch the AS compiler for ZScript, i would rather we play it safe and not have zscript and as interacting with one another... Too much can go wrong.
    I was thinking we'd just expose the ZScript internals to AS as a custom data type or something. Nothing fancy, just let AS get/set any arbitrary ZS variable, no complicated timing or waitdraws or whatever.

    In any case, whether it's added or not, I don't believe interaction between the two will affect the current part of the design at all. The decision can be safely put off until AS and ZS are working side by side in the first place.

  7. #87
    Banned
    Join Date
    May 2015
    Posts
    141
    Mentioned
    34 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    667
    Level
    9
    vBActivity - Bars
    Lv. Percent
    14.48%
    Quote Originally Posted by Tamamo View Post
    Why don't we go for 0% compatibility and you learn to deal with it. Gleeok already pretty much decided he is not dropping support for ZScript. "since that's crazysauce"
    There is therefore no reason for AS and ZScript to be compatible. Pick one or the other, or may'be both who knows.
    Quote Originally Posted by ZoriaRPG View Post
    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.
    I don't see what you're talking about, Tamamo

  8. #88
    Empty and become Moosh Moosh's Avatar
    Join Date
    Oct 2012
    Posts
    54
    Mentioned
    13 Post(s)
    Tagged
    4 Thread(s)
    vBActivity - Stats
    Points
    617
    Level
    8
    vBActivity - Bars
    Lv. Percent
    82.89%
    Quote Originally Posted by Gleeok View Post
    They only do it because you have to use hacks to get around the limitations in ZScript. ...But at least tell people that they should not do this with global arrays, or, at least no global array should be used to propagate this behavior from local arrays.
    I mostly do it because my waitframe functions tend to get more and more arguments as I work on a boss. Every time the number of arguments changes I have to change every instance of those functions, so it's faster to just cram most of them in an array.

    So for a boss with laser attacks I might have something like this:
    Code:
    int laserX[32]; //Laser X position
    int laserY[32]; //Laser Y position
    int laserA[32]; //Laser angle
    int laserW[32]; //Laser width
    int laserT[32]; //Laser timer
    int vars[16] = {laserX, laserY, laserA, laserW, laserT};
    
    
    void Example_Waitframe(ffc this, npc ghost, int vars){
    	Example_UpdateLasers(this, ghost, vars);
    	Ghost_Waitframe(this, ghost, true, true);
    }
    void Example_UpdateLasers(ffc this, npc ghost, int vars){
    	int laserX = vars[0];
    	int laserY = vars[1];
    	int laserA = vars[2];
    	int laserW = vars[3];
    	int laserT = vars[4];
    	for(int i=0; i<SizeOfArray(laserX); i++){
    		//pretend this is actually doing something
    	}
    }
    I see no use in doing this with global arrays so no worries there. And echoing what Grayswandir said, I learned to do this from looking at some of Saffith's scripts. I LEARNED IT FROM YOU, DAD! I LEARNED IT FROM WATCHING YOU!

  9. #89
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Here is my announcement: We are officially ditching both ZScript and AS for the only appropriate language:

    Spoiler: show

    Klingonese. I don't believe it has a translation for 'compromise', and its predilection for insults, bater, and argumentative and arrogant posturing, all seem wildly appropriate.


    End of report.

    /and I used to be so damned polite./


  10. #90
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    37
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,560
    Level
    30
    vBActivity - Bars
    Lv. Percent
    51.7%
    Quote Originally Posted by Moosh View Post
    I mostly do it because my waitframe functions tend to get more and more arguments as I work on a boss. Every time the number of arguments changes I have to change every instance of those functions, so it's faster to just cram most of them in an array.

    So for a boss with laser attacks I might have something like this:
    Code:
    int laserX[32]; //Laser X position
    int laserY[32]; //Laser Y position
    int laserA[32]; //Laser angle
    int laserW[32]; //Laser width
    int laserT[32]; //Laser timer
    int vars[16] = {laserX, laserY, laserA, laserW, laserT};
    
    
    void Example_Waitframe(ffc this, npc ghost, int vars){
    	Example_UpdateLasers(this, ghost, vars);
    	Ghost_Waitframe(this, ghost, true, true);
    }
    void Example_UpdateLasers(ffc this, npc ghost, int vars){
    	int laserX = vars[0];
    	int laserY = vars[1];
    	int laserA = vars[2];
    	int laserW = vars[3];
    	int laserT = vars[4];
    	for(int i=0; i<SizeOfArray(laserX); i++){
    		//pretend this is actually doing something
    	}
    }
    I see no use in doing this with global arrays so no worries there. And echoing what Grayswandir said, I learned to do this from looking at some of Saffith's scripts. I LEARNED IT FROM YOU, DAD! I LEARNED IT FROM WATCHING YOU!
    O.o

    You can do this?! Why do you do this? Why not just pass one big laser array?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social