Qmaster is right, here's a Scrag floating several thousand units above the floor and being lit by the red lighting at ground level. All the wall textures are grey. 

Winquake traced up to 2048 below the mdl, QS traces 8192 units. The code is in R_LightPoint: https://github.com/id-Software/Quake/blob/master/WinQuake/r_light.c#L248

@Tens
First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures.
Weird, I don't know why this worked, because the raytrace in R_LightPoint should have hit the func_detail_illusionary and picked that up instead of the lighting below it. Regular func_illusionary is safe though.

Btw, with my tools, you can set _minlight and _minlight_exclude on world brushes with func_group or func_detail - this could be a handy way to make the hidden brushes have the desired light value, without having to bother setting up spotlights pointing down. 

Thanks for the feedback mates. I was just curious what causes the ugly-looking effect. Good to know it's not a bug at all.

@ItEndsWithTens
If I ever dab at mapping I'll be sure to employ your workaround... :) 

@eric
I'm just going by what's in the 1.70 source files. Though looking at the map again in QS 0.93.0, Scrags flying over the pit do look kind of dark, so maybe it doesn't actually work? Hard to tell, honestly. You'd have to ask sock for more info, maybe there's more to it than meets the (or at least my) eye.

I'll be sure to fiddle with that minlight exclude key, sounds intriguing!

@maiden
Glad I could help! More Quake mappers is always a good thing, you'll certainly be welcome if you decide to join in one day. 

I added a "joy_exponent_move" cvar for controlling the move stick's mapping curve. Previously it was hardcoded as linear.. which translated to feeling twitchy (as Hipnotic Rogue was mentioing in ##3198)

I went with a new default of 3 (matching the "look" stick).. now you have to press the stuck further to get full speed, but it's easier to move slowly. The "look" stick is unchanged.

Wonder if any controller users could give me a second opinion on this in the dev build?
http://quakespasm.ericwa.com/job/quakespasm-sdl2/240/artifact/quakespasm-r1556.zip 

I'll give it a test run after work and get back to you. :) 

 

I've been messing around and setting the joy_exponent_move CVAR at lots of different values just to see the difference. I reckon you were on the money with setting it at "3" though. :)

Slow and small movements now feel much more manageable.

Good job. :) 

 

 

The scrag example is one of the reasons the lightgrid was invented for Quake 3. 

 

Does QS support .scale? I wonder if it would be fun to make tarbabies merge when they touch each other, forming a bigger tarbaby with each merging, all the way up to becoming a huge shambler-sized tarbaby. 

That would be an horrible "the thing"-like experience! 

 

I'm fairly confident that if you tried to use DarkPlaces .scale on an Ogre...

If you doubled his size, his feet would be in the floor.

Also you know Quake hulls (collision) ...

Maybe for Quake 3 map format .scale would work, but any feature using the Q1 map format shouldn't be called ".scale" but rather ".broken_scale". 

Hmm, that would require a protocol change then. Or a modified model, or CSQC.

The protocol method would send the mins&maxs from the QC physics bounding box to the client, so the renderer can offset the position of the model correctly. It's the most general-purpose solution and would make .scale more intuitive to use. 

scale is supported by the rmqe/999 protocol, as well as fte+dp's protocols of course.
QS supports 999, I don't recall if it supports the scale part but QSS definitely does.

.scale is just as 'broken' on q3bsp as q1bsp.
For it to work properly, you need to bias the mins_z value to compensate. Obviously this will look seriously broken in engines that don't support scaling...
On q1bsp you need to refrain from changing mins_x and mins_y though, which limits the range of sizes you can get away with (otherwise a large monster will walk through walls in one direction, but not its opposite, and values that differ from the hull's size will make it more extreme).
maxs_z can be changed freely, at least. the monster might ignore ceilings but that's not a problem if you just avoid placing upscaled monsters in places with low ceilings. 

I don't think .scale is a good idea for reasons outlined by Spike, with which I'm in full agreement.

It's important to remember that the RMQ engine was a tech demo. One of it's purposes was as a semi-experimental test-bed for new ideas, not all of which should be expected to work well. Another of it's purposes was to become obsolete as ideas that did get bedded-in and nailed-down were picked up by other engines. It's a natural consequence of those two purposes that sometimes the implementation might be a bit wonky, or might simplify to a special case, or whatever. The point is: RMQ engine's implementation of .scale might not be a great model to work from. 

RMQe's behaviour is fine, and is consistent with DP_ENT_SCALE, so that's a good thing.

But yeah, the hull issues make automatic scaling unworkable, so scale without qc is generally a bad idea.

So imho RMQe's scale is fine, and more robust than hexen2's... 

"Hmm, that would require a protocol change then. Or a modified model, or CSQC."

Nope. Neither.

1) Open up, say, QME and double the model size.
2) Change the .qc setting the box -- you might need to add a new monster. This would at least get the Ogre's feet touching the ground appropriately.

3) If you decided to make a monster too big for a Quake hull (Shambler size?) -- you better add some invisible func_walls to box the bastard in too hide the lack of proper collision.

You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

Just don't get forget the asterisks. ** Any proper map using a "too big" model like the QTest dragon (Once Upon Atrocity, for instance) needs to "no clip block him in" to his area and close the door behind the player so he can't be sticking his dragon wings through the walls.

The Kurok engine actually had a special brush type "monster_clip" for special clip brushes that instead of blocking the player would block only the monsters instead --- in the case of Kurok, it was a helicopter shooting missiles and the monster clip kept it in a defined box.

The Quake map "Source of Power" https://www.quakewiki.net/archives/underworld/quakerev030624.html ... had baby Shamblers in GLQuake -- and I can't remember the name but some map had a 2x sized fiend or Rogue gremlin or something like that. It was also a map that ran in WinQuake/GLQuake just fine.

The short version is that ".scale" is and always was ".completely_broken_scale" that sounded cool unless you knew how broke it was.

It doesn't solve any problems and creates false newbie-sauce visions of grandeur -- and you can manually create a double sized or half sized fiend that works in WinQuake/GLQuake.

/Someone should find the guy who came up with the idea for ".scale" and slap him with a wet fish. 

You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

My idea was to use .scale in an animated way, and with non-arbitrary sizes. There would be a maximum size, but the tarbaby would also have any size between the minimum and the maximum.

Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

The animated shadows in Fightoon were created using animated scaling. The higher in the air the player gets, the larger (and more transparent) the shadow gets. This would be absolutely impossible to create in a regular engine. 

And here's another example of animated scaling usage. This effect dynamically resizes the model to the intensity of its entity's lighting.

I just didn't try figuring out uses of .scale for solid objects before. But for purely visual effects, it's a clear improvement. 

Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

You could author a new animation of "growing" from size N to size N+1, in each model. Play in reverse to shrink. This means he can't do anything else while he grows/shrinks, though. 

Also, the vertex compression would still cause the transition from one model to another to be jittery.

Using multiple models would still be a hacky & inefficient method. But the bigger issue is that the physics would likely end up even more hacky.

A proper solution for the physics would probably be to use the Q2 BSP format, which uses raw brushes for collision. But this means that such gameplay ideas aren't suited for Q1 anyway.