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

    @zfoxfire: while visually adding some GUI widgets (buttons, even drop lists or combo boxes) to the current API to build an appearance of dialogue boxes might not be such a tremendous amount of work, interacting with them is another thing entirely.


    Remember that currently there is no mouse cursor in 'normal' RW work, so there would be no way to point and click those widgets. I can speculate that providing a mouse cursor would require a rather deep architectural change.


    Also because for almost all the usages I can think of, those 'dialogue boxes' would better be modeless, rather than modal, and would require the co-existence of a double mouse model: like the current one (no mouse cursor as the mouse moves the view) when you look at the scenery and another with a mouse cursor to point and click widgets when you look at the 'dialogue box'; of course assuming the programme can guess what you are looking at! ;)


    This rather long discussion between @red51 and me was mostly focused on a way to provide a sensible first step to allow some kind of interaction between the user and API objects (GUI panels included) within the framework of the Java plug-in API as it is now or with limited changes.

    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.

    @zfoxfire: no, no defs reversed.


    Now, think of an elevator: you enter it, the elevator button panel appears. No need for the game dynamics to stop, in fact, I would find it disturbing; the elevator panel is there but you can continue to play the game, perhaps just to exit the elevator without going anywhere with it.


    Or think of my GPS plug-in: you set the display of one waypoint and move toward it, then you bring up the GPS panel to move to the next waypoint; why should the game stop? (and in fact it would not stop: you would stop to react to it, but the world would go on around you, which I personally would find disturbing in most cases.)


    Perhaps, your ATM example is different. Yet, examples could be made to show the contrary: assume you are pursued by a gang of zombies (YEAH! Zombies! :evil: ), you stop at the shop to buy a set of wood poles (or whatever is used against zombies, perhaps wood poles are for vampires, nor familiar with either kinds...): you are 'frozen' interacting with the modal dlg box, but the zombies are approaching and you cannot do anything... worrying, isn't it? Admittedly contrived, but I believe it shows my point.

    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.

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

    The problem i see with this is how do you get that guiPanel to show in the first place oO you would need a command or the script would need to hog a key, i do think this idea is a good one but it needs some more ideas on how to get the panel to popup in the first place oO if the guiPanel is always there i think this could be more of a pain as you would need to walk/fly to where ever the panel is in the game to interact with it, how ever this would be good if it was only used as a button say for a lift script

    Yahgiggle Steam Signature, real name Deon Hamilton :thumbsup: Server @ ip 139.99.136.76:4255 Name (The Federation of territory) Unity :thumbsup:

    If at first your code does not work call it version 0.1 with the odd bug :thinking:

    My Own Website




    31245-logo-png

    Edited once, last by yahgiggle ().

    Quote from yahgiggle

    The problem i see with this is how do you get that guiPanel to show in the first place

    I see at least two scenarios, regardless the interface is a GuiPanel overlaid on the screen or a 3D object with some text on it within the scenery:


    1) the interface is related to a specific world point or area: the catalogue of a shop, the floor selector of an elevator ( ;);) ), the story of a quest giver, etc; some proximity detector code in the script of the shop/elevator/quest could easily detect the player position and show the interface on coming and hiding it on leaving.


    2) the interface is not area-specific: then some command is needed (like the chat commands right now) to trigger its initial display; if the interface items are selectable, they may trigger some action, including updating the contents of the interface itself to show different statuses or contexts or menus (a navigable interface). In principle, instead of the many commands for each script common today, a plug-in could have a single text command, showing the top level menu of that plug-in and from there go on through selections in the interface itself: less things to remember and less occasions for typos.


    If a plug-in manager is implemented and if a generic "main interface entry point" is decided (like a onMainMenu event), it would even be possible to have a list of running plug-in, select one and have its "main menu" displayed ,without any textual command at all.

    (onMainMenu event) is what i think is needed and sort of what i was getting at with the journal idea oO the Journal is implemented now so why not make use of it :/

    Yahgiggle Steam Signature, real name Deon Hamilton :thumbsup: Server @ ip 139.99.136.76:4255 Name (The Federation of territory) Unity :thumbsup:

    If at first your code does not work call it version 0.1 with the odd bug :thinking:

    My Own Website




    31245-logo-png

    Well, actually the GuiPanel is just intended for a simple box with no special functions, so it will not be modal or something like that ;) It's basically the same as the current panel in the Lua API, so it can be mainly used for text backgrounds etc.


    About modal stuff, there will be two options probably: On the one hand it will be possible to enable/disable the mouse cursor via API manually. On the other hand there will be special window elements (like a dialog box) which require any user input (they will be modal by default).


    But about the original topic: Being able to add certain gui elements as childs to a parent element is definitely planned^^

    @red51: of course, both modeless and modal 'dlg boxes' (between quotes!) have their uses and might be useful. I think to have shown above that I expect plug-ins GUI's to be more often more suited to modeless rather than to modal.


    It is true that mouse interaction with modeless 'dlg boxes' might be tricky to implement. given the current mouse management in RW. I still believe, however, that keyboard interaction could be implemented rather easily and efficiently along the lines we discussed here.


    Keyboard interaction may be considered old-style, but practically all plank / beam construction in RW is made through keyboard and nobody seems to complain.

    Damn, as i had first envisioned the GuiPanel, I was expecting something alongside how a player or chest inventory was drawn. this is a functionality that I would love to see.

    Upon looking at Gui stuff in the api more, I'm guessing that:


    GuiPanel = "background object"


    GuiLabel = "text object"


    GuiImage = "image object"


    and all are considered elements?


    still kinda new at this stuff. I'm sure i'll get it straight when the api fully drops lol.

    @nobotious: Sorry for my late response on that (I hope it's not too late^^). But basically you are right, all gui elements GuiPanel (colored rectangles), GuiLabel (texts), GuiImage (like a panel, but containing an image) and GuiTextField (an input text field) are subclasses of "GuiElement"


    Btw @topic: It's possible now to add gui elements as a child to another element. However, it's still necessary to register all gui elements to the player (i.e. even child elements), but maybe this will change in the medium run

    @red51 könntet ihr vllt für das nächste update eine MouseEvent klasse in die API mit einfügen? Dann könnte man schoneinmal einfache GUI Elemente erstellen oder gibt es irgendwo ein solches Event schon? Habe nur PlayerKeyEvent gefunden aber das hilft mir nicht bei meinem Problem.


    LG Garfield


    [EDIT] Konstruktor der Klasse GuiElement ist auf private gesetzt, kann somit keine eigene Elemente erstellen da ich immer den Fehler bekomme : "GuiElement(...) nicht sichtbar).

    Quote from Garfield

    @red51 könntet ihr vllt für das nächste update eine MouseEvent klasse in die API mit einfügen? Dann könnte man schoneinmal einfache GUI Elemente erstellen oder gibt es irgendwo ein solches Event schon? Habe nur PlayerKeyEvent gefunden aber das hilft mir nicht bei meinem Problem.

    Sowas gibt es bereits, muss allerdings auf das GuiElement selber angewendet werden. Gui Elemente können "anklickbar" gemacht werden, indem man zB guiElement.setClickable(true) aufruft. Nun wird - sobald das Gui Element angeklickt wird - ein PlayerGuiElementClickEvent getriggert (welches alle Infos über Mausbutton, Klickposition etc enthält).


    Man muss allerdings, um die Maus zu aktivieren (damit der Spieler überhaupt ein Gui Element anklicken kann), vorher player.setMouseCursorVisible(true) aufrufen (bedenke, den Cursor auch wieder auszuschalten, wenn nicht mehr benötigt, da der Spieler sich sonst nicht mehr fortbewegen kann) ;)

    Quote from red51

    Sowas gibt es bereits, muss allerdings auf das GuiElement selber angewendet werden. Gui Elemente können "anklickbar" gemacht werden, indem man zB guiElement.setClickable(true) aufruft. Nun wird - sobald das Gui Element angeklickt wird - ein PlayerGuiElementClickEvent getriggert (welches alle Infos über Mausbutton, Klickposition etc enthält).

    Ok danke für schnelle antwort. Habe ich garnicht in der Doku gefunden, liegt wohl daran das ich mir nicht die aktuelle Version runtergeladen habe wenn es sie gibt .... Muhaha :thumbsup::whistling:

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login