> It looks like there is the need for brush model interpolation in the Quake engine like when the cubes puzzle blocks drop off the ledge and the very fast "squishers" -- for lack of a better word.
>
> Also the camera cut-scenes are great but the occasional very subtle lack of smoothness that I occasionally notice makes me wanna try this in DarkPlaces which I know has camera smoothing.

These are actually a protocol limitation; the default angle quantization is not sufficient for smooth rotation of either bmodels or the camera, and the default position quantization doesn't help much either.

I've had brush model interpolation in DirectQ since almost the start and it makes no difference to this kind of thing whatsoever; you just need to go to full float in the protocol to resolve it. 

Thanks for the insight into the problem, Necros. Since QuakeC only runs at -- I'm thinking -- 10 frames per second that makes a lot of sense. 

... didn't see MH's comment as I was playing around noclipping around the map in DarkPlaces and looking at stuffs.

Some of the things that didn't look smooth didn't look smooth in DarkPlaces either. And a couple of things did (but not many).

Oddly enough, I swear that rotating camera cutscene didn't even happen using DarkPlaces where you destroy the first boiler ... but I was using DarkPlaces 2008-10-04 build on OS X as current DP runs hella turtle slug speed on this gfx card and current DP disables changing r_glsl to 0.

[But I digress ... but rather than discard an insightful comment even if rather offtopic -- I remember playing Nehahra first on a very old DarkPlaces that came with it and the map lighting was superb without any speed slowdown at all on whatever GeForce FX I was using back then. If the performance of ancient DarkPlaces lighting has no speed impact ... hmm project for imaginary future where I have unlimited time that will never happen.]

Either way, yeah ... the angle quantization, possibly the one shortcoming of Fitz 666 protocol from a stock Quake protocol perspective. I'm sure RMQ 999 already has and will continue to have more goodies as it evolves. (Hopefully vwep at some point, with grunts carrying different weapon models ... but even if that isn't in the plans ... all the extra king-sized treasure chest of tools available to modders is fodder enough.) 

Is a telling comment - and a pretty good compliment as well.

I know the real Q2 is liked by many, but I always found it a bit naff. It should have had more monstrous enemies (less humanoids) and much faster player movement. For me at least.

For the pushables to have better movement and be less 'snappy' they'll need some sort of velocity / acceleration in the Qc... 

Something I'd like to see would be an increase in friction for player movement, for deacceleration mainly. I think bunny hopping and ramp jumping are really awesome but I don't like the skating feeling Quake gives you.

Most of the time it isn't a problem at all, but as soon as you require some careful jumping it becomes an issue, and I think it is a factor that leads to many people disliking little platforming sections in maps. 

was the same as quake wasn't it? factoring bunnyhopping in i'd say it was even faster due to the friction physics working slightly differently

Something I'd like to see would be an increase in friction for player movement, for deacceleration mainly. I think bunny hopping and ramp jumping are really awesome but I don't like the skating feeling Quake gives you.

Most of the time it isn't a problem at all, but as soon as you require some careful jumping it becomes an issue, and I think it is a factor that leads to many people disliking little platforming sections in maps.

see if you were talking about q2 there i'd understand and probably agree.. quake is much less skatey though :P and not many newer engines allow you to better control mid-air player movement, which makes it better for jump puzzles imo

you can always tweak sv_friction in the console anyways 

'q2 player movement' should probably read 'q2 player speed', not movement as a whole 

The atmosphere and design in this map is exceptionally good. Truly Quake++ as I hoped it would be. And that's actually enough for me to tolerate the new additions, apart from the boss combat which I godmoded through. 

Thanks Shambler. That's quite a compliment.

I hope the additions will be polished to a point where even long time Quake addicts can tolerate them - the feedback in this thread gives us a pretty good idea where the niggles are so far.

One of the things where RMQ is still lacking is the monster lineup; we need to flesh that out, and we have several ideas, models and a bit of concept art that might yield a few totally new enemies and bosses.

