InsideQC Forums

leileilol wrote:Easier said than done.

QFT

I reckon if there was a will to do it, it would already have been done. That goes for most things.

Is the CSQC in the RMQe stable and fully supporting (compatible with other DP/FTE csqc mods)?

goldenboy wrote:I reckon if there was a will to do it, it would already have been done. That goes for most things.

QFT(2)
Also, with enough good will the QSB idea that some of us proposed here years ago would be a reality, and CSQC (among lots of important features) would be by now part of this standard.
Unfortunately, every engine coder has his/her own agenda for his/her project (I am not blaming no one BTW, I am fine with everyone pursuing their own ideas, Quake engine coding is all about freedom to experiment IMO).
I think we are lucky if FTEQW and Darkplaces implementations of CSQC are as close of "compatible" as they can be.
If the RMQ engine has a 100% compatible (I mean with at least one of the above cited projects) and well documented implementation, it indeed should be a great resource to spread the CSQC concept.
TBH this was the first time I heard about that. I'll check this out.

as with all things, RMQe is *meant* to be compatible.
However, its simply not complete, and is thus missing pretty much everything but 2d stuff.
It also currently requires a different globals/fields layout from both fte and dp right now (one that is a strict super set of ssqc's layouts). This isn't really any worse than the difference between fte and dp, and is probably the more sane layout anyway, if I'm honest about it. Both fte and dp should accept rmqe's layout, but it might trigger the wrong compatibility modes or whatever.

Spike wrote:as with all things, RMQe is *meant* to be compatible.
However, its simply not complete, and is thus missing pretty much everything but 2d stuff.
It also currently requires a different globals/fields layout from both fte and dp right now (one that is a strict super set of ssqc's layouts). This isn't really any worse than the difference between fte and dp, and is probably the more sane layout anyway, if I'm honest about it. Both fte and dp should accept rmqe's layout, but it might trigger the wrong compatibility modes or whatever.

But it's a third way to do the same things, and this defeats the very idea of spending time and effort learning CSQC if you need to either a) stick to a single engine, or b) resolve all incompatibilities in the QuakeC side. It has the same effect of doing things directly in engine side (at least for HUD changes, which I imagine is where most modders want to use CSQC).

If RMQ way is better and both you and LordHavoc agree on this, maybe it's time to unify at least a subset of CSQC around this implementation, call it CSQC2 or whatever you prefer, and from this start to work adding the remaining features in a more organized way. Just an idea. With a more stable and unified API it will be feasible to migrate it to other engines.

Better or not is it a complete standard of csqc ?
theres always this : http://www.quakeone.com/qrack/dev/csqcWinQuake.zip