User Tag List

Page 3 of 3 FirstFirst 1 2 3
Results 21 to 22 of 22

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

  1. #21
    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 Gleeok View Post
    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.
    Well, the present struct changes broke the build on more than one occasion. That is clearly nothing new. That's why I make changes in a branch, and wait until they are complete before merging them.

    If you give ffcs memory management, and their UIDs for each of them is stored in a vector, then adding to a pool > 32 should not be too hard. At least, I would not think it to be hard. That meaning, a user creating an ffc should work well with that system.

    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?
    It does not need to be valid at present to try loading it. LoadFFC(120) actually flipping permits loading junk data, and writing to goodness knows what memory area. I have in fact known users who have done this to try to create temporary scratch vars, and I have scolded them for it. The LoadFFC block, or soemewhere in the pipe, we need a routine that clamps the range to whatever is valid. I don;t ultimately care how this looks, but if we allow user-created ffcs, just like any other pointer, then a validity check will be needed for them, just as with any of the other objects connected to a screen.


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

  2. #22
    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%
    The interpreter checking that the FFC is valid before trying to do anything to it makes the most sense if you imagine in the future there might be need for more or less than exactly 32 FFCs per screen, or FFCs dynamically added/removed from the screen. (Compare to the item/npc/weapon ZASM commands, which already validate their references).

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