My solution for hollow pipes is to make two circles, one smaller than the other, and subtract the smaller one from the larger one.

Back in the day this crashed Trenchbroom 😃

(Recent RCs have been better about this, thank god...) 

extras_r4 is a bit shit really. the ladders are framerate dependant and bug out completely if you run at the wrong rate, in ANY engine.

The ladders+water volumes will fuck up prediction regardless, so if you're using FTE you'll probably need to disable that by setting sv_nqplayerphysics 1 otherwise you'll get horrible juddering every single frame when the client realises that the server is doing something different. Obviously that sucks for coop+deathmatch, but for single-player you probably won't care too much.
The alternative is to check for+use the FTE_ENT_SKIN_CONTENTS extension - eg set self.skin=CONTENTS_WATER; and FTE will just automatically treat an entire SOLID_BSP entity as a water volume (moving the player if it moves - hurrah for func_doors). -16 can be used to get the engine to treat the entity as a ladder, although for these to be invisible you'll need to use SOLID_BBOX or SOLID_BSP+setmodel+model="" if you're after invisible volumes (or I suppose a vanilla func_wall combined with skip textures would do it).
That extension will leave the engine free to do all the desired physics automatically. It'll even do the underwater warp thing. It won't do anything for other engines though, so DP will still be screwed, and other engines will still need the dodgy qc code.

@redfield:
dp interprets OP_IFNOT differently, treating the operands as floats while every other engine treats them as ints. Basically this means that the -0 hack is broken in DP. You should be okay with 0.000001 though.
(fteqcc can achieve a similar result for all engines, but does not do so by default). 

As always, thanks for the detailed information.

In the end I was just trying to help sceletope with that singular desired effect in his map. The draining water.

The ladder code I liked because it worked like Q2, which is more natural than AD's implementation. Even if it is bad ladder code ;)

I kept posting cause I was trying to resolve the inconsistencies. I clipped what you wrote and put it in my FTE folder, in case I ever get back this.

Thnx again. 

@Redfield Darkplaces 2014/05/13 build (...) is compatible with AD.</>
Except that DP didn't support fence textures until about one year ago.

@mukor Nice tutorial but this method doesn’t make 8 identical sides, unlike circles. 

 

Yeah I noticed my mistake afterwards, the concept remains the same though. Vertex manipulation and the square templates are the core elements that needed to be taught. 

that reminds me of the hollow torus that i made in january when i was learning the editor, with all the vertexes in grid

i didn't made anything at all with it
and now i don't remember how i did it lol

screens:
https://drive.google.com/open?id=0B72Jjyg-RfNFRENTNmxfMWhLbk0
https://drive.google.com/open?id=0B72Jjyg-RfNFSDNMWm9Nck11bWM

map:
https://drive.google.com/open?id=0B72Jjyg-RfNFRWM0ZDZZTjNRVEU 

Topher, looks like something Orl would have. 

Hey, post that map source. I'd be happy to do a low gravity speed map with that!!!! 

been a long hot day I am downloading the source. :) 

Hey there,

Does anyone know if there is a workaround or solution the mapper can implement to reduce the instances of elevators that randomly hurt the player, or reverse direction.

The map I'm working on has done this to me and a few testers on occasion. It seems to happen in Quakespasm frequently. I've read it is related to the host_maxfps and physics. I tried seting my maxfps to 60 and it seemed to help. I'm just wondering if there is anything I can put in the map to reduce this? The speed of the elevator maybe? I just don't know if telling all players to cap there fps at 72 is a workable solution. 

Try a speed less than 60 perhaps.

But really, we're all handicapped to use lower FPS due to the physics issues inherent to the engines currently. If you want, you could mention that players who want to use higher FPS must use Darkplaces (at the horrible expense of non-twisty water).

For the love of all that is holy, why is there no twisty water in Darkplaces??? Otherwise it would be perfectly serviceable. 

If rising the max_fps above 72, problems like that are to be expected. However, it can also happen with standard values under certain circumstances. Some random hiccough in the clipnodes or physics.

I suppose you could try changing the brushwork of the lift and the area surrounding it in an attempt to stop the issue from happening. Or maybe maybe insert the whole thing elsewhere in the brush order (top or bottom of .map file) to influence the way QBSP generates the corresponding data. 

Are sunlights known to cause ugly seams? Or what could be the cause of this?

https://i.imgur.com/AqeC21W.png

The only light is _sunlight with _sun_mangle "60 -45 0". 

Never mind, it's a bug with tyrutils-ericw 0.15.10:

.10: https://i.imgur.com/Tuub6Pe.jpg

.9: https://i.imgur.com/J1dwbIt.jpg

:/ 

Just a thought but what is your sunlight penumbra setting? 

Everything was default, except for -extra4 and -soft. I hadn't started messing with things like penumbra yet.

I'm just going to be using 0.15.9's light.exe until 0.15.11 or 0.15.10.1 (lol) drops, anyway. Apparently there aren't many downsides (particularly, not any that will affect how I make my maps) 

After many hours I found what I think is an acceptable way to convert Q1 textures to Q2(this was a request of sorts)

When I say acceptable I mean, a non destructive conversion! Which was every tools way of converting previous, hehe.

Here is a sample: https://media.discordapp.net/attachments/355836262847873045/355847674475446272/side_by_side.jpg

The jpeg straight out of the .wad on the LEFT, my converted .wal file on the right.

I think the conversion looks decent enough? But in Q2 I just think it looks like poop.

Thoughts? 

Q1 and Q2 have different palettes. You cannot convert from one to the other without destroying information.
Your .wal is thus slightly less bright etc.

On the other hand, if you use .tga instead then you can avoid the palette thing entirely, but this won't work in vanilla, obviously (most q2 engines are fine with a .tga instead of a .wal, but its best to provide both in case someone insists on vanilla/sw). 

Due to palette differences, the texure will shadow differently.
Quake 1's versatile palette:
https://quakewiki.org/w/images/0/09/Qpalette.png

Quake 2's restrictive palette:
http://fabiensanglard.net/quake2/quake2_palette.jpg

Now, Q2's palette is more bland because Q2 relies heavily on colored lighting. Try using light color to correct it maybe. :) 

Q2 was designed with old opengl in mind.
it has no fullbrights (nothing can glow in the dark).
it has no overbrights (brighter areas cannot oversaturate, resulting in flatter dull lighting)

it has rgb lighting, but this mostly just means that they went crazy with it, thus anywhere even near sky becomes orange, which reduces effective palette variation even more. 

No not moving literally, I'm still stuck here in the Canadian wilderness...

My AD map which is almost finished the beta stage has gotten a little bigger. Sometime at the point it grew from 10 000 brushes to 11 000. I got an error message (tyrutils v0.15.10) "Too many vertices... compile with bsp2..."

It wasn't a leak since the map still does full vis/no leak detected/no pnt file, and adding the bsp2 tag has fixed it. I guess it literally had too many vertices. Is there anything I should know now that the map is in this format? Everything seems to be working fine. I guess I'm stuck with it at this point since I won't be deleting details this time.

Thanks 

My understanding of BSP2 is that OTP will tell at you and your map won't work in old engines. I'm not aware of any engine that's actively developed that doesn't support BSP2.