Posts by Minotorious

A new update is now available, introducing a lot of new content!
Latest hotfix: 0.7.5.2 (2024-09-10)

    Then came the discussion of crops failing and the benefits of that but the big conversation was on the ability to destroy crops that a player is depending on. Even if he stages his plantings so that he always has food to eat. It would be nice to be able to burn crop fields to reduce their ability to survive.

    why don't you just pick their crops yourself? As in you can go there with a sickle or a pickaxe and steal/destroy the crop field anyway :/


    Or since it is PvP throw some sticks of dynamite in it will most likely destroy most of the crops as well as the land around them so double the effort for the poor guy to rebuild the field and plant everything.

    At some point you can't really explore further without starving. Unless by explore you mean basically starting over each time the animals are gone and only carrying what's in your inventory...which isn't fun at all.

    but why not? you can keep finding plants to eat as you go and every now and then find a cow or a pig for meat. But plants are always there you just need to look around you so you don't miss them.


    well since you can survive in the game currently on a few stacks of tomatoes for days there is no real point in carrying meat when starting expeditions.

    Actually it seems that player.setListenForKeyInput(true); is still required. Without it, my plugin doesn't respond to ESC.

    :O @red51 bugfix :D


    Edit: wait no my bad, mixed up the methods :D the player.setListenForKeyInput(true); is still required, the .setListenForObjectInteractions(boolean) is the one that is not required :D


    PS: sorry for tagging you red :/

    got it :D


    you are missing this line when showing the GUI player.disableClientsideKeys(KeyInput.KEY_ESCAPE);


    and then ofc this line when hiding it: player.enableClientsideKeys(KeyInput.KEY_ESCAPE);



    PS: this line player.setListenForKeyInput(true); is not necessary anymore as the listener always listens

    A regex would allows more flexibility like deciding the number of decimal figures and so on. Possibly allowing to specify a regex would already be enough, as far as I can tell. Of course, this can entirely happen client-side, once the server has sent it the regex.

    Do you just need it to allow certain characters only? In this case we could add a new method like "setAllowedCharacters()", preferably in combination with a regex. This way you can make sure the player can only enter numbers, for example

    Yes something like .setAllowedCharacters(regex) would be great and exactly what I would implement with the DocumentFIlter anyway (but simpler on my side, a bit more complex on your side to give us the Filter method complete and simple :D )


    also maybe a .setCharacterPattern(regex) method would be nice to have e.g. to allow a hex code in [#000000] pattern (^\\[#([A-Fa-f0-9]{6})\\]$) or a pattern of comma separated numbers of 3 digits each i.e. 001,002,003 (^[0-9]{3}[,][0-9]{3}[,][0-9]{3}$)

    Would it be possible for RW GuiTextFields to have support for DocumentFilter and ofc extensions thereof?


    I would like to implement filters on my GuiTextFields to for example allow only numbers. I am sure something like this has already been implemented on the back-end as there exists a .setMaxCharacters() method which is a type of DocumentFilter


    Currently the only way to do this is proof the input once the TextField loses focus and reset it if it is wrong or highlight it red or something for the user to fix.

    Well, basically this problem is caused by the way how the click-event is handled: currently it's fired when the mouse button is pressed. At this stage, the old element is still focused, so the "lose focus" and "gain focus" events are only called after the mouse button event (and since the input event depends on the "lose focus" event, it is called after the onClick() event).
    Changing this requires a lot of work unfortunately. However, actually it's not intended to fire the click-event when the mouse button is pressed, instead it's supposed to be fired when the mouse button is released (this event is always called after the "lose focus" event). The game buttons etc also listen for the mouse release (instead the mouse press) event btw, since it's more convenient (actually several other gui applications out there do the same thing).


    tl;dr we will change the click event with the next update so it will only be fired when the mouse button is released, this will solve this problem :)

    Will this mean that like in other GUIs, if I click on a label but decide I don't want to click it I can keep holding the mouse, move it outside the label and then release it? This way the ClickEvent will not be triggered correct?

    EDIT: I am rather sure that, in other GUI frameworks, in a case like this where one control looses focus and another gains it with a single click; the event for the loosing focus control is generated before the event for the focus gaining control; also because this is what makes more sense in a general way.

    this makes sense, the losing focus element should trigger before the gaining focus one.

    As it seems to me you are using a procedure like this yourself, possibly this relies on the high probability that the needed data have arrived or the needed PlayerGuiInputEvent has been triggered by the time the user presses the 'other' button ([X] or whatever). However, the whole of this is not deterministic (as network running is not deterministic to start with) and leaves room for any kind of problems.

    In fact what I have done is that my text input events to save the entered text as the default text and then the "Ok" button to save the text from all fields to the database and ofc internally in the plugin so they take immediate effect without the need for a server restart.


    In fact the swap you are recommending would benefit me as well in case the user clicks the "Ok" button before clicking somewhere else for the input event to be triggered first. I am just "arguing" to make sure the change if it happens is one that most people will prefer :)

    big chunk hole

    A chunk hole is always the same size, the size of a chunk :D (16x16x64 blocks XZY)


    maybe @red51 could add the F10 key as an extra permission with the new update? Under Creative Mode permissions maybe? Btw @red51 I thought there was a command that did the same as the F10 tool but couldn't find any more info on it with a quick search on the forum, is there one or did I dream of it? :P

    unless there is a good reason why this is not enabled in none-creative mode?

    To this I forgot to answer but if people start spamming F10 then that might cause a heavy load on the server. But I have no idea what the actual impact would be i.e. latency, connection issues, etc.

    What exactly do you mean by the world is not saving?

    • Are you getting red messages on the top left saying world could not be saved?
    • Are you trying to find a save button? Don't look anymore there isn't one, the game has autosave
    • If you are quitting the game too quickly after doing an action then that last action is sometimes not saved in the world database yet. it is recommended to wait a few seconds without doing anything before closing the game.
    • other? please provide more information


    I have only one world that was messing with the world choices from 7-24 but any that I try to start and save the don't.

    What 7-24 choices? Choices in world creation don't have any impact on how the world is saved, or do you mean something else?

    I still believe you are making things much more complicated than they have to be.


    If the callbacks are called and processed in your EventMethod for the GuiElementClickEvent before the same method closes the panel and its children then there should be no problem at all. I don't really understand why you think that would make the code unmanageable.


    other options I can think of right now (the second is the best imo):

    • add a 1-2 second timer (should be enough time for the other event to execute properly) before the Ok button's actions happen and the panel closes (i.e. put the whole contents of the method in a timer then start the timer in the method)
    • make the Ok button save the information but not close the panel and have a second "x" button to close it, this way if I pressed Ok with a wrong value I have the chance to notice it and correct it, press Ok again and then close the panel myself when I am sure I am done
    • tell the users to click somewhere else or press Return while in the text field before clicking the Ok button

    it is possible, but I have described a very real and relatively frequent case where the current event order is "non-preferred". Can you describe a use case where, when the focus moves from element A to element B, it would be preferred to have the event for element B (the focus destination element) notified before the event for element A (the source element)?

    I can't really think of a case right now as I haven't used that kind of thing before (I just put a save button to save the content of my 20 or so textfields and then close the panel with an "x" button on the top right as in Windows (Linux sometimes can have it on the top left instead)).


    But my point was more a general one, shifting the problem is not really a solution.


    PS: anyway now that I thought of it a bit more, the 2 events should trigger at the same time not one before the other anyway. As in when I click somewhere else the GuiInputEvent is executed and when I click on a clickable label the GuiElementClickEvent is executed so by clicking the label right after being in the text field should cause both events to execute simultaneously just like when I hit with a pickaxe while moving both the DestroyTerrain and the PlayerChangePosition Events should trigger at the same time not in some order.

    why use the PlayerGuiInputEvent then?


    let me explain:


    1) make the GuiTextField setListenForInput(false);
    2) then in the PlayerGuiElementClickEvent have a line like GuiTextField myTextField = (GuiTextField) player.getAttribute("myTextField"); or ofc in any other way you identify your Elements, I think you have said you use a unique ID number?
    3) then simply use String myText = myTextField.getCurrentText(blablabla);
    4) do whatever you want to do with the String
    5) close the GuiPanel


    this way you both get your text, process it and do whatever you want to do with it and close the panel both with only one event :)


    Would it be possible to have the PlayerGuiInputEvent before the PlayerGuiElementClickEvent? This also once that "real" GUI buttons are added to the API?

    In my opinion this is not a real solution as there could be a case someone would want them to trigger the other way around. And since there is a simple in my opinion solution to the problem as written above I don't believe any change to the API is required. But as always this is up to red to decide :)