Engine standards for mod compatibility

[Urre]

[Team Xlink]

[mh]

[Urre]

What about network protocol? I think I mentioned earlier, that some raised limits require altering the protocol, which in my mind would require some form of standard for that as well. Spike mentioned the fact that there could be singleplayer-only engines, which would get excluded if there was a protocol requirement. This, to me, is simply fixed by letting a singleplayer-only engine freely upping the limits to match that of the multiplayer-capable ones, while the multiplayer-capable engines have the additional requirement of supporting a common network protocol, to make sure they're all able to play online with eachother. I don't see it being an unreasonable thing to ask. As a modder you'd expect all the engines within the same standard to be able to run your multiplayer mod between eachother. Otherwise it's not much of a standard, is it?

Is Protocol 666 (FitzQuake) a reasonable suggestion? I'm not entirely sure on the boundaries of its limits, it didn't seem like the readme had all the details, I might not have looked hard enough though. It'd be great if someone could provide a detailed list of what Protocol 666 requires.

The main thing that absolutely needs to be bumped, and I suspect it does affect the protocol, is the amount of entities you're able to have on the server. One of the most common things I've heard modders worry about is saving in on entities, constantly, worrying about spawning an extra entity for something which might make their life easier or the feature they're developing a bit better. This is one of the main reasons I've been modding exclusively for the DarkPlaces engine, because it allows virtually unlimited entities. I've never reached any limit anyway, and I've had huge maps filled with over 4000 waypoints, on top of the regular entities used by the actual game. Ofcourse, the limit doesn't have to be insane, but reasonably larger than Quakes. A modder shouldn't have to worry about wasting entities just because the amount is limited. The question wether they can all be visible at the same time or not is a different one. That I guess is more of a packet-overflow kind of discussion, which also affects the network protocol.

[mh]

Mr Fitz himself kindly wrote up a description of that, and I'm pretty certain it's lurking somewhere on the wiki.

I think it's a good suggestion, although currently I think only FitzQuake and DirectQ support it (and I'm not 100% certain on how well - or not! - I've implemented it ) It would also be popular with mappers and modders, which can only help.

I would however extend it to add some more granularity to origin and angles. I don't see much reason why origin can't be transmitted using the original float, and all angles (not just the client) should - at worst - be extended to 16 bit quantization (full float would be preferable though).

This would require a bigger buffer, hence larger transmissions, but for MP games it would only matter if the server was running the same protocol.

For SP games I would advocate bypassing the protocol and network layer entirely and just writing/reading the data direct, but I haven't researched this enough to know how much work would be involved (quite a lot I suspect).

[Urre]

Concerning graphical features, seeing as they're both controversial and kind of silly to keep consistent between software and hardware accelerated rendering, I'm going to attempt finding some form of middleground which means different requirements depending on what rendering your engine supports, and for atleast one case, a completely new solution, which is kind of going against the core idea of this standard (standardize existing features), but I'm feeling it's justified for this specific case... You're all welcome to whine about it in the other thread once I've updated the QSB entry in the wiki

How does this sound though, theoretically speaking? Do you feel it's okay to have different requirements?

[Urre]

[metlslime]

[mh]

[metlslime]

[Urre]

[Urre]

[mh]

Sounds good to me too.

Adding a new protocol isn't that difficult, and even easier if you decide to replace protocol 15 outright. It's just kinda messy the first time you add one. Having more than 1 protocol supported can involve quite a bit of juggling in your code too.

I guess it's not really frowned upon, it just doesn't have quite the same sex appeal as a particle system or whatnot. Me, I enjoy tinkering with stuff on the level of the file system or the memory manager (it helps that I'm also rubbish at particle systems), so I'll cheerfully add as many protocols as are reasonably documented.

[metlslime]

[frag.machine]