Messages

Thanks! The language fix removes a weight from my shoulders.

[In the US, what's a popular platform for "tipping" a content creator?]

Simple question : In the US, what's a popular platform for "tipping" a content creator? By tipping I mean giving a small amount of money with the least hassle possible. It's not crowdfunding, as in "there's a project to achieve and a funding threshold to reach". More like the kind of free donation form that you'd see when downloading some small games bundle or for charity. You click on a button and in one minute you've given 50 cents.

I was thinking of Tipeee but I think it's very Europe-centered and it requires the tipper to create an account. Patreon might be more US-centered, but again it requires the tipper to create an account.

[MacOS]

I see that Expo is very focused on mobile apps (iOS and Android), which makes sense. But does it work on Desktop MacOS and does it build/sign for that target? I can't find it written explicitly. Or does only the binding with Electron make it possible?

EDIT : https://dev.to/evanbacon/making-desktop-apps-with-electron-react-native-and-expo-5e36

Do I understand correctly that there's no engine sources, and the engine is available as a compiled executable that can run game data, such as this "Delores" source?

Yes. But considering it's bleeding edge technology, the tradeoff is pretty good I'd say
The only tricks are : 1) No commercial use. Only hobby use (I'm fine with that ) 2) The tools are rather raw. Especially to import graphics and such. But they're good enough.

That being said I don't intend on switching to that engine, but I'm convinced that it would be totally feasible.

What the what now?

https://grumpygamer.com/delores_dev

Ron Gilbert had previously released his engine for Thimbleweed park.
Now he has released the source code for a mini-game ("Delores") based on the engine.

I haven't investigated exactly what it means in terms of ready-to-use adventure game engine, or if there's a catch, but holy Molly!

For react-native there's Expo: https://docs.expo.io/distribution/app-signing/

What a headache. Thanks!

[it's easy to build an app (Qt or Electron or whatever) for MacOS if you're already on MacOS.]

New question : Do you know of a free online code hosting platform that would let me build and sign my (Electron or anything else) app for MacOS?
My issue is currently that it's not too hard to build any project for its target platform on that platform. For example it's easy to build an app (Qt or Electron or whatever) for MacOS if you're already on MacOS. Since recently, it's also (quasi) impossible to build/sign an app for MacOS if you're on Windows (because of the signing mechanism of MacOS apps).

But I'm guessing there must be platforms online that have virtual machines and automated builds for other platforms? Something that runs build scripts for every platform every time you push your changes (or, as you call it, Continuous Integration). Something like Azure DevOps, except more humble and free.

Does that exist or is it a fantasy?
EDIT: Oh man, I'm going down the rabbit hole with this, fast-learning about MacStadium, Azure pipeline agents and all those strange beasts.

It did not come with Ubuntu when I installed it on VM, but it was as easy to install as "sudo apt-get install curl".

Cool, thanks.

You go get them tiger! I predict this game will be super fun.

Update : I have rewritten the first post to do the launcher with Electron. I tested it, it's awesome and super easy. And modern. Zero chance of breaking in the next 5 years at least.

OK but we will finally discover exactly what is the Schnibble of Azimuth?

More seriously : Now that's what I call a true high-resolution game. Gorgeous in every way.

It knows the .exe but it doesn't know which .cfg and which .tra to use. Or at least I thought so.

I can't understand what do you mean. How would it work if it did not know which cfg to use...

Well I thought it took acsetup.cfg no matter what. Which means that two games in the same folder would share the same config file. I'm realizing it's not a big issue because if one of those two games is a .ags then there's only one .exe, which means we need only one .cfg.
Yeah the real issue really only lies in listing all the .tra for both games in winsetup.

[(X) I want to run the game in full screen]

I think I finally managed to identify the biggest issue with winsetup.exe and just letting people choose their resolution from a list.

It should instead be presented like this wizard:
(the red part is the critical novelty)

(X) I want to run the game in full screen (  ) I want to run the game in a window

What is the thing you dislike the most? (  ) I don't like black borders around the game        I want the game to be displayed on the entirety of my screen, even if it makes it slightly blurry (X) I don't like bluriness        I want the game to be as sharp as possible, even if it means small black borders around the game

We have calculated that the ideal enlargement factor for your game is 3x. Do you agree with this? (X) Yes, please run the game as big as possible        This will apply the 3x scaling factor ( ) No, please stay moderate        This will apply the 2x scaling factor. The game will use about 1/4 of your screen. ( ) No, I don't want any enlargement at all.        This will apply the 1x scaling factor. Your game might appear very small on a screen with a high resolution.

All the settings should be calculated from those three questions. Also, obviously not all three questions need to be asked depending on the answers to the previous questions. For example if the player chose "windowed" you don't ask about letterbox.

Please note : asking for letterbox/no letterbox is not new. What's new is asking to the player what they dislike the most, and letting them understand that they can't have both.

A more general fix would be for winsetup to know what exe it targets, what .cfg file it uses,...

But it does know that.

It knows the .exe but it doesn't know which .cfg and which .tra to use. Or at least I thought so.

Not sure I understand this, are you saying that generic winsetup is good or bad?

It's good! But it becomes bad if it gets confused with the settings (again: because it can't tell which .tra files are meant for it and just displays all of them).

I don't like the "we forbid the access to winsetup.exe" option...  That's the first thing I run in any AGS game! And I will not play any game that doesn't provide it.

The only reason we do that is because of this issue with the translations. Cassiebsg you didn't see that but that's already how it worked in Relic of the Viking 1.0 : All the translations (both for the parent game and the embedded game) appear in the list, that's an issue.
Of course we don't really "forbid" the access to winsetup.exe. We just hide it a little bit to not encourage people who have no idea what they're doing to mess up their settings and be locked out of the game.

