
Originally Posted by
Sechs
Acorn, I was wondering what's the status on Windower5? Still going to happen sometimes in the future or did you guys decide to keep furtherly developing Windower4?
It's being actively developed, but slowly. Iryoku is currently working on it alone, I still have a huge list of issues for Windower 4 and related projects that I need to work on (Resource extraction, FFXIDB, addon API/libs, etc.), so I don't get to help out there much for now, but it is coming along pretty nicely. The Lua C++ framework Iryoku is working on is probably one of the best in existence at this point (wouldn't surprise me if it was the best since Lua people generally don't seem to know what they're doing). We also had CeGUI working at some point, but decided to go the GWEN route instead, which will take more time but should yield better results, since CeGUI was a pain to work with and progress was slow.
It already surpasses Windower 4 in many respects:
- Speed: Windower 4 uses some decade old and awful code, and despite their enthusiasm there were some less than qualified programmers working on it in the past, resulting in just stupid and redundant code that did a lot more than it should. Also, we use LuaJIT instead of stock Lua 5.1 for addons, which is magnitudes faster.
- Stability: The Lua API should ideally never crash or get into an unrecoverable state. Implementing this alone took weeks, but poor Iryoku is apparently bored enough to not have anything better to do. Lucky for the entire FFXI community!
- Error handling: If it does ever crash, error reporting will be amazingly detailed, even inside Lua. No more digging around in disassembly for weeks collecting dozens of crash dumps and handing out several versions of debug builds to figure out what went wrong. Just think of what we went through with Timers…
- C++ API: While we're not sure whether we'll make the C++ API open (the option is still being discussed) it will be much better designed than the mess that is the Windower 4 plugin API. Also, the Lua C++ wrapper is, like I said, nothing short of amazing. That means developing in C++ will be a lot easier, faster and safer than it is in Windower 4.
- Proper GUI: Instead of abusing text primitives like aligning them in a certain way and formatting them individually you'll be able to make proper GUIs using pre-defined elements (like buttons, check/radio boxes, etc.). It might be possible to provide custom skins for those as well, but I'm not sure about that yet.
- Memory: Currently all addons have to copy the resources when they use them, which can bloat their size up significantly (including the item resources alone costs over 20MB per addon). This will be shared across all addons, as such only one copy of the resources needs to be loaded. This can reduce the POL process size by hundreds of MB.
What's still missing though is the entire Lua API. Once that is added, it will be pretty much release-ready. Although we will probably be working on a translation layer between the Windower 4 Lua API and the new Windower 5 Lua API (since the v5 API will be entirely different). That will make all (or at least most) Windower 4 addons run on Windower 5 as well, despite a drastically different API.
For non-programmers, an API is essentially the set of variables and functions we allow Lua scripts to use. Both the amount, names and design of those will be entirely different than what they are on Windower 4. Here is a small Lua code example from Windower 4:
Code:
windower.register_event('incoming chunk', some_function)
This executes some_function every time a packet comes in. On Windower 5 it might look something like this (like I said, it's not finalized yet):
Code:
events.incoming_chunk:add(some_function)
While previously all Windower-related code was inside the "windower" table (as in the above example with register_event), we will structure it differently now. Hence v4 addons won't natively work on v5, but with a translation layer it should be possible by including this at the top of each addon:
Code:
windower = require('v4')
This is just a quick overview, once we start working on the addon API we can give more details, and like I said, at that point it will be essentially finished, or at least ready to be tested (there are still some things like the updating mechanism and startup options that we need to implement, but they should be somewhat fast in comparison). I'll let you know when the time comes.