User Tag List

Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 22

Thread: Yuurei: Utterly Bizarre Crash on 2.50.x Tree Builds

  1. #11
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    68 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,793
    Level
    30
    vBActivity - Bars
    Lv. Percent
    80.24%
    Daily Activity
    0%
    Weekly Activity
    3.94%
    Monthly Activity
    4.41%
    Can you copy the specific issue (something to do with reflected magic not working correctly?) into a new thread?

  2. #12
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    34
    Posts
    3,340
    Mentioned
    164 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,034
    Level
    24
    vBActivity - Bars
    Lv. Percent
    3.44%
    Daily Activity
    0%
    Weekly Activity
    19.69%
    Monthly Activity
    11.76%
    Going back to the original issue, rather than adding a whole bunch of if(ri->ffcref<=31), how about this as a solution:
    Code:
    byte ffcref: 5;
    Any problems with that?
    [téknolŕiz]

    ffcscript.zh 1.1.1 - Updated 2014-08-19
    ghost.zh 2.8.2 - Updated 2017-09-10
    tango.zh 1.3.0 - Updated 2017-09-10

  3. #13
    ZC Contirbutor ZC Developer ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,030
    Mentioned
    95 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,586
    Level
    19
    vBActivity - Bars
    Lv. Percent
    17.74%
    Daily Activity
    0%
    Weekly Activity
    51.18%
    Monthly Activity
    15.43%
    Quote Originally Posted by Saffith View Post
    Going back to the original issue, rather than adding a whole bunch of if(ri->ffcref<=31), how about this as a solution:
    Code:
    byte ffcref: 5;
    Any problems with that?
    We were planning to allow calling ffcs > 32 on demand. These would not be preserved in global memory, and would use resources only when in use.

    The allowed range for ffcref needs defines MIN_FFCREF and MAXFFCREF. Just modify LoadFFC and vbound it's input value to a range between those values.

    That's how I'd do it.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

  4. #14
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    34
    Posts
    3,340
    Mentioned
    164 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,034
    Level
    24
    vBActivity - Bars
    Lv. Percent
    3.44%
    Daily Activity
    0%
    Weekly Activity
    19.69%
    Monthly Activity
    11.76%
    Also a possible concern is that this may affect existing quests. Some may be doing things with invalid FFC pointers, and it just happens to be having no visible effect. If an FFC pointer can no longer be invalid, those benign invalid operations could become quest-breaking.
    I don't think that's a reason not to change it - surely invalid operations have undefined behavior if the game doesn't catch them - but it's something to warn people about, at least.
    [téknolŕiz]

    ffcscript.zh 1.1.1 - Updated 2014-08-19
    ghost.zh 2.8.2 - Updated 2017-09-10
    tango.zh 1.3.0 - Updated 2017-09-10

  5. #15
    ZC Contirbutor ZC Developer ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,030
    Mentioned
    95 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,586
    Level
    19
    vBActivity - Bars
    Lv. Percent
    17.74%
    Daily Activity
    0%
    Weekly Activity
    51.18%
    Monthly Activity
    15.43%
    Quote Originally Posted by Saffith View Post
    Also a possible concern is that this may affect existing quests. Some may be doing things with invalid FFC pointers, and it just happens to be having no visible effect. If an FFC pointer can no longer be invalid, those benign invalid operations could become quest-breaking.
    I don't think that's a reason not to change it - surely invalid operations have undefined behavior if the game doesn't catch them - but it's something to warn people about, at least.
    I could always report an invalid pointer, and break, instead of returning the index, instead of vbounding them. Returning 0 or -1 there would probably be bad, for similar reasons.

    I read your post, and I hope you will stick around for these little discussions in the future.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

  6. #16
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    34
    Posts
    3,340
    Mentioned
    164 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,034
    Level
    24
    vBActivity - Bars
    Lv. Percent
    3.44%
    Daily Activity
    0%
    Weekly Activity
    19.69%
    Monthly Activity
    11.76%
    Here's a thought: add a 33rd FFC. Don't save it or load it; just make the arrays bigger and don't do anything else. Whenever ffcref is set, if it would be out of range, point it to #33. It won't hurt anything, and it won't need further verification.
    Of course, if FFCs were changed to structs (which shouldn't be hard), you'd only need one global dummy rather than one per screen.
    [téknolŕiz]

    ffcscript.zh 1.1.1 - Updated 2014-08-19
    ghost.zh 2.8.2 - Updated 2017-09-10
    tango.zh 1.3.0 - Updated 2017-09-10

  7. #17
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    68 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,793
    Level
    30
    vBActivity - Bars
    Lv. Percent
    80.24%
    Daily Activity
    0%
    Weekly Activity
    3.94%
    Monthly Activity
    4.41%
    Doesn't FFCREF only need to be validated (i) when the interpreter first begins executing the script; and (ii) when a script explicitly changes its value? That doesn't seem like too many places to check if the ref is valid and if not, terminate the script with a warning message.

    EDIT: Ah, I see the issue.

    I'm not so against a lot of if(isValid(ffcref)), though. Sure it's ugly, but it's safe, makes it clear what the code is intending to do, makes it easy to later change the number of FFCs (or allow the refs to be nonconsecutive integers, i.e. UIDs), and makes it slightly more painful to add gratuitous new FFC variables

  8. #18
    ZC Contirbutor ZC Developer ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,030
    Mentioned
    95 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,586
    Level
    19
    vBActivity - Bars
    Lv. Percent
    17.74%
    Daily Activity
    0%
    Weekly Activity
    51.18%
    Monthly Activity
    15.43%
    Quote Originally Posted by DarkDragon View Post
    Doesn't FFCREF only need to be validated (i) when the interpreter first begins executing the script; and (ii) when a script explicitly changes its value? That doesn't seem like too many places to check if the ref is valid and if not, terminate the script with a warning message.

    EDIT: Ah, I see the issue.

    I'm not so against a lot of if(isValid(ffcref)), though. Sure it's ugly, but it's safe, makes it clear what the code is intending to do, makes it easy to later change the number of FFCs (or allow the refs to be nonconsecutive integers, i.e. UIDs), and makes it slightly more painful to add gratuitous new FFC variables

    I think it would be a good idea to find out what @Gleeok is working on in this regard. A month or two back, he said that he was still planning to work on FFC memory management, user-created FFCs, and stuff of that sort. if(isValid(ffcref)) would become quite important at that point. The only things that I had at all considered adding to ffcs, that would require new values and variables are: Solidity flags, and a running flag. A running flag would be useful say, to pause/suspend and unpause/resume a script. That one is surely gratuitous.

    The solidity, I figured I would just use the present 'solid' flag, and we would read the combo solidity for each combo comprising the ffc. (I wouldn't mind making ffcs larger than 4x4, too, but that is incidental.)

    All of that more belongs in a dev topic. I like the solutions of validity checking, and I also like the idea of putting ffcs into their own class or struct. I'm concerned that @Gleeok may already have some of this legwork done, and I do not want to step on his toes.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

  9. #19
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    68 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,793
    Level
    30
    vBActivity - Bars
    Lv. Percent
    80.24%
    Daily Activity
    0%
    Weekly Activity
    3.94%
    Monthly Activity
    4.41%
    Sure, that makes sense. And I completely agree that ffcs (and the ASM interpreter) could use a good refactoring.

  10. #20
    Developer ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,687
    Mentioned
    241 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,385
    Level
    32
    vBActivity - Bars
    Lv. Percent
    63.63%
    Daily Activity
    0%
    Weekly Activity
    27.56%
    Monthly Activity
    9.92%
    Quote Originally Posted by ZoriaRPG View Post
    I think it would be a good idea to find out what @Gleeok is working on in this regard. A month or two back, he said that he was still planning to work on FFC memory management, user-created FFCs, and stuff of that sort. if(isValid(ffcref)) would become quite important at that point. The only things that I had at all considered adding to ffcs, that would require new values and variables are: Solidity flags, and a running flag. A running flag would be useful say, to pause/suspend and unpause/resume a script. That one is surely gratuitous.

    The solidity, I figured I would just use the present 'solid' flag, and we would read the combo solidity for each combo comprising the ffc. (I wouldn't mind making ffcs larger than 4x4, too, but that is incidental.)

    All of that more belongs in a dev topic. I like the solutions of validity checking, and I also like the idea of putting ffcs into their own class or struct. I'm concerned that @Gleeok may already have some of this legwork done, and I do not want to step on his toes.
    Different things: The FFC memory issue has to do with how they are stored inefficiently (in the map struct) after being read from the quest file; the user-created scripts was an AS thing. I haven't started the ffc refactor because I haven't had time... :/ ..Also it's possible I might break the build for a day or two once I actually start it, so I'll start a thread about it first, depends on how long it takes.


    Surely "isValid(ffcref)" is like the most horrible last-resort anti-solution for the problem, isn't it? I mean it has to be valid for it to run in the first place, right?
    This post contains the official Gleeok™ seal of approval. Look for these and other posts in an area near you.

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