AGS 3.4.1 - RC 3 (new release candidate)

Started by Crimson Wizard, Sun 09/04/2017 22:02:10

Previous topic - Next topic

NicolaGs

#260
The real problem is that we're never happy with what we've got... :-D

Edit:
Could it be something like that?
My first game : I Want Out!

Radiant

Yes, that does sound too complicated for the average user... It strikes me that most players want to fill their screen as much as possible, stretching where necessary; and that most artists want to maintain aspect ratio. Find a middle road between these and you're good to go.

proximity

Quote from: Crimson Wizard on Sat 11/11/2017 16:37:42
Quote from: proximity on Sat 11/11/2017 14:36:21I last tried it with AGS 3.4.0.
Could you specify which 3.4.0 exactly (what is the fourth version number)? The mouse fix I was referring to was added somewhere in the midst of 3.4.0 development.

Just in case I opened ticket for this issue: http://www.adventuregamestudio.co.uk/forums/index.php?issue=849.0

Although, first of all set of conditions has to be established. For example, you are saying that you use 32-bit color gfx - and I assume - high resolutions? - in your game. Do other people who play your game experience same problem? Or, on contrary, do you have same issue when you run low-res games made by other people?

I tried other AGS games and I realized that cursor movement is better at 60 FPS. I also changed my speed to 60 and cursor is better now. AGS 3.4.0.13. eri0o was right. Thanks.
Proximity Entertainment

Crimson Wizard

Quote from: NicolaGs on Sun 12/11/2017 17:24:10
Could it be something like that?


I can do that, if that's actually seem convenient. Is it?

Radiant

That's three pull downs that most players will not understand. So I don't think it's convenient.

NicolaGs

#265
Could this behaviour be set in the editor (default setup) and made enabled or disabled in the Winsetup.
That way, the game creator could set what option he/she thinks is the best for the game and forbid this parameter to be modified by the player (the option(s) would be greyed out in the Winsetup) ?
The player then would could have only "important" options visible in the main Winsetup screen : language, fullscreen+resolution/windowed, driver.

Could the ability to disable some winsetup options from within the editor a solution to both problems :
- simplicity for the player (as much as the game creator intend it)
- versatility of the settings, to make every game maker happy ?

edit : I add that it's not really a request from my part. The current situation suits me perfectly...
edit2 : it should be a post-3.4.1 discussion, right?
My first game : I Want Out!


Crimson Wizard

#267
This situation has no solution without separate scaling setting for windowed mode.

For example, many people complained that the game is not stretched to whole fullscreen. For that reason I was considering to make "proportional stretch" be default scaling. But if I do that, then the people who prefer to play in windowed mode will complain that window is too large by default.

And the preference about how the game should behave if mode is switched during runtime (which scaling option used for alternate mode) also may be different.

Quote from: NicolaGs on Sun 12/11/2017 20:13:20
edit2 : it should be a post-3.4.1 discussion, right?

There are already complains and confusion about this, and who knows when next version will be.

Snarky

Quote from: Radiant on Sun 12/11/2017 20:04:17
That's three pull downs that most players will not understand. So I don't think it's convenient.

Quote from: Crimson Wizard on Sun 12/11/2017 22:08:44
This situation has no solution without separate scaling setting for windowed mode.

Good design makes things as simple as possible, and no simpler. The best thing would be to be able to resize windowed mode on the fly, but as long as that's not possible, yeah, we do need separate settings.

Crimson Wizard

I guess I should leave this until next (minor) update or patch. This is not the only thing that makes me concerned, to be honest, another one is new file paths restrictions: at first they seemed to be logical, but I have doubts about usability (they became stronger when I actually tried to create a game with AGS).

I would need to discuss this before changing anything again.

Crimson Wizard

#270
AGS 3.4.1 RC2
http://www.adventuregamestudio.co.uk/releases/betas/AGS-3.4.1-RC2/AGS-3.4.1-rc-2.zip
(also updated first post)

Changes since RC 1:

Editor:
- Fixed unhandled exception occuring when user types "#undef", "#ifdef" or "#ifndef" on the last line of the script.
- Fixed "Script compatibility level" option was incorrectly set to "v3.2.1" every time a project is loaded. (Bug introduced in RC1)

