Publish new post

content/blog/kawari10/index.md

@@ -1,64 +1,60 @@
 ---
 title: "Kawari Progress Report 10 - Polish"
 date: 2025-05-10
-draft: true
+draft: false
 tags:
 - FFXIV
 - Reverse Engineering
 series:
 - Kawari Progress Report
-summary: "This update is all about polish and making Kawari easier to setup/use. What's the point of an alternative server that's difficult to setup?"
+summary: "This update is all about polish and making Kawari easier to setup/use. What's the point of building a project that's difficult to setup?"
 ---
 
-This update is all about polish and making Kawari easier to setup/use. What's the point of an alternative server that's difficult to setup?
+This update is all about polish and making Kawari easier to setup/use. What's the point of building a project that's difficult to setup?
 
 # Better Artifacts
 
 I have redone the structure of the artifacts, which was mostly putting the binaries in the top-level directory. The original web template files are now included, so they can be freely changed without recompiling:
 
-[screenshot]
+![How the ZIP file is setup now.](artifacts.webp)
 
-Additionally, there are now run scripts (that work!) for Windows and Linux to start all of Kawari's services. I have _no_ clue how to write Batch scripts, so it ends up doing funny things like spawning a dozen console windows. If you're a Windows expert and know how to make that better, I would appreciate some help!
+Additionally, there are now run scripts (that work!) for Windows and Linux to start all of Kawari's services. I have _no_ clue how to write Batch scripts, so it ends up doing funny things like spawning a dozen console windows. If you're a Windows expert and know how to make that better, I would appreciate the help!
 
 ## Better Web
 
 I redone the web interface and slapped on Bootstrap styling since I'm too lazy to come up with my own CSS. It actually looks decently nice now:
 
-[screenshot]
+![The new account management webpage!](account.webp)
+![The new login page!](login.webp)
 
-[screenshot]
-
-Thanks to [sfss] for bug testing, and some minor issues with the Web/Launcher pages are now fixed.
+Thanks to [Sayaniku](https://github.com/Sayaniku) for reporting bugs for these pages, and those issues should be fixed like redirects not going to the right places.
 
 # Official Launcher
 
 Kawari can now be used with the official launcher, making it super easy to use. For Windows, this only consists of dragging files into a folder - and Linux isn't that much harder. The setup instructions are located on the internal website:
 
-[screenshot]
+![The (hopefully easy to follow) setup instructions](setup.webp)
 
-And here's how it looks like in the launcher:
+What you're downloading is an auto-generated config file, pointing to the server names (like `ffxiv.localhost`) defined in your Kawari config. That is then read by our `winmm.dll`, enabling us to bypass the default SqEx URLs - effectively taking over the launcher. And here's the end result:
 
-[screenshot]
+![The official launcher doing something it was never meant to :)](launcher.webp)
 