Especially high tier monsters need a boost in RMQ since the player can dish out more damage now. There is already an initiative by Supa to make shamblers more threatening / interesting, and there is ijed's idea of a DIMENSIONAL shambler. Another route to make high level monsters more threatening is the caster_level key - ie spellcasters. RMQ has a dedicated magic subsystem. I should write something about that in the mapping guide.

Anyone succumbed to a forcewall spell while playing the map yet? ;-)

Fall damage will be revised in the future (impact damage), we can have an eye on reducing the damage a little more... although you will usually find health packs wherever you have to take a drop.

The very fast movers actually had their velocity capped shortly before release - they didn't collide properly with the player at speeds much > 1000 ups. The triple slider is supposed to be faster.

The part where you block crushers with boxes (thanks TR/Zelda?) is unfinished; it will be revised. It is good to know that several people instantly figured out what to do there - this means we can use that mechanic a bit more often. Blocked crushers do need the constant noise eliminated, of course.

And once we have detail brushes, the hundreds of func_walls in this map (it does evil things to Quake's model limit) will finally cast shadows again. Try noclipping outside of the map to see what is a model and what isn't. :-)

Fitzquake 085: While Fitz is RMQ's ancestor, it is really recommended to use RMQ's own engine, for the protocol, the alpha masked textures and so forth. It is desirable to have a MacOSX build for the point release.

Thanks again to everyone playing and giving feedback about this, it's much appreciated and very helpful. 

Try noclipping outside of the map to see what is a model and what isn't.

r_drawworld 0 

Things I'd like fixed (in rough order):

Falling damage - too sensitive and too much for a short fall, please reduce.

Off-centre weapons - doesn't feel right, if I was shooting stuff I'd be sighting down the gun so it would be in the centre, please revert or give the player the option.

Boiler damage - radius waaaay too large and instant death. Please reduce lots.

Shambler lightning - a bit too blue, please tone down. Ditto for voreball pink.

New player sounds - please minimise as they don't really enhance the experience.

Screenshake on firing sng / rl / damage etc - ditto, please minimise as it's distracting.

Railgun - please beef up the normal shooting sounded. The damage feedback sound is good but the default sound is too weedy.

Teleporter effect - could do with being a bit more ominous / magical.

Box speed - please increase a bit as others have suggested.

Health vials - would prefer something more general/industrial and less generic fantasy.

New stuff (in no order):

Hook - fine, takes a bit of getting used to, but works well. A bit heavy on the hook secrets in this map.

Railgun - good, a fine addition gameplaywise.

New shotgun / ssg - good, a change that's quite acceptable.

New Ogres - fine.

Shards - fine.

Puzzle / box gameplay - fine, quite tastefully done. Not sure what the bit near the moving barriers was supposed to do, it didn't go anywhere?

New transparent thingy wotever effects - good, very good in some places, the big blue lightning column thing was excellent.

The map:

Design was 99% perfect, the other 1% being unsubtle coloured lighting. As before as a remake of a Quake metal map this is spot on in all aspects.

Gameplay was generally good. Monster usage was fine and progression around scenery was good. Two exceptions: too many death traps (crusher jumps, boilers) and the end battle seemed ridiculously hard.

Overall:

See my initial comment. The additions were more tolerable than expected. I think there are some obvious tweaks to make. The revamped graphical / design style is very good and shows a lot of promise. 

I have the texture packs in Quake\id1, and I'm running RMQEngine-Win32, but it keeps starting up with no textures on anything - not models, not the map, etc. Err... what am I doing wrong? 

The only one I don't get is Teleporter effect - could do with being a bit more ominous / magical. you mean when a monster teleports in?

Not to give too much away, but the boss can be toned down for this level in final version, since he'll make a reappearance.

The health vials are worldtype dependant, we just haven't made the metal ones yet.

Good tip OTP - didn't know that. 

Texture packs ...

FitzQuake and hence Quakespasm and the RMQEngine do not support loading external textures from pak files.

You must extract the .tga textures to quake\id1\textures 

