Messages

For what it's worth, in the global script, in repeatedly_execute(), I have this :

Code: ags

 
Game.TextReadingSpeed = 10;
Game.MinimumTextDisplayTimeMs = 2500;

If you put this in repeatedly_execute, that would run N times per second over and over again for no reason.
Settings like that are supposed to be initialized once in game_start, and perhaps when player uses some menu control if you support changing them in game.

Adding such things to repeatedly_execute is a lazy way when a person does not know the correct way, just because it suddenly works. It seems that AGS users used to do this a lot in the past, and older forum threads mention this kind of examples, but that is wrong.

Oh you probably mean the https://khris.ddns.net/agsparser/ from one of the earlier posts?

So by "program" you mean the website, and not AGS?

Are you trying to post a big text on forums? Perhaps it would be easier to upload it to some file hosting and post a link here.

Sigh.
I finally figured out a way to format the text file quickly and easily, but I can't even try it out because the file is too large and it crashes your program when I try to import it...

How large, and how exactly do you try to import it?

Other than that, I find it a little weird that there's a bunch of code to ensure that if the player uses the same description as an existing savegame, it will overwrite it rather than save it as a separate savegame. That would really piss me off as a player.

The existing templates provide no clear way of telling whether to create a new save or overwrite an existing one.
Instead they fill the description text box whenever player clicks on a existing item. That's why they use the description to match the existing save.

I suppose you may clarify if this depends on dialog at all. Set the starting room for the player character to room 2 and see if hotspot interaction works if game begins there.


Then, I'm not sure if this is relevant to the problem, but I noticed that you use "StopDialog" in your dialog script and "return" after ChangeRoom. You don't have to use "StopDialog" inside the dialog script at all, instead use "stop" command in the end:

Code: ags

cMimi: Debo ir a la casa de quien pidio esto
  player.ChangeRoom(2, 336, 500);
  player.ManualScaling = true;
  player.Scaling = 20;
stop

The problem is that room 2 has a hotspot and I can't interect in any form with it, look, interact, grab, it doesn't matter. I can't log a Display(), nothing.

In 99% cases this would be because you did not register hHouse_Interact in the list of hotspot's events.
https://adventuregamestudio.github.io/ags-manual/images/acintro3_03.png
so that's the first thing to check.

There are many many ways an indicator could be done. So, whenever such question arises (any similar question really), it's important to define the desired logical behavior of a game element, point by point, "on paper". How does it look like, how does it behave, how does it connect to the game, what are the conditions that define its state, etc, etc.
When such "paper" exists, divide it on parts that you already know how to do, and those that you don't. Then find out about the latter.

Art of Dying would be a fantastic tool to learn from BUT it doesn't work with the later AGS versions.

Which one? It must work in 3.6.1; perhaps turning backwards compatibility options in General Settings is required.
https://adventuregamestudio.github.io/ags-manual/GeneralSettings.html#backwards-compatibility
I mentioned this many times on these forums: 3.* versions are fully backward compatible and support importing and running games down to AGS v2.5.

EDIT: I just quickly tried it, and the only problem found is that it declares a "Camera" struct in script. This may be solved either by renaming this struct to something else (throughout the code), or setting "Script API version" to < 3.5.0 (this is where AGS introduced its own Camera).

EDIT2: anyway, this all is a wrong place to post this. I will stop here.

This is the kind of stuff i wished was available for sourcecode in AGS

There's a "Art of Dying" available with the source code:
http://gamejolt.com/games/the-art-of-dying/21047
Much simpler one room platformer:
https://github.com/VacaRoxa/dogfromhell
Taken from the list of opensourced AGS games:
https://www.adventuregamestudio.co.uk/forums/advanced-technical-forum/a-sticky-list-with-open-source-ags-games/

lstSaveGamesList is the name of the ListBox control, which you want to fill with names of saves.

If you're using this code, then you're supposed to create a GUI with certain controls on them.

Of course you may adjust this to suit your needs. You do not have to use this code as it is.

Also, should I be clicking on the link (BASS, Sierra, Verb Coin: updated find_save_slot(), fix going over limit) and use that code?

No, the version of the code that I linked above already has this fix.

We do not define the size of "close" button in any way in this program, these are standard window elements created by operating system, and looks of these buttons depend on the active visual theme too.
Maybe it's a problem with AGS window border style; or that the window does not stretch far enough for some reason.