-Breaking apart SqEx's launcher honestly has been the most fun in RE I've had in a while...
+This is powered by [LauncherTweaks](https://github.com/redstrate/LauncherTweaks) and it enables anyone to write their own custom launcher pages too[^1]! Digging into the launcher has honestly been the most RE fun I've had in a while...
 
 # Scripting
 
-I have expanded the breadth of things you can script, and I have it working on a variety of things now - such as:
-* Inns
-* Warps (including ferries, lifts, and exit doors.)
-* Beds
-* Commands
-* Items
+I have expanded the breadth of things you can script, and I have it working making a variety of events work - such as:
 
-Additionally, events used to be hard-coded but can now be added dynamically through Lua:
+{{< tube "https://tube.ryne.moe/videos/embed/qhrk2kdf13p4qLXPggqupB" >}}
+
+Events used to be hard-coded but can now be added dynamically in the `Global.lua` script:
 
 ```lua
 registerEvent(721028, "tosort/UnendingJourney.lua")
 registerEvent(721044, "tosort/CrystalBell.lua")
 ```
 
-Note that the event IDs are declared when you register the function, so you can reuse the same script across multiple IDs:
+Event IDs are now declared when you register the function, so you can reuse the same script across multiple IDs:
 
 ```lua
 --- all of these are simple, so they can be handled by the same script!
@@ -67,13 +63,13 @@ registerEvent(131083, "common/GenericWarp.lua")
 registerEvent(131084, "common/GenericWarp.lua")
 ```
 
-The event ID is injected into the event script as `EVENT_ID`, so scripts can be more generic:
+The ID can now be accessed inside of event scripts as `EVENT_ID`:
 
 ```lua
 player:play_scene(target, EVENT_ID, 00000, 8192, 0)
 ```
 
-And of course a breadth of new, interesting player API to make these events functional:
+And of course a breadth of new player API for you to use:
 
 ```lua
 --- go to the pre-defined warp (and switch the zone if nessecary)
@@ -92,7 +88,7 @@ player:set_position({ x = 1, y = 2, z = 3 })
 player:set_remake_mode("EditAppearance")
 ```
 
-To register new commands, define a new Lua script:
+It's now possible to register new commands in Lua, I have already ported the `!setpos` command for example:
 
 ```lua
 function onCommand(args, player)
@@ -101,35 +97,33 @@ function onCommand(args, player)
 end
 ```
 
-And then register it in `Global.lua`:
+They are registered like how'd you expect:
 
 ```lua
 registerCommand("setpos", "commands/debug/SetPos.lua")
 ```
 
-I also want to give a reminder that the entire Lua interface is still a big WIP. At some point when it's more complete, I'll give it a complete redo. I didn't want to prematurely design an API that ended up being too limiting, so I'm bolting on new things instead.
-
 # Better Multiplayer
 
-As seen in a previous update, multiplayer "worked" but it was bad. It pretty much only shown the other player's position and their initial appearance. I have greatly improved it, including propagating model id changes, emotes, poses, targeting and more:
+As seen in a previous update, multiplayer "worked" but it was bad. It only displayed the other player's position and their initial appearance. I improved it a bunch since then including propagating your rotation, targets and poses to other players:
 
-I struggled with sending player rotations for a while because they changed the packet used to update actor positions in Endwalker(?) After fixing that, everything fell into place.
+{{< tube "https://tube.ryne.moe/videos/embed/ewr7CAABUjaRea46TQMR7Z" >}}
 
-s
+I struggled with sending player rotations for a while because they changed the packet used to update actor positions in Endwalker(?) After fixing that, everything fell into place. I also implemented _very basic_ zone isolation, so people won't phase-shift into your zone.
 
-What's curious is that this means rotations are actually _more_ accurate between clients, and I wondered if that's actually noticeable. So I tested it, "emulating" the old 255-value system and did a comparison:
-
-I also implemented _very basic_ zone isolation, so people won't phase-shift into your view despite being in a totally different place:
-
-s
+Part of the reason why this takes a while is because Kawari was built under the assumption that there's only a single connection, so there's a *lot* of code written before I added multiplayer. A lot of my time is spent untangling that mess, and of course that work can't really be showcased here because it's _super boring_.
 
 # Fantasia
 
-Everyone's favorite item/coping mechanism (yes, I really did use the same joke from the commit description) is now implemented, just for funsies. It doesn't remove the Fantasia from your inventory because we lack the Lua API for it:
+Everyone's favorite item/coping mechanism is now fully implemented, just for funsies. It doesn't remove the Fantasia from your inventory yet, because we lack the Lua API for it. Here it is in action:
+
+{{< tube "https://tube.ryne.moe/videos/embed/kUE72k1gTCxXPPxf1k9f9r" >}}
+
+Oh yeah, and the Armory Chest is now 100% functional too instead of crashing the World server.
 
 # Excel Data
 
-This is just a technical tidbit, hence why it's at the end here. Kawari has to read more and more Excel data, and the code usually looks like this:
+This is just a technical tidbit, hence why it's at the end here. Kawari needs to read lots of Excel data to function properly, and the code to do so usually looks like this:
 
 ```rust
 /// Returns the pop range object id that's associated with the warp id
@@ -157,7 +151,9 @@ pub fn get_warp(&mut self, warp_id: u32) -> (u32, u16) {
 }
 ```
 
-🤢 Yeah, that's bad! We are associating columns with their indexes, and these tend to change over time. We also don't have that great error handling here, so I spent some time cleaning this up. Now it looks like this:
+🤢 Yeah, that's bad! We are hardcoding column indices, and these also tend to change over time. There's also a whole lot of `let x = else` matching code, because column data is actually an enum. Our error handling here is also terrible with lots of `panic!`s, oh man!
+
+I have spent some time cleaning up this technical debt, so now our Excel code looks like this:
 
 ```rust
 /// Returns the pop range object id that's associated with the warp id
@@ -172,4 +168,6 @@ pub fn get_warp(&mut self, warp_id: u32) -> Option<(u32, u16)> {
 }
 ```
 
-Some of this was fixed by improving the signature of the function itself (with `Option`!) Another part of it is introducing a higher-level API for grabbing Excel data. I auto-generate a library called [Icarus](https://github.com/redstrate/Icarus) based on the great schema in [EXDSchema](https://github.com/xivdev/EXDSchema), with [EXDGen](https://github.com/redstrate/EXDGen). While it only supports a small portion of the schema, it's more than enough for Kawari. 
+Some of this was fixed by improving the signature of the function itself (with `Option`!) Another part of it is introducing a higher-level API for grabbing Excel data. I now have a library called [Icarus](https://github.com/redstrate/Icarus) based on the fantastic schema in [EXDSchema](https://github.com/xivdev/EXDSchema), generated with [EXDGen](https://github.com/redstrate/EXDGen). While it only supports a small portion of the schema, it's more than good enough for Kawari's purposes. Another improvement that helped was in [Physis](https://github.com/redstrate/Physis), where `ColumnData` now has `into_x()` helpers so you don't have to write `match` code yourself in the caller.
+
+[^1]: If you are interested, I have some incomplete documentation [here](https://wiki.xiv.zone/Launcher). You might also want to take a look at [Kawari's launcher page HTML](https://github.com/redstrate/Kawari/blob/master/resources/templates/launcher.html).