I retract the issue with the boss combat, the actual combat is fine, it's just those retarded boilers again. Explode them first and it's quite reasonable.

Teleporter effect, the one when the teleporter texture appears in a wobbly oval. It's okay but could be more worrying. Not a biggie anyway.

I've played this a couple of times now, it is very cool overall. 

Try an earlier version of the engine: http://mhquake.blogspot.com/2010/11/rmq-engine-test-release-17th-november.html 

FitzQuake and hence Quakespasm and the RMQEngine do not support loading external textures from pak files.

that is totally untrue. quoth 1 has a bunch of external textures in pak0.pak for ne_marb and they load just fine. this was way back on FQ080, and 085 as well as quakespasm still have that functionality. 

Some posts in this thread led me to believe that FitzQuake couldn't load textures from pak files.

http://www.celephais.net/board/view_thread.php?id=60172

Admittedly I have never tried loading textures from pak files in FitzQuake and instead extracted them solely due to that [false] information.

Baker -1 for repeating wrong imformation then. My bad. 

There was an issue with pcx textures in pak files at one time, but it has been fixed. 

freakin sweet so far. expect this review and others soon. 

Will take a look at the tele fx again as well. It's not great I know. Hm.

Maybe I could duplicate the mesh inside all .mdls to make it take the shape of the creature...

Not sure about the texture problem since I haven't got them loaded up - email gb or mh. 

good feedback, we will address those issues.

The colored lighting in this map:

I had to switch tools literally hours before release, because as soon as I started turning a lot of things into func_walls, hmap2 broke. First the qbsp part, then the light.

So I switched to treeqbsp and mh's colored light version of Bengtlight but kept the same light values - no time left for tweaking them since Supa and I really, really wanted to make this deadline. Expect colored light tweaking in the future... the old version looked slightly better with less problems, but then the breakage came :-/

It is a real problem that we have no active Quake tools coder. Maybe if we all start sucking up to Rich Whitehouse or someone of that caliber, he'll spend a weekend on a unified version of Bengt-tools with the rotating bmodel fixes from hmap2 ported and the colored lights and multithreading merged in... crossplatform hopefully :-/

hmap2 is a good compiler, but it is a friggin' diva. It has very strong ideas about what the mapper is and isn't supposed to do. That approach isn't working though for something like level design. Tools need to be pretty lenient.

External textures: I didn't use .pk3 for those since I wasn't sure if our own engine supported it. Again, immense pressure due to the deadline. So I zipped them. You need the tga files in Quake/id1/textures.

Expect the QRP addon pack to grow in the future. I have contact to moondrunk and inkub0 (hexen 2 retexture pack guy), and the latter said he'd like to help with creating missing textures. moondrunk offered his help as well. I myself am pretty good at butchering textures by now, and I may have more time for that now.

New HUD etc. are in the future, I think.

gb 

PK3 support is in the future and will be just a rip from the Q3A source; I prefer approaches that don't require use of external libraries, and our experience of people having difficulties with getting the SDL DLLs on their machines validates this preference.

I've done some hacking on the tools source but I'm not a tools guy and my own experience of them is *very* limited, in particular of qbsp and vis. Basically I have low confidence in my own ability to deliver any kind of major tools work, and I'd second GB's call for a dedicated tools person.

Yeah, there are problems with certain textures on certain hardware with the current engine build. This is an unfortunate consequence of an older generation of hardware (the first generation of DX9-level hardware specifically) where support for the full OpenGL 2.0 feature set was claimed by this hardware but didn't actually exist. This one needs to be put down to a lesson learned. 

Will take a look at the tele fx again as well. It's not great I know. Hm.

it always looked kind of placeholder. i'd vote for an alpha sprite of some kind instead, like an explosion kind of graphic (emphasis on the 'kind of', not literally an explosion) 

Really like it's performance, runs big stuff better than any other engine I tried :)

However, after hopping back and forth between it and others I can confirm it has some kind of mouse lag which is pretty annoying :(

Any command line stuff/variables that might be able to change it?