I have an older version of Windows, and use a different visual style (classic windows style), where buttons are of different shape and smaller, and don't touch the window edge, so I cannot see how this works. I'd have to try this on Windows 10 to see how these look there.

EDIT: but I don't have two monitors, so idk if I will be able to replicate this test precisely.

Could you clarify, is this about AGS Editor, or running game?

I suppose that it's not a problem with exit button, but the size of a window that does not cover whole desktop?
Because we do not control the size of exit button, it's a standard window button, as created by the operating system.

[players]

So, it's not really "portable"... it would likely become "portable" if it had VC libraries linked along with the program. Engine does that in order to avoid forcing players to install VC redist along with the game. It might be possible to create a Editor distribution that has VC libs linked with the Editor program too, it's just that there was not much of the explicit demand for that in the past.

Necessary VC redistributable may be found by the link on the same page (https://www.adventuregamestudio.co.uk/site/ags/)
Direct link is: https://download.microsoft.com/download/6/A/A/6AA4EDFF-645B-48C5-81CC-ED5963AEAD48/vc_redist.x86.exe

[OPENED A DRAFT PR]

OPENED A DRAFT PR
PR: https://github.com/adventuregamestudio/ags/pull/2489
Download: https://cirrus-ci.com/task/5522434697199616

UPDATED: 31th August

As Khris said, Editor may be downloaded in an archive and simply unpacked. It does still have system requirements (.NET framework and VC Redist) but other than that may run, for example, from a flash drive that you insert into a random machine.

Sorry, could not find it.

The download section on the website is inconvenient in my opinion,
but you may find zip download of the latest stable editor under "More downloads for ..." spoiler on this page:
https://www.adventuregamestudio.co.uk/site/ags/

Is this a question of portable Editor or portable engine (game runner)?
At first I thought you are speaking of the former, but then you referred to it as "interactive video player" which sounds like the game engine.

As Khris said, Editor may be downloaded in an archive and simply unpacked. It does still have system requirements (.NET framework and VC Redist) but other than that may run, for example, from a flash drive that you insert into a random machine.

As for the engine, it has a Web version, that may be be run on a web server and played in a browser. Multiple game developers have used this to create online versions of their AGS games on itch.io, for instance.

PS. But... why dig out a 13 years old forum thread for this?

This is interesting to read the opinion on save system. It looks like other game engines do not provide an "out of the box" save system, but that's natural, as engine cannot know what the game's save should include, or which part has to be recreated upon restoring a save.

AGS has a opposite problem, it often saves too much, including things that do not belong to the game progression, or temporary resources that would rather be recreated on game load, in order to not increase the save file size.
(Perhaps not in small games, but in bigger AGS games save files may reach many tens of MBs each, or more, especially if game author does not clean temporary allocated objects when they are no longer needed).

Another problem is upgrading saves (loading saves from the older version of the game), but this is a universal problem, not specific to AGS. In AGS this is coupled with ready save system, which might cause wrong assumptions, and lead to nasty surprises much time later.

I suppose that the principal problem is dividing data into the part that is relevant to the game progress, and the part which is not relevant to that. The easiest example is game interface: main menu, icon bars, and so forth. Normally one would not save the states of these, but AGS cannot distinguish these, and saves altogether. This leads to strange problems: if you save the game by pressing a button in a menu, restoring that save will have that menu open, as its state is saved along. That is why in our templates we have save menu closed prior to running SaveGameSlot command. Alternatively, a game developer has to override "game restored" event and fixup all the opened menus, and such. Which is like reverting a part of the save system's work; which means that it was doing excess work in the first place.

I also absolutely hate the fact that indenting of code lines is not just a visual thing in Godot, but a functional part of the code, and if your line of code is indented too far right or left the code simply won't compile.

That's Python rules, Godot Script is made as an expansion / variant of Python.

Hey, @eri0o is there a way of including a .dll engine plugin in these games?  Specifically ags_agi.dll (AGS Resolution Emulation Plugin)?

AGI plugin in particular may be substituted with the existing viewport/camera feature with relative ease in modern version of AGS.
We've discussed this recently here:
https://www.adventuregamestudio.co.uk/forums/editor-development/feature-request-agi-21-aspect-ratio-support/