Ender Client

[mvgulik]

Source code: "do not flatten Land Survey when Flat terrain is on"

Hmm ... Aha. (don't use flat terrain that often myself)
+Alternative system message perhaps ? (than "You need soil to fill this up.")

Potentially added "Flat terrain is On" warning text when placing a build on to uneven terrain comes to mind.

[mvgulik]

Timers

I think it could be useful if the "timer.cfg" data included the "start" related real-time epoch value (also in milliseconds if need be).

Useful: As in being able to using the "timer.cfg" data directly to easily calculate the related real-time finish times. (for stuff that take a relative long time)
One caveat ofc. Those real-time epoch values, and the calculated real finish times based on them, will ofc be off target after a server outage/patch. (although a bit to soon it still better than to late)

Technically ... one only needs one "Game-time vs related Real-time" data set to do the same job on all active timers (-> Current virtual world start rt-epoch value. Which will not change while the game-server is up.)

Anyway. Just thinking out loud.

[mvgulik]

Trellis crops don't show there on-screen quality-label anymore (after inspected a given trellis crop ofc).

Ground crops still do.

[mvgulik]

During replanting of (Red Onions, after harvesting them).
Was near a village flag. But that might be just a coincident.
Got noting else. (Beta)

Code: Select all

java.lang.NullPointerException: Cannot read field "states" because "bk" is null
   at haven.render.RenderTree$TreeSlot$SlotPipe.get(RenderTree.java:729)
   at haven.render.GroupPipe.get(GroupPipe.java:38)
   at haven.render.RenderTree$DepPipe.get(RenderTree.java:313)
   at haven.render.Location.apply(Location.java:128)
   at haven.render.RenderTree$DepPipe.prep(RenderTree.java:294)
   at haven.render.RenderTree$TreeSlot.mkdstate(RenderTree.java:546)
   at haven.render.RenderTree$TreeSlot.dstate(RenderTree.java:659)
   at haven.render.RenderTree$TreeSlot.access$700(RenderTree.java:408)
   at haven.render.RenderTree$TreeSlot$SlotPipe.get(RenderTree.java:727)
   at haven.render.GroupPipe.get(GroupPipe.java:38)
   at haven.render.Homo3D.obj2clip(Homo3D.java:192)
   at haven.render.Homo3D.obj2sc(Homo3D.java:210)
   at haven.Sprite.draw(Sprite.java:168)
   at haven.PView$ScreenList.draw(PView.java:415)
   at haven.PView.draw(PView.java:341)
   at haven.MapView.draw(MapView.java:1878)
   at haven.Widget.draw(Widget.java:811)
   at haven.Widget.draw(Widget.java:816)
   at haven.GameUI.draw(GameUI.java:1370)
   at haven.Widget.draw(Widget.java:811)
   at haven.Widget.draw(Widget.java:816)
   at haven.RootWidget.draw(RootWidget.java:93)
   at haven.UI.draw(UI.java:428)
   at haven.GLPanel$Loop.display(GLPanel.java:307)
   at haven.GLPanel$Loop.run(GLPanel.java:396)
   at haven.JOGLPanel.run(JOGLPanel.java:246)
   at java.base/java.lang.Thread.run(Thread.java:833)

[mvgulik]

Kinda funny "Now you see me, now you don't" case.
Domestic horse with saddlebag don't show on minimap.
...
Figure it can be manual user-added to "radar.json" [gfx/kritter/horse/saddlebags]

[mvgulik]

[mvgulik]

Seems some odd rare exception.
Related to client Craft-search-menu.
Think I mouse selected an item down the list followed by a fast Enter. But could not reproduce it at will.

Code: Select all

java.lang.NullPointerException: Cannot read field "pagina" because "haven.ActWindow.access$000(haven.ActWindow).sel" is null
   at haven.ActWindow$1.activate(ActWindow.java:29)
   at haven.TextEntry.done(TextEntry.java:156)
   at haven.ReadLine$PCLine.key2(ReadLine.java:277)
   at haven.ReadLine$Base.key(ReadLine.java:157)
   at haven.ReadLine.key(ReadLine.java:80)
   at haven.TextEntry.keydown(TextEntry.java:174)
   at haven.ActWindow$1.keydown(ActWindow.java:49)
   at haven.Widget$KeyDownEvent.shandle(Widget.java:1205)
   at haven.Widget.handle(Widget.java:910)
   at haven.Widget$Event.dispatch(Widget.java:863)
   at haven.Widget$FocusedKeyEvent.propagation(Widget.java:1186)
   at haven.Widget$Event.propagate(Widget.java:853)
   at haven.Window.keydown(Window.java:605)
   at haven.ActWindow.keydown(ActWindow.java:88)
   at haven.Widget$KeyDownEvent.shandle(Widget.java:1205)
   at haven.Widget.handle(Widget.java:910)
   at haven.Window.handle(Window.java:597)
   at haven.Widget$Event.dispatch(Widget.java:863)
   at haven.Widget$FocusedKeyEvent.propagation(Widget.java:1186)
   at haven.Widget$Event.propagate(Widget.java:853)
   at haven.Widget.keydown(Widget.java:1417)
   at haven.ConsoleHost.keydown(ConsoleHost.java:131)
   at haven.Widget$KeyDownEvent.shandle(Widget.java:1205)
   at haven.Widget.handle(Widget.java:910)
   at haven.Widget$Event.dispatch(Widget.java:863)
   at haven.Widget$FocusedKeyEvent.propagation(Widget.java:1186)
   at haven.Widget$Event.propagate(Widget.java:853)
   at haven.Widget.keydown(Widget.java:1417)
   at haven.ConsoleHost.keydown(ConsoleHost.java:131)
   at haven.Widget$KeyDownEvent.shandle(Widget.java:1205)
   at haven.Widget.handle(Widget.java:910)
   at haven.Widget$Event.dispatch(Widget.java:863)
   at haven.UI.dispatch(UI.java:655)
   at haven.UI.keydown(UI.java:882)
   at haven.UIPanel$Dispatcher.dispatch(UIPanel.java:102)
   at haven.GLPanel$Loop.run(GLPanel.java:367)
   at haven.JOGLPanel.run(JOGLPanel.java:246)
   at java.base/java.lang.Thread.run(Thread.java:833)


[mvgulik]

Symbel protection on feasting table note.

If I'm correct this protection was coded for having only one table(gui) open while also 'only' feasting on food from that table (and not from some container or the player inventory).

Meaning that feasting on food from any secondary table, other container or the player inventory ... the symbel protection will just fail. (ie: Either it checks the wrong table, or no table at all.)

(If possible it would be nice if the Main feasting table (the one with the [Feast!] button & "There can be only one".) was actively targeted by the symbel protection feature while feasting (from any other container).)

...

Based on a quick look at ender-client code this seems doable.

[xyzzy57]

As of approximately yesterday, the behavior of arrows leading to quest givers has changed - they no longer show distance, and when you click on them, you only move to the underlying spot on your map - you don't keep going in that direction. This happens whether or not the questgiver is already on your map.

The quest helper UI now only shows distances for questgivers already on your map. It no longer has any idea how far away other quest givers might be.

I'm using the Ender beta client.

I strongly suspect a server-side change as the source of this nuisance.

Note by the way that the Hurricane client had similar issues starting at about the same time, plus a large number of other issues I didn't see on Ender Beta. They issued an update last night, which hopefully fixed most of their issues.

Note also that the quest giver arrows already had issues. If you were too far from an unknown questgiver, it tended to display rubbish, usually with a ? following, and often a nice round number. Sometimes after arriving in an area by Thingwall, questgiver distances would vary erratically for a time, but eventually settle, particularly if you moved around. I never checked behavior on the default client.

Also, in the unfortunate case that a questgiver on your map was destroyed, and another arose with the same name, and then you got a quest to go to the new one, really bizarre things happened - you'd get sent to the old one and be unable to interact with it when you got there. The fix/workaround was to delete the remembered quest giver. The default client did *not* have this problem.

[maybeI]

The ender client crashes