Roaarrr!

http://www.doomworld.com/julian/rorEternity.png

Wasn't THAT hard. Now debugging will.
Note that this "extension" is not (yet?) endorsed by Mr.Q.

Sweeet.

Hey Joel, I love your sig actually.

The Merovingian said:
http://www.doomworld.com/julian/rorEternity.png

OMG I WANT THAT!

[Edit] There are soooo many instances I've been thinking up some really cool architecture, only to realise a few seconds later that, despite all the tricks in my book, it still isn't possible. But this new RoR effect seems to be HOM-free, right? As in, no problems with suspended floor/ceiling even during transition?

Gods, I can do some TRULY EVIL STUFF with that!

[Edit 2] Of course, one thing to test is monster behaviour inside a RoR sector. It's one thing to make the floor/ceiling blocking shots, quite another to prevent a monster from (futile) attacking a player above/below him.

[Edit 3] Give me one finger and I'll.... How about deep-water in combination with RoR?

Ok...heh...I knew about this on IRC, so, here was my reaction...

OH MY FUCKING GOD HELL FUCKING YES WOOHOO YES YES YES YES WOOT OH YEAH BABY!!!

* orgasms enough to fill a fish tank *

BTW, I tried sending James a bug report but his listed email bounced. So, here goes: in the current beta2 terraintypes have stopped working for deep-water sectors. This used to work in the previous beta. But, normal sectors with terraintype flats still work.

Mordeth said:
[Edit] There are soooo many instances I've been thinking up some really cool architecture, only to realise a few seconds later that, despite all the tricks in my book, it still isn't possible. But this new RoR effect seems to be HOM-free, right? As in, no problems with suspended floor/ceiling even during transition?

It's the good old rorDoom system, meaning no more than 1 floor & 1 ceiling per screen column.

Mordeth said:
[Edit 2] Of course, one thing to test is monster behaviour inside a RoR sector. It's one thing to make the floor/ceiling blocking shots, quite another to prevent a monster from (futile) attacking a player above/below him.

Well, aiming and shooting algos are pretty similar, so as in rorDoom, it's already in there. But, given Doom's AI and the fact it supposed 2D architecture you may end up with funny behaviors.
Sprite clipping is also handled tho some bugs remain of course.

Mordeth said:
[Edit 3] Give me one finger and I'll.... How about deep-water in combination with RoR?

It should work, but I have a level someone sent me ages ago that presents a nasty bug. But this is the kinda bug that can get fixed with some instinct, I sense it.

This is mainly for people that deal with node builders (cph & deep in short):
I'll need help in this domain.
For the time being, the ror subsectors detection is handled thru quite a horrible hack (supposition is made that all ror sectors have at least a seg facing any one of them present in the flat subsector, of course, there are many situations where this is not true - always with BSP because it avoids subsectors with different sectors).
However, this "horrible" hack could work given the node builder complies with the supposition. I have checked BSP and it seems the thing to work on is the isItConvex function. To be ror compliant I have the feeling it only needs to declare convex any subsector where contained concavities are due to segs that do not cross in term of height (that is seg1.floorheight>seg2.ceilingheight or the other way round).
It is certainly not that simple but may be a good start.

The Merovingian said:

Hey Joel, I love your sig actually.

It's another one from an e-mail my Mother sent me. She rules :) The same e-mail was the source for the one I use in that special place you and I visit on occasion. You know the one with the endless booze, hookers and...crap, I've said too much haven't I?

/me dives for cover as a bullet shatters my bedroom window

Mordeth said:

BTW, I tried sending James a bug report but his listed email bounced. So, here goes: in the current beta2 terraintypes have stopped working for deep-water sectors. This used to work in the previous beta. But, normal sectors with terraintype flats still work.

That probably means my mailbox was full ^_^ My hotmail filters have more or less stopped working.

This is a known issue though, and the change in beta 2 was deliberate because TT's never worked *properly* in deep water. They would trigger when you hit the REAL floor, which for very shallow deep water, works fine enough. But try it in something like BOOMEDIT.WAD and you find out fast that it looks pretty ridiculous. Hopefully this will be fixed in beta 3; I've been thinking about it a lot lately.

If it only took 8 lines of code to get *that* far, you have my complete and full blessing to develop this as far as you wish with the intentions of it being included in Eternity ^_^

Quasar said:

If it only took 8 lines of code to get *that* far, you have my complete and full blessing to develop this as far as you wish with the intentions of it being included in Eternity ^_^

