Another known bug since years:

Originally the SHATTER9 objects must have been destroyed by sword-wielding enemies (SKELETON or KNIGHTS_TEMPLAR) only, but at the moment you can simply destroy them by any of your weapons. :(

And one more old bug:
Saving game during key/puzzle actions is a game killer.

The shatter9 was the last shatter static in the serie. Since from many years it's possible changing the first and last shatter serie, have you tried if now the last shatter you set, is that having that feature about to be destroyed only by sword-wielding enemies?

While is lara placing the puzzle item?

Yes, if you save in the meantime, the game will detect it as "done", so if you load it, Lara will finish the movement, but nothing happens. A very old bug.

Do you mean the Customize= CUST_SHATTER_RANGE, 50, 59 command?
If so, even with or without that the shatter9 function doesn't seem to work. :/ I mean the sword-wielding enemies will destroy the shatters, but you could also shoot the shatters by any of your weapons.

If this is a bug that can't be fixed any other way, how about disabling load/save during the animations? :ponder:

You are right. :)
But perhaps we can get away with it even without this workaround at last.
Just imagine players hitting F5 during the animaton, not understanding why the save isn't work...

This means that the problem is that the trigger, linked with that puzzle, will be not executed?

Yeah, that was my first thought, in spite it could be weird to see in game, it could be only solution. I was already figuring how this problem worked and it's not easy saving intermediate data in this situation. :confused:

Now I understand: the shatter9 was a special shatter, while I treated it like a common shatter.
I've already found a fixing, it will be available in next update.
About this, I regret to inform you that I have the flu. Ok it's not a great news but I feel not so fine and so my replies will have some delay in these days. :(

Well, okay, then we will solve it with a GlobalTrigger workaround, if it is so complicated. :D

Yes, that is the point. ;)

No problem. Get better. :D

Thank you so much for your continuous support!
Get well soon! :hug:

Hey Paolone,
I found another gamebreaking issue.

The condition "Creature. <#>Moveable with (E)degrees of view is able to see Lara" is broken in newest TRNG version. It worked perfectly fine with the old TRNG version (before plugin update).

For instance, when I trigger a 'frozen" ennemy the condition's true even if lara sneaks behind him. As soon as lara is perfectly behind the ennemy (exactly 180 degrees) the condition returns true. I send you a PM with a little video clip illustrating the issue.

Get well soon :/

There's a bug with the FROGMAN slot. He swims about fine, tracking Lara and trying to line up with her vertical axis. The problem is when he is lined up he jitters up and down. I can swim away up or down and he's fine while he ascends or decends to match, but as soon as he's lined up the jitters return.


