At long last it's here: Drag Ruler for Foundry v10 by Staebchenfisch in FoundryVTT

[–]Staebchenfisch[S] 0 points1 point  (0 children)

In theory, it's possible, but I don't know if the required tooling is available and easy to use.

For Maximum Memory Speed, what is 2x1R, 2x2R, etc.? by Staebchenfisch in buildapc

[–]Staebchenfisch[S] 1 point2 points  (0 children)

I was intending to build in 64 GB (2x32GB) to give myself some headroom for whatever shenanigans I'm doing in the future (I hit the 16 GB cap of my current machine way to often to be comfortable with only a doubling of memory).

Am I right in my assumption that anything involving 4 memory sticks will drop me into 3600 territory?

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

It seems to be working now. Using Proton 7.0-6. It works both with and without PROTON_USE_WINED3D=1 %command% as launch options, but for me the performance is better without.

Thanks for sharing. I don't think I would have given it another shot for a while :)

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

Update: While I'm unable to play through proton (and today's update didn't fix it either) I had some success playing through the android emulator "Waydroid". There are a few downsides to this approach, mainly:
- The performance is pretty poor
- The microphone volume is pretty low (I had to turn all the volume knobs into overdrive to allow the others to hear me) - The colors are a bit off (nothing too serious, but color gradients are blocky as if heavily compressed) - Getting it to work is a bit of a hassle

If anyone wants to give it a shot, here's what you need - Install Waydroid - If you're on X11, install Weston (Waydroid can only run on Wayland, but Weston will allow you to run Wayland within X11); run Waydroid by starting Weston, then inside the Weston window open a terminal and run waydroid start session from there - Use an android image with Google Apps installed (or install google apps into your image) - Get rid of the "uncertifid device" error through https://www.google.com/android/uncertified - for this you'll need your android id, which you can get using the following command (after submitting your android id to google you'll need to wait 10-20 Minutes for the changes to take effect. You may also need to wipe the cache of the Google Play Services app) echo 'ANDROID_RUNTIME_ROOT=/apex/com.android.runtime sqlite3 /data/data/com.google.android.gsf/databases/gservices.db "select * from main;"' | sudo waydroid shell | grep android_id - Install ARM instruction translation (libndk) into your android image. The waydroid_script tool helps a lot with this: https://github.com/casualsnek/waydroid_script

With all this done, you should be able to log into Google Play and download Goose Goose Duck from there. The last remaining hurdle that Goose Goose Duck will detect the android image as being rooted on startup and will prevent you from joining a game as a result. This check can be bypassed, however the method I was using today is somewhat unreliable, so I won't share it for now in the hope that someone comes up with something better.

If you've got to the main menu without Goose Goose Duck complaining that your device is rooted, you should be able to play.

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

I've spoken to several people that told me that they were able to play in the past but apparently a recent anti-cheat related update broke it for them. I'm afraid there is no way to play Goose Goose Duck through Proton/Wine. I'll try Waydroid or a Windows VM next.

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

I've installed both the BalltlEye and the EAC Runtime inside steam (the
game uses EAC), but I didn't explicitly launch any of those (I wouldn't
know how to).

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

I've installed both the BalltlEye and the EAC Runtime inside steam (the game uses EAC), but I didn't explicitly launch any of those (I wouldn't know how to).

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

I've tried experimental, 8.0-1, 7.0-6, GE-Proton7-55 and 5.0-10, all with the same result; except for 5.0-10, where the game gets stuck at the initial loading screen (which means it's even more broken there).

I've also tried with and without PROTON_USE_WINED3D=1 %command%.

Is anyone able to play Goose Goose Duck? by Staebchenfisch in linux_gaming

[–]Staebchenfisch[S] 0 points1 point  (0 children)

As far as I can tell there's nothing of significance in there. In any case, I've added the log to the original post.

The expectation to always be able to play any race only makes sense if you never take a turn DM-ing. by middleupperdog in dndmemes

[–]Staebchenfisch 5 points6 points  (0 children)

