Player Attributes Question

  • I am in the process of building a rather complex Gui for one of my plugins as a test and if it works out I plan to go on and build Guis for all of my plugins. Thus I have come up with a question regarding Gui Elements and holding them as attributes so that each player has their own Gui.


    Question: Can storing multiple GuiElements be they panels, labels, images, etc. as Attributes on the Player object of every player reduce server performance, player connection, fps, or anything else or not? Just to clarify I am not referring here to 5-10-20 elements I am referring to 100-500 elements each stored as its own Attribute on the Player object.

  • As far as I can tell from 'outside':
    *) fps is local to the client and should be totally unrelated to number or nature of player attributes (server side);
    *) server performance should also not be substantially affected by how GuiElements are stored; it will be affected by their existence and management, but I would not expect how they are stored would change this very much;
    *) the time necessary to "connect" to a server (from clicking [Connect] to starting playing, which is much more than simply establishing a connection) may be slightly longer, but as there is a significant network load, it will possibly not noticeable in itself.


    A point I would raise, though, is if you really need to store each of hundreds of GuiElements as a separate player attribute; I would expect them to combine into larger GUI units (dialogue boxes, windows, menus, ..), which would be possibly more reasonable to store as player attributes.


    Or, as an alternative, only a limited number of major "GUI entry points" (starting windows or perhaps only one "top menu"?) could be stored per player and from them other GUI windows constructed on the fly with the player-specific data.


    So, there is ample margin for experiment and optimisation...

  • A point I would raise, though, is if you really need to store each of hundreds of GuiElements as a separate player attribute; I would expect them to combine into larger GUI units (dialogue boxes, windows, menus, ..), which would be possibly more reasonable to store as player attributes.

    hmm how do you mean that, sounds like a good solution but I don't fully understand it in practice? To explain a bit better what exactly I am doing so that you have some more information to help me with.


    I have:
    1 GuiPanel
    8 Clickable GuiLabel/GuiImage combinations for a button like appearance (GuiImage has a border of set size and GuiLabel has the Text in the middle of the bordered square)
    Each of the 8 Image/Labels refers to a different Tab of my Gui so in practice you click the first Label the first Tab appears you click the second Label the second Tab appears and so on
    Each Tab is comprised of a number of GuiElements (not panels just Images, Labels, and TextFields)
    Currently I have it so as when you click one Tab Label all the Elements of that Tab appear and all the elements of the previous Tab you were on disappear.


    If I understand your solution quoted above right I should:
    1) make 8 GuiPanels one for each tab and add all the Elements as children to each Panel
    2) store the 8 GuiPanels as 8 distinct attributes for the Player object
    3) when switching from one Tab to another do a getAttribute on the GuiPanel to be shown and have a for loop getting and showing all of its children.


    From my understanding this way I will only have 8 Attributes and will be able to have individual GuiElements for every Player Object just not stored as Attributes but saved as children of the Attribute GuiPanels.


    But then the question how do I distinguish between all my child elements since they don't have an individual attribute name anymore :/

  • But then the question how do I distinguish between all my child elements since they don't have an individual attribute name anymore

    I see your problem; I was distracted by RW-Gui, which has a user-defined ID for each GuiElement and reports the element ID for each event; in this way there is no need to store anything, just checking the ID.


    As the default GUI elements have no ID and one has to rely on PlayerGuiElementClickEvent.getGuiElement() or PlayerGuiInputEvent.getGuiElement(), I see the need to store each GuiElement separately.


    One could perhaps use the order of the List returned by getChildren(), but I don't know how reliable it would be.


    Or one could build his own ID system as RW-Gui does...

Participate now!

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