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.
My old setup of throwing *all* of the IPC types and opcodes into *one* enum was
becoming unbearable. Now that we have multiple things using the same opcodes
(because they can overlap) I think it's time to repay this technical debt.
This overhauls the structure of the project to move IPC structs into their own
modules, and separate the opcode data/lists into separate ones depending on if
it's clientbound and serverbound.
Nothing has changed functionall, but this is going to make it way easier to add
more IPC in the future.
This doesn't really fix anything functionally, but makes the Character window
look nicer. The same (currently unchangable) data is now reflected in the lobby.
I have unsuccessfully tried to spawn another actor, the game recieves it (and
adds it to the object table) but they are marked invisible. Besises, this also
contains various field improvements and initial support for social lists.
The current situation of throw-every-piece-of-logic-into-one-file for each
server isn't working out. So now there is a new ZoneConnection/LobbyConnection
struct that will be delegating tasks to their own Handlers (for example, there
could be a ChatHandler.)
I'm not sure how well this architecture will scale, but it's better than what
we have right now.
