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