Scroll zoom and scrolling in menus like outfitters and shipyards is too fast for me on a touchpad, others have reported similar:

Can you please make Endless Web's scroll-to-zoom controls a little less sensitive? When I'm not home I play on a chromebook and it basically gives me the option to be really zoomed in or really zoomed out

I tried to fix it by installing microsoft fonts on my device. They load and work on all other websites I have tried, but this game.

The problem was caused by some anti-browser finger print setting in about:config

https://support.mozilla.org/en-US/questions/1283036

This setting does two things.

1)It changes the useragent from firefox/linux to firefox/windows10 & 2)It won't tell the website what fonts you have available.

I would say the later probably messed up you site. It is all good now;)

I can't find it now but I believe @tehhowch suggested using command line flags instead of ifdefs to turn off features. Will check again, but if this is still the case then we need to mock out the functions provided mad.h (so it still compiles, though it won't work) and a command line flags to decide whether to start the music threads.

Currently plugins work... so long as they're listed at https://github.com/EndlessSkyCommunity/endless-sky-plugins/blob/master/generated/plugins.json. Plugins are downloaded each time, there's no caching.

• maybe we should cache these (https://raw.githubusercontent.com/ is probably ok to depend on, but the CORS proxy I'm running not long-term sustainable)
  • or just change the CORS proxy behavior to be more specific to avoid abuse
• this index isn't very complete. Do people know how to add to this repository? Are the ES Launcher folks using this?
• specify a plugin set via url?

For getting this upstreamed, sure let's keep using threads. But that's what makes the web build not run on Safari, and so for play-endless-web.com let's go back to removing threads.

This should be roughly https://github.com/endless-sky/endless-sky/pull/5594/files

We may only need to be running asyncify on the main gameloop? also, make sure we're using -O3! see https://emscripten.org/docs/porting/asyncify.html#optimizing

Big #ifdef changes make things hard to upstream. We're currently using asyncify to make the gameloop changes we used to make in main.cpp unnecessary, which is a light performance hit but basically works.

https://github.com/thomasballinger/endless-web/blob/a6dabc60fba74c2df02773cd73c88e48759b95e3/SConstruct#L126

If we could use Emscripten thread support that would bring us much closer! I imagine this is the wrong approach and the upstreamable thing to do is to abstract threading a bit instead, e.g. a threading implementation that just runs the thread to completion immediately.

Things to try with pthread support:

• [x] Engine.cpp + Engine.h: spawn a calcThread to handle calculations
  • no noticeable changes
• [x] SpriteQueue.cpp + SpriteQueue.h: spawns worker threads to load sprites
  • loading is significantly slower, but that seems fine
• [x] Audio.cpp Using the old code breaks everything
• [ ] Music.cpp: this is turned off for web anyway, it's just about finding the cleanest way to turn off music

I experienced this on Firefox 88.0.1 on Windows.

21:17:37.070
XHRGEThttps://play-endless-sky.com/endless-sky.wasm
[HTTP/2 304 Not Modified 41ms]

21:17:38.502 WebAssembly.Memory failed to reserve a large virtual memory region. This may be due to low configured virtual memory limits on this system.
21:17:38.611 Uncaught (in promise) RuntimeError: abort(out of memory) at [email protected]://play-endless-sky.com/endless-sky.js:2090:19
[email protected]://play-endless-sky.com/endless-sky.js:2112:16
[email protected]://play-endless-sky.com/endless-sky.js:1738:44
instantiateArrayBuffer/<@https://play-endless-sky.com/endless-sky.js:1915:12
promise callback*[email protected]://play-endless-sky.com/endless-sky.js:1908:8
instantiateAsync/</<@https://play-endless-sky.com/endless-sky.js:1934:20
promise callback*instantiateAsync/<@https://play-endless-sky.com/endless-sky.js:1929:23
promise callback*[email protected]://play-endless-sky.com/endless-sky.js:1927:68
[email protected]://play-endless-sky.com/endless-sky.js:1956:3
@https://play-endless-sky.com/endless-sky.js:14046:11
    abort https://play-endless-sky.com/endless-sky.js:1744
    instantiateArrayBuffer https://play-endless-sky.com/endless-sky.js:1915
    promise callback*instantiateArrayBuffer https://play-endless-sky.com/endless-sky.js:1908
    instantiateAsync https://play-endless-sky.com/endless-sky.js:1934
    promise callback*instantiateAsync/< https://play-endless-sky.com/endless-sky.js:1929
    promise callback*instantiateAsync https://play-endless-sky.com/endless-sky.js:1927
    createWasm https://play-endless-sky.com/endless-sky.js:1956
    <anonymous> https://play-endless-sky.com/endless-sky.js:14046
endless-sky.js:1744:11

and the loading screen was just stuck at loading - i checked the console and didn't see any trouble there. I wasn't sure how long I needed to wait before I got impatient, reloaded and looked in the console again - and then saw the message above.

Closing down some other stuff on my end before yet another reload did fix the issue though.

This does the following:

• make does the same thing as make dev
• make clean now actually cleans the build.
• make clean-full is renamed to make distclean because of convention and also deletes the jpeg lib.
• The source files depend on the headers so that changing the headers triggers a rebuild.
• The source files depend on the jpeg lib so that make -jN works correctly

Missing: make -jN doesn't build jpeg in parallel and I can't figure out how to tell make to listen to -jN.

Script terminated by timeout at:
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[2225]:0x2e7e05
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[2238]:0x2ef3da
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[1371]:0x14231c
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[3479]:0x3e4986
Pg/</b[d]<@https://play-endless-sky.com/endless-sky.js:819:264
E/<@https://play-endless-sky.com/endless-sky.js:643:317
[email protected]://play-endless-sky.com/endless-sky.js:980:160
a[d]@https://play-endless-sky.com/endless-sky.js:969:68
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[1345]:0x12e220
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[1246]:0xe7461
@https://play-endless-sky.com/endless-sky.wasm:wasm-function[636]:0x40527
Pg/</b[d]<@https://play-endless-sky.com/endless-sky.js:819:264
E/<@https://play-endless-sky.com/endless-sky.js:643:317
[email protected]://play-endless-sky.com/endless-sky.js:1064:342
[email protected]://play-endless-sky.com/:431:16
async*@https://play-endless-sky.com/:434:7

@tehhowch makes an interesting point in https://github.com/endless-sky/endless-sky/pull/6164: the official Endless Sky project doesn't want a web build built on PR or in CI; that would limit the project to things that are possible to do on the web.

I can think of a couple versions of this argument.

1. If a PR adding a new dependency also has to make it work for the web, that makes it much harder to contribute. Even breaking a CI test that doesn't officially block merging can have this effect.
2. If the web build is official then the big picture design of the the project is affected: adding something cool or useful that doesn't exist for the web platform is not longer an option.

It's obviously up to the Endless Sky maintainers what to upstream, but beyond that I'm mostly convinced and if I were in their shoes I'm not sure I would! I think it would be beneficial for that project's processes to have web builds available, but I understand @tehhowch's point that just adding the build is a significant change in direction for that project.

Which leaves me to decide what the goal of this project is! Years ago, I wrote a game that allowed users to program their ship and missiles which reused Endless Sky assets and data file formats. That made me want to do something similar for the larger community of Endless Sky players. After a few false starts, last year I got help with porting the game to the web with the initial goal of upstreaming the changes. We got very close, but I've now hit the limit of what the project maintainers are interested in merging. They have been and likely will continue to be willing to accept changing that make it easier to do a web build, but at this time don't want the web build in the repo.

Thinking about what excites me, it's

• enabling people to play this on the web
• helping developers of the project by providing tooling like the formation tool
• helping plugin authors by providing tooling like a data file editor

I'm also still interested in some of the wackier stuff:

• a platform to link directly to specific save games and missions in order to share bite-size experiences like a single mission
• allowing players to write code to control their ship (running a WebAssembly interpreter? Lua? other interpreter?) and sharing these programs

So what's the goal?

For maintainability (plus if this were every to get upstreamed to https://github.com/endless-sky/endless-sky) the diff should be smaller. Let's get threads working again, even if it is a worse experience. Now that Safari supports it it should be fine!

Previously a threaded build was working: https://github.com/endless-sky/endless-sky/pull/6164

The goal is that the first two commits of the endless-web branch should be enough to have a working build using threads, but also that a threaded version work at the tip of endless-web.

They do not work again until I do a complete reset, but it is a pain resetting all the time, so i would like to find a better way. Admittedly this device is AUP, but it might happen with newer ones as well.