User Tag List

Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 11 to 20 of 32

Thread: Message system discussion

  1. #11
    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%
    Global Scripts
    onDeath --called when dying
    onWin --called when saving zelda
    onPassiveSubscreen --called everyframe but only if subscreen is enabled
    onActiveSubscreen --called when opening subscreen, would allow for some awesome stuff
    onMap --called when opening maps

  2. #12
    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%
    Thank you @Tamano for actually suggesting things. :) I think I'll start a list so people can start adding them in at a later time.

    I started on global callbacks with the aim to make them dead simple for you guys to add to ZC. Currently you have these to work with:

    void CallGlobalCallbackFunction(int id);
    bool CallGlobalCallbackFunctionWithArgs(u32 id, ScriptVariant* args, u32 argCount, ScriptVariant* returnValue = NULL);

    -Step 1: add an enum value to a supported callback list. ex: CB_ON_LINK_DEATH,
    -Step 2: in the code that checks for link death and add: "CallGlobalCallbackFunction(CB_ON_LINK_DEATH); "

    In general, once the AS engine is hashed out better, any additions to the script engine generally requires modifying a single function.

    Next I have to figure out the best way to allowscripts to set callbacks dynamically. This might require reserving space in the save file.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  3. #13
    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%
    @Gleeok
    you're welcome. :)

  4. #14
    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
    Thank you @Tamano for actually suggesting things. :) I think I'll start a list so people can start adding them in at a later time.

    I started on global callbacks with the aim to make them dead simple for you guys to add to ZC. Currently you have these to work with:

    void CallGlobalCallbackFunction(int id);
    bool CallGlobalCallbackFunctionWithArgs(u32 id, ScriptVariant* args, u32 argCount, ScriptVariant* returnValue = NULL);

    -Step 1: add an enum value to a supported callback list. ex: CB_ON_LINK_DEATH,
    -Step 2: in the code that checks for link death and add: "CallGlobalCallbackFunction(CB_ON_LINK_DEATH); "

    In general, once the AS engine is hashed out better, any additions to the script engine generally requires modifying a single function.

    Next I have to figure out the best way to allowscripts to set callbacks dynamically. This might require reserving space in the save file.
    Why are you hardcoding messages like this? AFAIK, @DarkDragon was planning to allow the user to define messages in the ZScript parser.

    I would just allow defining a message and linking it to a series of events that are easy to expand.

    OnUseItem(int itm) and such are good, if you can;t do it this way.
    OnScriptRunning(type, id)

    OnEngineEvent(event) would be a prudent generic.
    OnSpawnNPCs()
    OnGenerateDrop()
    OnGenerateDrop(dropset)
    OnGenerateItem(item id)
    OnTriggerSecret()
    OnTriggerSecret(specific_secret)
    OnUseWeapon
    OnUseEWeapon
    OnTriggerMapFlag(flag)
    OnLowHP()

    There are too many single-purpose message points to list...

  5. #15
    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
    Why are you hardcoding messages like this? AFAIK, @DarkDragon was planning to allow the user to define messages in the ZScript parser.

    I would just allow defining a message and linking it to a series of events that are easy to expand.
    .
    I don't understand what you are saying. You have to "hardcode" them otherwise how in the hell is ZC going to call the script function at the appropriate place in the code? Hint: It can't.

    Scripts can also at any time - even in the callback itself!! - change the callback dynamically in the script. Ex:

    Code:
    void OnDeathWithFairy()
    {
       //revive Link
       // then....
       if(--bottled_fairy_count == 0)
         Game.SetCallback(CB_DEATH, @OnLinkDeath);
    }
    
    void OnLinkDeath()
    { 
      //dies ..poor guy. R.I.P.
    }
    For all the writing you do I feel like you don'tread what I am saying... like ever. You don't NEED TO SET EVERYTHING IN ZQUEST BECAUSE WITH THE NEW SCRIPT ENGINE YOU DONT NEED TO EVER OPEN ZQUEST. You can compile scripts directly in ZC as you are playing, minus setting up enemies in the editor and shit like that. At least that's the plan.
    Last edited by Gleeok; 02-01-2017 at 03:04 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  6. #16
    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 don't understand what you are saying. You have to "hardcode" them otherwise how in the hell is ZC going to call the script function at the appropriate place in the code? Hint: It can't.

    Scripts can also at any time - even in the callback itself!! - change the callback dynamically in the script. Ex:

    Code:
    void OnDeathWithFairy()
    {
       //revive Link
       // then....
       if(--bottled_fairy_count == 0)
         Game.SetCallback(CB_DEATH, @OnLinkDeath);
    }
    
    void OnLinkDeath()
    { 
      //dies ..poor guy. R.I.P.
    }
    For all the writing you do I feel like you don'tread what I am saying... like ever. You don't NEED TO SET EVERYTHING IN ZQUEST BECAUSE WITH THE NEW SCRIPT ENGINE YOU DONT NEED TO EVER OPEN ZQUEST. You can compile scripts directly in ZC as you are playing, minus setting up enemies in the editor and shit like that. At least that's the plan.
    What did I write, at all, in this thread, that is even remotely related to requiring the user to open ZQuest?

    'I would just allow defining a message and linking it to a series of events that are easy to expand. '

    So, that feeling is mutual.

    By hardcoding, I mean creating individual callback identifiers, versus OnEvent(system event), which would IMO, be easier to later expand, by expanding the possible events. That is, OnEvent(EVENT_DEATH, ...). What is the point of:

    OnDeath(EVENT_DEATH, ...) ??

    You want a series of enums for the events, and you want to separately list every possible event, too? Please, what is the purpose? I legitimately do not comprehend it. Please, if I;m missing something here, let me know. I see a handle in the syntax, and a defined value. Is there a need for individual message IDs, or is that just a list of examples for internal use, and not for user-use?

    Perhaps that is what I am missing here.
    That, and of course, setting user-defined events, would be nice. If that isn't possible, that's fine.

  7. #17
    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%
    You're going to have to expand that idea and clarify what you mean with some sort of implementation detail then, because I don't understand how what you are suggesting is even possible.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  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,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    You're going to have to expand that idea and clarify what you mean with some sort of implementation detail then, because I don't understand how what you are suggesting is even possible.
    You mean user-defined callbacks?

    I was thinking that a user could set them up, sort of like a jump. Put an insertion point in a piece of code, and if a callback references the 'jump point', it executes that code starting at the specified point. So, you would use the @ Handle to reference a function, and the defined value for the jump point:

    Code:
    void foo(){
       //instructions
       //instructions
       $jump_identifier
       //other instructions
    }
    
    user_callback(jump_identifier, @foo)
    Not sure if it is feasible, but I thought it would be interesting. There may be more idyllic ways to do it. In fact, it may be possible to allow setting some kinds of special engine conditions in the programme, labeling them, and using them as callbacks; which would, probably require setting them up in ZQuest. I would think though, that dmap IDs, items in use, eweapons in use, and the lot that I posted above, would all be useful events for this sort of thing, and you didn't even comment on those.

    This would be mostly useful in a script series where a defined series of events was logical. Taking @ywkls Metroid thing as an example, you would want an onSamusNoHP() callback, that was linked to the custom HP system. For one of my quests, I may want OnIsInSpace() as a callback. Who knows. The point, is that if it could exist as an option, may as well make it possible.

    I was mistakenly reading the labels for some of these things as specific callback instructions though. That was my fault. I though that OnLinkDeath(ON_DEATH, @function_to_run) was how you were doing it, which was silly. This was probably because DD and Gray were discussing it two weeks ago, and the message OnDeath() was one of the proposed things from that chat.

    I don;t think that this kind of callback is actually something that I have used to date. C/Cpp don;t support them. I don;t recall if Ruby does, but I've never used them. I avoid Java/J++ like the plague. I see how useful they would be, don;t mistake me. I just want to ensure that the implementation is sane and streamlined.

    I'm not sure how these would be written so that adding callback types internally wouldn't be a gigantic pain. By this, I mean, writing the source-code side of things to define the event and wrap it in something, because our present 'events' are strewn through classes in a wherever-fashion. I would think that would all need fixing.

    I will add however,

    onLinkDrawing ...
    onLinkWeapon(weapon)

    and similar.

    onCollision(type) is also good, if I missed that above. Simplify the hell out of those.

    Other suggestions:

    onWarp(type)
    onRolLCredits
    onIntroScreen
    onTitleScreen
    onNameEntry

    Howzat?

  9. #19
    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%
    An enum is a simple and convenient way of declaring to ZC what specific engine behavior you want to change. Overrides are handled internally.

    You can already do all that stuff you mentioned in AS. You can call any callback yourself, or you can store an array of funcdefs or delegates and call them whenever. http://www.angelcode.com/angelscript...s_funcptr.html
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  10. #20
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%

    void CallGlobalCallbackFunction(int id);
    bool CallGlobalCallbackFunctionWithArgs(u32 id, ScriptVariant* args, u32 argCount, ScriptVariant* returnValue = NULL);
    Gleeok, can we do something like this:

    There is a list of game objects (which I will cause Objects, for lack of any creativity) that can have scripts attached to them. An initial list of Objects are
    1. the game itself;
    2. the screen;
    3. Link;
    4. npcs;
    5. items;
    6. weapons;
    7. combos (freeform or otherwise).

    Each Object maintains
    - any number of scripts, each of which can contain any number of callbacks;
    - local variables associated to that Object

    The game engine, and scripts, can send a message to either a specific Object (via a pointer to that Object) or broadcast a message to all active Objects.
    If multiple Objects would receive a message, they receive them in a well-defined order (for example, in the order listed above, with scripts associated to the game getting first dibs, then screen scripts, etc). Each callback returns whether to continue processing the message, or to stop. Each callback runs in its own execution context as described in my first post.

    You suggestion to start with just CB_ON_UPDATE and CB_ON_DRAW sounds fine to me. We can work out the details of WaitFrame() and WaitDraw() within callbacks, Object pointers and variables, execution contexts, etc. for just these two basic messages, and build up from there.

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