
Moderator: GZDoom Developers
Nash wrote:Alright, thanks for the replies. Looking forward to see this progress! Good job!
Oh BTW I can't run the latest EXE:Execution could not continue.
Script error, "zdoom.pk3:compatibility.txt" line 390:
Expected '}', got 'DisablePushWindowCheck'.
mallo wrote:Noticed two more graphical glitches. The last one is from a custom map I've quickly made so I think I just built it wrong.
I guess I could've been more clear. Shooting the projectile through a portal works fine; impacting it just in front of a portal won't spawn rain on the other side of the portal, though, which is what one might logically expect. As in, instead of the rain spawning through the portal, they just spawn on the other side of the portal linedef. Man, this is confusing to explain. Does that make sense?ZZYZX wrote:http://i.imgur.com/MHA3sog.pnggamefreakdude wrote:An observation that broke immersion was that the powered-up Skull Rod didn't spawn rain on the other side of the portal as one might logically expect.
ZZYZX wrote:I've implemented portals on 2-sided linedefs, but xlat is still impossible due to buffer floor/ceiling leaking into portal from the other side in ZDoom (apparently this won't happen in Eternity).
Nash wrote:^ seems like the rain drops aren't being teleported through
Nash wrote:On a similar note, would it be worth it/possible to create a flag that would purposely exclude an actor from portal teleporting?
Blzut3 wrote:Hmm, I wonder if this is at all related to the reason Eternity requires that the "buffer sector" be a different lightlevel/texture. Forces the software renderer to stop flood filling and fixes mid texture bleeding?
else if (P_FindPortalEndPoint(line->linedef)
// [ZZ] added portal check above everything because typical portal line will cause all these checks to be done... (although not in translated Eternity maps, they have lightlevel changed)
|| backsector->lightlevel != frontsector->lightlevel
|| backsector->GetTexture(sector_t::floor) != frontsector->GetTexture(sector_t::floor)
|| backsector->GetTexture(sector_t::ceiling) != frontsector->GetTexture(sector_t::ceiling)
|| curline->sidedef->GetTexture(side_t::mid).isValid()
Gez wrote:Just a comment: in a few places I've seen you've hardcoded portal recursions to 5 (e.g. here). You should make it a CVAR, like r_mirror_recursions, or a #define constants, just so that it's guaranteed to stay the same value in all places.
Gez wrote: in the polyobject test, activating the door from the outside is hard. I only manage to do it at an angle.
Gez wrote:Finally, some HOMs
Major Cooke wrote:Hate to derail, but since we're on the topic of recursion limiting... would it be possible for you to make floor and ceiling portal recursion limits? Since we're talking about limiting it, that's one thing I've always wanted to get, where I tried making a chamber where the floor and ceiling had holes to let the player fall through and pop out from the ceiling, but it just caused a crash when looking through one.
Return to Closed Feature Suggestions
Users browsing this forum: No registered users and 1 guest