Posts by zfoxfire

  • NPC.moveTo method request (and alsoNPC ownership)

    Oooh, I guess NPC servitude is kinda relevant to this too (I'm going to re-name this topic to make it more relevant in a second) and I will appologize now because this post as it is written below is more of just an API request, it could also be a built-in game feature but atleast with the API functions I'm requesting we might be able to write something ourselves.


    NPC servants is another nice feature. How would we work out how ownership works? Basically a Player or NPC can own another. Player owns Player, Player owns NPC, NPC own Player, NPC owns NPC



    Some new methods for an NPC object:

    • NPC.isOwned() returns a boolean
    • NPC.getOwnershipCriteria () returns a condition
    • NPC.setOwner(Player)
    • NPC.setOwnerCriteria(condition)


    And why not set it for player relationships too? :

    • Player.isOwned() returns a boolean
    • Player.setOwner(Player) ... suppose you are in a relationship with another player. This can be set one way or be mutual ( PlayerA.setOwner(B); PlayerB.setOwner(A)
    • Player.setOwner(NPC) .... this would work if say, a wandering NPC saves you from death (maybe this could be a random event build into the game or something we could do via API.. example: Player dies, a randomizer runs(e.g. dice roll), if successful then a NPC will spawn nearby and resurrect player. This automatically triggers Player.setOwner and Player.setOwnershipCriteria
    • Player.getOwner() returns a player object
    • Player.setOwnershipCriteria(condition[]) accepts an array of conditions


    Ideas for conditions:

    • Ownership continues after a certain amount of time passes
    • Servant follows random orders given while game is in session (player can still possibly exit game at anytime to pause this)
    • Servant pays Owner in resources (give ores which implies requiring work)




    Accepting conditions:

    • Whoever initiates negotiations (be it the NPC that saves the life of a player or a player approaching an npc merchant). begins with a randomized list of conditions (follow me, defend me, pay me)
    • There is a negotiation window (similar to the trading window) that shows a list of conditions on each side with buttons to accept/reject/re-negotiate
    • A variable for whether or not terms are negotiable
      • If non-negotiable: initiator has full ownership of player (can kill you, rob you, etc..(I suspect this could backfire in the situation where a condition cannot be satisfied but I figured this might be an option for in the event an NPC saves your life) however an option to reject this condition triggers Player death.
      • If negotiation is allowed then re-negotiate button is activated and will re-randomize conditions and allow the player to offer conditions on their end and click the re-negotiate button (e.g. I will not pay you money that you demand but I can protect you for X amount of time
      • Accept causes the conditions to be set (if conditions are given two ways then a condition set is applied to both character (being either a player or an npc)
      • Deny -- depending on the situation might result in NPC being killed or hurt and looted (probably should add a consciousness variable to Player (have consciousness work like in ARK where is returns to normal over time but character is susceptible to looting or death while a value is set.
      • Re-negotiate -- if active,


    Ownership Perks (this needs to be expanded on):

    • Owner can access your inventory (if ownership is set both ways then the access is also both ways but I suspect NPC on NPC ownership can be a problem as deadlock or infinite loop might occur here)
    • Owner can access vitals (e.g. feed you or heal/break your bones) --- wow that's mean!


    any getOwnershipCriteria needs to return an array of conditions. We need add/remove methods for conditions as well as a check condition so if condition is an array then Condition[1].isSatisfied return a boolean


    Orders (orders given by owner to servant:

    • give me x number of inventory items
    • craft something
    • build something
    • follow me (servant must keep within a certain radius)
    • ride me (this order will play whatever "ride" animation is optionally implemented and ensure that the rider is following the position and view angle of the Player) -- this is how I would implement a more advanced version of the pig taxi
    • i will ride you
    • follow me and fight


    Penalties of breaking orders:

    • Health reduction
    • Taking inventory
    • Breaking bones
    • Fight (ownership is disolved when either owner or servant is killed) - trigger event where player eventually de-spawns. Inventory is now up for grabs.

  • NPC.moveTo method request (and alsoNPC ownership)

    So I was chatting the other day with Arcticu about my thoughts of BladeRunner flying cars as taxi services and I got an even better idea just now. What about flying pigs?


    So I'd like to request that the Player.moveTo method be implemented into NPC as well. Also a way to assign a rider to the NPC ( NPC.setRider(Player player). The idea of spawning a rideable flying pig as part of my taxi service that I'm working on would pay homeage to the older bugs of Rising World and all the fun and jokes we all made about them. When the Animal AI is fixed then we won't have flying pigs anymore. :(


    If something like Npc.setRider(Player) is not ready yet then atleast att Npc.moveTo and I can translate both player and npc at the same time :)


    Ohh... Player.setRider(Player) and Player.setRider(Npc) are also good ideas as with many online environments such as SecondLife, you can carry someone on your back.

  • my command interpreter

    Quote from Miwarre

    Just had a cursory look. A few comments:


    1) Purely stylistic, but usually classes have initial upper case while variables have initial lower case. So, the class consoleListener and the class commandInterpreter would usually be spelt class ConsoleListener and class CommandInterpreter.


    Also the variable commandInterpreter CI; would be better spelt CommandInterpreter cI;. This has some consequences, as when the variable is used later as in CI.parseString(tokens); the 'instict' would be to see the invocation of a static method parseString() of a hypothetical class CI.


    Yes you are correct. It is stylistic but I am not following the standard. I'll fix this. I jump back and forth between different languages and forget those little things.


    Quote from Miwarre

    2) In line 12 of the CommandInterpreter constructor, the parameters passed are not used, rather literal values used in their stead; if the use of literals is intentional, then it is useless to pass any parameter to the constructor.

    Gotcha. I added the constructor because Netbeans was complaining about one not being there. There is no reason to modify the values so I restored it to the constructor generated by default. That was probably me trying to fix something from before but now it seems incorrect. Thanks for the catch :)


    Java
    public commandInterpreter(float x, float y, boolean relativeposition) {

            super(x, y, relativeposition);

        }


    Quote from Miwarre

    3) The CommandInterpreter class is derived from GuiLabel and its text is repeatedly set, but the label itself is never shown on the screen of any player; am I missing something?

    I don't know what you mean by the text being repeatedly set. The idea is that the command argument typed into the console is read and depending on what each command does will determine what text is printed to the screen. The string will be appended to or replace the contents of the stringbuffer. or The screen is made visible and shows the contents of the stringbuffer. into the standard command console... StringBuffer is actually old and I should use StringBuilder instead. Maybe something better is available in JDK 8 but I haven't looked yet.


    Quote from Miwarre

    4) Do I understand correctly that the GuiLabel origin of CommandInterpreter is used only to display generated text? Why not using it also to display the command themselves? And perhaps even to select them by intercepting a few strategic key presses, without relying on memory?

    I could print the original command and format it to look more like an actual operating system command line. The string shown can be anything I want it to me. I'm mainly focusing more on the structure of the plugin and not really the content yet.. What do you mean by select them ? What memory issue do you see?

  • my command interpreter

    Finally got all the red squiggly lines to go away. So I'm just posting in hopes for some feedback. I want to make sure I'm going in the right direction.


    The idea is to eventually offer a suite of commands and additional plugins that can be interfaced by the console. The output is a guiPanel which pops up in the middle of the screen wheras the standard console box is for input. I like this route better than the current implementation which uses the chat window as output and when you are on a busy server.


    Some improvements I want to do (what I can think of right now):
    1. make console output fancier which would include multiple colors and indented lines. I don't know if the text colors supported in Player.sendTextMessage are supported in guiPanel text.
    2. pass an array subset of the arguments to each command, rather than the full one. Shouldn't be that hard.
    3. Possibly abstract the commands. It seems un-necessary since each command will just parse the argument array and return a string. Maybe as the API advances and we can do custom panels with buttons and dropdowns then I'll need more functionality besides returning a string so abstraction will make more sense.
    4. Make the guipanel invisible by default. I just realized that it will be drawn as soon as gameplay starts :(
    5


    So here is my primary class:




    And here is the command interpreter



    And an example command:



    Java
    package rwZorkConsole;

    /**

     *

     * @author zork

     */

    public class cmdHelp {

        public static String parse(String[] args) {

            return "Welcome to ZorkNet (znet), for all your adventuring needs!";

        }

    }

  • guiPanels

    @red51


    Hi Red,


    I'm tagging you in this so hopefully you see it. I had an idea that might solve the problem...


    As the guiPanel develops further and more elements are added (essentially making it like a standard jPanel) then we can have a two options for implementing:


    1. The guiPanel is drawn like a standard jPanel on the screen. This panel is modal which will takes mouse and keyboard control away from gameplay. I don't see how this can possibly be added modeless unless the player was to have a second mouse or if maybe element selection was linked to they keypad (which would free up the mouse for movement). Currently the keypad only functions for rotational commands when doing construction.


    2. the guiPanel can be rendered as a world object. It would act like essentially a giant touch-screen. So a player can walk up to the object and interact with the panel using the mouse button. This would not shift mouse focus away from the game. The only time possibly that keyboard focus would switch is if the player clicks into a textbox. However, quickly clicking the mouse outside of the text field would return the normal keyboard control (so movement can presume).


    You and Miwarre were discussing implementing an interaction event into custom 3d models. I think that the interaction event would tie in with both the custom model and the guiPanel idea from #2 above.

  • guiPanels

    I agree that in a slow-paced situation, or when you have a more complicated interface, the gui Panel would be fine. However you can program it so that the ESC key would immediately cancel out the screen and return your mouse and keyboard to normal character control


    In a fast-paced situation the guiPanel may not be appropriate.. For example, if you've ever play 7D2D then you'll find yourself looting a abandoned car while zombies are creeping up on you. A search takes about 4 seconds to complete which can be an eternity if the zombies are too close but you can hit ESC to abort and start running.


    To use your elevator as an example, if you don't want the action interrupted then you would have to design a button panel or maybe large up/down arrows as part of the elevator model. Then capture where on the panel the mouse was clicked to determine which floor to go to.


    No fancy re-design needs to be done for these scenarios. Unless you are thinking about adding game controller support. Modern game controls have two analog sticks and can certainly offer a way to look around or move while operating a menu. A PC computer has only one analog control (a mouse). Perhaps that is what you mean. I know some people want controller support but this game doesn't feel like the kind that needs that added. Also keep in mind that the primary platform for this game uses a keyboard and a mouse so if you design it to have unique functionality that is only possible with a control pad then you've added an unfair advantage over the target audience of this game.

  • guiPanels

    I really don't see why modal is a problem. Think of the current ESC key functionality: mouse and keyboard control is released from the controlling the player within the 3d portion of the game, the gameplay is paused (single player only), and then a guipaneel with buttons is drawn. These are all seperate calls but the mouse and keyboard release event is what we need access to.


    Lets say you wanted to build an ATM application. So you walk into the First Bank of Rising World, click the ATM (custom 3d model) which listens for the F key. The mouse control is released and a guipanel with graphics, buttons, and a text readout are drawn. This does not pause the game like ESC does but it still carries out most of the other tasks that that game is already carrying out when ESC is pressed. When your transaction is complete, mouse control is returned to player control.


    This does not seem too hard to accomplish, we just need to access the mouse via the API.


    As for modeless, I can't imagine anyone would want to be moving their head around in-game while interacting with something else. I already have this problem when I ALT-TAB to another Window before pausing the game ;)


    Are you sure you don't have your definitions reversed? Modal is locking out the interface that launched the interface you are creating. Modeless allows interaction with both such as detatchable toolbars.

  • guiPanels

    Red51,


    Per our chat, I'm posting this in public as a reminder that eventually this needs to be improved. I can add guiLabels directly to the screen which will suit my immediate needs.


    I'm imagine that in the future, a guiPanel will behave much like a jPanel where various elements can be added and organized such as buttons, drop downs, canvas, maybe even a remoteCamera feed from my other suggestion ^^




    Quote from Red51

    red51: hmm... actually this is something the API doesn't take into account yet. our gui works this way (basically even elements like the chat are nothing but several labels and panels), but the API has no methods to add child elements (or to set an element as parent). that's definitely something that needs to be changed. I don't think we get that ready for the first release, maybe post a topic about that in the feature suggestion forum, so it does not fall into oblivion ^^


    but yeah, you can just add a GuiLabel to the screen directly. a "GuiLabel" is a text element (it can also have a background color if desired).

  • 7D2D A15

    If I could run my 7D2D sever, I'd love to play with you. Unfortunately the final A14 release broke the linux server. So I have no way of hosting a game :( I hear a variety of rumors about A15 coming out in the next month but other rumors state early next year so I have no idea what is going on. :(

  • the chat window

    If the console is relative in size then that works even better. So if I know the console won't be more than 20% the height of the screen then I'll make sure my window is never larger than 80%.


    What I was envisioning is that any custom services offered should be migrated out of chat window and into console. I'm not even sure why everyone is using the chat window for commands in the first place. For my idea, the console would be below the panel and the panel would be the output device wheras the console just shows keyboard input, kinda like if you were sitting in front of a computer terminal :)


    The only issue I have with the console and chat window right now is that both of those and the F3 text overlap so it is difficult to use them all effectively at the same time.


    I'm not sure what you mean by move-in animation. Anyways, this is just a suggestion. Low priority. :)

  • Rising World: Are we Going somewhere?

    That's one I still have some trouble dealing with. Jumping into the river helps a lot but it still can be not good enough. The best way is to find shelter. I ducked under a bridge and solved the problem. I probably could have kept some wood frames on me and built a shelter. Would be nice if we could get a tarp and just duck under that for protection from the sun.