(yeah he looks quite different and I've changed his animations so he stops rather than fires at her, but the problem is on the default one)

Is there any solution to this? They are quite prevalent.

^
I'd also like to add some other things regarding the frogman:

• Lara's harpoons fly below him but still hurt him.
  It works, but it sure does look very odd that he gets killed without actually being hit.
• His harpoons don't hurt Lara a lot.
  Haven't tried Enemy= on him yet though, so that might just fix this issue.

I'm also experiencing that jitter, so that bug is confirmed.

Paolone, any news about this issue ? :(
Have you received my PM ?

It is worse.
I mean, I just tried to change the distance fog (!) color with flipeffect (F224). The game crashed. So it is not a fog bulb color bug.

I got this error message:

Note:
However, the distance fog color has changed, 1 moment before the crash.

Can anyone verify if shooting the pistols while in the same room as an/multiple opened SARCOPHAGUS that didn't contain any items crashes the game in the latest TRNG? It's happening in one of my levels.

I cannot confirm it, sorry... :o

I had the same bug when I ripped the SARCOPHAGUS from the TR4 level, the object from the cleopal WAD works fine though.

__________________

If you use NewSoundEngine= DISABLED in the latest TRNG version (really since 1.3.0.0) the game will crash after a few minutes. I think it might happen when the game tries to loop the ambience track but I'm not 100% sure.

Not really a bug but in TR4 you could move pushables over pickups and nullmeshes but in TRNG that's not possible anymore. If you set the "clear body" flag for the items, Lara can move pushables over those objects but saving and reloading the game will remove them from the game.
It would be nice if the TR4 behaviour could be restored.

I was sure I read somewhere there was an OCB or something like that to make the pushables able to be pushed above items, but I can't find it in the Reference tab. :ponder:

Not an OCB, but a flag, FFS_PUSHABLE_CAN_OVERSTEP_IT, which is used in the Customize= script. Quoting the description from the reference:
;)

Well, the pushable issue is fixed then :D

I don't know how old bug is this but I can abort the little beetle emission if I save the game when the emission is being performed, and then load that savegame.
After that, even if the beetle trigger is One Shot (as it should be!) I am able to re-activate the trigger, so the emission will continue.

Thank you for the notice AkyV, I'll remember it when playing a game with little beetles in it. I hate them. :D
(not digusted, scared or anything, they're just extremly annoying because they're hard to avoid and can drain your health very fast)

Would love to see enemies not being blocked in an unflipped room by enemy boxes which are in the flipped room. This seems to be a bug which seems to be hard to avoid in an elegant manner.

I don't know, Elio. I can't confirm it. Perhaps it is only a very specified situation. :ponder:
What if you try it in another (test) project, perhaps with other room properties/sizes, other enemies?

To me it's probably not a bug but a "limitation" due to how boxes are calculated.

Flipmap rooms are placed somewhere else in the map before they're triggered, they are not really connected (that's also why there are visible seams with the lighting at the connection of a flipped room and a normal room), so probably the boxes are generated separately, not taking care of the surrounding rooms when the converter computes boxes for the flipmap room, unlike when it probably does with the normal rooms.
I may be completely wrong, I find boxes quite hard to imagine without a visible map of what they look like. There were some pretty good explanations on boxes and zones by MontyTRC in the Tomb Editor thread, maybe it/he could shed some light on this topic? Maybe the problem indeed lies in the way boxes are generated and this way it's not the engine that could correct this problem, but the editor.

Maybe. I'm absolutely not sure. Kay? :pi:

I have a question: did the last TRNG update change something in the way TRNG uses keyboard language? I am quite positive that either Room Editor or NG Center changes my keyboard language from PL to ENG. Since I'm on Windows 10 I cannot just delete ENG keyboard anymore, so I have to look for other ways to fix it.

Hello there,
I found a bug about the frogman:
If you put him in a dry room he doesn't shoot.
Fixing this bug would allow us to create flying shooting enemies, for example Natla :)

Trng doesn't perform any change in keyaboard language.
That new [ENG] change borns from some windows10 update I believe. I have yet seen it appearing suddenly and I cann't remove it.

I have neither thought to check if room is really flooded.
I could try to fix the problem about the shooting.
By the way, I see that also submarine works in same way.

Speaking of the diver enemy, wouldn't it be interesting if he could get in and out of the water? :ponder:
Then again, I guess him walking with his flippers on would be odd...

The submarine can shoot when flies, with a script line :)
Water enemies (hammerhead and frogman) could also drop when die, if they are in a dry room, instead of go up like a balloon :D

The previous bug, where the game would crash when it tried to loop an audio track with the new Sound Engine disabled, has been fixed but it seems another bug was introduced :(
Now the game crashes when you trigger a new audio track. It seems to be random, sometimes I can trigger all of the audio tracks in a level without any crashes, but sometimes it crashes when I trigger the first one.

I have a heavy trigger F145 (ItemGroup. Activate <&>ItemGroup with (E)Timer value) triggered when a flyby passes onto it. The trigger is in a flipmap room. The cameras are in the normal room obviously.
Before the update (can't tell which one, because I went straight from 1.2.2.7+ to 1.3.0.7 with that level), it was working fine: the doors opened. Now, they still open, but close just after they're opened.

I haven't tested another situation yet with that trigger, but it was working fine before the update and I haven't touched that setup, so I suspect a bug from that trigger.

Flame Emitter OCB:

It is not quite true. The source of the flame is different. -2: the nullmesh, -7: the edge of the sector.

^
Not sure if we should call that a bug.
It can be usefull to have a flame start at the edge of a sector instead of always in the middle, where the nullmesh is.

So perhaps this could be left the way it is? :ponder:

I wrote that so he can fix the description it in the Reference list. ;)
It is a reference bug. :)