How to properly modify the lpr?

1

The lpr is autogenerated, but to facilitate debugging with console in windows I wanted to allow the app to be CONSOLE when my debug compiler directive is turned on. I guess at some point this will autogenerate maybe when I save from castle game editor and I will lose this. What is the correct way to do this?

{$ifdef dbgBehavior}
   {$apptype CONSOLE}
{$else}
   {$ifdef MSWINDOWS} {$apptype GUI} {$endif}
{$endif}
2

I’m afraid that’s the only way to do this I know.

Indeed, regenerating the project from Castle Editor will overwrite these changes. This won’t happen accidentally though, you need to explicitly press Code → Regenerate Project.

So to avoid losing the custom code in autogenerated files I just use a version control system (GIT) to track changes, and when I see that something had changed in an undesirable way, I can simply revert the lines:

2024-05-12 08_11_13-Greenshot
2024-05-12 08_11_13-Greenshot1039×350 20.6 KB

3

I have never used ‘Regenerate Project’, so won’t. I most use the editor to figure things out, then code them so they don’t appear there anymore. So my editor scene is empty except for screen controls. Sounds like just saving those edits are safe. I tried using window’s allocconsole as I have in the past for being able to turn on the console on the fly… but now it works unreliably and gives me a console that is broken half the time and writelns will fail. Debugging debug console behavior is not my idea of fun!

4

Indeed, that’s one way to use Castle Editor - I also personally prefer to instantiate most of the game elements from the code :slight_smile:

but now it works unreliably and gives me a console that is broken half the time and writelns will fail. Debugging debug console behavior is not my idea of fun!

Note, that WriteLn is technically not a good way to send logging information. Its behavior depends on the platform (and on specific project settings), and therefore it’s better to use a cross-platform solution: CastleLog. It works on all target platforms CGE supports and smartly detects if {$apptype console} (in this case sends logs to console) or {$apptype gui} (in this case sends log to a log filein AppData folder. To use it just:

uses CastleLog;
...
WriteLnLog('Something something');

It has several more useful features. One thing you’ll need to do is to InitializeLog somewhere as early as possible, most likely in initialization section of your program. If you generate a project through Castle Editor it will be there automatically in castleautogenerated.pas.

1 Like
5

The LPR / DPR is not regenerated automatically now – you need to explicitly do

So in practice it is OK to just refrain from doing the above, or remember to revert the LPR / DPR after regenerating as Eugene shows.

I know it’s not optimal – in the long run I don’t want you to worry that “someday, this regeneration will be more automatic”. (Though I don’t have plan to change it now, but something may make it necessary in the future.)

Most things can (and should) be placed outside of LPR / DPR actually, to support also non-desktop platforms (like Android, iOS, WebAssembly). But the above $apptype I think work only in LPR / DPR? You can try – maybe putting it in any unit (like gameinitialize.pas) will work too?

If you need CONSOLE for Writeln, then better answer (again repeating Eugene :slight_smile: ) is to make a habit of using CGE WritelnLog / WritelnWarning, see Logging | Manual | Castle Game Engine . This will work on all platforms, e.g. on Android it will write to Android facility. And if you run from editor, it will show in editor output. On Windows GUI, it will by default go to file, but (if you know you have stduot available – this happens if you run from console, like Cygwin) you can set CASTLE_LOG environment variable to stdout to force it to go to stdout.

P.S. I recommend to put it inside {$ifdef MSWINDOWS}...{$endif} . This is Windows-specific, FPC will warn that it’s ignored on other platforms.

1 Like