Actor lose their dynamic lighting when teleported

[Jekyll Grim Payne]

To me it sounds kinda crazy, but... Here's the deal: I have a multistorey building that uses some teleporters on the stairs between floors to make mapping simpler (you know, the classic trick). The problem is that in one of such places there's a room that can be seen both from the position before teleporting and after. Thus I just dupliacted this room (and some adjacant area), gave the same tag to all the sectors and used TeleportInSector function.

Looks great: all objects, enemies that are following you and stuff gets teleported along with the player, thus you barely notice teleportation. BUT! When teleporting some of the light sources lose their dynamic lighting (bound to them, obviously, through GLDEFS).

There are 4 absolutely similar (!) light sources in the room, they are all positioned in the same sector (!) but certain of them (and only certain ones) lose their dynamic lighting, while others don't. I tried deleting and putting them there again or moving them away slightly -- no effect.

I thought it might have had something to do with height difference (it was different in these room-twins; I use Destination Spot Z, No Gravity), but I tried to temporary change the heights to be the same, but it was no use. I also checked if the light sources were stuck in the walls, but they weren't.

Here's the image so that you can understand it clearly (I hope):


So, you see, you go down the central stairs from the 3rd floor to the 2nd floor (they do not really overlap anywhere, so no teleporting here). The 1st floor is positioned below the 3rd floor, thus only the stairs from the 2nd floor to the 1st floor go under 3d-floor 3rd floor. You can see 'fake' stairs from 2nd to the 1st floor, when you cross the teleporting lines before them you and all other objects there get teleported to the 'fake' 2nd floor so that you can enter 'real' stairs to the 1st floor.

The 2nd floor hallways on the right and on the left both consist of 2 sectors which are joined between them, thus though there are 2 teleporting lines on each floor, each pair of lines belongs to the same sector. BUT! Here's the thing!

If I go through the teleporting line on the right (considering the image, on the right, i.e. eastern), the south-eastern and north-western lamps lose their lighting (it simply disappears, while the lamps are teleported OK). If I cross the western teleporting line, the south-eastern lamp loses dynamic lighting.

The south-western lamp never loses the lighting. However, both south lamps are in the same sector! Yet if I position any other kind of object with dynamic lighting near the south-eastern lamp, it will ALSO lose its dynamic lighting when teleported!

I should also point out that when I cross the teleporting lines back, the dynamic lights always show again. They are lost when teleported first time, but not when teleported back.

This drives me crazy. I even thought that maybe the problem is that dynamic lightings are positioned close to walls, that if I give them more space, they will teleport OK -- but I tried it and it's not so.

I would solve the problem by teleporting everything BUT lamps, unfortunately I can't do it: I use 0 tag for TeleportInSector (meaning 'teleport everything'), and giving +NOTELEPORT flag to lamps is ineffective: the TeleportInSector function still teleports them.

[Enjay]

I wonder if it is something to do with this observation? If you look at an actor that has a dynamic light attached using IDDT IDDT on the automap, you can see two triangles in the actors position. This is especially obvious with actors that temporarily have a light. eg when a trooper fires, he gets a second triangle in his position for a second or so when he fires. Perhaps if the lights are being handled as separate actors something is getting confused when the main actor teleports?

[Jekyll Grim Payne]

I wonder if it is something to do with this observation? If you look at an actor that has a dynamic light attached using IDDT IDDT on the automap, you can see two triangles in the actors position. This is especially obvious with actors that temporarily have a light. eg when a trooper fires, he gets a second triangle in his position for a second or so when he fires. Perhaps if the lights are being handled as separate actors something is getting confused when the main actor teleports?

Good point, but I doubt it as I checked it with automap on and IDDT: ALL triangles actually stay intact when I teleport but somehow dynamic lighting doesn't show though.

Also, I have a small room that is further to the west (not seen in the image) with two light sources in it: they also lose their lighting when teleported, though you don't see it (but I checked it by entering the 'fake' room with NOCLIP so that I don't activate the teleporting line).

Besides, if that was the case, why would only certain light sources disappear when crossing only certain teleport lines?

I also tried using ActorEntersSector thing and bind the teleporting scripts to it, however the effect was absolutely the same (when I entered the eastern hallway the south-eastern and north-western lamps lost light, when I entered the western hallway the south-eastern lamp lost light -- even though the hallways belong to the same sector).

