You can clone it and then either tell me where your mirror is when you're done (any Git host will do), or just send me the translation file as an email attachment or something if you're not comfortable using Git.

It's standard gettext. From data/locale in the terminal, do:

msginit --locale=de --input=retux.pot

Then edit de.po replacing each msgstr string with a translation (but do not change the msgid strings). If you want to test, run the "build.py" script in that directory and, if German is not your system language, run ReTux with the "-l de" command-line option.

I'm allmost done with the translation. Now I'm not sure if I should translate the messages that are past to stout/the log as well or would it be better to leave them like they are. I guess english would better for you if people like to send you a bug report and add their logfile to it.

themightyglider {l Wrote}:I'm allmost done with the translation. Now I'm not sure if I should translate the messages that are past to stout/the log as well or would it be better to leave them like they are. I guess english would better for you if people like to send you a bug report and add their logfile to it.

Personally I think debug info intended to the upstream developers should always stay in English. Even the translation of tools like git make them harder to understand IMO, I wish mine were in English and not in French (but at the same time I'm not annoyed enough to rm -rf git's fr.mo, so I guess it's not that bad ).

If onpon4 agrees, the debug messages should likely be removed from the translation catalog to avoid translators spending time on them.

Edit: Well judging by the above it seems debug strings are not in the template in the first place.

Akien {l Wrote}:Edit: Well judging by the above it seems debug strings are not in the template in the first place.

Correct.

themightyglider was probably talking about the strings that are printed to the terminal as the game starts, but these are not there for debugging purposes, rather they are there so you can see that the game is starting up properly.

Or he could have been talking about the messages that pop up in-game if an error occurs, explaining to the user that an error occurred and showing the error. The error itself is controlled by Python, though, and that explanatory text absolutely should be translated so that the user understands what's going on. These are again not for debugging purposes, but rather they are there to tell the user that a level set is broken.

When I've tried to remap the keys, it removed arrow keys and I could no longer use them.

If you unset an arrow key as a control, you can no longer use it in the menus. This is deliberate; otherwise, you could have keys doing multiple things at once.

The control config menu never allows you to unset the last keyboard control, so you can always navigate the menu regardless of what you do.

Tux is very hard to control.

Subjective, and I personally disagree. But feel free to publish your modified version.

No 4:3 mode? I have black bars in fullscreen.

ReTux uses a fixed aspect ratio. I chose 16:9 because that is more common than 4:3. It would be possible to distort the picture and stretch it to 4:3, but I don't think that's desirable. If you would rather distort the image, set the "scale_proportional" argument in the call to "Game" (right below where it prints "Initializing game system") to False.

I'd load the level when the player starts it, otherwise navigating the map is laggy.

The level needs to be loaded to know the name of the level. This is why pre-loading is attempted when you start the game.

No way to change settings during the gameplay.

In the case of fullscreen, this is deliberate; switching to fullscreen mid-game can lock up X systems due what I assume is an SDL bug, and it would be undesirable to make the player lose progress because of that. In any case, the game saves every level, so it makes little practical difference.

I ragequit at the 2nd castle.

Really? My younger brothers didn't have a particular problem with that one to my recollection.

onpon4 {l Wrote}:If you unset an arrow key as a control, you can no longer use it in the menus. This is deliberate; otherwise, you could have keys doing multiple things at once.

The control config menu never allows you to unset the last keyboard control, so you can always navigate the menu regardless of what you do.

I'm not sure why keys doing multiple things at once is related; to me they are separate problems. You should consider having multiple ways for driving the menus. For example, in C-Dogs SDL, you can drive the menus using: player 1 controls, arrow keys, mouse, or joystick 1. And yes, even if you set player 1 controls to the arrows for example, it still works, because the game just loops over all the possible menu controls to determine whether up was pressed or whatever.

onpon4 {l Wrote}:The level needs to be loaded to know the name of the level. This is why pre-loading is attempted when you start the game.

You can reduce the amount of loading by separating the level metadata from the rest of the level. Then you can preload all the metadata required for the map and have it lag-free.

onpon4 {l Wrote}:

No way to change settings during the gameplay.

In the case of fullscreen, this is deliberate; switching to fullscreen mid-game can lock up X systems due what I assume is an SDL bug, and it would be undesirable to make the player lose progress because of that. In any case, the game saves every level, so it makes little practical difference.

I've never seen this with SDL2 + win/macOS, so either it's an X bug or SDL 1 bug. If it's the former you should allow changing it for non-X ports. Being able to change options mid-game makes things much less annoying.

onpon4 {l Wrote}:The control config menu never allows you to unset the last keyboard control, so you can always navigate the menu regardless of what you do.

I assumed that game used WASD to control so I opened config menu and presses arrow keys. To my amazement, when I "rebound" down key, I couldn't use arrow keys at all. Since down is the last movement key, I've "rebound" all the movement keys before noticing this.

onpon4 {l Wrote}:ReTux uses a fixed aspect ratio. I chose 16:9 because that is more common than 4:3. It would be possible to distort the picture and stretch it to 4:3, but I don't think that's desirable. If you would rather distort the image, set the "scale_proportional" argument in the call to "Game" (right below where it prints "Initializing game system") to False.

I don't like fixed aspect ratio. In my own engine I decided the have a notion of field of view that is the lowest amount of game world that must be visible at any aspect ratio. So the game renders more horizontal stuff in widescreen and more vertical stuff in portrait.

onpon4 {l Wrote}:The level needs to be loaded to know the name of the level. This is why pre-loading is attempted when you start the game.

This is just a bad design decision. You need to put level name somewhere at the start of the file and read only a few bytes.

onpon4 {l Wrote}:

No way to change settings during the gameplay.

In the case of fullscreen, this is deliberate; switching to fullscreen mid-game can lock up X systems due what I assume is an SDL bug, and it would be undesirable to make the player lose progress because of that. In any case, the game saves every level, so it makes little practical difference.

You can lock one or two settings that are buggy and let other settings be changed. At one level the game told me to use Action key to Up key. I have no idea what Action key is so I wanted to open settings and look it up. Too bad there are no settings menu.

onpon4 {l Wrote}:

I ragequit at the 2nd castle.

Really? My younger brothers didn't have a particular problem with that one to my recollection.

Well it's not solely because of the difficulty but overall boringness. There is no multiplayer or sandbox mode to experiment in. Though SuperTux has the same problem.

Btw I really like the plot because it shows that government is by definition oppressive. I've never paid taxes on my income and never will because government is, to quote Andrew Ryan from Bioshock, "parasite".

I'm not sure why keys doing multiple things at once is related; to me they are separate problems.

For example, if you're allowed to set the down arrow to "select" while the down arrow still moves the selection down, and you can't move the selection down any way, you're forced to select every menu entry.

If you disagree with this design decision, you can re-add the arrow keys or whatever to the lists assigned in set_gui_controls. But I've made this decision for very specific reasons, so I will not be regressing my release.

You should consider having multiple ways for driving the menus. For example, in C-Dogs SDL, you can drive the menus using: player 1 controls, arrow keys, mouse, or joystick 1.

You can use the keyboard or gamepad. In this context, I don't think mouse control is a good idea, since you don't normally use the mouse anywhere in the game. Even in games where you do use the mouse, I'd say navigating menus with it like in a GUI is questionable, because in some contexts, mouse support can make it unreasonably difficult to just use the keyboard (which is easier).

And yes, even if you set player 1 controls to the arrows for example, it still works, because the game just loops over all the possible menu controls to determine whether up was pressed or whatever.

That method of control puts the order of controls out of sync, and not to mention is inefficient. For example, if the game slows down and the player presses "down" twice and presses "enter" expecting to go into a certain menu, then presses down again because of impatience, this design decision would cause them to choose the wrong menu option. I think this is a bad design choice. If you disagree, feel free to publish a fork of xsge_gui (which handles the menu control) that works the way you describe.

I've never seen this with SDL2 + win/macOS, so either it's an X bug or SDL 1 bug.

It's a bug with the combination of SDL 1 and X, as far as I know.

If it's the former you should allow changing it for non-X ports.

I'm not going to design a game to behave in different ways on different window systems, even if I can figure out how to detect whether or not X is running and currently in use. Besides, I don't know the cause of the bug I am referring to. I'm not going to play a game of cat and mouse where I make special environments for every affected system.

If you disagree with my design decision to put the options menu only in the main menu, please feel free to publish your fork which also adds an options menu to the pause menu. All you should need to do is make a new class inheriting ModalMenu and OptionsMenu, then add an option that creates these to PauseMenu.

I assumed that game used WASD to control so I opened config menu and presses arrow keys. To my amazement, when I "rebound" down key, I couldn't use arrow keys at all. Since down is the last movement key, I've "rebound" all the movement keys before noticing this.

You can see all the controls after you change one, so all you have to do is look through the list and see which key is assigned to "down". In fact, although it is not documented, you can even use the "sneak" key to do the same thing. I think you're exaggerating a minor nuisance which is a result of a trade-off for stability and reliability. If you disagree with the design choices I made for controls config, feel free to publish your modified version. All of the code which handles it is in the event_choose method of KeyboardMenu.

In my own engine I decided the have a notion of field of view that is the lowest amount of game world that must be visible at any aspect ratio. So the game renders more horizontal stuff in widescreen and more vertical stuff in portrait.

This complicates game design tremendously, and it is pretty much guaranteed to allow breaking the game or making it look atrocious. I design my games in a simple manner unless there is a very good reason why they shouldn't be. If you disagree with my decision to design games like this, then please feel free to develop your fork, though I must warn you that this is not a simple task and the only assistance I will give is to add unavailable capabilities needed for the job to the SGE API.

This is just a bad design decision. You need to put level name somewhere at the start of the file and read only a few bytes.

I didn't design the level format. It's a standard TMX file. Also, you can't just look for the name; you also have to look through all the objects and see if any Tux dolls are available, because otherwise the indicator for that won't display correctly, and that entails looking for doors and warp pipes and recursively searching those files as well. If you can change it so that it only loads the TMX file softly (without creating a room, the part that takes up the most time), and if it is always instantaneous (because I consider two load times for one level to be unacceptable), then I will happily merge that. However, I consider this to be an enhancement of very little importance that involves a lot of work, so I will not be devoting my own time to it.

Well it's not solely because of the difficulty but overall boringness. There is no multiplayer or sandbox mode to experiment in. Though SuperTux has the same problem.

Haven't we been through this before? If you don't like single-player games, that's fine, but many people do.

I am open to adding a 2-player option to ReTux (probably similar to NSMBWii), but I don't have graphics for that.

I would rather have a modal version of the key and joystick bindings menu; it wouldn't be substantially more effort than that. I'll look into it today after I finish the work I wanted to do on Naev, since while it benefits ReTux very little, I can see a more significant benefit in that for Hexoshi (where you only save at designated save points).