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.
The PlayerStatus struct shifted around recently, so I fixed the offsets
yet again. Unlocks should be persistent now, but this as usual requires
a database wipe, sorry!
I also included some refactors of the !unlock debug command that still
had references to the old unlock_action API.
-Global.lua is no longer a catch-all dumping ground for registering actions and events
Instead, Global.lua will actually contain useful global constants and functions
-Init.lua will take over the role of being the initial script run when doing reloads or booting the servers
-Actions.lua will take over registering all actions
-Items.lua will take over registering all items
-Commands.lua will take over registering all text commands
-Events.lua will take over registering all warps, openings/quests, aetherytes, etc.
To this end, event ids now live in organized tables to reduce error-prone copy paste clutter
If we get enough actions, items or commands, we can move those to tables too.
Now that we have a ton of events registered, this just becomes
log spam. I initially added it while testing the Lua API, but
I don't think it's necessary anymore.
* 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!
-Create common methods create_segment_self and create_segment_target.
These reduce the amount of copy-paste boilerplate code since the IPC queueing stuff basically never changes
as far as I can tell. Now we simply specify the opcode and the data that goes with it, and off we go.
Create_segment_self retains the current behaviour of using the player's actor id as both the source and target,
and create_segment_target allows us to change the source and target in case commands are written that require
one or the other to be different (Sending targeted players to other coords/zones? Bringing a player to the GM/source user? Several possibilities.).
It's a command that moves the user forward, backward, up, or down a specified amount of yalms.
It's quite helpful for exploration convenience, and doesn't replace setpos, rather, it's meant to complement it.
The set_position function was also extended to allow for lua code to specify the rotation/direction facing.
This makes the Teleport action functional now, although it looks pretty
rough as it warps you instantly instead of waiting for the action to
actually finish.
This is super simple, you get the player and the args (which you can
choose to split if you so choose.) I reimplemented the !setpos, and will
start doing the rest of the commands.
The inn bed is the most complex script we have written so far, and needs
a little bit more logic to when it finishes. I also made it play the bed
animation, although you *will* sleep forever as we don't know how to
disconnect you yet.
This kinda works, you can now talk to them without locking up your
character but you aren't warped yet. I also need to clean up the mess of
the Lua API.
Everyone's favorite copying mechanism/purchasable item is now functional
in Kawari. The item doesn't disappear once you use it, because there's
no API for that yet.
It turns out (amazingly) that this data exists client-side, I guess because the
server and the client share the same planevent LGB file. So instead of
hardcoding the starting location in each city, it's now literally like retail*
* Except for the fact that we don't support rotation yet, and positions in pop
ranges are probably randomized too. But it's close!