[Gez]

There are a few invisible issues with dynamic light actors, they don't always disappear when they stop emitting lights. I've noticed for example on Heretic E1M1, after picking up the yellow key, that the key glow would stay behind. You can only detect that with the automap cheat of course, since it no longer emits light, but it's there. This happens quite often, but not always.

[Jekyll Grim Payne]

Well, in my case it happens always and always in the same way. Seems to be some kind of logic here, which I can't grasp.
Besides, why doesn't +NOTELEPORT affect the TeleportInSector function, I wonder?


BTW, when I cross the teleporting lines back, the dynamic lights always show again. They are lost when teleported first time, but not when teleported back.


UPD:
Well, I kind of solved the problem by creating small sectors around the light sources and giving the sectors 0 tag thus making them not participate in the teleporting at all, then I simply created twin light sources at the same places in the destination area. However, the essence of the mentioned bug still leaves me curious...

[FDARI]

Event flow as I see it:

Actors with lights are placed (original location) in one sector.
Actors teleport. Actors are now in another sector. Some lights do not function correctly (consistent failure).
Actors teleport back. Actors are now in original sector. All lights function correctly.

What this does not show conclusively is that the teleportation event causes the lighting failure. Have you tested placing all actors directly in the second sector? That and a few teleports would show rather clearly whether the relocation or the sector causes failure.

Also, you could test alternate destinations and methods of movement. (Other teleport methods, and pushing actors...)

I don't know anything about the underlying system, so my suggestions are all about creating observable phenomena for further guesswork.

[Jekyll Grim Payne]

As I wrote in my edited message above, I found some kind of a solution, though this is just an alternative way. However...

Have you tested placing all actors directly in the second sector?

What do you actually mean by 'directly placing'? If you mean just testing whether ANY dynamic lights would work in the destination sector at all, then yes, there's nothing wrong with the destination area. I originally hadn't planned this massive teleportation at all, I simply had a twin area with similar environment, the actors were just duplicated to make it look the same, and everything worked OK. I implemented TeleportInSector so that all objects including the monsters that might be following the player don't disappear when he crosses the teleporting line and continue to follow him as if the place is still the same.

But if by directly placing you mean something like Thing_Move (or whatever it is written like), then I haven't tried it... It would be very inconveniet anyway, as this function doesn't allow to move a bunch of things keeping their positions the same according to relative spots.

Besides, if the problem was in the sector, I still just can't wrap my head around the fact that the south-western lamp is NEVER buggy, it always teleported with its light intact, no matter what line I crossed, however at the same time it is at the _same_ sector as the south-eastern lamp.... It simply seems that the 'eastern part' of the sector, so to say, is buggy, while the 'western part' is not, but this just sounds crazy.


Now I'm partly back to my original idea where the light sources are duplicated, while everything else gets teleported. This is not very nice though, because the bug may occur not only with static light sources but with things like illuminating projectiles, etc. (in my wad you'll be able to drop a kind of a lamp on the floor so that it shines, and I tested it and in this case this lamp's dynamic light also disappears if the lamp is dropped at the eastern part of that sector and then teleported).


P.S. Actually I was wrong saying that all the light sources are positioned at the same sector. As you can see in the screenshot, the two northern are in the same sector and the two southern are in the same sector, not all of them.


P.P.S. As testing with IDDT proved that the dynamic lighting 'things' themselves actually ARE teleported, I assume that the problem is in the engine: the game doesn't fail to move the lights, it fails to draw them on the walls. The trick, however, is that the bug is consistent and has a certain logic... Yet it makes me wonder if this should be announced as a GZDoom bug.

[Enjay]

The trick, however, is that the bug is consistent and has a certain logic... Yet it makes me wonder if this should be announced as a GZDoom bug.

It wouldn't do any harm to make up a quick small demo level and post it on the GZdoom forum with a description of the problem.

[Jekyll Grim Payne]

The trick, however, is that the bug is consistent and has a certain logic... Yet it makes me wonder if this should be announced as a GZDoom bug.

It wouldn't do any harm to make up a quick small demo level and post it on the GZdoom forum with a description of the problem.

Good point. I'll do that (and this way I'll also check whether this bug appears in any similar situation or this is just my bad luck).