rofl. It take some more lines of course something in the magnitude of 100/150 lines I guess. Involved a rewrite of the clipping system in R_BSP.c (which works prefectly but is opened to some optimisation imo), the addition of a z parameter to R_PointInSubsector (which means the z has to be added at each call and I admit I have hard time determining how to get the info for spawning and teleport - EDF to provide a z? - and also for cams). Some tests added into the sprite clipping code too. And aiming and collision detection.
But all the changes are quite straight forward. TerrainType shouldn't be an issue because they are associated with sectors iirc.
The real issue is having a node builder that delivers nodes that comply with the ror detection algorithm without breaking good old doom tricks (not sure if I'll be able to preserve all of them, so my guess is to add an empty ROR lump in the level data in order not to detect rors if the level is not ror). hmmm lotsa rors.
I should also note that there is theorically no limit to the number of floors on top of one another. To map floor over floor is simply a matter of putting sectors on top of eachothers (without splitting intersecting lines) which will undoubtedly involve some kinda option in editors or it'll get messy. Talking about that, I have stricly no clue how to handle the automap properly. Any idea is welcome as long as it's doable.

The Merovingian said:

Talking about that, I have stricly no clue how to handle the automap properly. Any idea is welcome as long as it's doable.

Do it Duke 3d / Shadow Warrior style, like, you'd need something that signals the automap that it's on a different floor, heh, but I'm sure you knew that :-P

Quasar said:
They would trigger when you hit the REAL floor, which for very shallow deep water, works fine enough. But try it in something like BOOMEDIT.WAD and you find out fast that it looks pretty ridiculous.

Huh? I've tried this with beta1 in my levels, in a combination of shallow deep-water (heh) and in really deep-water sectors and it worked very well. Eg. jumping into a very deep pool would cause the splash sound when touching the surface and a splash would form on the surface even when the player is sinking (er, falling... someone ought to fix that) to the bottom.

The thing I did find was that the terraintype is not always triggered by projectile impact (nearby), and never by nearby or direct hits by monster projectiles.

I should also note that there is theorically no limit to the number of floors on top of one another.

*SPOOGE!* :-)

Cool!

RRROOOAAARRR!

This'll be interesting.

Actually, I think you should look at the Duke 3d source and see how they handled fake RoR

BBG said:

Actually, I think you should look at the Duke 3d source and see how they handled fake RoR

Why? It's working already :P

Mordeth said:

Huh? I've tried this with beta1 in my levels, in a combination of shallow deep-water (heh) and in really deep-water sectors and it worked very well. Eg. jumping into a very deep pool would cause the splash sound when touching the surface and a splash would form on the surface even when the player is sinking (er, falling... someone ought to fix that) to the bottom.

I'm fairly sure you're either mistaken, or confused by what I mean. The splash object has always been spawned at the correct location. The splash only occured, however, when the object touches the REAL floor of the deep water sector. I tested this in several wads and that's exactly what happened. P_HitFloor is only called when a thing touches a real floor, and I have yet to devise a consistent and efficient method of detecting an object meeting a fake floor.

As for projectiles, normal projectiles NEVER cause TerrainType hits, I've explained this more than once. Rockets cause hits because *blast radii* cause TerrainType hits, not because the rocket missile hit the floor. Shoot a rocket on a wall over water 128 units or less from the floor and you will still see a splash -- its from the explosion. Bouncing projectiles also cause TerrainType hits when they touch the ground. This is because they bounce, rather than exploding, so the splash looks much more appropriate. It does not look very good, IMO, for an exploding projectile to cause a splash.

BBG said:

Actually, I think you should look at the Duke 3d source and see how they handled fake RoR

haha anyone could make that kind of fake ror in doom, all they used was a bunch of lame hacks

Quasar said:

As for projectiles, normal projectiles NEVER cause TerrainType hits, I've explained this more than once. Rockets cause hits because *blast radii* cause TerrainType hits, not because the rocket missile hit the floor. Shoot a rocket on a wall over water 128 units or less from the floor and you will still see a splash -- its from the explosion. Bouncing projectiles also cause TerrainType hits when they touch the ground. This is because they bounce, rather than exploding, so the splash looks much more appropriate. It does not look very good, IMO, for an exploding projectile to cause a splash.

why not give the level editor the option to flag something if they want it to makes a splash or not via dehacked or somesuch, because personally I think projectiles hitting the water and splashing makes more sense than them not splashing, but that's just me

BBG said:

Actually, I think you should look at the Duke 3d source and see how they handled fake RoR

They're two different types of engines, and handle levels differently, and like Sarge said it is just a bunch of hacks (ala ~65% of the whole engine).

Cyb said:

why not give the level editor the option to flag something if they want it to makes a splash or not via dehacked or somesuch, because personally I think projectiles hitting the water and splashing makes more sense than them not splashing, but that's just me

I agree. It makes more sense to me if the projectiles do make a splash as they hit the water, but also making this customizable via a flag of some sort would be the perfect comprimise.