www.tombraiderforums.com

www.tombraiderforums.com (https://www.tombraiderforums.com/index.php)
-   Next Generation Level Editor (https://www.tombraiderforums.com/forumdisplay.php?f=40)
-   -   TRNG - Bugs & Limitations Thread (https://www.tombraiderforums.com/showthread.php?t=165980)

-Roli- 29-01-17 21:12

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. :(

AkyV 30-01-17 09:42

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

Paolone 30-01-17 12:33

Quote:

Originally Posted by -Roli- (Post 7706863)
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. :(

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?

Paolone 30-01-17 12:34

Quote:

Originally Posted by AkyV (Post 7706979)
And one more old bug:
Saving game during key/puzzle actions is a game killer.

While is lara placing the puzzle item?

AkyV 30-01-17 12:49

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.

-Roli- 30-01-17 14:50

Quote:

Originally Posted by Paolone (Post 7707015)
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?

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.

Titak 30-01-17 15:52

Quote:

Originally Posted by AkyV (Post 7707022)
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.

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

AkyV 30-01-17 16:02

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...

Paolone 01-02-17 14:38

Quote:

Originally Posted by AkyV (Post 7707022)
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.

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

Paolone 01-02-17 14:41

Quote:

Originally Posted by Titak (Post 7707075)
If this is a bug that can't be fixed any other way, how about disabling load/save during the animations? :ponder:

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:

Paolone 01-02-17 14:46

Quote:

Originally Posted by -Roli- (Post 7707064)
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.

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. :(

AkyV 01-02-17 14:53

Quote:

Originally Posted by Paolone (Post 7707919)
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:

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

Quote:

This means that the problem is that the trigger, linked with that puzzle, will be not executed?
Yes, that is the point. ;)

Quote:

Originally Posted by Paolone (Post 7707923)
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. :(

No problem. Get better. :D

-Roli- 01-02-17 18:00

Quote:

Originally Posted by Paolone (Post 7707923)
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. :(

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

Nicklander 01-02-17 20:17

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 :/

Boobandie 01-02-17 20:54

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.

Titak 01-02-17 21:18

^
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.

Nicklander 11-02-17 21:48

Quote:

Originally Posted by Nicklander (Post 7708082)
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 :/

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

AkyV 12-02-17 11:14

Quote:

Originally Posted by Delta (Post 7706352)
with 1.3.0.4 (and previous versions) the fog is always black, regardless of how i set the F28 ...

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:

Code:

CRASH OFFSET: 0x2B420A7  (Outside of all tomb4, trng or plugin engines. Probably windows APIs)
Note:
However, the distance fog color has changed, 1 moment before the crash.

Boobandie 22-02-17 09:19

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.

AkyV 22-02-17 10:30

I cannot confirm it, sorry... :o

AODfan 23-02-17 16:08

Quote:

Originally Posted by Boobandie (Post 7715287)
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 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.

Joey79100 23-02-17 17:17

Quote:

Originally Posted by AODfan (Post 7715703)
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:

Krystian 23-02-17 19:06

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

Used into Customize=CUST_SLOT_FLAGS command.
When you wish that a moveable (usually a little pickups) was oversteppable from pushable objects, you can add this flag for the wished pickup items.
Example:

Customize=CUST_SLOT_FLAGS, LASERSIGHT_ITEM, FFS_PUSHABLE_CAN_OVERSTEP_IT

With above command list the pushable object will be able to pass over the lasersight item on the floor.
;)

AODfan 24-02-17 13:57

Well, the pushable issue is fixed then :D

AkyV 13-03-17 13:34

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.

Joey79100 13-03-17 13:48

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)

Laras Boyfr. 13-03-17 15:26

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.

AkyV 13-03-17 16:04

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?

Joey79100 13-03-17 19:37

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:

Caesum 19-03-17 14:20

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.

LGG_PRODUCTION 09-04-17 20:58

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 :)

Paolone 13-04-17 11:49

Quote:

Originally Posted by Caesum (Post 7723223)
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.

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.

Paolone 13-04-17 11:50

Quote:

Originally Posted by LGG_PRODUCTION (Post 7730379)
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 :)

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.

Titak 13-04-17 14:25

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...

LGG_PRODUCTION 13-04-17 17:41

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

AODfan 20-04-17 11:17

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.

Joey79100 21-04-17 15:59

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.

AkyV 23-04-17 23:56

Flame Emitter OCB:

Quote:

-2 or -7: it shots continuosly the flames in horizontal, following the direction of the cone. Apparently these two ocb values have the same result.
It is not quite true. The source of the flame is different. -2: the nullmesh, -7: the edge of the sector.

Titak 24-04-17 09:41

^
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:

AkyV 24-04-17 10:45

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


All times are GMT. The time now is 20:34.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.