[0.6.0-452-gfc466849ce] Lighting isn't diminishing properly

[sinisterseed]

I figured as much, otherwise you'd have said there already was a way provided by the backend but needed to be simply activated in the games.

I've tried testing out the feature in MJ's build but um... I think I'm missing the obvious - because both commands return an "unknown command" in the console. Something to do with that .cmd file I take it?

[mjr4077au]

Just to be sure, you're not entering them with that osdcmd_ prefix from the underlying code? Also, is your Duke 3D in 1.5/RR compatibility mode?

In a clean start up of Duke 3D using the EDuke32 code, you should be able to just type 'printcoords' at the console and get an output that you can use again for 'warptocoords'.

Not sure how one of my .cmd launchers actually got in there but it's absolutely not necessary.

[sinisterseed]

Just to be sure, you're not entering them with that osdcmd_ prefix from the underlying code? Also, is your Duke 3D in 1.5/RR compatibility mode?

In a clean start up of Duke 3D using the EDuke32 code, you should be able to just type 'printcoords' at the console and get an output that you can use again for 'warptocoords'.

Not sure how one of my .cmd launchers actually got in there but it's absolutely not necessary.

Nah, user error, oops.

I was actually using your Coolie fix build, I thought it was the same but not really. It works correctly now, so if you can implement it in the other games too, this should be ready to go .

[mjr4077au]

I've done the other games, but Exhumed is being a shit because the player's Z position gets shifted in the game-side draw code before calling renderDrawRoomsQ16(). It might mean I need to have a game specific printcoords CCMD like I initially had for testing. It's extra code, but if I can't rely on the engine's coordinates to match the player's, then I'll have to. Will look further at it during the week.