because fire rate is linked to frame rate. 

WWWAAAAAAATTTTTTTTTTTT 

Q:C is unfortunately sort of a dumpster fire on the coding side due to the outsourced development, which is a royal shame because the actual gameplay is typical fun Quake but there's so many naggling performance and networking issues plus a slowwwwwwwww balance change schedule. 

Preach had mentioned on his wordpress page that QME has an "undo" feature.
Preach, I've tried ctrl-z in the 3d view and it doesn't work on either version 3.1 or 3.0. How does this work??

Here's a link to the page where he mentions it:
https://tomeofpreach.wordpress.com/2012/12/31/in-defence-of-qme/

Thanks. 

The undo is for drawing on the skin only, other changes aren't tracked. It works for me on 3.1 

While browsing through news pages about quake in Steam, I chanced upon this news about a gore mod for quake, which is akin to the well known Brutal Doom mod for classic Doom and Doom 2, stylishly named Qore:

https://www.rockpapershotgun.com/2017/10/16/quake-mod-qore-slidekick-and-gore

The mod itself can be downloaded here:
http://www.moddb.com/mods/qore/downloads/

If you are interested in pumping up the gore factor in your quake game, and this also somehow went previously beneath your radar like me, then give it a swirl!

(Moved to GA because it seems to be a work in progress mod) 

Thanks Preach!
It'd be great see a program as simplistic and specific to Quake modeling as QME, but with more features, like an undo for geometry. Get on that please, somebody. 

video 

 

I want to add a gravity keyvalue to worldspawn. 

Been trying to learn how to bhop properly in NetQuake engines like QuakeSpasm and Mark V. Mark V has a handy "scr_showspeed" cvar, so I've been experimenting on it.

In QuakeWorld engines like ezQuake it's so easy, I just do a circle jump, then release +forward and keep on jumping while strafing and moving mouse in the air. I can reach 700+ ups no problem. But in QS and MV I seem to lose speed with a couple of jumps, even if I try to press +forward with each jump. Is the NQ friction too high or what? All I can do is 400 something ups at best, which doesn't seem meaningful.

What's the trick, if there's one? I mostly want to do speedruns of modern map packs, hence the the interest in the technique. 

bunnyhopping in qw is possible because you can avoid being on the ground at any point - there is no friction and thus theoretically no real upper bound to max speed (up so sv_maxvelocity of about 2000 anyway).

nq keeps you grounded for at least one frame each jump, so you're till at least partially subject to friction, limiting max speeds. 

Then how come the QDQ guys move so fast?

https://www.youtube.com/watch?v=VpiNDxssUL0&t=14 

here is the quake speedrunning discord

https://discord.gg/2FUySJ

If you want your times to be officially accepted by the community and want them posted on speedrun.com or similar you pretty much need to use neaquake or joequake. That is pretty much the standard.

Yes, the difference in protocols between the engines means you can get more speed. Watch some of the streams from beehivekay:

https://go.twitch.tv/beehivekay

The tricks he does aren't possible in "normal" engines. He doesn't want to set times, he just does it for fun / practice.

So I guess it depends on what you want to get out of it. 

newhouse_: how does it feel to have over 100 quake maps this year?

CustomShambler: it feels like making love to a beautiful woman.....

CustomShambler: ....WHO HAS 100 DIFFERENT TYPES OF AWFUL S.T.D.s 

Wut? We're still at 94 yeah?... don't jinx it! 

I believe that the main diff is that QW runs at a ticrate of 0.01388~ or 1/72fps where as standard (net)Quake runs at a ticrate of 0.1 10fps (modern servers online run at 0.05 or even 0.025 so this affects the physics timings. As Spike said netQuake has longer times for the physics to apply to the player. Try lowering your ticrate to 0.0133 in Qspasm and see if your bunny-hopping speeds increase. I've always been curious how speed runners achieve QW like physics at normal ticrates. IMHO they should have the visible spedometers on screen or at least show their settings. 

Is physics tied to a frame/tic rate? Shouldn't this be framerate independent and calculate based on time since last frame? 

>framerate independent
>time since last frame

Don't be naive.