Refactouring /quest

Discussion in 'Archives' started by robxu9, Sep 9, 2012.

Thread Status:
Not open for further replies.
  1. robxu9 Head Developer

    I was rethinking /quest one night. I clearly think about MQ too much.

    The current set of /quest commands are simply... confusing. They don't help the user experience, and can be utterly mind-boggling. I was thinking of refactoring them to this structure:


    /*
    * OP: reload [name]
    * OP: info [name]
    * OP: drop <username> <name> <true/false (complete?)>
    * OP: userhas <username>
    *
    * given [name]
    * main [name]
    * drop <name>
    *
    * abandon
    * active
    * enter
    * exit
    * start <name>
    */


    OP doesn't mean requires op; it just means that in plugin.yml I'll default it to op.

    Does anyone have a better suggestion? Because I still think this could be confusing.

    EDIT: I just like to make clear that I've already overhauled it a bit. If you're on the latest dev builds, /quest will not show you a help menu, but an overall quest list instead.
  2. makraiz Moderator

    I think it should be simplified on the player end to just /quest start, /quest abandon, & /quest.

    Here's how it works in my head:
    /quest start <questname>

    In an instanced quest, this should launch the world generation, and then teleport the player to it once it's done building the world. In a non-instanced quest, launch the quest. Ideally this would be handled via sign/npc methods, perhaps via a double-click, once to give a warning/accept the quest, then the second to confirm/start the quest.

    /quest abandon <questname>

    Teleport the player back to where they were when they launched the quest, delete all quest progress from the players database file, delete the junk world if instanced. Ideally this would also happen if a player quits mid-quest in an instance.

    /quest

    Lists quests known to the player. This would be the first of the double click I mentioned earlier.

    Also, it would be cool to leave it open for someone to develop a GUI later down the road for spout awesomeness.

    Feel free to shoot these down, as I have no idea how the coding would work :p.
  3. robxu9 Head Developer

    Hm. These sound like good ideas.
    It might also eliminate the /quest enter/exit stuff as well.
    (But that also raises the question - what if we want a custom entry point into the instanced quest?)
  4. makraiz Moderator

    Maybe implement a custom portal system? ie. Build a nether gate, place a sign on it, and it will act as the entry point to a quest. I'm not sure if that's possible, but I think it would be cool hehe.
  5. robxu9 Head Developer

    I'm not so sure either. :<
    I guess we could go ahead and trash custom entry/exit points for now (eliminate enter/exit and related). It'll still be in the code, though.
  6. makraiz Moderator

    Less commands for the player is always a good thing. I did some digging, and saw that multiverse 2 (open souce) does have the ability to control a portal w/ a sign.. which leads me to believe that we could implement the portal system. In the end, it's up to you whether or not you'd like to code in such a thing, or maybe take advantage of mv2's api. On the other hand you could leave custom entry points the way they are now and still use /quest enter/exit etc. for those types of quests exclusively, if you don't want to scrap the custom entry/exit point system entirely.
  7. robxu9 Head Developer

    To be honest, I consider MV2 a bit crappy if it throws an exception when loading a world it doesn't know about. (Aka, using native Bukkit methods throws a mv2 exception)

    That being said, if there is some way to do that, then maybe that portal or sign would trigger /quest start instead.
  8. Echobob Developer

    It could just be like an area event at the beginning of the quest. Like maybe something like after you hit the sign you start a simple quest that has just one task where you walk over to a portal (or anything) and then that starts the real quest. Don't know if that makes sense but I could probably demonstrate it sometime.
    makraiz likes this.
  9. robxu9 Head Developer

    I don't think we have a method to automatically start the next quest. I think it only does that for main world quests... hm.
  10. Echobob Developer

    Well maybe we should make a method for it to start a instanced quest? and then we can make the first (starter) quest into a simple event. Like PortalQuestStartEvent:X:Y:Z:Quest_to_start
    makraiz and robxu9 like this.
  11. robxu9 Head Developer

    Yes, that would work.

    Edit: PortalQuestStartEvent:WORLD:X:Y:Z:Quest
    (don't forget the world ;D)

    ...(I still need to make the full compiled list of all events, methods, etc we have)
    makraiz likes this.
  12. Echobob Developer

    Ok well I'm going to work on the wiki. (Giving each event a page with example uses) I will mark which I see are added and we can go from there.
  13. robxu9 Head Developer

    Ok, so for a /quest menu, we've now narrowed it to the following:

    /*
    * OP: reload [name]
    * OP: admininfo [name]
    * OP: admindrop <username> <name> <true/false (complete?)>
    * OP: userhas <username>
    * NoByDefault: drop <name>
    *
    * list [name]
    * info [name] // when called by non-admin, it checks if the player has the actual quest
    *
    * active // in MW, shows main world status. in instance, shows instance status.
    * abandon
    * start <name>
    */

    edit: did some command changing - op drop is now admindrop and op info is now admininfo.
    makraiz likes this.
  14. robxu9 Head Developer

    This is all said and done for now. Moving to Archives.
Thread Status:
Not open for further replies.