Like everyone has said before, there are two ways out of this :
1) Fix the TRA issue in winsetup.exe -- that one I'm not demanding because this is a very specific scenario (very few people have an embedded game and translations!).
OR
2) Use a custom setup programs. That's on my TODO list anyways so I'm OK with it (I'll use eeri0o's program).

[React Native]

@eri0o : investigating a custom setup is my next step.

About the launcher: All of the above leads to not much as this stupid Qt framework actually broke its compatibility with its QtWebEngine module, hence making it hard to embed a web page in a desktop app on anything but Windows -- which was pretty much the whole point of this exercise.

I'm currently investigating doing the same with a very simple React Native or an Electron app -- still with the goal of making it work at least on Windows, MacOS and Linux, and if simple enough on iOS and Android.

This means there's a mistake in winsetup that should be fixed: it should test whether TRA belongs to the current game.

Yes.
A more general fix would be for winsetup to know what exe it targets, what .cfg file it uses, and what .tra entries it offers. The central issue is that winsetup is a generic program that's meant to autodetect everything in the same folder. If you start making winsetup specific to one game, then you create new constraints.

[I need to test more but I'm 90% sure that your patch fixed my issue.]

I need to test more but I'm 90% sure that your patch fixed my issue.

Default translation ("") works simply because there's "default" in any game.

Well that's what I was hoping and that's the scenario I indentified as the only one that could possible work. I wasn't hoping for more.

But this means that neither ChangeTranslation neither config from game B should be applied for game A at all. What's the point if you must run ChangeTranslation("") before RunAGSGame to simply make it run? Perhaps, better make RunAGSGame reset translation to default on its own?
How translation setting is supposed to work anyway in case there are two games bundled together? I'd rather find old developers who used RunAGSGame earlier to know what was the expected behavior in this case.

I think that you're entering a dangerous realm here; Indeed the language setting should be even more restrictive, but do we really want that? It increases the risk of you making a mistake on engine-development end, and the risk of the game maker making a mistake on their end.
That being said, you just made me realize that it's unclear to me what ends up in acsetup.cfg after I quit the embedded game. But my code now works with your patched engine.


Here is how I do it (this is currently implemented in my game, and works) :

Solution for a normal game (no "RunAGSGame") :


- Make the end-user use winsetup.exe if they know about it
  => If they don't, then at first startup "game default" is selected
  => If they do, then at first startup the language is the one they selected
- When the game quits the language hasn't changed and remains the same in acsetup.cfg until next startup

Solution for a normal game (no "RunAGSGame") that lets the payer choose the language in-game :

- in game_start, the game tests the value of the current translation. If it's "" it means that the player didn't explicitly pick a language.
- Depending on that value and how much we want the player to choose, then :
   => No matter what the player has selected in winsetup.exe, the game immediately does a Game.ChangeTranslation("") at startup
   => The game displays a custom GUI asking to pick a language
   => If the user picks English, then we do Game.ChangeTranslation("English") to be able to tell the difference with "".
         Note: One extra benefit of having an explicit "English" .tra file is that the Tumbleweed and 9verb modules rely on a GUI_LANGUAGE entry that must be translated to "en" in English.tra.
- When the game quits the language is remembered in acsetup.cfg until next startup, so we can decide not to display the languageselection GUI at next startup

Solution for a game containing another game (uses "RunAGSGame"):

- we forbid the access to winsetup.exe. A game that starts for the first time with something else than "game default" is considered corrupt.
  The reason for that is that winsetup.exe displays the list of .TRA files for both games. If the parent game has "English" and the child game has "EN", then you will see both in the list.
  If the player is a smart arse and tries to force-pick a .TRA entry belonging to the child game, then the game will crash at startup anyways (built-in AGS engine check).

- As an extra safety, we do Game.ChangeTranslation("") in game_start but I'm not even sure that's needed.
- in game_start, the game reads the value of the language in a custom .ini file.
  => If the value does not exist or is not recognized as a correct value for the parent game, then the game displays the "select language" custom GUI
  => We update that value in the .ini file
  => We go Game.ChangeTranslation based on that value.
- Just before calling RunAGSGame, we do Game.ChangeTranslation(""). Thanks to your patch, the child game knows to start with "" and doesn't get confused with the parent's .TRA files.
   => For convenience, in the child game we display the custom language seection screen every time, but we could totally save it into a .ini file too.
- When any of these games exit, then some value is saved in acsetup.cfg
  => I don't care what the value is because the mechanisms described above help me work around it.

Here's the patched engine: https://www.dropbox.com/s/yyxbt7h2x97460p/acwin-3.5.0-p3--runagsgame-trs.zip?dl=1

Please tell if it works for you now.

Wow, thanks!
I will try asap

I am not sure I understand how does not it find "whatever.tra" if it lies in same folder.

The engine finds it, but has a mechanism to detect that it was generated for the other game. So it finds it but rejects it.

ChangeTranslation was called in game2, but then game1 does its own initialization at startup.

Yes but it means that game1 reads which language it should boot with from acsetup.cfg. And that's problematic because:
- I can change the current language with an instruction. That happens instantaneously,
- but the language in acsetup.cfg gets changed against my will, and with a delay (at exit time). I have no control over that. The language selected in a previous session of game2 determines what language game1 will try to start with in the current session.

As always, thanks a lot for taking the time of answering. Now you have all the facts.

Everything you wrote is correct.

The weird thing (to me) is really that Game.ChangeTranslation("") succeeds, but a moment later the engine is still looking for whatever.tra.
I think there's an overlap between "current translation", "defaut language" and "last saved language".