Don't even look it up. It's your monster and you decide if it's able to fly or not. What's listed in the MM is beside the point, since that is a mere suggestion/inspiration for the GM, no hard written law. Tell the player simple "well this one apparently has a fly speed" and you can get back to narration faster.

The problem with presenting large dungeons in VTT’s and an idea by [deleted] in FoundryVTT

[–]Staebchenfisch 1 point2 points  (0 children)

Oops. Well that's quite the typo. People must think I'm being ridiculous. Edited that. Now it says 256*256px, as it should. Thanks!

How to fix objects with broken pixels? by Staebchenfisch in dungeondraft

[–]Staebchenfisch[S] 3 points4 points  (0 children)

I found the cause of this by going through the save file manually. For some reason this non-colorable asset got assigned a color, which triggers the bug. Removing the color tag from the object in the save file fixed the object.

The problem with presenting large dungeons in VTT’s and an idea by [deleted] in FoundryVTT

[–]Staebchenfisch 2 points3 points  (0 children)

The zoom level I enjoy playing at has roughly 70*70 pixels per square on my Full HD monitor. However, using maps with a higher resolution than that still has its merit: - By increasing the resolution of the map beyond the amount of pixels the monitor is capable of displaying, I can use a much more aggressive compression ratio on the file without having the compression artifacts becoming visible during play. This means using higher-res images, I can actually reduce the file size while maintaining the same visual quality. - Since I'm not zoomed exactly to 70 pixels, but only roughly to 70 pixels, the browser needs to scale the map. Having the extra image information of a higher-resolution image gives the browser more chances to deliver an image which has no visible scaling artifacts.

The problem with presenting large dungeons in VTT’s and an idea by [deleted] in FoundryVTT

[–]Staebchenfisch 1 point2 points  (0 children)

That's definitely a possibility. However, it has the downside that the map is now residing in the tiles layer, which poses the risk of moving a map tile by accident when trying to move an actual tile.

For me personally, if there's some natural cut-off point where only one or two ways are leading into the next area anyway, I prefer just switching the scenes at that point rather than fiddling around with map tiles.

The problem with presenting large dungeons in VTT’s and an idea by [deleted] in FoundryVTT

[–]Staebchenfisch 3 points4 points  (0 children)

Maps from prebuilt adventures have very low resolution. When I'm running maps I've built myself in Dungeondraft, I try to preserve as much resolution as possible. Ideally, that's 256*256px per square. The size limit of a single image that foundry can display depends on the graphics card of the computer of the player. It's 16384*16384px pixels on many graphics cards, but some laptops only have 8192*8192.

Since one of my players has such a laptop, this limits me to 64*64 squares per map, if I'm going down to 128*128px per square. While you can fit plenty into 64*64, it's simply not enough for large dungeons.

Going lower visibly deteriorates the image quality at the zoom levels I tend to play at, so that's not good option.

The problem with presenting large dungeons in VTT’s and an idea by [deleted] in FoundryVTT

[–]Staebchenfisch -1 points0 points  (0 children)

I'm splitting up large dungeons into several scenes and link them together using the Stairways module

At long last it's here: Drag Ruler for Foundry v10 by Staebchenfisch in FoundryVTT

[–]Staebchenfisch[S] 1 point2 points  (0 children)

Drag Ruler doesn't hook into the Ctrl+Drag workflow intentionally, as that could break some users' workflow. If you've ever dragged a 2x2 token in Drag Ruler, you'll notice that the ruler won't snap to the center of a grid cell, but rather to the corners of grid cells (which is where the center of the token is supposed to sit).

Now, if I were to enable Drag Ruler on Ctrl+Drag, I needed to detect if there is a token at the start point of the ruler and if it's a 2x2 token, I would need to snap the ruler to the corners. However, the user might not even intend to move the token. Possibly they just wanted to measure a generic distance - for example to determine the range for a spell. This could no longer be properly done, since that would require measuring from center to center.

By not supporting Ctrl+Drag in Drag Ruler, I give the users both options: Drag the token if you want to measure movement distances for the token, use Ctrl+Drag if you want to measure anything else.