last line of envelope in an old level no longer displays ingame

[ncrecc]

i made this level on 7/2/2022 (and edited it a bit on 7/4/2022 - i think it was still fine back then?)

000.level

(900 Bytes) Downloaded 745 times

in it, i included a yellow envelope, which you can easily collect from the start. it is of width 18 and height 3. the contents were this:

Code: Select all

they don't make
power shields like
they used to!

indeed, if you open this level in a hex editor (or just in notepad) you will see those exact 3 lines appear.

but in RnD, both ingame and in the editor, it displays like this:

rnd_envelope_message.png (2.65 KiB) Viewed 9232 times

the editor also treats the last line as being empty.

for ease in reproducing the issue, i readded the last line in the editor and saved the level. this version now correctly shows the last line, and is now 34 bytes larger:

000_repaired.level

(934 Bytes) Downloaded 755 times

[ncrecc]

a similar bug at some point hit level 007 of my levelset "ncrtorial" (included with the rocks'n'diamonds download). this time, there is not even a space where the lost line was.

rnd_envelope_message_2.png (23.98 KiB) Viewed 9230 times

the intended last line is "androids can do so.)" and is still present in the level file. you can verify it for yourself, since this is the version of the level currently distributed with rocks'n'diamonds.

the double-line break after the 2nd line also only exists ingame. in the level file, it is just 1 line break (2 LF characters until the next line of text). i think this can be explained with the line break being at the very end of the row, and thus wrapping around and causing a double-line break. come to think of it, maybe that explains this bug - line breaks immediately after the last column of an envelope were changed in how they were handled at some point, breaking envelopes in older levels.

[TheOnyxGuy]

Code: Select all

they don't make
power shields like
they used to!

Yeah, it's probably just a result of some envelope fixes that were done, like, several years ago, because, if I recall correctly, before that the envelopes were used to not skip to the next line if it reaches the end of the first one, so you just had to manually move to next line.

look i reply for you, just reply me

Dude, like, can you stop? I get that you're not that patient, but replying to some unrelated topics with completely off-topic messages just to draw attention? Like, why? If you desperately want a respond from someone, you could at least send them a private message. (one of buttons on top right of the forum) You don't have to chase someone around the entire forum just to get a response from them. I'm not sure if ncrecc is even interested in your topic, but I can't tell if that's true or not.

[Holger]

Thanks for the detailed description of this problem! I will have to check out what's going on there, and what might have changed between older versions and the last version regarding the described behavior.

It seems to have something to do with how R'n'D treats line breaks in envelopes, and maybe I have changed this in a way I shouldn't have.

Update: Just did a very quick test in the level editor, editing a tape text, typing from one line over to the next line, entering and/or deleting newlines, and got weird results (like having the typed text and the cursor in different lines while typing). However, I wasn't able to reproduce this a second time immediately after the first time it occured, but there seems to be a bug in handling overlong lines and newlines even in the current version.

I have to do some more tests here...

[Holger]

OK, I found the problem; it was introduced in version 4.3.2.3, in commit e567cb7f.

The intention of the change was to fix some envelope text area editing bugs in the level editor, where the cursor was displayed on a wrong position if lines exist in the text area that fill the complete line, immediately followed by a line break (like in your test level, and in the mentioned tutorial level). (Even worse, the editing problem can still be triggered by entering the "right" input. )

However, I still have no good solution how to handle this "special" case at the moment. But I will at least fix it so that existing envelope texts will be displayed properly again.

Will have to think about this a little bit more...

[Holger]

That one was a nasty and persistent bug!

It should finally be fixed now, and all existing envelope texts of older and newer levels should be displayed as they were intended again.