chattheatre / skotos Goto Github PK
View Code? Open in Web Editor NEWOpen Source version of the SkotOS narrative prose library, using the DGD driver.
Home Page: https://www.ChatTheatre.com
License: Other
Open Source version of the SkotOS narrative prose library, using the DGD driver.
Home Page: https://www.ChatTheatre.com
License: Other
When doing a local cold boot of SkotOS, Tool:Lib:Popup is missing which causes other issues in Tree of Woe. Trying to load any file results in:
cannot resolve ${Tool:Lib:Popup}
Tool:Lib:Popup does appear in /skoot/data/vault. I have also tried cold booting my Lovecraft Country vault dump and Tool:Lib:Popup is still missing. The dgd log shows this error during the boot process:
May 1 19:22:30 ** Could not load Tool:Lib:Popup, not found
The latest commit to Maintenance.md specifies 8000 in some places, I suspect this might need to be converted to X000
If you edit out all the old users in WOE:System:Developers using the XML edit mode, none of the changes get committed. You have to delete them by hand from the [V] interface.
When taking an item, it returns a blank line rather than outputting the action. This has been tested locally and in vRWOT.
When using Gables, RWOT, etc., it's nice to be able to specify an alternate SkotOS branch from the StackScript. It allows reasonable debugging of patches to core SkotOS by running them with a game.
However, right now that branch in the StackScript is not reflected in the final manifest file. So debugging of StackScript variations works from the StackScript, but it's not clear how to debug actual core SkotOS changes from the game.
One possibility: have the StackScript patch the manifest in the cloned game to point at the alternative SkotOS branch.
We should consider how to handle pages and whatnot that are sent/received with bodies involved in a possess chain.
This caused some...difficulties in ironclaw
Attempting to run this script from the command line gives me an error:
You must set a GAME_ROOT to run this setup script.
This script gets called from the start_server.sh script but would be nice to have the option to call it manually if needed.
I'm looking through a dump from the prod Gables server and the WOE directory from ChatTheatre/SkotOS and bringing the latter up-to-date where appropriate. Some notes, some of which are future work:
I'll keep editing this as I go along.
When there's any evokes in a language other than common, they trigger an action of language/encounter with some special parameters that get garbled later by merry.
I don't remember whree it is, but I found the reference in an odd place.
Running the Gables mac setup seems to happen successfully. However, manually running the show_dgd_logs.sh script shows an error and it's hard to know if dgd actually booted successfully.
$ ./show_dgd_logs.sh
tail: /log/dgd_server.out: No such file or directory
tail: /log/wafer_log.txt: No such file or directory
Wafer does not load and cannot be loaded manually.
$ wafer
Got exception in thread! Dying! Connection refused - connect(2) for "127.0.0.1" port 10070
When attempting to load dgd manually, the output reveals that several ports failed to open. Rebooting my computer does not help.
May 3 22:00:44 ** info:DEV_USERD: accepting connections on telnet devport 10098
May 3 22:00:44 ** critical:Panic: failed to open binary devport 10099
May 3 22:00:44 ** critical:Panic: failed to open Broadcast TCP port 10017
May 3 22:00:44 ** critical:Panic: failed to open AUTHD TCP port 10070
May 3 22:00:44 ** critical:Panic: failed to open CTLD TCP port 10071
May 3 22:00:44 ** critical:Panic: failed to open HTTP port: 10080
May 3 22:00:44 ** critical:Panic: failed to open HTTP port: 10089
May 3 22:00:44 ** critical:Panic: failed to open Woe port 10090
May 3 22:00:44 ** info:WOED: opened port 10090 successfully.
May 3 22:00:44 ** info:TextIF: accepting connections on game port 10443
Not sure if this is an issue on my end but I did not have the same port trouble when loading dgd from the SkotOS repo.
Rather than seeing a page with an error log, I get a "Page not found" message when Merry code fails to compile. It makes it difficult to track down where in the Merry script I messed up.
I have also noticed I no longer get an error output when Merry code crashes. It still gets logged in the +kpe tracker but it when code fails to work, it isn't immediately apparent why.
Christopher Allen said:
Eventually you should format any non-internal DGD docs as .md
Hello all!
Hoping to get some assistance with an issue I'm running into trying to use the +emitter command. From everything that I can see, it's written exactly the same way in two other games where it functions correctly. Although, that may be part of the issue. Below is the full error string I'm getting upon use:
+emitter
Value is not a string
/kernel/obj/binary#7064 'ondite'
90 /kernel/obj/binary receive_message
203 /kernel/lib/connection receive_message
/usr/TextIF/obj/user#7063 'ondite'
443 /usr/TextIF/obj/user receive_message
825 - receive_line
762 /kernel/lib/auto call_limited
920 /usr/TextIF/obj/user parse_command
/usr/TextIF/main
355 - command
/usr/TextIF/cmd/social
810 - cmd_DEV_raw_social
100 /usr/SkotOS/lib/merryapi run_merry
/usr/SkotOS/data/merry#-1
319 /usr/SkotOS/data/merry evaluate
/usr/SkotOS/merry/03f75e0ad4c5edf1a518772c412b2e43 M<Neoct:Staff:Tools:+emitter/global:command>
69 /usr/SkotOS/lib/merrynode evaluate
18 /usr/SkotOS/merry/03f75e0ad4c5edf1a518772c412b2e43 merry
489 /usr/SkotOS/lib/merrynode LabelCall
475 - Call
100 /usr/SkotOS/lib/merryapi run_merry
/usr/SkotOS/data/merry#-1
319 /usr/SkotOS/data/merry evaluate
/usr/SkotOS/merry/f7cb14cb8860ad86ca4bfe85867c12a9 M<Lib:chatlib/lib:log>
69 /usr/SkotOS/lib/merrynode evaluate
9 /usr/SkotOS/merry/f7cb14cb8860ad86ca4bfe85867c12a9 merry
475 /usr/SkotOS/lib/merrynode Call
100 /usr/SkotOS/lib/merryapi run_merry
/usr/SkotOS/data/merry#-1
319 /usr/SkotOS/data/merry evaluate
/usr/SkotOS/merry/4ea5e5a07a4a245439229467b2822b1f M<Lib:chatlib/lib:chat>
69 /usr/SkotOS/lib/merrynode evaluate
206 /usr/SkotOS/merry/4ea5e5a07a4a245439229467b2822b1f merry
475 /usr/SkotOS/lib/merrynode Call
100 /usr/SkotOS/lib/merryapi run_merry
/usr/SkotOS/data/merry#-1
319 /usr/SkotOS/data/merry evaluate
/usr/SkotOS/merry/04f2f91c47f68e997bee66cae1eba7e4 M<Lib:filter:lfc/lib:input>
69 /usr/SkotOS/lib/merrynode evaluate
171 /usr/SkotOS/merry/04f2f91c47f68e997bee66cae1eba7e4 merry
>
Any help would be greatly appreciated!
I would like to lobby for the preservation of storynuggets as a character generation interface, I think it was used on marrach if I'm not mistaken unless I misread something, and if they still work I don't think they should be removed.
Though by contrast I agree bilbo needs to go.
Right now, a bunch of folders are still marked as slaved to Castle Marrach. However, they can't see that server and they shouldn't ever be allowed to. So that warning is pretty silly for our end-users.
We should remove sync from all folders so that people don't see the warning that their local changes will go away.
CC: @saraht45
Right now, to keep the web config simple, I have DGD serving its own HTML web client, its own JS and CSS files, etc. This isn't particularly efficient -- especially because DGD will contact AuthD for every file. It could be fixed with a better NGinX configuration that checked (on a port other than 10080) for static files, served them if present, and fell back to DGD on port 10080 as a back end.
This would also solve the logout problem we currently have with cookies -- by keeping everything on a single port handled by NGinX for static files and DGD for dynamic files, we can keep the cookies unified. Right now that's not happening.
self explanatory but I noticed that they were left out of the document.
Hey noah I noticed you're gutting a lot of things.
Could you please preserve the ability for multiple instances of skotoslib to communicate on a shared backbone? For things like cross-game chatlines, centralized user accounts, and cross game assists?
I rather liked how Skotos was able to host multiple games with a shared backend and I'd like to preserve the ability to duplicate this functionality going forward.
In the rush to get to cold boot, some useful but non essential code was culled.
This includes but is not limited to the CSD module
Turns out an ancient tape-drive archiving program (called AMANDA) uses port 10080, so Chrome thinks connecting to it as a websocket is dodgy. D'oh! We'll need to change our local config on SkotOS, but also Wafer (and maybe gables_game/vRWOT?) to not expect Chrome to connect to port 10080.
Some state was missing in the old SID that didn't get dumped, which would make it harder to both preserve enough information for a cold boot as well as hampering runtime manipulation through the WOE interface.
Example: Whether doors are closed in addition to being locked.
May 4 17:15:55 ** error:String too long [caught]
error: /usr/System/sys/tool/vault
error: 732 - work
error: 202 - spawn_object_from_state
error:1115 /kernel/lib/auto read_file
May 4 17:15:55 ** Error spawning Bodies:UrMainbody
May 4 17:15:56 ** error:String too long [caught]
error: /usr/System/sys/tool/vault
error: 732 - work
error: 202 - spawn_object_from_state
error:1115 /kernel/lib/auto read_file
May 4 17:15:56 ** Error spawning Data:DB:mhelp
May 4 17:15:56 ** error:String too long [caught]
error: /usr/System/sys/tool/vault
error: 732 - work
error: 202 - spawn_object_from_state
error:1115 /kernel/lib/auto read_file
I'm almost certain this is due to failure to use a sufficiently large maximum string size in the DGD binary.
Suggested solution is a subroutine invoked by INITD->create() that will abort the startup process if certain configuration or status() values fail a sanity check.
I suggest checking max array size and max string size for starters.
I can come up with a patch for this myself if needed but atm the priority is to report the issue. I have higher priorities to deal with irl atm so for now a report will have to suffice until I can get more free time unless someone else wants to take care of this first.
Something possibly on port X090..the ability to upload and download files with the server as a developer?
I found a java class file to handle this as an applet but no java source was found.
When executing the command, everything works fine but I get this message:
I assume this is just because I don't have an application named "Apple_terminal" and may not be an issue but I thought it worth mentioning.
One difficult workflow for Jitsi: what if we have an expired JWT token on the browser side, and we wind up needing to reconnect? We need to test the "JWT token expires, browser needs to request a new one, then we successfully reconnect" workflow.
When cloning SkotOS_vault on a Mac, I get path collisions, mostly due to case-insensitive file system on the Mac.
We want everything to work on a Mac for root SkotoOS and SkotOS-Vault.
This might be a good project for @saraht45 โ start with SkotOS on a linux install, fix the easiest (which is to just move all of Regents including these collisions to it own repo for a future plugin), and delete them from root SkotOS and submit PR with deletions. Then look at SkotOS Vault and other vaults (gables, etc.) for similar easy to export to a plugin sets. Test by cloning to Mac.
Then work on the remainder of the collisions by group. For instance, why are there verbs in Neoct & neoct, etc.
A side project for @noahgibbs is to make a deeper level fix so that it isn't possible to name objects that might collide.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
'Data/DB/Spawn.xml'
'Data/DB/spawn.xml'
'Data/Initial/DB/Spawn.xml'
'Data/Initial/DB/spawn.xml'
'Data/Misc/Shared/DB.xml'
'Data/misc/Shared/DB.xml'
'Jonkichi/Data/aliases.xml'
'Jonkichi/data/aliases.xml'
'Jonkichi/Neoct/ic/verb/%40alias.xml'
'Jonkichi/neoct/ic/verb/%40alias.xml'
'Jonkichi/Neoct/ooc/verb/%40chargen.xml'
'Jonkichi/neoct/ooc/verb/%40chargen.xml'
'Jonkichi/Neoct/ooc/verb/%40finger.xml'
'Jonkichi/neoct/ooc/verb/%40finger.xml'
'Jonkichi/Neoct/ooc/verb/%40goto.xml'
'Jonkichi/neoct/ooc/verb/%40goto.xml'
'Jonkichi/Neoct/ooc/verb/%40status.xml'
'Jonkichi/neoct/ooc/verb/%40status.xml'
'Jonkichi/Neoct/staff/verb/%2Baccadm.xml'
'Jonkichi/neoct/staff/verb/%2Baccadm.xml'
'Jonkichi/Neoct/staff/verb/%2Baccfinger.xml'
'Jonkichi/neoct/staff/verb/%2Baccfinger.xml'
'Jonkichi/Neoct/staff/verb/%2Bfinger.xml'
'Jonkichi/neoct/staff/verb/%2Bfinger.xml'
'Jonkichi/Neoct/verb/%2Brename.xml'
'Jonkichi/neoct/verb/%2Brename.xml'
'Shared/Unsorted/S7/HN/bandana.xml'
'Shared/Unsorted/s7/HN/bandana.xml'
'Shared/Unsorted/S7/HN/belt.xml'
'Shared/Unsorted/s7/HN/belt.xml'
'Shared/Unsorted/S7/HN/boot-cowboy.xml'
'Shared/Unsorted/s7/HN/boot-cowboy.xml'
'Shared/Unsorted/S7/HN/chemise.xml'
'Shared/Unsorted/s7/HN/chemise.xml'
'Shared/Unsorted/S7/HN/corset.xml'
'Shared/Unsorted/s7/HN/corset.xml'
'Shared/Unsorted/S7/HN/drawers-gents.xml'
'Shared/Unsorted/s7/HN/drawers-gents.xml'
'Shared/Unsorted/S7/HN/drawers-ladies.xml'
'Shared/Unsorted/s7/HN/drawers-ladies.xml'
'Shared/Unsorted/S7/HN/duster.xml'
'Shared/Unsorted/s7/HN/duster.xml'
'Shared/Unsorted/S7/HN/garter.xml'
'Shared/Unsorted/s7/HN/garter.xml'
'Shared/Unsorted/S7/HN/hat-stetson.xml'
'Shared/Unsorted/s7/HN/hat-stetson.xml'
'Shared/Unsorted/S7/HN/petticoat-ruffled.xml'
'Shared/Unsorted/s7/HN/petticoat-ruffled.xml'
'Shared/Unsorted/S7/HN/petticoat.xml'
'Shared/Unsorted/s7/HN/petticoat.xml'
'Shared/Unsorted/S7/HN/shirt-mens-longsleeved.xml'
'Shared/Unsorted/s7/HN/shirt-mens-longsleeved.xml'
'Shared/Unsorted/S7/HN/stockings.xml'
'Shared/Unsorted/s7/HN/stockings.xml'
'Shared/Unsorted/S7/HN/suspenders.xml'
'Shared/Unsorted/s7/HN/suspenders.xml'
'Shared/Unsorted/S7/HN/trousers-denim.xml'
'Shared/Unsorted/s7/HN/trousers-denim.xml'
'Shared/Unsorted/S7/HN/trousers-woolen.xml'
'Shared/Unsorted/s7/HN/trousers-woolen.xml'
'Shared/Unsorted/S7/HN/vest.xml'
'Shared/Unsorted/s7/HN/vest.xml'
'Shared/Unsorted/S7/Regents/apron-long.xml'
'Shared/Unsorted/s7/Regents/apron-long.xml'
'Shared/Unsorted/S7/Regents/apron-short.xml'
'Shared/Unsorted/s7/Regents/apron-short.xml'
'Shared/Unsorted/S7/Regents/bandana.xml'
'Shared/Unsorted/s7/Regents/bandana.xml'
'Shared/Unsorted/S7/Regents/belt.xml'
'Shared/Unsorted/s7/Regents/belt.xml'
'Shared/Unsorted/S7/Regents/blouse-longsleeved.xml'
'Shared/Unsorted/s7/Regents/blouse-longsleeved.xml'
'Shared/Unsorted/S7/Regents/blouse-shortsleeved.xml'
'Shared/Unsorted/s7/Regents/blouse-shortsleeved.xml'
'Shared/Unsorted/S7/Regents/blouse-sleeveless.xml'
'Shared/Unsorted/s7/Regents/blouse-sleeveless.xml'
'Shared/Unsorted/S7/Regents/boot-cowboy.xml'
'Shared/Unsorted/s7/Regents/boot-cowboy.xml'
'Shared/Unsorted/S7/Regents/boots-ankle.xml'
'Shared/Unsorted/s7/Regents/boots-ankle.xml'
'Shared/Unsorted/S7/Regents/boots-knee.xml'
'Shared/Unsorted/s7/Regents/boots-knee.xml'
'Shared/Unsorted/S7/Regents/boots-riding.xml'
'Shared/Unsorted/s7/Regents/boots-riding.xml'
'Shared/Unsorted/S7/Regents/breeches.xml'
'Shared/Unsorted/s7/Regents/breeches.xml'
'Shared/Unsorted/S7/Regents/busk.xml'
'Shared/Unsorted/s7/Regents/busk.xml'
'Shared/Unsorted/S7/Regents/cape.xml'
'Shared/Unsorted/s7/Regents/cape.xml'
'Shared/Unsorted/S7/Regents/chemise.xml'
'Shared/Unsorted/s7/Regents/chemise.xml'
'Shared/Unsorted/S7/Regents/chemisette.xml'
'Shared/Unsorted/s7/Regents/chemisette.xml'
'Shared/Unsorted/S7/Regents/coat-double-breasted.xml'
'Shared/Unsorted/s7/Regents/coat-double-breasted.xml'
'Shared/Unsorted/S7/Regents/corset.xml'
'Shared/Unsorted/s7/Regents/corset.xml'
'Shared/Unsorted/S7/Regents/cravat.xml'
'Shared/Unsorted/s7/Regents/cravat.xml'
'Shared/Unsorted/S7/Regents/day-dress-shortsleeved.xml'
'Shared/Unsorted/s7/Regents/day-dress-shortsleeved.xml'
'Shared/Unsorted/S7/Regents/day-dress-sleeveless.xml'
'Shared/Unsorted/s7/Regents/day-dress-sleeveless.xml'
'Shared/Unsorted/S7/Regents/day-gown-shortsleeved.xml'
'Shared/Unsorted/s7/Regents/day-gown-shortsleeved.xml'
'Shared/Unsorted/S7/Regents/day-gown-sleeveless.xml'
'Shared/Unsorted/s7/Regents/day-gown-sleeveless.xml'
'Shared/Unsorted/S7/Regents/drawers-long.xml'
'Shared/Unsorted/s7/Regents/drawers-long.xml'
'Shared/Unsorted/S7/Regents/dress-mourning.xml'
'Shared/Unsorted/s7/Regents/dress-mourning.xml'
'Shared/Unsorted/S7/Regents/evening-dress-shortsleeved.xml'
'Shared/Unsorted/s7/Regents/evening-dress-shortsleeved.xml'
'Shared/Unsorted/S7/Regents/evening-dress-sleeveless.xml'
'Shared/Unsorted/s7/Regents/evening-dress-sleeveless.xml'
'Shared/Unsorted/S7/Regents/evening-gown-shortsleeved.xml'
'Shared/Unsorted/s7/Regents/evening-gown-shortsleeved.xml'
'Shared/Unsorted/S7/Regents/evening-gown-sleeveless.xml'
'Shared/Unsorted/s7/Regents/evening-gown-sleeveless.xml'
'Shared/Unsorted/S7/Regents/garter-pair.xml'
'Shared/Unsorted/s7/Regents/garter-pair.xml'
'Shared/Unsorted/S7/Regents/gloves-long.xml'
'Shared/Unsorted/s7/Regents/gloves-long.xml'
'Shared/Unsorted/S7/Regents/gloves.xml'
'Shared/Unsorted/s7/Regents/gloves.xml'
'Shared/Unsorted/S7/Regents/gown-night.xml'
'Shared/Unsorted/s7/Regents/gown-night.xml'
'Shared/Unsorted/S7/Regents/hat-bonnet.xml'
'Shared/Unsorted/s7/Regents/hat-bonnet.xml'
'Shared/Unsorted/S7/Regents/hat-top.xml'
'Shared/Unsorted/s7/Regents/hat-top.xml'
'Shared/Unsorted/S7/Regents/jacket-spencer.xml'
'Shared/Unsorted/s7/Regents/jacket-spencer.xml'
'Shared/Unsorted/S7/Regents/jodhpurs.xml'
'Shared/Unsorted/s7/Regents/jodhpurs.xml'
'Shared/Unsorted/S7/Regents/muff.xml'
'Shared/Unsorted/s7/Regents/muff.xml'
'Shared/Unsorted/S7/Regents/nightshirt.xml'
'Shared/Unsorted/s7/Regents/nightshirt.xml'
'Shared/Unsorted/S7/Regents/pantaloons.xml'
'Shared/Unsorted/s7/Regents/pantaloons.xml'
'Shared/Unsorted/S7/Regents/pelisse.xml'
'Shared/Unsorted/s7/Regents/pelisse.xml'
'Shared/Unsorted/S7/Regents/petticoat.xml'
'Shared/Unsorted/s7/Regents/petticoat.xml'
'Shared/Unsorted/S7/Regents/purse.xml'
'Shared/Unsorted/s7/Regents/purse.xml'
'Shared/Unsorted/S7/Regents/robe-dressing.xml'
'Shared/Unsorted/s7/Regents/robe-dressing.xml'
'Shared/Unsorted/S7/Regents/robe.xml'
'Shared/Unsorted/s7/Regents/robe.xml'
'Shared/Unsorted/S7/Regents/sash-waist.xml'
'Shared/Unsorted/s7/Regents/sash-waist.xml'
'Shared/Unsorted/S7/Regents/shawl.xml'
'Shared/Unsorted/s7/Regents/shawl.xml'
'Shared/Unsorted/S7/Regents/shirt-dress.xml'
'Shared/Unsorted/s7/Regents/shirt-dress.xml'
'Shared/Unsorted/S7/Regents/shirt-longsleeved.xml'
'Shared/Unsorted/s7/Regents/shirt-longsleeved.xml'
'Shared/Unsorted/S7/Regents/shoes-buckled.xml'
'Shared/Unsorted/s7/Regents/shoes-buckled.xml'
'Shared/Unsorted/S7/Regents/shoes.xml'
'Shared/Unsorted/s7/Regents/shoes.xml'
'Shared/Unsorted/S7/Regents/slippers-carpet.xml'
'Shared/Unsorted/s7/Regents/slippers-carpet.xml'
'Shared/Unsorted/S7/Regents/stockings-men.xml'
'Shared/Unsorted/s7/Regents/stockings-men.xml'
'Shared/Unsorted/S7/Regents/stockings-women.xml'
'Shared/Unsorted/s7/Regents/stockings-women.xml'
'Shared/Unsorted/S7/Regents/trousers.xml'
'Shared/Unsorted/s7/Regents/trousers.xml'
'Shared/Unsorted/S7/Regents/waistcoat.xml'
'Shared/Unsorted/s7/Regents/waistcoat.xml'
Some filenames are indistinguishable without distinguishing between uppercase and lowercase (e.g. s7 vs S7 in the vault data.) Git does a weird mapping here, and I think there may have been problems before that too. Basically, some of the filename case seems borked.
This is causing problems with WOE objects in some cases because WOE tracks WOEnames directly from filenames. So Data/DB/Spawn.xml became Data/DB/spawn.xml and couldn't be found. I suspect the hunting birds (e.g. the saker-terciel) problem came from the same thing with the S7 WOE subtree in the vault.
At some point I need to clone the repo on Linux, get the list of files that Mac Git complains about, and sort out all the case in the filenames.
Prior to cold-boot SkotOS, the game's DGD server was nearly always fully booted. It just wasn't much of an issue. In this new world, we cold-boot much more often and so we care more often. That's why deploy_scripts/shared/wait_for_full_boot.sh exists - so we can wait for SkotOS to finish loading all that MERRY code, open its ports, etc.
It would be really useful if wafer and thin-auth could indicate whether SkotOS appears to have booted fully. Because if you click through before that, errors are expected. When spinning up a new local install, we just don't boot wafer until DGD has finished booting -- but a bookmark will still get you to the not-yet-ready server. Some kind of visual indicator (warning text?) would be nice, and possibly a "reload" button to check right now instead of waiting for the next 30 second timer.
There's a URL for that, the same one used by wait_for_full_boot.sh. On the SkotOS raw HTTP port (localhost:10080 or the client URL's port 10080), the url "/FullyBooted" will only return 200 if it's fully booted. A 404 normally means "still booting" and a 5XX (error) response normally means "something went wrong and it's not going to boot up." It's possible to get an error where it will just 404 forever, but that's not normally what happens.
For wafer, the right answer is probably to colour or disable the "Play" and "Tree of WOE" buttons and add a setInterval to keep pinging the server (maybe every 30 seconds or so?) and enable them when the server is fully booted. After the server is up we can get rid of the setInterval and not keep doing it.
It would also be possible to check every you hit "Play" and give you a dialogue if it's not fully booted - not sure if that's a good idea. The up-side is that if you keep a stale Wafer browser tab open it will still tell you if your current boot isn't finished. The down-side is that sometimes you get a browser alert when you may not want one.
This should nip a large part of the "case insensitive name collision" issue that showed up on the mac.
Stopping those names from being created in the first place will nip the situation in the bud.
Caveats:
Patching idd.c should NOT cause errors with any noncompliant data already loaded, only prevent new folders or object names from being created that would clash with ones that already exist.
There are probably some other caveats that I haven't thought of yet.
Right now, it's hard to combine Jitsi (video/audio chat) with a local server. It should be pretty straightforward for the SkotOS server to send the Jitsi URL in a message... but for a fully-local setup, you still need a Jitsi server of some description, and they're painful to set up locally.
Anyway, should be possible to work this out. We need a slightly unusual setup (JWT, token_moderation plugin) so the public meet.jit.si server won't work. But it should be possible to change a config file (or something) to set the Jitsi URL, and right now it's not.
As we move toward support for a broader range of gender identities, we need a more generalized Chatter Ur.
There is a new version of the Orchil client which has fixes to one important bug, and some minor features.
@shentino can you talk with the leads about scheduling this update?
Tree of Woe fails to load when objects are saved to the root directory. Special characters can also be a problem. We should figure out some solution to either disallow special characters/saves to root or update Tree of Woe to handle it better.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.