EE 3.33.03 Final Report

[Quasar]

This'll be the final report for the looooooooooooooooooong-delayed 3.33.03 release. I'm working on the menus slowly but surely, and soon they should be finished up.

SoM has worked on 3DMidTex clipping (AGAIN), and believes he has fixed yet more problems that my previous fixes caused. Let's hope it's really all fixed up now ^_^

Portals have a number of issues but none of them look like they are going to be addressed by this version (nor are we even certain what's causing some of the reported issues) -- so don't count on those being any different.

[SoM]

Quasar said:

Portals have a number of issues but none of them look like they are going to be addressed by this version (nor are we even certain what's causing some of the reported issues) -- so don't count on those being any different.

What issues do portals currently have? I know there are a lot of people who take issue because portals don't behave the way they think they should/want them to, but what actual issues are there still?

[Mordeth]

SoM said:
What issues do portals currently have? I know there are a lot of people who take issue because portals don't behave the way they think they should/want them to, but what actual issues are there still?

The fact that the player's viewpoint can never go below the floor height of a sector tagged with a floor portal without causing HOM, while it IS possible to get a player's viewpoint go above the ceiling height of a sector tagged with a ceiling portal. So, you can create a house-with-roof structure and a player has a perfect view of both the house below the roof ceiling as the roof itself (seen from above). But the equivalent is not possible with floor portals.

In the other thread you commented that you had disabled this behaviour for floor portals because it caused troubles for 2-way portals (two in-game sectors that act as the respective floor or ceiling portal for the other sector). Is it possible that you can undo this chance, and work on the solution for 2-way portals later, instead of the other way around? IMO removing the limit on floor portals is much more important (from a level design point, that is) than having perfect 2-way portals. Besides, 2-way portals can be faked, by just using a copy of the target sector :)

PS: very excited about the upcoming new release! Thanks guys!

[Quasar]

Looks like we're on different pages then :) I assumed there were still things on the drawing board that needed to be addressed, after all the comments kept flying around. I assume the Millennium's crew's issues have been fully addressed?

[Quasar]

Mordeth said:

Is it possible that you can undo this chance, and work on the solution for 2-way portals later, instead of the other way around? IMO removing the limit on floor portals is much more important (from a level design point, that is) than having perfect 2-way portals. Besides, 2-way portals can be faked, by just using a copy of the target sector :)

PS: very excited about the upcoming new release! Thanks guys!

Or lacking that, maybe make a separate type of anchored floor portal that has that behavior special-cased into it? I'm not the expert here though ;)

You're welcome too ^_^ Sorry about the ridiculous delays though. They are entirely the fault of my laziness and I am ashamed :P

[sargebaldy]

Yay! About time you got to working on the menus :P

[SoM]

Mordeth said:

The fact that the player's viewpoint can never go below the floor height of a sector tagged with a floor portal without causing HOM, while it IS possible to get a player's viewpoint go above the ceiling height of a sector tagged with a ceiling portal. So, you can create a house-with-roof structure and a player has a perfect view of both the house below the roof ceiling as the roof itself (seen from above). But the equivalent is not possible with floor portals.

Like I said, this isn't a bug. I was asking quasar` if there we still bugs that needed fixing (like crashes, graphic glitches, things that I didn't intend to happen) not behavior changes :P

I dunno, I guess I'll have to create different anchored portal linedef types. >_< The whole purpose of two-way portals is the player and mobjs are eventually going to be able to travel through them, as is the sound and automap. But seeing as how it's been quit a long time since the initial release of portals, I may just need to create a new set of anchored portal specials to accomplish this, and revert the current specials to the previous behavior.

In the other thread you commented that you had disabled this behaviour for floor portals because it caused troubles for 2-way portals (two in-game sectors that act as the respective floor or ceiling portal for the other sector). Is it possible that you can undo this chance, and work on the solution for 2-way portals later, instead of the other way around? IMO removing the limit on floor portals is much more important (from a level design point, that is) than having perfect 2-way portals. Besides, 2-way portals can be faked, by just using a copy of the target sector :)

