The new-formats experimental player does not create a "Replay" folder when trying to (automatically) save a replay, if no such directory is present in the player's folder. Instead the game crashes and has to be closed brutally, because it no longer reacts to any input.

This bug occurs in the new file-type version. I am haven't tried reproducing it in the released versions.

Steps to reproduce:
- Start NL from the IDE and load a level pack.
- Go to the preview screen and start the level.
- While the game switches between the preview screen and the game screen, click a few dozen times as fast as you can.
- Then wait a few seconds, while the screen remains black.

Then I get an EAccessViolation, because some code wants to read an already freed resource. This occurs in TGamePreviewScreen.CloseScreen, on the line
GameParams.NextScreen2 := gstPlay;or the one following it.

The call stack is very interesting, too:
TGamePreviewScreen.CloseScreen(gstPlay)
TGamePreviewScreen.Img_MouseDown($4A8448,mbLeft,[ssLeft],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft],429,264)
TGameBaseScreen.CloseScreen(gstText)
TGamePreviewScreen.CloseScreen(gstPlay)
TGamePreviewScreen.Img_MouseDown($4A8448,mbLeft,[ssLeft,ssDouble],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft,ssDouble],429,264,nil)
TCustomImage32.MouseDown(mbLeft,[ssLeft,ssDouble],429,264)
... [and several dozens of lines like these]

It seems that we try to make sense of mouse clicks, as if we were still in the previous menu. I am baffled how this could causes so many stacked MouseDown events in one thread, but here you are...

In the new-filetype version, there will be a default style with objects that are used if a given style does not provide any object sprites of this kind itself. In this thread I want to discuss what sprite and animation to use as the default for one-way arrows. Note that this issue is completely independant of any custom designs, like the ones found in the Fire style or many of namida's LemPlus styles.

Currently the default one-way arrows are the ones found in the Pillar or Marble style, which wobble around like this:

These arrows look nice if they are used on large areas, but have problems if placed next to each other or when used in very small areas.

Therefore I propose to change the default one-way arrow to one moving continuously and slowly in one direction:

It's not (yet) as smooth as if could be, but it doesn't constantly catch the player's attention by a too wild movement while still being animated and signalling some special area.

I also experimented with some SEGA-style arrows:

They look a lot nicer than the bland arrows above, but have disadvantages: The movement is still too fast for my taste. And more importantly, they cannot be recolored automatically to adapt to a given style. The uniform color of the arrows above changes depending on the color theme used by the primary style of the level, while these arrows always keep their reddish hue.
According to namida, they may change their color depending on the color theme of the primary style used in the level (in the same way that the sprites above are able to). I just have to use different shades of gray instead of pure white in the sprite. I will have to experiment, whether this automatic recoloring produced good results and will post them here, once I finish my experiments.
I have created them by hand (not automatic recoloring!) in two more colors:

My suggestion would be to add all three SEGA-type arrows to the SEGA style, rather than to the default style.

I realize that none of the arrows above is perfect yet, so would like to hear about your preferences, ideas and wishes.

If one has solved a level, a green check-mark appears next to the level title in the level selection menu. However this does not work, if the replay just runs through the mass replay checker. I suggest to change this.

The change would be useful in case one has played an old version of a level pack and a new one came out recently. Then one is only interested in playing those levels again where one's backroutes got fixed. Currently the only way to do so is to have the result file of the mass replay checker constantly open and compare for each single level, whether it got solved by the existing replay or not. Looking at the list of changed levels in the forum posts is slightly better, but is still not perfect. Not only does this still need a comparison with an external source, but it ignores the fact that only a different backroute got fixed that doesn't impact one's own replay. My suggestion above provides a very simple solution instead.

In the new editor, the screen start box is a pretty small squear with diagonals. As the screen size can now change and the screen start position is now defined via the center on the level screen, I can totally understand why this change was made. On the other hand, the current setup doesn't give me any indication how much of the level an average player (like me! ) will see resp. where the borders actually are. Here are two suggestions, how to adapt the screen position indicator:
A) Simply resize the current box to 320x160 pixels (keeping the drawn diagonals), in the expectation that players will usually see roughly this size, especially if they updated to V10.13 from an earlier player version.
B) Or go fancy: Read the user's player setting file, in particular window size and zoom factor/full-screen. Then use these values to determine the size (in pixels) of the level screen and adapt the screen start rectangle according to them.

Upon starting the lastest editor version, an empty level appears. The style of this level is however randomly chosen. I prefer instead, that the default style is always the first one in the style list.
The random choice is particularly annoying if a style with large background images is chosen, and the editor takes another second or so to load this background image and display it on the level area.

If one plays a level pack, the time taken to solve a level is displayed on the result screen. This information is however missing when one plays a single level. I suggest to add it.