Help with character F7

[edwardcarnby]

Hi all. I'm trying to translate kam - tpr into spanish. Setup.lib is done. But text.lib has the character F7 in a few position in the file. I've tried match this char using FF in the file, but when it shows the messages some of the words aren't spaced. Could you tell what's the meaning of this char? Thanks.

[Litude]

The 7F character is used as a work-around to ensure that the buggy automatic message formatting that TPR uses when creating new lines doesn't malfunction and end up creating an empty line into the middle of a message.

Basically, the 7F character is a non-breaking space, if you are familiar with HTML, it serves the same function as the   character. More to the point, putting a non-breaking space between two words makes it impossible for a line break to occur between those two words, which then can be used to bypass the empty lines in messages bug.

I've written into my notes that at 800x600 resolution, there has to be a space of at least 18 pixels between the buttons (go to, delete and close) and the message text. If the space is between 17-15 pixels (I'm not sure if 15 is the exact amount as I haven't written it down), an empty line will appear and the text will then continue on the next line. However if it's less than 15 (again, not completely sure on the amount), the message formatting will work correctly and there won't be an empty line.

These values vary when changing the resolution, making it a real pain to have the messages correctly formatted on all resolutions. For 1024x768, 1280x900 and 1280x1024 the minimum amount of space between the buttons and the text is 8 pixels. Again, I'm not sure about the interval wherein the formatting will mess up.

Usually, I just took a screenshot and then used paint to check how many pixels there were between the buttons. Ideally someone would check how many pixels a line is allowed to have at each resolution without glitching and also check the interval at which the glitching occurs. Then the width of all characters should be set into a database that a tool could read and it could then use this to automatically format the messages.

But the remakes are a lot more user friendly way to bypass this horrible bug.

EDIT: One thing I forgot to mention that might be worth noting is that the 7F character is actually one pixel smaller (7 pixels) than a normal space (8 pixels).

[Categoricus]

OK Litude, you were faster. I had to delete my post because of you. That's what I hate in geekness of forum administrators. Otherwise 7F is not an NBSP but a DELETE character. Cheers.

[edwardcarnby]

Then... I could write this char in another position of the file inside the same sentence (3 or 4 chars adjacents), or I have to respect the offset where it was written?.
Thanks.

[Litude]

The positioning of the 7F bytes are dependent on the contents of the string, so you shouldn't put them at the same position as where they used to be.

[eCarnby]

I tried write this char in adjacent spaces but no success. Could you give me a more detailed info and, if possible, an example?. I don't understand why this char is sometimes written only 7 chars next to the previous char.
Thanks.

[ecarnby]

What will happen if I make a program that fill all spaces (only text, not the beginning of the file) with 7F?. It will work?.

[Litude]

I think you've misunderstood the point of the character. I can't tell you where to position the 7F bytes more exactly than what I already told, the only way to position them correctly is to create your messages without any 7F bytes and then test them in-game.

If you're lucky, the message will work fine at all resolutions. If you're not so lucky, there will be an empty line somewhere in the message.

I urge you to not use any 7F bytes yet. Just finish the messages using normal spacing and then test them in-game. If you see an empty line in one of the messages that you didn't plan to have there, take a screenshot of it and post it here.

EDIT: What program are you using to translate? Something you created on your own, Lewin's editor or a hex editor?

[ecarnby]

I'm using Hex Workshop. The translation is already done, but I encountered this bug and I can't continue. The file setup.bin is translated and works correctly. I make little programs in language C to facilitate the compilation of the file.

[Lewin]

Don't feel obliged to use it, but I think you should at least know about my Text Editor: (LIB Decoder)
http://lewin.namsys.com.au/kam/index.php?go=knights_and_merchants_editor_map2bitmap
Scroll down and choose the latest version to download it.

[ecarnby]

Bad luck!. I noticed that file that I was editing was 1.58 and I patched the game to 1.6. I have to translate files again. I am trying now your editor. It seems good, but, in next versions, could you make the font bigger?. I have visual fatigue, and it would be worth for me.
Thanks.

[ecarnby]

Well. Let's see if I've understood you. I'm going to try an experiment in a resolution of 800x600. Generally, the length of the lines is 45 chars. According to your notes above, I'll write the lines with a maximum length of 42 chars. So, I substract 24 pixels per line. Do you think it will work?, or it has nothing to do with?.
Thanks.

[Litude]

You shouldn't use line breaks at all when formatting messages unless you want a new paragraph, depend on the auto-formatting instead (it's useful when it works without error). To avoid the problem with overflowing pixels, you need to use the 7F (non-breaking space) byte.

However like I said, first create the messages without any 7F bytes. When you test them in-game, screenshot any message you find with an out of place empty line and upload it so I can see it. This will make it easier for me to explain the function of the 7F byte.

[ecarnby]

Ok. When I test it, if fails, I'll take a screenshot for you. Other thing...
Is there any way for underlining characters?.

[Litude]

Nope, unfortunately underlining characters is not possible.