Well, sorry I can't anticipate end-user activity with my apparently in-development features :P I'll talk to Quasar` about getting it set back to the old behavior.

PS: very excited about the upcoming new release! Thanks guys!

Hey, thanks for choosing it for the most anticipated megawad of all time :) I must admit that MordethTC and Millennium are some of the main reasons I still work on Eternity. That and all the cool ideas I have for doom editing ;)

Steve

[Mordeth]

Thanks for looking into it!

SoM said:
Hey, thanks for choosing it for the most anticipated megawad of all time :) I must admit that MordethTC and Millennium are some of the main reasons I still work on Eternity. That and all the cool ideas I have for doom editing ;)

Thanks, and I'm trying to live up to the expectations!

I fully expect people to come around and "see the light" once these two main projects are released, so Eternity will finally get the attention it deserves.

[SoM]

Ok, I have the portals rendering the way they were before for all existing portal types. The next portal specials I implement (two way) will not.

[Lüt]

Mordeth said:

Thanks, and I'm trying to live up to the expectations!

Ditto.

Hey SoM I'll try sending you some of the current maps next time I'm online. Or, you could just come over sometime.

Do you still visit #zdoom?

SoM said:

Ok, I have the portals rendering the way they were before for all existing portal types. The next portal specials I implement (two way) will not.

Wait, you didn't re-break the solid-structure fix, did you?

[SoM]

Lüt said:

Ditto.

Hey SoM I'll try sending you some of the current maps next time I'm online. Or, you could just come over sometime.

sounds like a plan. I'm laid off of work right now so after I move into my new apartment I'll have a lot of spare time.

Do you still visit #zdoom?
Wait, you didn't re-break the solid-structure fix, did you?

No, that still works just fine.

[Mordeth]

SoM FTW ! :)

[SoM]

Mordeth said:

SoM FTW ! :)

What?

[Lüt]

SoM said:

sounds like a plan. I'm laid off of work right now so after I move into my new apartment I'll have a lot of spare time.

Cool, I got fired a while back too so I've got enough time as well. Where are you moving to now?

SoM said:

No, that still works just fine.

Whee :D

SoM said:

What?

"Fuck the world", AFAIK.

[myk]

Lüt said:
"Fuck the world", AFAIK. [/B]

for teh wiki

[Mordeth]

SoM said:
What?

FTW = For Teh Win. Meaning you are awesome SoM :) Although I'll admit it's not funny if you haven't heard that term before.

[SoM]

Awwww. I'm not awesome, I just take requests ;)

[Quasar]

Just to make note of it here, I repaired a demo compatibility issue found by the PrBoom+ guys which involved a change Lee Killough made to the "fight-back" logic in MBF. He moved down the point where the MF_JUSTHIT flag is set on objects that have been attacked because he needed it to be below the point where an object's new target is set. However, he forgot that P_SetMobjState will call the codepointer of the object's seestate immediately, and if that pointer is or calls A_Chase, as it is nearly 100% of the time, then the MF_JUSTHIT flag NOT being set before that call will result in differing monster behavior.

I believe this bug has been manifest in all MBF-descended ports as a seeming reluctance of monsters to fight each other. I've always noticed it can be very frustrating to get monsters to fight back against friends at times, much more than it should be, and I believe this was due to this problem. So in addition to affecting demo comp, it also created a gameplay problem. I believe this is now fixed.

[Grazza]

The only demos where it clearly led to a desync were those that featured a monster with that flag set via dehacked (the Samurai Statue in Hacx). Is there any firm evidence that it causes any difference otherwise? MBF's enhanced monster AI (if enabled) will presumably have an impact on the monsters' tendency to infight, but that's a separate matter.

It was obviously worth fixing, but it may only be relevant in a minute proportion of cases. If it were relevant generally, there would surely have been a mass of hitherto unexplained desyncs.

[Quasar]

Hmm you may be right. I'll take another look at the code for the MF_JUSTHIT flag. I just assumed that since it *is* used in A_Chase, it must have some impact on monster AI related to maintenance of their target or when they decide to attack. Clearly, if setting the flag via DeHackEd can make a difference, then the timing of setting it in the game may still be important in some circumstances. Better safe than sorry, in any case.

[Grazza]

Actually I seem to have got myself quite confused on this. "Steps before attack" is MF_JUSTATTACKED, whereas MF_JUSTHIT is "In pain". And the three demos that desync without this fix (hx07-932.lmp, hx11-631.lmp, and hx17-459.lmp in hxhmplmp.zip) don't feature the Samurai Statue either.

Still, it does seem to be a problem that only arises in very specific circumstances, and probably related to dehacked stuff. It's not obvious what the common link between these three desyncs is (other than the fact that it is to do with MF_JUSTHIT) - maybe Andrey can explain.

Sorry for the error. I've spent way too long checking these Hacx demos and trying to work out what the hell was going wrong with them (there were four separate issues causing problems...) and it all must have become a bit muddled in my mind.

[Quasar]

JUSTATTACKED is used to regulate the rate of monster attacks in normal gameplay. Monsters ignore this flag in Nightmare mode however, which is why they attack like turrets.

JUSTHIT is set on a thing in P_DamageMobj when it has been damaged. I've never memorized what exactly it does, but I know it has an impact on logic in the A_Chase codepointer, and that must be where the demo desync factor comes in at. There's nothing else sync-critical after the flag is set that requires it to be set or not except the call to P_SetMobjState.

[Quasar]

New progress.

Centered menus:
http://eternity.mancubus.net/pics/menu_centered.png

Small menu pointer:
http://eternity.mancubus.net/pics/menuptr.png

The latter feature has been requested for ages but took me a while to figure out exactly how I should do it. It'll help out with those TCs that change the font into a color range that can't be changed by the default colrng tables from BOOM.