Real Time Slopes?

[TheDarkArchon]

Real Time slopes are easier to implement than 3d floors (In a software renderer, at least)

[Phobus]

Real time slopes would be nice, and I could think of a lot of places it could be used. (I was actually quite surprised to find there wasn't real time slopes when I was making something)

[Bio Hazard]

How would this be implemented? I'm sure it wouldn't be global as that would surely break neumerous maps.

How about making line 181 accept 3 for front real-time and 4 back real-time?

[TheDarkArchon]

I thought it would be changed via altering the height of one of the sloped sectors.

[Phobus]

Ahh, but some may not want real time slopes, therefore additional arguments like what Bio suggested would probably be the best.

[Graf Zahl]

I thought it would be changed via altering the height of one of the sloped sectors.

That would be the easy solution. Or you could cook up some complex mathematic approach. Both have their uses.

[Bio Hazard]

I'm thinking about compatabillity. What if I want a slope to stay the way it is? I have a bunch of slopes in a map I'm working on that would break quite badly if they changed when the surrounding sectors moved.

(making a quick map to prove my point)

[Enjay]

I thought it would be changed via altering the height of one of the sloped sectors.

Or the height of the sector being used to reference the slope against?

[Bio Hazard]

Okay, here is an example:

Shot1: What If I built a lift like this and was a n00b and made the slope reference the lift. This would work fine for the current version. Therefore, it's not a bug.

Shot2: I go back and play my level in the new ZDoom with real-time slopes. Oh No! My lift is broken!

[Enjay]

Not a problem if there is a new line type for real time slopes or an arg that simply sets real time modification for the slope referenced by the line.

Anyway. n00bs make mapping errors all the time. They should discover the errors by testing the level (or asking people to test) and then fixing the problem. That's a useful part of learning to map.

That doesn't of course negate the fact that some way to differentiate between fixed and real time slopes would be required. IMO it certainly shouldn't be global as both types have a use. I don't think anyone was suggesting it should be global though.

[Lexus Alyus]

Not just n00bs, but everyone else makes errors all the time .

[justin024]

I like this idea. If it becomes implemented, the slope line special should be extended by one arg to give the option of toggling real-time movement. It was brought up that this could cause problems if the slope line is against a lift or something similar. The second arg could be 0=no real-time 1-use real-time. This would ensure compatibility with old wads.

Anyway. n00bs make mapping errors all the time. They should discover the errors by testing the level (or asking people to test) and then fixing the problem. That's a useful part of learning to map.

Right. 2 very annoying and easy to solve problems: Unclosed sectors and missing textures. Its called an error checker

[BetaSword]

Good idea. 181 only takes two arguments at the moment, so there's plenty of room for another.

[Remmirath]

MEGA-BUMP!

Hey, Graf, how do you think to add this? Real-time 3D floors are possible, so I think this could be possible too!

[Project Dark Fox]

MEGA-BUMP!

Hey, Graf, how do you think to add this? Real-time 3D floors are possible, so I think this could be possible too!

3D floors are done in GZDoom, not in ZDoom. I don't otherwise know the specifics so I simply think it was a bad idea to bump it. I just lashed out on the last guy who did it.