Game Development: Creel Quern

[mvgulik]

Would have thought the new client would be Java 11 compatible.

It is, rather I'm fairly sure that's a bug in glibc. I get that on my laptop running Debian Testing, but not on my desktop running Debian 9.

Linux, Mint, Cinnamon, 19.3. (in case that is of any use)

Just for the record, I don't think that is something that I can fix, since, again, it appears to be a bug with glibc. If anything, perhaps I should actually try to debug that and report it; I've just been assuming that someone is already aware of it and that it will be fixed, but that might be naïve.

How do you figure this "illegal reflective access" error is due to a bug in glibc ?

Code: Select all

(Java 11)
$ <Run Client>
$ WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.jogamp.common.os.NativeLibrary$3 (file:/home/<user>/.cache/haven-launcher/cache/https/game.havenandhearth.com/java/jogl2/jar/gluegen-rt.jar) to method java.lang.ClassLoader.findLibrary(java.lang.String)
WARNING: Please consider reporting this to the maintainers of com.jogamp.common.os.NativeLibrary$3
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)' failed!


The only glibc hint I see is if I start the New-, or the Old-, client from terminal (using Java 8). (In both cases the client will run)

Code: Select all

...$ <Run_Client_Old>
(java:21368): GLib-GObject-WARNING **: 19:25:48.091: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'
...$
(java:21396): GLib-GObject-WARNING **: 19:25:57.525: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'
--- rem "after closing client" ---
(java:21396): GLib-GObject-WARNING **: 19:26:10.839: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'
(java:21396): GLib-GObject-WARNING **: 19:26:10.906: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'

...$ <Run_Client_New>
(java:21554): GLib-GObject-WARNING **: 19:28:27.557: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'
...$
(java:21579): GLib-GObject-WARNING **: 19:28:35.785: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'
--- rem "after closing client" ---
(java:21579): GLib-GObject-WARNING **: 19:28:43.135: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'
(java:21579): GLib-GObject-WARNING **: 19:28:43.246: invalid cast from 'GtkToplevelAccessible' to 'JawToplevel'


Based on a packaged manager search my system seems to be using v2.27 (of glibc) ... ("2.27-3ubuntu1").

Would compiling the client from source help in this case ? (ie: client binary would be better geared for the local system (?))

[loftar]

How do you figure this "illegal reflective access" error is due to a bug in glibc ?
The only glibc hint I see is if I start the New-, or the Old-, client from terminal (using Java 8). (In both cases the client will run)

Because the actual crash happens in ld.so, which is part of glibc.
EDIT: The "illegal reflective access" isn't the actual error that causes the crash, that's just a completely unrelated warning. It's the "Inconsistency detected by ld.so" that is the crash message.

Would compiling the client from source help in this case ?

Doesn't help for me, at least. Running with Java 9 is what has worked for me.

[shubla]

You cannot take screenshots with the new client? Nothing seems to happen when I press alt + s

[mvgulik]

In my case this kinda means that for Haven I'm stuck to Java 8 until my system is (auto)updated with a correctly working/patched glibc ... someday. Bummer.
Anyway, thanks for additional info.

(Java 9 ... Mmm, think I stick to 8 or 11. Got enough troubles with Linux as it is. )

[loftar]

You cannot take screenshots with the new client? Nothing seems to happen when I press alt + s

Right you are. Should be fixed now.

[halorocks22]

Mr Job and Mr loftard I like youe game. Thanks and loves and kisses xoxo no homo unless u swing that way lols

[Agrik]

I guess there is a case to be made that the camera angle should be indicated on the minimap.

It would be nice, but the main problem (or at least how it seems to me) is the 45° discrepancy between the map and the main view.

I'm fine with fixed map orientation, but my brain seems to stumble at rotating my surroundings at the fine angle of 45°. Each time I have to double-check what diagonal directions my "right" and "left" are now, and to find in what direction lies an object I see being "behind, rougly 30° to the left" is so exhaustive (when you have to do it often in your wanderings) that it's faster to check with the actual movement...

it wouldn't just be a matter of tilting it 45°, but rather to keep it rotated with the main camera at any angle it might be

No, it's mostly a matter of tilting, because "fixed map" vs "rotating map" is an eternal argument. Some people (including me) prefer fixed map, some prefer rotating one.

I suppose that fixed maps are usually preferred by people who like to think about bigger picture, to scale in and out and relate maps to each other (it's easier when you don't have to rotate images in addition to scaling and moving them), while rotating maps are preferred by those who mostly use existing maps in different places or draw their immediate surroundings (it's easier when "up" is what in front of you).

Nevertheless, there are two kinds of people with opposite preferences, so you don't exactly have to make the minimap rotating (though it may be a larger part of consumers that prefer being presented with a rotating map). But I'm afraid that everybody, or almost everybody, is discomforted with 45° tilt.

[valeriesusanne]

Love the LED cap!
(it's the little things...)

[kirion]

Allowing the camera to rotate freely seems like a no-brainer. That's the big reason why my friends and I are using a custom client (+ some other QoL).

[Garlicman]

If only there was such a thing as making camera angle locking (or free rotation) optional.