User Tag List

Page 2 of 2 FirstFirst 1 2
Results 11 to 15 of 15

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

  1. #11
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,116
    Mentioned
    41 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,531
    Level
    30
    vBActivity - Bars
    Lv. Percent
    48.22%
    Daily Activity
    0%
    Weekly Activity
    48.87%
    Monthly Activity
    14.86%
    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,291
    Mentioned
    140 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    5,836
    Level
    23
    vBActivity - Bars
    Lv. Percent
    68.6%
    Daily Activity
    0%
    Weekly Activity
    3.86%
    Monthly Activity
    10.35%
    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.1 - Updated 2016-09-16
    tango.zh 1.2.0 - Updated 2016-09-16

  3. #13
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,927
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.71%
    Daily Activity
    0%
    Weekly Activity
    3.86%
    Monthly Activity
    10.35%
    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.


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

  4. #14
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    34
    Posts
    3,291
    Mentioned
    140 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    5,836
    Level
    23
    vBActivity - Bars
    Lv. Percent
    68.6%
    Daily Activity
    0%
    Weekly Activity
    3.86%
    Monthly Activity
    10.35%
    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.1 - Updated 2016-09-16
    tango.zh 1.2.0 - Updated 2016-09-16

  5. #15
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    763
    Mentioned
    68 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    2,927
    Level
    17
    vBActivity - Bars
    Lv. Percent
    54.71%
    Daily Activity
    0%
    Weekly Activity
    3.86%
    Monthly Activity
    10.35%
    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.


    Script Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | stdArguments.zh (v.6.9.9/1) | | Timers.zh (v.1.5)
    ZScript | ZC Dev | ZC 2.53 | Alucard's: stdCombos.zh (v1.1) | stdWeapons.zh | particles.z
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0.

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