* Implement the following actors/entities:
-Inn Toy Chest actor, which simply says you haven't unlocked mini-games
-Inn Glamour Dresser actor, which simply says you haven't unlocked the GD yet
-Orchestrion, which is fully functional as long as you have songs unlocked
Accompanying the orchestrion is the GM orchestrion command, with a caveat:
-It allows you to learn one song at a time, but id 0 (aka "all) doesn't learn a single
song for some unknown reason, so I've disabled it for now.
* Run cargo fmt
* Update USAGE.md
How many times will I forget...
* Reimplement !unlockaction in Lua
Rebased on upstream master
* Unlockaction: display the action id that was unlocked
* Reimplement GM speed in Lua
* Fix warnings and errors
* Run cargo fmt
* Reimplement GM wireframe in Lua
* Reimplement GM invis command, with a caveat
It can't toggle the invis state yet, and I'm not sure where to update it.
* Lua invis: add the gm_invisible toggle, but it still doesn't revert back to false...
* Reimplement GM aetheryte in Lua, with a caveat
It's seemingly not working right now though: it doesn't add any new aetherytes to the teleport menu.
But I can't get the command `//gm aetheryte on X` to do it either, so it's possible Kawari isn't responding correctly?
Either way this needs further testing.
* Lua invis: add the forgotten Lua file
* Reimplement GM teri in Lua
Also add a TODO for UnlockAetheryte
* Make comment in lua.rs more useful
* Run cargo fmt again
* Teri: range check the territory ID
* Update USAGE.md to reflect the new commands
Rebased on upstream master
* Clarify unlockaetheryte USAGE and in-script usage
* Refactor UnlockAetheryte.lua, and make ToggleInvisibility actually work properly.
I opted to create a Task for this, because sticking it in kawari-world.rs felt like a hack to me.
* Run cargo fmt for hopefully the last time today
* Move lua.ra:toggle_invisibility down with the other queued tasks
* Fix spaces in USAGE.md, remove stray rebase message
Scripts are normally loaded when they are needed, with the exception of
Global.lua that's only loaded once at start-up. But now you can reload
it in-game with the !reload command, which should make event and command
scripting way less of a hassle.
This command enables the user to set the current zone's festival.
For example, you can toggle the Starlight festival in any of the starting cities.
Thanks, OTCompa!
This was initially removed because the localhost TLD Caddy magic, but I
just discovered that this isn't honored by WinHTTP which breaks the
retail patcher. So users will still - unfortunately - have to do this.
We have had an import feature for a while, allowing you to easily
recreate your retail character from Auracite backups. But the feature
was implemented *before* we had proper service accounts, and it always
assigned it to ID 1.
Now it's moved to the user-visible account management page.
Curiously the spawned clone shows up as a player, despite not using the
NPCSpawn packet. This might be a suitable workaround for the
PlayerSpawn packet being buggy from our side.
This makes it possible to use Kawari easily without compilation. You
still need to acquire Oodle yourself since we build with the shared
library version of Oodle.
The USAGE instructions is modified accordingly.
I don't have Astra locally so I had to do this to test things. It works
fine right now, but in the future the user must complete the login
process manually.
I ran into the issue with privileged ports myself. The link to the Caddy
website has an aside about how to use setcap or sudo, which should be
good enough.
While you can just drop the Oodle static library into /usr, I'm not a
big fan of doing it, especially when the binary didn't come from my
machine or package manager. You can set a RUSTFLAGS environment variable
or cargo config file to specify a link path, but having the build script
search there for you is easier.
The docs now specify which variant of Oodle is required, since there are
multiple. It also specifically mentions the static library, because I
had some weird issues leaving the dynamic library in that folder, where
the executables wouldn't start unless it could dynamically load the .so.
This allows you to register in the web frontend now, and the login server now
checks this before giving a session ID. Note that this is wildly insecure (it
stores the passwords in plaintext!) and is duly noted in the USAGE.
