Messages

Yes, but I wondered if this could cover both cases, as long as any available script functions to restore the state were still available in a newer engine version. So the data version is just the script version, and you drop support support for loading an old restoration script in the same way that legacy functions are phased out (script version strictness).

Just an idea though (and possibly a bad one).

Escoria has an interesting approach, where the save game file contains the script commands to restore you to your current point in the game. Potentially, could the 'cutscene' functionality be used to jump through a script if there are checkpoints set?

Perhaps this explains what I saw, when the file was still being written whilst the engine was trying to open it. It might be the attempt to create a hardlink is triggering a copy as a fallback, but it isn't a blocking operation.

I think there was a suggestion of rebranding 3.4.2+ as 3.5 anyway, just because of the level of change?
Release version is on .NET 2.0, and 3.4.2 is currently on .NET 4.0, so it has already been upgraded.

The usage numbers for XP were actually much lower than I was expecting, so I'd vote to drop it.

I created a project using it, I selected Default Template, and it created TWO projects with the name of my project, one called Default Game, and one called new_test_game, but both are the same project?

It was tricky to differentiate between the recent game entries, as the data was just a collections of string (so external to a change of project name). I'm not sure how making a new project would show two entries, but potentially it could have migrated one of them from an old entry, from an older Editor version.

The comparison between entries is pretty basic, for the moment:
https://github.com/adventuregamestudio/ags/blob/master/Editor/AGS.Editor/Entities/EditorPreferences.cs#L58-L61

If it deduplicated by path, the correct project name needs to come from somewhere.

I am with the current stable (3.4.1). I don't know if it's the same with 3.4.2.
In the clipboard I don't have anything open, you could be that PlayOnLinux itself is the cause.

It would be interesting to see if you had the same issue running the game with 3.4.2. I've found that the Editor's autocomplete would crash on Gnome 3, but I've never been sure that I've got WINE setup correctly.

I wish I could make a native version of AGS for Linux to get rid of Windows, all the programs I use are open source and AGS is the only one that is not for Linux :_(

Yes, me too. The editor itself will actually run, but the majority of the functionality to edit a game are currently in a library that is not cross-platform.

AGS with PlayOnLinux works quite well, but it has a problem: if you click on Run (F5) the game doesn't start most of the time because Wine gives an error.
To be able to run it, compile it all and execute the setup and press on Save and Run.

I've also seen this on WINE, and it seems the file is still being written when the engine tries to open it. I thought it didn't happen on AGS 3.4.2 builds though; which specific version are you seeing this with?

Also, sometimes the function selector does not appear.

There is also an issue the autocomplete on WINE, which I think is also related to having something in the clipboard. Is this what you mean by function selector?

Is it web interface only, or is there some way to access some storage directly?

GUIs have an OnClick event (for the GUI itself) and that can only be in the global script. I've had similar problems recently, and the best I could do was have a generic function to assign to OnClick events, which just just passed the data back to the module:
https://github.com/adventuregamestudio/ags-template-source/blob/master/Verb%20Coin/GlobalScript.asc#L234-L238

I also had to resort to using OnEvent for some things though, due to lack of built in click handling:
https://github.com/adventuregamestudio/ags-template-source/blob/master/Verb%20Coin/VerbCoin.asc#L463-L480

Those are pretty old, I bought some of these at my old job and that was about 8 years ago. Plus the one in that ebay listing says broken screen so it seems pretty expensive.

Are you just looking to run AGS, or would it have to do anything else?

You can get some of the low-end Lenovo laptops that are a couple of years old for pretty cheap.
https://www.ebay.co.uk/itm/Lenovo-G51-35-Laptop-AMD-A8-8GB-RAM-1TB-HDD-Windows-10-Home-15-6-screen/302836372939
This is the second one I've seen at £40, and the first just ended with no bids.

It should be able to run from the charger.
Maybe your friend would let you 'test drive' it for a few days?

I'd say that is fair price for it, but the processor is one designed to not use much power (so may seem a bit slow) and the build quality in general might not be too great (cheaper Lenovo stuff tends to be quite bendy).

If you try it out and are happy with the speed and condition of it, I think £90 is fine. If you didn't need it to run on batteries and fold into a tablet, you could probably get something either newer or faster for the same money.

What is the price?

I'm a bit unsettled by the answers provided there.

Same here.

16 bit executables, rather than applications that use 16 bit colour. If you don't need to run anything from before the mid 90s, you should be fine.

On 64 bit Windows you can't run 16 bit applications, which is a legit reason to stay on the 32 bit version.

Have you installed the driver for the graphics card?

I am coming at this from the perspective that AGS is also a tool for users who are not tech specialists.

Potentially you could just emit a warning when a read or write was only successful because the filesystem was case-insensitive. If the whole things is abstracted away into a virtual filesystem, that is really a different concept. In this example the read write functions are operating on the filesystem, with assumptions about how the filesystem operates. I guess it would be less of an issue if there was a try/catch wrapper in the scripting; if I copied a game to a FAT16 volume I wouldn't expect the engine to adapt to that.

Maybe this is a good example of splitting between AGS3 and AGS4, rather than trying to accommodate the old behaviour and also fix the issue. I can't really see the benefit in making everything case-insensitive, and this is related to the file system rather than a platform (ReFS supports case sensitive filenames, and that is for Windows). I would vote for just removing all the 'helper' parts (so the consistency is achieved by not doing anything) and letting the filesystem deal with it. It looks like the line handling assumes Windows line endings too, which is probably an issue long term.