Doors on a diagonal: wont open correctly

[Bikerdude]

This has bugged me for a number of years, how to get a door that's on the horizontal diagonal to open correctly. I would appreciate any ideas or help, as I have been banging my head against this for the last hour or so.

 

 

test.map.txt

[Moonbo]

I don't think it's possible, at least I never found a way to do it. The solution I ended up using was just to have a single door at that angle and make it swing upwards.

[grayman]

Doors only rotate about the x or y or z axes.

 

To get a door to rotate around anything else would require scripting. The script would need to recalculate the door position and angle every frame.

 

I don't recall anyone having written such a script. (Even if I did it, I don't remember doing it. Old age sucks.)

 

Equations exist for rotating around a given 3d axis; the scripter would search for and start with that.

[grayman]

That having been said, I remember that the doors of footlockers will open around a random vector in the xy plane. Most of us orient footlockers along the x or y planes, but there was one in Outpost that was not set up that way, and it works fine. I think the math uses the local axes orientation of the door rather than the world axes when opening.

 

Maybe there's hope in grabbing a footlocker prefab, rotating it so the door angle matches the cellar door angle, and see what happens when you open it. If that works, perhaps the attributes of the footlocker door can be transferred to the cellar door. Dunno, but it's worth a try before hiring a scripter.

[Bikerdude]

Ok, was worth an ask. And clearly not doable for me, as I havent got a clue about scripting.

[Amadeus]

Hey, I asked this question a while back and Sotha is the one who gave me a good solution. Let me see if I can't find that thread

[Amadeus]

https://drive.google.com/file/d/1op_tFCldbh8TF8ihI6vbm4HVWeJI6qwk/view?usp=sharing

 

Here is a download link to a test map that Sotha made for the door. (let me know if this doesn't work or if you can't download it)

 

The idea is that you make a func_static of like a cup or a plate or something small, then angle it to the angle you have your doors at, then bind the doors to the func_static, and it should work like a dream. Its a workaround, sure, but players shouldn't know the difference. You can just hide the cup anywhere in the map and you should be good to go

[grayman]

Well there ya go, exactly what you want.

 

That's not an intuitively obvious solution, but it's what you expect from the genius of Sotha.

[Obsttorte]

The rotation is specified by the rotate spawnarg, which is a vector, not a scalar. Passing the correct vector should allow such rotations without the need of the above mentioned workaround. idTech 4 uses Euler angles if I am not mistaken.

[Obsttorte]

Addentum: The rotation is actually yzx, so not really Euler. Calculating the correct vector is a bit annoying, though. However, it is not necessary to create an extra entity to bind your door to. The doorframe containing the door will suffice.

 

I guess the most straight-forward approach (at least from my point of view ) would be to use doorframes that have the doors def-attached.

[Amadeus]

That's a good idea. Also, you wouldn't be able to put a visportal on a slanted door right? Don't they have to be upright or flat?

[Bikerdude]

Grrr, I just built a new coal shoot and door.

 

But will have a look at the above test map! thanks Amadeus

 

@Obs, a door hinge model could be used in place of that cup on Sotha'd test map - sweet!

Edited February 20, 2018 by Bikerdude

[ERH+]

I've made door like this based on func_rotating but the problem is with button attached to the door: if player stands in it's way, the door model will stop and func_rotating will make next reversed move from that point, breaking default start-stop position. I've tried "not pushable" and "push player" with no success. You can avoid this if button will not we bound to the door, some sort of a lever or a chain aside of the door (maybe if it will be lever, not button - it will benefit from "not pushable" and "push player", I didn't checked. And no solid makes button not frobable).

 

https://1drv.ms/u/s!AoIlw2GQnPGZcqnZ6yHFEg1dVN0

Edited February 20, 2018 by ERH+

[Obsttorte]

That's a good idea. Also, you wouldn't be able to put a visportal on a slanted door right? Don't they have to be upright or flat?

Visportals are flat, but they don't have to stand upright. Their orientation doesn't matter. It is a good idea to avoid them to have more then 4 edges (and keep them rectangular probably), though, as otherwise they will (or were, maybe this has been changed in the code) cause issues with sound propagation due to some optimization in the code.

[grayman]

The sound propagation code doesn't care how many sides a visportal has.

 

IIRC, think of the actual N-sided portal fitting inside a virtual 4-sided portal. The sides of the virtual portal are used for propagation, which is good enough for sound purposes.

[demagogue]

If there is a way to make an angled door like this, I recommend a version it be made into a prefab and packaged with the mod, because it's a problem a lot of mapper have run into over the years.

[Bikerdude]

If there is a way to make an angled door like this, I recommend a version it be made into a prefab and packaged with the mod, because it's a problem a lot of mapper have run into over the years.

On it.

 

I will make a set of coal/basement doors like I was trying to as this I think will be what mappers will be wanting to use.

[AluminumHaste]

So I could make an apple entity and it can be set to rotate relative to it's object instead of world. What's so different about doors aside from AI interaction?

[Obsttorte]

The sound propagation code doesn't care how many sides a visportal has.

 

IIRC, think of the actual N-sided portal fitting inside a virtual 4-sided portal. The sides of the virtual portal are used for propagation, which is good enough for sound purposes.

Than this must have been changed. The last time I looked at the specific peace of code the center of the visportal plane was used if the amount of sides exceeded four. Been a while, though.

 

EDIT: I've just taken a look and you are right. The amount of portal sides does not matter. My mistake.

[grayman]

Think of sound propagation as a loose string that runs through all the portals between points A and B (A = producer, B = listener).

 

Now pull the string taught.

 

It slides into place at the appropriate points in each portal, providing the shortest distance from A to B.

 

Ever since I made that change, we haven't had any complaints about sound not behaving correctly. If the mapper does a good job with his portals, sound delivery should be as realistic as we can make it.