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
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,024
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.05%
    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
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    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?

  3. #13
    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,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    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.

  4. #14
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    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.

  5. #15
    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,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    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.

  6. #16
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,429
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.42%
    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.

  7. #17
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,024
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.05%
    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
    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,759
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.52%
    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.

  9. #19
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,024
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.05%
    Sure, that makes sense. And I completely agree that ffcs (and the ASM interpreter) could use a good refactoring.

  10. #20
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,814
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,931
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.24%
    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