* Also included Linux build pack (https://github.com/adventuregamestudio/ags/releases/download/v.3.4.1.9/AGS.3.4.1.9.Editor.Linux.Pack.zip).


If no critical issue is found in the course of this week, I guess we may call it a final release.

eri0o

where should I place the Linux Build Pack? I created a folder named Linux on Program Files/Adventure Game Studio 3.4.1 with the contents of the attached folder, but Linux build didn't work. :/ (Compiled/Linux is slightly empty)

Crimson Wizard

#272
Quote from: eri0o on Wed 15/11/2017 12:07:11
where should I place the Linux Build Pack? I created a folder named Linux on Program Files/Adventure Game Studio 3.4.1 with the contents of the attached folder, but Linux build didn't work. :/ (Compiled/Linux is slightly empty)

Hmm, things to check: -

1) These files should be in Adventure Game Studio 3.4.1\Linux\, meaning not Adventure Game Studio 3.4.1\Linux\Linux\
2) "Linux" checkbox should be ticked in General Settings - Compiler - Build target platform
3) Run Build Exe.

Quote(Compiled/Linux is slightly empty)
Do you mean the folder was created but no files inside? Was that folder there before or just appeared?

eri0o

:/ it appears I don't have the command takeown in my system for some reason, will try to figure out why.

Crimson Wizard

#274
Quote from: eri0o on Wed 15/11/2017 17:11:45
:/ it appears I don't have the command takeown in my system for some reason, will try to figure out why.

I could add this to exceptions, in which case AGS will fallback to copying the files (it does that in case of lack of permissions).

EDIT: Actually... I realized do not know what I should do; first need to investigate why it needs this command exactly, and whether there is a way around without it.

eri0o

Hey CW, don't hold back the update because of this, it's working fine and this wasn't working previously already.

morganw

I'm not sure why it needs to do anything regarding ownership or ACLs. If you aren't running as an elevated process then you cannot take ownership, but even if you could, I'm not sure why it tries to make the files writable for all users. If two users need to edit on the same machine, you would just put the game folder somewhere where they can both write and take the default inheritance from that location, and if someone does set an ACL you wouldn't want to have the build process modify it.

Crimson Wizard

#277
http://www.adventuregamestudio.co.uk/forums/index.php?topic=55474.msg636575300

This is happening too often, people use default settings and get unexpected results, that they do not know how to fix in settings. This means that "stretch" must be default.

This is it, I am adding separate scaling settings for windowed and fullscreen modes.

Crimson Wizard

Quote from: Crimson Wizard on Fri 17/11/2017 14:29:02
This is it, I am adding separate scaling settings for windowed and fullscreen modes.

I am sorry, this is going to take longer than expected.

The engine code related to config is based on assumption that config options are only used once to create graphics mode for the first time. Also it will take more than just add one variable. There is also several cases which may be affected (starting with config, without config, from legacy config, from command line parameters).

I've been rewriting this gfx init / config code for so many times in past few years, and still cannot make it proper for some reason. I need to think very well before making changes again.

Unfortunately, I made mistake to participate in MAGS this month, and need to focus on one task at time.

Crimson Wizard

#279
Another note, after giving this some thought, I would like to return back the ability to tell AGS to write files into game directory.

Normally this should be advised against, because users may run the game from somewhere where writing is forbidden (either by system permissions, or physically). But I found on my own that there may be at least one case where you may need this ability: when you have a "development" mode in your game to create game data right from inside the game. Currently you'd have to temporarily set custom "APPDATADIR" path in config for the development time, and reset it later before distribution.

To write to game's directory one would have to explicitly use $INSTALLDIR$ token in the file path. File paths without any token will be rerouted to $APPDATADIR$ as they are currently. Manual must contain a warning that one should not write to $INSTALLDIR$ without serious need, because that may prevent some users from running the game normally.
Writing into $INSTALLDIR$ won't have same meaning as writing to $APPDATADIR$ or $SAVEGAMEDIR$ even if these are set to game directory in config, because, obviously, one may always remap the last two onto another location, while $INSTALLDIR$ is always $INSTALLDIR$, so to speak.

SMF spam blocked by CleanTalk