Ender Client

[Miss_Min]

ok disregard, problem solved.

Many thanks for updates, especially the fixing of map flags.

[mvgulik]

Client Timers ...

Would be really nice if timers would support count-UP/Duration timers.
As in starting a timer without any duration [00:00:00] that than will start counting the passed time.
And that, when you stop it, keeps the final counted time until its restarted.

Would only needs one additional saved setting.
Something like "counted|span|...":<counted time value>} (Preferably in game time.)
("start" being zero ofc in those cases.)

Hmm. that make we wonder how timers perform with w16.1. ... and when one switching between world.

[mvgulik]

Client Timers ...
Hmm. that make we wonder how timers perform with w16.1. ... and when one switches between world.

Right. Considering the client only uses one timer.cfg for all accounts and therefor also for all characters (per sys-user installed client case I presume). ... And don't uses some world setting in the times.cfg.
The following behaviors make sense.
Current world clocks during test:
== w16.0: gt > 180*(10^9)
== w16.1: gt > 101*(10^9)
-- Timers set at w16.0 will (usually*) show significant different countdown times. [w16.0: 10 days => w16.1: 288 days] -- Usual*: Depending on the game time difference between the worlds.
-- w16.1 timers seem to count down at the right rate. Although not to sure here as the w16.1 countdown feels/looks erratic.
-- As the timers are only using/saving the current world time when they where started. They will continue to show the right countdown in the right world.
-- -- The exception here is of course when active timers from one world are deemed finished in the other world ... Which means you just lost those timer(s).
(I think that last one is what one can call a show-stopper, or at least a show-spoiler.)

[mvgulik]

I'm sure there is some deep sorting logic at work here. But from a end-user perspective ... Is just weird. lol

(Watch the amounts.)


At least it seems controllable'ish (wel, at least for 2 same q cases).

[mvgulik]

Figure this could be because the client is using more than one decimals behind the comma to group items here.
But as those additional decimals are never displayed (anywhere in any client as far as I know) it seems to be more general confusing then actually useful.

Or ... something really weird, that's way beyond my imagination, is going on here.

--- --- --- --- ---
Below post image:

[yuryudjin]

The import map button currently works as an export.

https://imgur.com/a/Ttub4yb

[ReDll]

The import map button currently works as an export.

https://imgur.com/a/Ttub4yb

As far as I can see functionality works, it's just message is wrong. But message it's vanilla.
Do you have proof that it's not importing maps?

[mvgulik]

What ... Vanilla client issue... wow. So one issue get fixed and an other lame one gets added for good measure.

Do you have proof that it's not importing maps?

Would be a kinda lame excuse for Vanilla dev's to not fix that bad messages. And ofc check themself at the same time if [Export] is actually exporting instead of importing.

So far no related bug message in the so called 'official' bug reporting forum section. But than again ... unofficially ... its kinda dead.

[ReDll]

It was actually broken somewhere in may)
We fixed this in Ender. Works now.

[mvgulik]

Cool. That was super fast.