Messages

Still I don't get how I import my walkable areas masks on new overlays. @Crimson Wizard  spoke of drawingsurfaces, but I didn't find how to transform tha into a real walkable area, and also (though I guess it's going to be the same method) how to change the walkbehind areas and regions.

This is not done with overlays.
If you are changing areas in the room, there's GetDrawingSurface method for all of them:
https://adventuregamestudio.github.io/ags-manual/Hotspot.html#hotspotgetdrawingsurface
https://adventuregamestudio.github.io/ags-manual/Region.html#regiongetdrawingsurface
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Room.html#getdrawingsurfaceforwalkablearea
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_Room.html#getdrawingsurfaceforwalkbehind

After getting a drawing surface, you may paint a new mask on them.

AGS 4 has slightly different functions.

[project root folder]

The absolute simpliest way is to use the "Log Panel" in the Editor that eri0o mentioned, it may be made visible in "Windows" menu.
https://adventuregamestudio.github.io/ags-manual/EditorLogPanel.html
(unfortunately the help page does not tell about the menu command)

About acsetup, global config is the fastest way perhaps, but if you require an individual approach per game, then adding acsetup.cfg file to the project root folder will make it merged with the one that Editor generates.

Note that you don't have to put "file-path" unless you really want that, the default log path is "%USERPROFILE%/Saved Games/Adventure Game Studio/ags.log"

I suppose that we may discuss some better way of configuring this log file setting from the Editor itself.

[after]

I maybe will try to make a dirty version of this soon.

I've been thinking about the script callback accompanying save/restore system, and a conclusion is that in the current engine no callback may be run during the save/restore process:
* if run during save, this callback may modify data or trigger some action, resulting in inconsistent data.
* if run during restore, the script data is not loaded, and so is dynamic objects pool (where managed objects are stored) so any random operation may lead to errors.

This means that a script callback may only be run before and after save and restore process.



If we think about a callback that checks for the loaded save and possibly adjusting game data, - that one should definitely be run after a save was already loaded. If callback decides that the game should not proceed with this restored save, this means a bit of wasted time, but I suppose this is not a big deal.
More important is the question what to do after that. Because if the restored save is to be discarded, game appears in a unreliable state, and cannot run; cannot even display a menu, etc, since in AGS there's no distinction between "menu objects" and "gameplay objects". This in turn means that it should either:
* quit immediately, with some error message (provided by developer?);
* do RestartGame, if restart slot was created;
* load a reserved save slot as per developer's instruction.



Now, if we think about an optional callback that lets to read or write custom data into save... Since callbacks cannot be run during save, this means that the callback for writing custom data must be called right before saving begins, and write not to the file, but to a temporary memory buffer, which later will be written as a extra component into save file. Writing to a memory buffer may also be performed using File API; that will only require implementing a "memory file" mode for the script File object.
And callback for reading this custom data must be called after save was loaded, where reading will be done from a memory buffer (previously filled during save restore).
This custom data reading callback may in fact be merged with the "save check and update game" into one callback that lets do both. Or not...



To summarize, we may have something like (following is a draft):

Code: ags

void on_save_custom_data(File* savefile)
{
}

and

Code: ags

bool on_restore_custom_data(File* savefile)
{
    return true; // if everything is fine and game continues to run
    return false; // if we decided that save is not compatible
}

and

Code: ags

bool on_restored_save_validate()
{
    return true; // if everything is fine and game continues to run
    return false; // if we decided that save is not compatible

    // can we order to restart game / restore another save here on failure?
}

[EDIT:]

Uhm, there are a few other small additions in ags4 that aren't listed because they were added with intention of being in the at some point upcoming 3.6.2 but they are also in ags4 simply because ags4 gets all improvements.   

My intent was to list these too, it looks like I forgot to add them to the update's list this time. But they are added to the full list in the first post.

EDIT: added changes from 3.6.2 dev branch.

[finished]

Automount likely may be easily done by a shell script, such as batch or Python, there's no necessity in using AI for something that trivial.
Not every automatization requires AI.

Fixing the crashing game is something that AI cannot do without either having a source code, or having to analyze and decipher the machine code. As AI does not possess magical abilities, it's a tool, and will require at least the exact amount of knowledge that a human would require to do this (if doing properly).
That's the least, but then AI should also know how to fix particular issues. Some of those may be not fixable without a larger rewrite of the program, such as porting the game to the framework that works better with the modern operating system, for example.
The amount of necessary knowledge and understanding here is extreme.
- Find out that the program is failing (requires learning what is correct and incorrect game behavior);
- Recognize the source code or machine code, analyze and memorize its structure;
- Understand which part of the code is responsible for the failing situation;
- Understand what this particular error would need to get fixed (this may be anything from program mistake to a logical game mistake);
- Plan ahead and implement the fixing (may involve a major program rewrite).

I cannot fathom how AI can accomplish this at the current stage, given right now it more or less tries to emulate finished human work based on examples that it's fed by its instructors, or fetched from the internet.

Do you mean GetTextWidth()?

No, GetTextHeight had a mistake that used "width - 1" instead of "width" when splitting text up into multiple lines.
GetTextWidth worked properly.

[Editor:]

Updated to Alpha 12
(Please use download links in the first post)

Contains updates and fixes from 3.6.1 Patch 4 (except ones related to backwards compatibility).

Other changes:

Editor:
- Improved scrolling of drop-down lists in the Room's navigation bar: made scroll buttons larger, and support mouse wheel.
- Do not delete previously built game exe from Compiled/Windows folder when testing a game from the editor.
- Added "Open Recent" submenu in the File menu.
- Sync script editor's commands in Edit menu with the context menu.
- Added "Toggle Line Comment" command to Edit menu for scripts.
- Added "Word Wrap" command to Edit menu for scripts.
- Support to import and keep sprites as explicitly 8-bit images without converting to the game's default color depth. This lets to have chosen sprites used as 8-bit masks in a 16/32-bit game.
- Added TurnWhenFacing property to Characters.
- Fixed Character.Enabled and Visible properties not written correctly when the game is built.
- Fixed an unhandled exception occuring when rebuilding rooms if any script's header is missing.

Script API:
- Added MaskPathfinder struct, which lets to initialize a Pathfinder using a 8-bit sprite serving as a navigation mask.
- Added Character.TurnWhenFacing property.
- Added ColorFormat enum, and optional "color_format" parameter to DynamicSprite's functions: Create(), CreateFromBackground(), CreateFromDrawingSurface(), CreateFromExistingSprite() and CreateFromFile().
- Added readonly DrawingSurface.ColorDepth property.
- Added readonly Game.SpriteColorDepth[] indexed property.
- Added StringSplitOptions enum, and "options" parameter to String.Split().
- Expanded `on_mouse_click` callback, now supports two more parameters: click x,y coordinates.
- Global generated game objects (Characters, GUIs, etc) are now declared as object *pointers* in script (this complements recent similar change done to arrays of game objects).
- All the area-related GetAtScreenXY functions (for Hotspot, Region, Walkbehind and WalkableArea) now return a null pointer if no room viewport is found under given coordinates.

Engine:
- GetTextHeight() no longer reduces "width" parameter by -1. This was an ancient mistake in the engine kept for many years for backwards compatibility.
- Fixed a crash occuring when debugger requested a variable's value, but script contains no "table of contents".
- Fixed Character.MovePath and WalkPath not reacting to the "path" parameter being a null pointer, and proceeding with mistakes.
- Fixed a crash in SaveScreenShot (repeating regression in AGS 4).
- Fixed WalkableArea.GetAtScreenXY and GetAtRoomXY returning "garbage" values instead of a valid WalkableArea pointer.

You could use one of the default templates for the reference of the saving/loading code.
Either create a dummy game from Sierra-style template (for example), or download this template's source project from here:
https://github.com/adventuregamestudio/ags-template-source/tree/master/Sierra-style

Specifically save / load dialog code is this part:
https://github.com/adventuregamestudio/ags-template-source/blob/f6deb48a8d205fb996b81b4319350637016161ee/Sierra-style/GlobalScript.asc#L271-L359

As an aside, this begs the question why ags scripting doesn't have a simple "include" statement, like #include otherfile.asc so humans can split things up but the compiler can cram it all back together into one huge script if it wants. Obviously this was thought of years ago; I'm curious about the technical reason why it's not there.

No specific technical reason prevents this, it was just never prioritized and addressed.

OTOH, "include" is a C/C++ kind of thing, while some people suggested to make AGS script more C#-kind, where you don't use headers at all, and declarations are imported either automatically or by a sort of "import" statement, rather than joining script files verbatim. So there are multiple options to consider.

Then, there's of course a idea to let users put event functions in arbitrary scripts, not only global script. If that is done, then there will be no or less need to "include" asc files into each other.

Are you referring to windows that are called using SaveGameDialog()/RestoreGameDialog(), or user-made guis found in the project tree?

If former, then you cannot customize them, and you should just create your own guis and script their behavior.

If latter, then find these GUIs in the project and change their properties.

I am not saying that it's ridiculous to have short script names, I'm saying it's ridiculous that people resort to this when working around the voice clip problems.

And of course it's ridiculous that this have not been fixed yet.

the approach we tried with direct memory access didn't do significant improvements - it was like 30% faster but this was still slow so we didn't go that road.

I must clarify: this was not implemented not because it was not much faster, but because that would break certain things, as noted in following comments in the ticket. This, or certain alternate approach, still may be done at some point in ags4, maybe.

Or do you mean that each time I add an overlay I should 'replace' all my coordinates to get back in the center of my room. A little like a treadmill?

Indeed, more or less so, that idea is to have a smaller room and keep visuals moving sideways.

This may be implemented in various ways. It may move all the time as player moves (in which case your room may be only bit larger than the screen), or it may replace bigger chunks of the room when player reaches certain threshold.

The choice depends on various factors, including whether you are using AGS own pathfinding (walkable areas in the room).
Note that this may be easier to do in the upcoming AGS 4 update, where there's a pathfinding API which allows to use custom sprites as masks, and not rely on room itself.

I usually just make all of the character script names four characters long, to avoid this problem.

That is ridiculous, i have recently removed a character name limit after someones request, and now turns out other users intentionally limit them to 4 characters just to avoid a stupid voice script issues.

Why not keep a list of all your character names in a alphabetic order, then you can notice when there are 2+ characters with identical 4-letters beginning?

And of course, this voice naming rule must be modified to allow using full character names.
https://github.com/adventuregamestudio/ags/issues/1456

I thought the same but was explained that pictures are like divided into areas of the same exact colors.

That's true for images saved with RLE compression (for instance). But bitmaps are uncompressed when loaded in AGS memory.
Textures created from room bgs may be compressed in their own way, although I do not know if they are or which compression they use (graphics driver is responsible for that).

[not]

But to do that it would be much easier to initally plant a huge room, on which you would define your walkable are mask, characters' positions etc. and then turn the background to a big black sheet, that you would continuously replace with the dynamic sprites as the character moves.

No, the idea is to not create a huge room (like 6k x 15k) at all, but create a smaller sized room, like a smaller canvas, on which you place pieces of a larger background, objects, and walkable areas, corresponding to the current "active" area.

The thing is, it does not matter whether there's a valid background, or a blank background, it takes exactly same size in memory ("blank" pixels are still pixels). And masks also take memory. And objects and characters do. If you display all of that at once, that would require extra processing and memory.

Unfortunately I have several characters whose script names share the first four letters. Is my only option to change their script names?

Yes, i'm afraid so.

I think i posted a reply to something very similar a while ago. (I cannot remember whether it was your question or someone elses).

The thing is, there's a difference between how AGS does the rooms and how "big world" games do their "rooms".

In AGS the room is a seamless bitmap for background. This is convenient in point and click games, but may be not convenient when you're making other kinds of games, such as arcades, or strategies, etc.

These games usually don't use a single background bitmap, instead they have scenes constructed of tiles dynamically (with some optimizations). These tiles may be of various sizes: small cells, or bigger chunks, - whatever is more convenient for a particular game and its art style. But in a very nutshell, they have the world in memory as some data, and generate the visuals as player walks around. When player passes a part of the world, its visuals got discarded from processing, and sometimes from memory. If the world is really big, they would not keep it whole data in memory, but load parts of it from file(s), and unload some parts when player is far away from them.

This system is doable in AGS, but you have to program it yourself in ags script, with some good forethought.

How much and what you will have to do depends on which AGS functionality are you planning to use. For example, for visuals, you may use room overlays to dynamically create visual parts of the world and displayed them in a tiled manner. If you need to use AGS pathfinding, then you will have to also dynamically update room masks as player moves to other places (the walkable mask is accessible using DrawingSurface).


In regards to the 2009th post about room sizes, I suggest to completely ignore that, because many things changed since.

There's no hard limit on a room size now, but there may be problems with some functions if your room exceeds 32k of size in any axis. That's because some parameters in game objects are represented as signed 2-byte numbers, meaning they will "wrap" to negative values if exceed 32k.

That said, I have no idea how well it would work if you make a giant seamless 32k x 32k room. Personally, I would recommend reconsidering this approach, and instead either split the world into multiple rooms, or think of methods that I mentioned above. But it's your choice what to do with your AGS game.

What is the size of the gui and label? It may be simply that they are not large enough.

I'm wondering what the best way would be to push my work into git.
The repo for the templates only contains .agt files. Which means two things :

You are looking at the wrong repo.

Here are template sources:
https://github.com/adventuregamestudio/ags-template-source

Any idea? @eri0o since you're on fire you should create a pipeline that turns a game into a .agt and we should store the templates as game projects (just kidding)

This is actually a scheduled task:
https://github.com/adventuregamestudio/ags-template-source/issues/27

But for now we update *.agt files by hand, when preparing a new release and there were changes made to sources.