This means that the static .lib is no longer required at compile time, but
the .dll is still required at runtime. On Linux, the .so is still
required at both compile time and runtime, because linking works
differently there.
This removes a ton of implementation overlap between the two
command systems. For example, we had two different implementations
of unlocking aetherytes which is just unnecessary.
On the flipside, this makes implementing new GM commands just as
easy as writing debug ones. I moved the existing debug Lua
implementations into their GM counterparts and updated the USAGE
accordingly.
When learning how to unlock emotes, apparently FFXIV just has one
kind of ID for all kinds of stuff. So I picked a number, stuck it
as the max (this is unconfirmed) and you can now unlock everything.
The reload command was previously implemented in Lua, but this
is a little dangerous as it could itself have an error and is
unable to work in the first place. I moved this to Rust to
ensure it's always available. I left the reload_scripts() API
in Lua as someone could still find that useful!
Additionally, I added a !finishevent debug command to forcefully
end the current event you're in. This can be useful if your script
is incomplete or has an error, as your client gets stuck very
easily.
* 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.
