User Tag List

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

Thread: NPCData, ComboData, SpriteData

  1. #11
    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,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    Eh, they were removed because at that point I was burned out and depressed and basically doing stupid things at random. The conversion was really easy, though, at least as far as I got with it. But yeah, there was some issue with reading the return values from animate(), I guess? Worked fine for me, not at all for Gleeok. We never did figure out what it was, but then, we didn't exactly try.

  2. #12
    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%
    Exactly... And for your information, I spent a whole week trying to solve the problem.
    Guess I wasted a week of my life. Thanks for the affirmation...

  3. #13
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    I'm still against moving c++ code to scripts just on principle alone. If you think guys are a pain to debug or work with now, just wait until you have no debugging support whatsoever. My argument is that built-in enemy (i.e., editor edited or legacy) behavior should be a separate code path from customized (scripted) behavior.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  4. #14
    Developer
    ZC Developer
    jman2050's Avatar
    Join Date
    Jun 2001
    Location
    Do you really need to know
    Age
    37
    Posts
    3,883
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    5,706
    Level
    23
    vBActivity - Bars
    Lv. Percent
    45.65%
    In general I think that compartmentalizing the scripting environment into various arbitrary categories is a mistake. That was never the intent of ZASM/ZScript in the first place and really the distinction between stuff like "global" scripts and "FFC" and "item" scripts only really exists to tether specific programmable functionality into specific use cases as already defined in the engine itself. i.e. the only reason you'd use an item script over an FFC script is that you want whatever stuff you've programmed to happen to occur specifically when using an item as defined in the ZC engine itself. You could just as well make an FFC script with the exact same functionality and design in what way it's activated yourself. In the same way while the ability to attach scripts to enemies defined in the enemy editor directly would be convenient, that doesn't stop people from programatically making Fire enemies with custom attributes and custom behavior on their own terms without worrying about ZC's enemy code at all.

    In general I think worrying about how any advancements in the scripting environment will clash with legacy code is a pointless exercise. The legacy code has to exist in some form because it's used in every quest. Whether it's the same kludgey spaghetti code we've had for 10+ years or refactored to be easier to manage and integrate with future changes or even converted to scripts entirely is immaterial to the end user and becomes merely a question on which will be easier to manage on the development end. Rather than trying to further entrench the scripting environment into the legacy code (or vice versa) I think the setup we've had up to this point is perfectly fine. ZC behavior will be ZC behavior and scripting will be an open sandbox that allows users to extend or even outright replace ZC's functionality with their own. Not that I'm saying things can't be improved in areas where the legacy code remains a rigid restriction, but those improvements should primarily be focused on improving the end user's ease-of-use and freedom. Stuff like making scripting more modular so scripts can act more independently of each other, better ability to use generic scripts without modification, improvements to the language itself, and even improvements to ZC's engine to accommodate ambitions that are otherwise difficult or impossible to accomplish. Allowing scrolling and rooms not conforming to the same 16x11 play area we've had since 1999 to state one example, or finally moving away from the limitations of 8-bit palettes.

    I guess this is more just a random hodgepodge of thoughts relating to the direction of ZC rather than a direct response to the topic at hand, so sorry for that. In general I'm not against exposing more of the engine's properties to user editing but DarkDragon has already clearly laid out the dangers of doing so. The good part though is that as long as you guys don't actually release anything, you don't have to worry about those consequences for the time being!
    AGN's Resident Zelda Classic Developer and Sonic the Hedgehog Fanboy

  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,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    I'm still against moving c++ code to scripts just on principle alone. If you think guys are a pain to debug or work with now, just wait until you have no debugging support whatsoever. My argument is that built-in enemy (i.e., editor edited or legacy) behavior should be a separate code path from customized (scripted) behavior.

    That was my original plan. Add an npc type, 'Scripted', and that type (and all offshoots) use scripted behaviour. The other internal npcs are preserved as-is. Thus, any new npcs that we add after that point, would all be scripts that the user can edit. This is a bit forward of the present formulae.

    Quote Originally Posted by jman2050 View Post
    In general I think that compartmentalizing the scripting environment into various arbitrary categories is a mistake. That was never the intent of ZASM/ZScript in the first place and really the distinction between stuff like "global" scripts and "FFC" and "item" scripts only really exists to tether specific programmable functionality into specific use cases as already defined in the engine itself. i.e. the only reason you'd use an item script over an FFC script is that you want whatever stuff you've programmed to happen to occur specifically when using an item as defined in the ZC engine itself. You could just as well make an FFC script with the exact same functionality and design in what way it's activated yourself. In the same way while the ability to attach scripts to enemies defined in the enemy editor directly would be convenient, that doesn't stop people from programatically making Fire enemies with custom attributes and custom behavior on their own terms without worrying about ZC's enemy code at all.

    In general I think worrying about how any advancements in the scripting environment will clash with legacy code is a pointless exercise. The legacy code has to exist in some form because it's used in every quest. Whether it's the same kludgey spaghetti code we've had for 10+ years or refactored to be easier to manage and integrate with future changes or even converted to scripts entirely is immaterial to the end user and becomes merely a question on which will be easier to manage on the development end. Rather than trying to further entrench the scripting environment into the legacy code (or vice versa) I think the setup we've had up to this point is perfectly fine. ZC behavior will be ZC behavior and scripting will be an open sandbox that allows users to extend or even outright replace ZC's functionality with their own. Not that I'm saying things can't be improved in areas where the legacy code remains a rigid restriction, but those improvements should primarily be focused on improving the end user's ease-of-use and freedom. Stuff like making scripting more modular so scripts can act more independently of each other, better ability to use generic scripts without modification, improvements to the language itself, and even improvements to ZC's engine to accommodate ambitions that are otherwise difficult or impossible to accomplish. Allowing scrolling and rooms not conforming to the same 16x11 play area we've had since 1999 to state one example, or finally moving away from the limitations of 8-bit palettes.

    I guess this is more just a random hodgepodge of thoughts relating to the direction of ZC rather than a direct response to the topic at hand, so sorry for that. In general I'm not against exposing more of the engine's properties to user editing but DarkDragon has already clearly laid out the dangers of doing so. The good part though is that as long as you guys don't actually release anything, you don't have to worry about those consequences for the time being!
    Whle I agree with most of this, I feel that segregating things into class/pointer format makes it a bit easier to remember, rather than dumping everything at the global level. It makes far more sense to have Graphics->Draw, for what we will be doing, and Graphics->Palette, than splitting these between screen and game, IMO. If a function is attached to a script type that is associated with a pointer, and therefore has a 'this', pointer, then it belongs in that class. Otherwise, I would, as a scripter, rather know that all the audio functions are under Audio->, rather than Game-> and (global)->.

    Hell, I would rather that the extant stuff was categorised, as it is easy enough to trip yourself up on the pointer type for some of this stuff. It will also make things a bit cleaner when reading them, as the pointer type illustrates the purpose of a function in a broader scope, so the script code itself is cleaner as a result.

    You know, @Dimentio mentioned something about you having previously worked on some kind of engine modification to modify screen dimensions, permit pseudo-scrolling, or some such thing. Is there any fact to that, and if so, does any of that still exist, or would it be pertinent to the 2.6 process? I was considering working on a way to modify the screen draw dimensions, adding boundary points that can be modified (for smaller output, or custom scroll zones), and adding boundary points for all weapons, at which they automatically die; these set by quest data, or modified by script.

    These are some examples of 'rules' that would be in the FFScript class, @DarkDragon . WeaponLeftBoundary, WeaponRightBoundary, and so forth, as these are linked both to ZQuest, and to ZScript, and thus it seems logical (to me), to centralise them in FFRules[]. You can call them BananaRules[] if you want, but the point is to put anything that both the engine, and the script engine routinely access in there, unless it belongs as part of a class/struct, say, for weapon behaviour (other than global boundaries and such nonsense), or item animation (as part of the itemclass struct, on a per-item basis.

    This would mean setting these flags by default for old quets based on the old QRs, and reading the class bits instead of QR bits on a per-item basis, or per-npc basi, or what-have-you, when determining how they work. That allows the same level of compatibility, with far more flexibility in the mechanics, and it (in theory) makes it easier to later integrate these things into scripted behaviour for weapon, and npc scripts.

    Quote Originally Posted by DarkDragon View Post
    Tried to post this last night but was blocked by some server issues; I think I already mentioned all of this to you in chat but I'm pasting it here for the record.

    These function the same as Game->LoadItemData, right? Why not mimic its syntax?
    Sure, I likely will, when these things are better defined, and they need a 'this pointer. For the moment, I need to determine what the actual results are of doing any of these things, to see what works, what does not work, and what requires sticky tape on the windows.

    That is why they are all in their own branches.


    Regarding the ability to write to the buffers during the game: some values in the buffer are read when enemies are created, and will not change if you write to the buffer after the enemy is already on screen. Others are read when enemies move, are hit, etc. It's a random hodgepodge of behaviors based on the particular way each enemy is coded up in guys.cpp. Exposing the internal .qst file buffers with write access permanently locks in the current behavior of every enemy, since there will be no other way to ensure that scripts continue to function in the future. This may (or may not) hamper future attempts at making enemies more customizable or scriptable, so think carefully before opening that bottle, because it won't close again. At a minimum, all developers need to be made aware that the guys.cpp behavior can no longer be changed, and quest authors need to understand the dangers of writing to the buffers while enemies are using those values dynamically (best would be full documentation of how every enemy uses the buffer values during play, but that may not be feasible). All of the above also applies to combos etc.

    Also it should be made clear in the documentation that changes to any .qst file buffers do not persist across quest save/load or reset. You might think that's obvious, but I've gotten related questions about why scripted changes to the ZC GUI do not persist...

    I have in fact, considered adding two forms of work-arounds.

    1. FIx the refresh cycle so that if any of these facets are changed, all of the elemts that are on display are also changed (on the enxt frame).
    2. Add a Refresh() function to each of the pointers, so that the user cna direct them to redraw, refresh, or reload.

    Some things, such as npc->SeHP() could be written so that the engine checks this, and if it changes, to do npcptr->HP = min(currentHP, npcdats->HP) for all npcs that exist of that type.

    I'm not sure if this is desirable default behaviour, or if it should be called on a per-npc instance by the user.

  6. #16
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    Quote Originally Posted by ZoriaRPG View Post
    That was my original plan. Add an npc type, 'Scripted', and that type (and all offshoots) use scripted behaviour. The other internal npcs are preserved as-is. Thus, any new npcs that we add after that point, would all be scripts that the user can edit. This is a bit forward of the present formulae.
    This was one of my next things to do, at least it was before I burned out... The idea is you just assign a script to the enemy in the editor and it becomes scripted. Of course enemies created by script won't even have this limitation. Every enemy script can inherit from different data. At least this is one of my ideas on how to organize it.


    Quote Originally Posted by ZoriaRPG View Post
    Some things, such as npc->SeHP() could be written so that the engine checks this, and if it changes, to do npcptr->HP = min(currentHP, npcdats->HP) for all npcs that exist of that type.
    I'm not sure if this is desirable default behaviour, or if it should be called on a per-npc instance by the user.
    Very undesirable. Coupling these internally should be avoided at all cost.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  7. #17
    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 Gleeok View Post
    This was one of my next things to do, at least it was before I burned out... The idea is you just assign a script to the enemy in the editor and it becomes scripted. Of course enemies created by script won't even have this limitation. Every enemy script can inherit from different data. At least this is one of my ideas on how to organize it.
    The only issue I see arising from this, is that the enemy behaviour can change radically and unexpectedly, without setting tis type by script as well. That may not itself be a bad thing, but it may confuse some users. Otherwise, all fo this seems work-able. I was going to add a dedicated 'scripted' npc type, and then that npc derives its properties from the script assigned to it. DD wants to automatically populate enemy lists with scritped npcs provided by the script metadata.

    It might be simpler just to have two npc categories to accomplish that. Stock, internal npcs, and scripted npcs, as two separate tables. I'm not too fond of having two distinct tables, but if the scripts are in charge of the table entries, rather than the table entry selecting a script, then I don;t see a good way to keep them from clashing.


    Very undesirable. Coupling these internally should be avoided at all cost.
    Do you mean forced-coupling, permissive coupling by command, or both? I need to add a refresh entry for npcs to Screen-> anyway, so that the user can reload them after changing npc values ont he screen, without needing to exit and reload the screen. I will likely need to do the same for other map stuff, but perhaps not. Adding a Refresn() function to the pointers seems a logical way to permit the user to reload all of the properties of a given object.

    For npcs, I was leaning toward a per-npc thing, by instruction. Just, npc->Refresh(), to reload it from the full default state. Thus, if there is an instance of npc ID 17 on the screen, all of its values are re-loaded from npcdata[17]. That should nto itself be problematic, I would hope, as it would be useful even without adding npcdata. It is effectively 'respawn in place', without needing to kill and respawn it manually.

    This could easily be a universal function for each object pointer, that clears any pointer to its default state. The only pointer for which this is probably not useful, is Game->...Game->Refresh() I guess would be the same as F6 Retry. Perhaps that is useful, after all. ...anyway...

    I was not fond of the idea of forced linking, because that is just a way to limit flexibility in use.

  8. #18
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    What the heck is dmisc?? I saw this in enemy class:

    Code:
        long dmisc1, dmisc2, dmisc3, dmisc4, dmisc5, dmisc6, dmisc7, dmisc8, dmisc9, dmisc10, dmisc11, dmisc12, dmisc13, dmisc14, dmisc15;
    The enemy class keeps on getting bigger! Ahhhh!!!

    ..Seriously though, no clue.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  9. #19
    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%
    misc attributes 1 - 12 respectfully.
    Originally we thought we would need more.
    Why are you the one asking this question?

  10. #20
    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 Gleeok View Post
    What the heck is dmisc?? I saw this in enemy class:

    Code:
        long dmisc1, dmisc2, dmisc3, dmisc4, dmisc5, dmisc6, dmisc7, dmisc8, dmisc9, dmisc10, dmisc11, dmisc12, dmisc13, dmisc14, dmisc15;
    The enemy class keeps on getting bigger! Ahhhh!!!

    ..Seriously though, no clue.
    I have already pushed those to ZScript, and I was going to add fields for them in the EE; as users do whine about being out of attribs for scripts, and these were there all along

    Quote Originally Posted by Tamamo View Post
    Yeah, you're pretty much know what your doing now. I may be stubbon but i'm not oblivious.
    When I say something is impossible, it clearly means it's only impossible for me.

    Also, have you tried looking at the unimplemented enemies to see what can be done with them.
    As far as I'm concerned. We can just swap out NPC_WALKING and NPC_STANDING. But it would be nice to see about adding the others, since sprites for those do exist in the classic tileset, and other tilesets as well.
    I have not done anything with unimplemented types, and the reason is simple: I want to make as much of this work for the enemy types that exist in the engine (visible to the user) as possible, before compounding the job by adding more stuff to support later. I mean, if we are going with script-based npcs, why add more hardcoded npcs to the engine? Adding all of these class vars may also be a bit silly, but it will at least be usable in the next major release, whilst npc scripts, may not.

    Some of these unimplemented enemies, such as Wizrobe (ice), don't need to exist as a specific enemy category. Adding an ice weapon and giving npcs access to it, is a far better solution. It also requires adding ice combo effects to the engine itself. :/ At least, I would think of ice magic affecting floors, in the same way as Trinexx does; and possibly Stun Link on contact.

    I have no clue what 'standing' npcs were meant to do, unless they were intended to charge Link in LoS. There are no notes anywhere to aid in the archaeology.
    @Dimentio is the one who wanted to add wholly new npcs to the hardcoded base. I think that doing that is a long-term kludge, but everything relating to adding npcs hinges on npc scripts. I don't mind adding ptterns, move types, and other class values that can be used later anyway, but adding hardcoded movement that is not a pattern type to select; that can be applied to generic npcs, is another matter.

    Are there any specific types that you want working?

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