Grimrock

Beta-1.2.11 has been released. This build is mostly a hotfix for a couple of annoying bugs.

If you think you have found a bug, please check that the bug is not in the Known Issues list before reporting (see below).

Thanks to everybody for relentless testing! Have fun!

Changes since beta-1.2.10:
- added scrollbar to inspector
- bug fix: destroyed blockages result in "table index is nil" crash when map is unloaded or preview is stopped
- bug fix: after pressing Alt Gr it is no longer possible to select any entity on the map

Known Issues:
- textures & sound are not reloaded even if the project is reloaded (the editor has to be restarted)
- Steam think grimrock process is still running if web browser was launched by selecting Help from menu before shutting down the game
- clicking "resume" from the pause menu throws away the item on the mouse cursor
- when opening the automap in the small preview window, the text names of the levels are HUGE
- pasting text with newline characters to a singleline textbox causes part of the text to disappear (single line text boxes don't filter newlines)
- dungeon description box is tiny
- if you give setMouseItem() an item that's placed already somewhere on the level, and then player tries to place that item on the ground, the game crashes "item is already placed".
- cloned Orb of Radiance does not glow
- cloned Uggardian does not have the flame effect
- cloned cube crashes the editor
- setMouseItem(spawn("dagger")) and variants do not work from console (scripts work ok)

3 cheers for scroll bar in the inspector!

Has the doors of the temple_door_iron always come through the walls? O.o I mean if you place it directly on the straight wall instead of in the corridor, you can see the doors in the adjacent walls as they open. I thought that they haven't acted like that pre 1.2.10 but I might be wrong.

they did act like that before, it's even in my videos! There are places in the original game (at least one) where they are flat near a wall and don't have any problem, so I guess it's a bug that will need to be fixed

It's not a bug. Flip the facing of the door 180 degrees and it should work. There is a slight offset in the doors to avoid clipping with walls but it requires correct facing.

A feature I'd like to see in the editor is:-

A placed entity list...I kinda forget where I hid those leather pants, did I put them in, didn't I....jeez my memory

I think you know what I mean guys, it'd be very helpful !!

Komag wrote:they did act like that before, it's even in my videos! There are places in the original game (at least one) where they are flat near a wall and don't have any problem, so I guess it's a bug that will need to be fixed

This bug is based on the placing / facing. The door has to "face" away from the player when going into a tunnel, then the graphics will look fine.
Edit: Damn, Ninja'd by Petri.


On a different note:
I noticed a kind of strange behaviour with timers. When you connect a pressure plate with a timer that has a longer interval (e.g. 5 sec) and set the plate to toggle the timer (best used with the "any" event) then the timer will continue from the time it was toggled off. If you use two connectors with activate/deactivate, the deactivation will also reset the timer to its initial interval. Intended behaviour?

Montis wrote:I noticed a kind of strange behaviour with timers. When you connect a pressure plate with a timer that has a longer interval (e.g. 5 sec) and set the plate to toggle the timer (best used with the "any" event) then the timer will continue from the time it was toggled off. If you use two connectors with activate/deactivate, the deactivation will also reset the timer to its initial interval. Intended behaviour?

Good catch! Activating a timer with toggle() and activate() should have the same effect but clearly it doesn't. I need to think about this a bit. I'm leaning towards removing the side-effect that resets timer's value when it is activated, and adding a new method for manually resetting timer. Any comments which behavior would be logical?

I had always assumed that if you stop the timer before it's finished that it would reset. I think "pausing" the timer is the more unusual thing to do. Maybe could be a [] checkbox for "reset upon deactivation"

I'm not quite sure but having activate, deactivate AND reset would probably leave open the most possibilities.
Although this could screw some existing scripts.

So I would suggest leaving everything as is and adding reset and continue methods for those that want to use it, what do you think?

Or alternatively do the reset on deactivate and add a pause method. Or everything combined