But, the udp system already works
"<app> needs version <x> of <dll>..." is different because DLL integration is "closer" to the LFS core,
if a DLL plainly stops working with LFS, you know what happens, if insim slightly changes, an older insim app might very well still work.
And still, if the insim protocol as it is now would change so that my apps would not work, i don't need to rely on someone else fixing something to make my thing work, i can just update it myself.
Look, what i'm basically saying is something like this
When you have an extension interface you can use to make your software do what you like, that people successfully use, it's fine.
When you want to go further, you need another interface.
Take mirc for example, i'd guess about 5% of extensions for mirc are DLL's, 95% are fine with what's offered by the standard interface.
The other 5% use a _different_ system to get their functionality into mirc using dll's, the systems are separated, but can ofcourse interact.
The 95% do not need the complexity of the DLL system, they do not need the extra performance, or they cannot be
bothered with such development, the stuff will work fine anyway.
The interface that the 95% of users use is made by the developer of mirc, not someone making a plugin that offers this, the
other 5% get access to whatever they want, with all the complexity in the world.
The 95% of users can develop without ever caring about the other method(s), the software from these users will work without anything else.
If you as a user want to extend <software> and you can't be satisfied with what <software> offers, the way you solve this problem
should not interfere with how other users extend <software>
Insim/udp is the standard interface, if this interface is unable to provide functionality for, say, modding lfs in a ghostcar sort of way,
this problem should be solved without altering the standard interface that already works.
The more complex you make the insim system, the less insim apps will be made, simple as that.
Even if it's as simple as "go download this dll and you can do this", this is added complexity that isn't needed.
A dll extension system would be great, but keep the simple universal insim system
that already works perfectly, don't emulate it, there's no need for extra layers, it does already work.
About the welcome message, i just wrote a small php script to test that, 14 lines of code, 3 lines for handling the udp connection. it even handles the keepalive.
This discussion is getting rather pointless, i mean, you're talking about bloated code, to me nothing could be more bloating then
converting insim to a dll based system, because there's absolutely nothing in such a thing i'd ever need, nor would any of the regular insim apps i've encountered so far.
To me that means coding something to make something that already works, work again.
I would never need the performance of getting/parsing full telemetry data at 100hz, this is very unreasonable traffic for a server.
My opinion is that insim does precisely what it's designed to do, and does it very well, if you need a better link then that, then
something else should offer that, just like any other software i can think of that offers extension thru a main interface and a dll method.
Maybe i'm all wrong, but to me insim seems to be designed for server functionality, maybe that's why you who make very different stuff seem unhappy with it.
If it's not broken, don't fix it, i-m-h-o
Why would you not rather want a full-fledged dll extension system?
