06-21-2017, 01:32 PM
06-21-2017, 07:09 PM
Am I the only one who doesn't want to deal with vector snapping in Quake 3 (based) engines?
06-22-2017, 06:21 AM
https://www.q3df.org/forum/viewtopic.php?p=3516#p3516
Or the terminology was velocity snapping.
I don't have first hand experience with it; it was something brought up while playing Race CTS with someone. The way it was presented, was that if the map was rotated to align with 45 degrees, players would be (slightly) slower than if it wasn't- and slightly slower is the a big difference in a mode fighting over fractions of a second.
It'll be largely imperceivable if someone decided to port a map, but then rotate a bit to troll people.
Or the terminology was velocity snapping.
I don't have first hand experience with it; it was something brought up while playing Race CTS with someone. The way it was presented, was that if the map was rotated to align with 45 degrees, players would be (slightly) slower than if it wasn't- and slightly slower is the a big difference in a mode fighting over fractions of a second.
It'll be largely imperceivable if someone decided to port a map, but then rotate a bit to troll people.
07-13-2017, 09:46 AM
That's actually really cool! Thanks for speeding the Daemon port along with this!
07-14-2017, 10:39 AM
(06-21-2017, 01:32 PM)Lyberta Wrote: [ -> ]Now the only thing that is left to port Xonotic to Daemon is to implement all builtin functions. This library has 45 such functions already implemented.
For us non-experts: 45 out of how many approximately to get Xonotic / QC pogs code compiled with gmqcc running on this?
07-14-2017, 04:01 PM
Uh, ok... that significantly dampens my enthusiasm for this and explains why the original Xonotic to Daemon porting plan was never getting anywhere. Still great work and lets see where this goes.