XaiJu
clickteam_phi
clickteam_phi

patreon


Lacewing Blue Unicode progress

Hey folks,
Just dropping a quick progress update about the Lacewing Unicode. Here's the plan:

1) Merge fixes from Unicode into ANSI (non-Unicode) version
2) Publish a new version of ANSI-only Lacewing as build 83(?)
3) Merge Unicode into Git repo
4) Publish a new version of ANSI & Unicode Lacewing as build 84(?) , on server b14(?)

I'm currently stuck in the secret step 1.5, where I fix Lacewing's bugs. Although, there's only two long-standing bugs.

Thanks to a tip from LekKit, I've fixed the UDP connection bug, which has been around in liblacewing code from the start.
The bug wasn't really a fault in my code per se but more the normal issue of UDP being connectionless, and devices along the route deciding after a period of inactivity that the faux connection is over and should be closed.
So, adding a regular ping on UDP (when it's inactive for a while), on server-side, soon fixed that up. I get no more connection issues, the server doesn't stop accepting new clients at a random interval.
To be honest, I'm still not sure why that bug would appear the way it did - I could understand it blocking off existing clients that went inactive for a while, but the bug blocked off new clients too.

At any rate, with that bug fixed, there's only one outstanding bug which is a long-timer. I'm fairly certain it's stuck around since liblacewing times too.

The bug occurs under rare conditions, so rare I had extreme difficulty isolating it; where multiple TCP writes are in progress during a disconnect. Notably, it happens when a bunch of clients disconnect at once, along with ping timeouts throwing some out.

The data used for the in-progress message is freed too early, causing the after-message function attempts to run an invalid address as a function and falls over.
Lacewing uses IO completion ports on Windows, where the event/message queue is managed by the OS and left asynchronous. It's not possible to change the data that's being held midway, as Windows is opaque in the stages between queuing an event and its completion.

It's potentially doable to free later (lazily, if you like) by keeping a reference count, but since Windows may or may not finish an event aborted midway...

It's been effectively worked around by a no-op catch:

...which amounts to ignoring the invalid memory access after the fact, which is far from ideal. That code is here, if you're curious.

If I can eliminate that hack, I'll have a fully working Lacewing set with no known hacks or issues. Frankly, I'd rather have that before I upgrade it to Unicode, but I'm not gonna burn much more time on it.

The Unicode upgrade itself should take around a couple of weeks.

Stay safe and thanks for your continued sponsorship!

~Phi


More Creators