itch.io

Some more thoughts: in fact it would be smarter if the (multilingual) text used in the compiled installer are separate files so that the user can change the texts or add translations. At least it should be editable inside the tool for the chosen language (english or russian for now).

Hi Ewenloy, I purchased your tool two weeks ago and have some problems and/or suggestions.

1. Switching language to english has to be done on every start of your installer. Would be cool if language settings could be saved and loaded on startup.
2. Would also be cool if the settings for all the 4 steps could be saved for the last generated installer.
3. The generated installer has Russian text although I have english settings (see screenshot).
4. After successful compilation the tool resets the Compile window and the log is gone. Would be helpful to have that saved.
5. Might be good to create a separate directory under "builds" directory for each new installer. Directory name should be the game name plus version number (similar to the generated output name). That would allow developers to have a demo installer and a full version installer in the same subdirectory. Then you could also save the compilation log file in that subdirectory.
6. Might be helpful to also save the generated NSIS script for each installer in the same subdirectory.
7. Finally it would be helpful for automated builds to start your nsis-builder from a command line with stored settings (see step 2) or parameters (version number, input directory, etc.) to automate the build pipeline to create installers for different versions (Demo, Full Steam version, Full itch.io version, etc.).

Anyways, nice tool but the biggest issue/bug for me right now is the russian text in the compiled installer which makes your tool unusable for me right now.

Finally do you plan to support other languages?

Cheers,

Thomas

Hi hawkwork, Theralite is made with Godot and C#. Feel free to download the demo and give it a try ;-)

Hi Jason, bought your asset over on YoYoGame's Marketplace and I think it's awesome ;-)

But it seems to contain quite some stuff that is not yet used (like the particle scripts or the time_set stuff).

I'm also not quite sure if I need the PRE CONTROLLER object in my own games when I just want to use the camera scripts. The CONTROLLER object includes a lot of debugging stuff I might have to strip down for my own game if I have to have it.

If it IS required I would suggest you clean it up and just keep the absolutely necessary stuff required for the camera asset. You should extend the CONTROLLER when you start to add more features and they require some more functionality inside the CONTROLLER.

Another issue are naming conventions across your asset:

• some script names are all UPPER_CASE (most of the Particle scripts)
• some script names are lower_case (in the General and ASSET_Cam folder)
• some script names use some mixture of Camel_Case but with "_"
• Global variables use all different upper/lower case mixtures (debug_lerp_alpha, WINDOW, TIME, font, ...)

Then there are areas I think you should improve design/code wise:

• The CAM object contains functionality only used for the demo (much code in the step event of the camera object) like starting the screen shake on right mouse click, dealing with the Shift key and such. This does not belong there. You should create a separate controller object for the demo room which handles all that stuff. The CAM object should stay clear of that and just deal with camera stuff that is set via scripts.
• Also dealing with the debug buttons in the demo does not belong into the CAM object (begin step, alarm 1, draw gui) but should be moved into this separate controller or debug object.

As you see, for now my only complaints are just code cleanups and once more: the overall functionality is great and just what I wanted!

Cheers,

Thomas