Messages

[EDIT:]

EDIT: Had to reupload the RC5 update once more, with 1 extra bug fixed. (details under spoiler)

Spoiler

So, there's immediately a new bug that I did not notice in time: the GUIs have few pixels cut off from their top and right edge.
OpenGL has a slight difference: looks like it's cut from top and right edge.
EDIT: hmm, or rather gui elements are shifted up or down. Also, not sure why, but it looks like this only happens to buttons or backgrounds made of sprites.

Easily seen with the iconbar in Sierra template, where buttons are suddenly not centered in Direct3D, or cut from the top in OpenGL.

EDIT: I found an approximate reason, will need to make a quick fix and reupload a release.

EDIT: Ah, so this is a stupid rounding error, which creates a 1 px mistake if the GUI has non-even size.

[close]

I keep hitting a post limit of 30k characters when making Release posts, because I need to put download links, changelog (which may contain a lengthy list of items), and some overview, etc.

I guess the easiest workaround would be to make extra empty post(s) for backup, right after the first one. But in this case I forgot to add one.

Is it possible to somehow add an extra post in the middle, if I'm a local moderator?

Hmm, maybe I should be giving a link to changelog elsewhere instead.

[Editor]

Updated to RC5 (3.6.0.40)
(use download links in the first post)

Editor
- Fixed games built for Linux cannot load AGSSteam plugin.

Engine:
- Fixed GUI controls incorrectly blended with gui background if GUI.Transparency is > 0.
- Optimized memory usage in Direct3D/OpenGL renderers related to plugin raw drawing.
- Fixed Direct3D/OpenGL renderers were displaying plugin's raw drawings in a wrong position in the scrolling rooms, if the drawing was done on AGSE_PRESCREENDRAW or AGSE_POSTROOMDRAW events.

Plugins:
- Fixed SnowRain plugin drawing particles only in 320x200 bounds.


Reported issues remaining:
* Direct3D is said to still be not fully stable when alt+tabbing in exclusive fullscreen mode: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-release-candidate-rc1/msg636650995/#msg636650995

What I don't get is why all these overlays do not change their sprite as soon as the slot is repopulated with a new sprite, so it looks like the graphical overlay does somehow buffer the sprite even without the clone parameter?*

*I'm still not sure what exactly is happening tbh. But it's pretty safe to say that this is caused by user error, not an engine bug.

Could you clarify this; do you know if it's possible to reproduce this with a simpler code?

Some sprite and texture caching exist in the engine, so it's hypothetically possible that it is not cleared on sprite deletion too. (That happened with room objects before)

If this is what actually happens, then it of course should be considered an engine bug. I would separate solving the bug and workarounds; and I'm mostly interested in the bug details atm. There's a ticket opened about same problem: https://github.com/adventuregamestudio/ags/issues/1879
Ideally we'd need a walkable mask, and an example of starting position / Walk command arguments which causes character to stuck. This would help to reproduce and diagnose the problem.

I had to reverse the logic: rather than manually drawing walkable tiles, I had to make whole room walkable and "drill" nonwalkable tiles in it

Ahh, actually I thought this is what you're doing from the start; I had a wrong idea all this time.

Note: apparenly it's better, for isometric games, not to extend the nonwalkable areas/tiles in all directions, but only downwards.

This makes perfect sense, that amount of "outline" may be different depending on direction. I'm bit concerned about the horizontal corners too, but that's something one may find out by testing.

I'm too not quite certain about the reasons, but there's RunAGSGame function that lets to run another AGS game from the first one (and so forth): https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#runagsgame

The code snippet I pasted above is taken as-is from my script: all rows are one after the other, all inside the same function; moving the declaration out of the function as first line of the script does not help. The sprite IS drawn and it DOES remain there after function ends... but it's the wrong sprite!

This does not sound normal, I expected Khris's code to work.
If the wrong sprite is one with ID = 0, that's a placeholder, which might mean the dynamic sprite was deleted.
Can you post a code that you tried according to the Khris's advice (and which still did not work)?

Can a warning message be added in the editor console? This is an "autonomous behaviour", I would expect a "null pointer error" rather than automatically changing to default pointer, but if the "autonomous behaviour" is designed to prevent game crash, maybe a warning to developer would be enough.

Adding a warning is a good idea. I don't think editor is currently programmed to receive runtime warnings like that (this may be another future feature); but the warnings about potential game mistakes are written into the "warnings.log" file found in Compiled/Windows folder when the game is run with F5 from the editor.
(and also in the general engine log too)

When you assign DynamicSprite to an object, it normally is not copied, but referenced by the sprite ID (this is their Graphic property). Like Khris mentioned above, in AGS script dynamic sprites, like overlays, are deleted when the last pointer to them is removed, which happens when the function ends in your case. This is similar to Overlays. As soon as dynamic sprite is destroyed, the game object looses it and switches to sprite 0, which is historically used as a "placeholder".

Painting the dynamic sprite onto background will stay, as it changes background image, so it no longer depends on a sprite's presence.

But in regards to Overlays, there's another opportunity: CreateOverlay* functions have an optional "clone" argument. It's default value is "false", but if you pass "true", then they will make a copy of an assigned sprite, and the original sprite may get safely deleted after. So, if you do not want to keep the sprite afterwards, you may use this method.

Code: ags

Overlay.CreateRoomGraphical(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic, 0 /*transparency*/, true /*clone*/);

(This is since AGS 3.6.0, previously it was always cloned, even non-dynamic sprites, which could cause lots of redundant sprite copying.)

This behavior is documented in the CreateGraphical's article:
https://adventuregamestudio.github.io/ags-manual/Overlay.html#overlaycreategraphical

This won't work with other game objects though: for them you'd have to save dynamic sprite in a global variable, like you seem to do with Overlays.

Anyway I'll disable mouse and use only keyboard control to override this behaviour.

I might mention that mouse or keyboard (as an input method) do not enforce walking behavior. It's all in the script, how the script reacts to the player's input, which functions it uses. It's possible to call same functions in both cases.

Isn't pathfinder algorithm hardcoded?

The pathfinder is hardcoded, but the reaction to player's input is not. Everything that happens on mouse clicks or keyboard presses is in the game script and may be changed.

If there's a difference in how character walks after mouse click and key press, this means that the game script issues different commands depending on the input event. And it should be possible to alter the script, making them both to produce similar behavior.

What I am trying to say, is that you don't have to drop an input device support only because the original game script causes it to do something that you do not like.

At the moment I do not fully know which walking behavior you are trying to achieve, so I am merely speculating.
If I remember correctly, in the default game template keyboard controls call WalkStraight function, passing relative coordinates instead of absolute ones (like, player.x + X, player.y + Y). It is possible, for example, to do similar thing with the mouse, by converting absolute mouse coords into relative ones.

This is only to clarify existing opportunities.

[* iterating through existing objects using AGS own arrays.* creating your own arrays;]

Like eri0o mentioned, if the objects names have numbers - that does not mean anything, and does not automatically let you iterate through them. Iterating may only be done over arrays, but array is a separate variable, like a list, that has to store references to these objects.

I think it's worth mentioning that there are 2 potential questions here:
* iterating through existing objects using AGS own arrays.
* creating your own arrays;

In AGS many types of objects are already stored inside some array. For instance, room objects are stored inside "object" array (it's literally called - "object"; you may notice it in the autocomplete list when you type).

If objects in question are stored sequentially. have sequential IDs in this room, then you may as well just use that array. In the loop you would iterate starting with the first object's ID and until last object's ID.

Code: ags

int i = FIRST_OBJECT_ID;
while (i <= LAST_OBJECT_ID)
{
    object[i].Visible = false;
    i++;
}

If objects are not sequential, and it is not convenient to remake the room, then you would have to create a custom array and store either their indices or pointers there. Think of this as writing a list of items, which references only a portion of existing ones. This is what eri0o's example is about.

I'd only exclude unnecessary extra "initArray" function to simplify things, and put the initialization directly into Room_Load.
Also, to prevent possible misunderstanding (because you already had a misunderstanding about a number in name): your array's name does not have to be similar to object names. There's no connection at all. You may call it "ImageList", or whatever.

Code: ags

// This is array of object pointers, it will contain pointers to some objects, but not objects themselves
// defining OIMG_COUNT here is not obligatory, and is used only for convenience
// (to avoid hardcoded array sizes in case you would like to change the number of elements in the future)
#define OIMG_COUNT 4
Object* ImageList[OIMG_COUNT];

function Room_Load()
{
    // array indices begin with 0; overall indices have no relation to the object names;
    // that is - object names could be MyObject, MyAnotherObject, and so on, without numbers.
    ImageList[0] = image1;
    ImageList[1] = image2;
    ImageList[2] = image3;
    ImageList[3] = image4;
}

I honestly still do not understand why cannot you make the non-walking area further from their tiles to compensate for character's sprite width? I think that would be the first thing I'd try, if I were experimenting with such setup. Would not the result look approximately as if the character's "blocking area" was working the way you implied? Is there anything that prevents using this method?

Anyway I'll disable mouse and use only keyboard control to override this behaviour.

I might mention that mouse or keyboard (as an input method) do not enforce walking behavior. It's all in the script, how the script reacts to the player's input, which functions it uses. It's possible to call same functions in both cases.

Looking at how character move with debug mode enabled to show walkable area, apparently it seems that check is performed on single pixel on foot of the character versus edges of nonwalkable area. In other words, the "nonwalkable hole" around character's feet can overlap the nonwalkable area, as long as the single pixel at (playerwidth/2 , playerheight) is out of the area.

Can this be considered a bug?

No, this is not a bug, this is an intended behavior of AGS. I tried to explain above, that this "hole" is used only to prevent other characters from walking too close to the "solid" character.

Yes, like you say, when calculating a path, the check is only performed against a single pixel on foot of a character, and not the area around it.
IIRC, this particular character's "hole" is edited out while calculating the path, so it does not block itself.

[SOLUTION 1. Keeping track of what music you are playing]

There are two approaches to this.

SOLUTION 1. Keeping track of what music you are playing

If you have only 1 channel reserved for the music (this may be checked in the Editor: Audio -> Types -> Music -> MaxChannels).
Make a global variable of AudioChannel* type, and save returned value from Play() function. Next time you need to play a music, test this variable and see if same music is played on that channel.
Name that variable "MusicChannel", for example.
The global variable may be created in "Global Variables" panel, or by hand in script if you know how to do that.

Every time you play a music, any music, you must remember to assign Play's return value into that variable:

Code: ags

MusicChannel = aSomeMusic.Play();

And for each case where you want to prevent same music restart, use this code:

Code: ags

function room_AfterFadeIn()
{
    // This means that you will start music IF:
    // * the channel variable was not initialized yet (this means no music played before), OR
    // * the currently playing clip is NOT this music
    if ((MusicChannel == null) || (MusicChannel.PlayingClip != aMusic1))
    {
        MusicChannel = aMusic1.Play();
    }
}

SOLUTION 2. Test each channel to see if your music is playing

All audio channels can be accessed using System.AudioChannels[] array, and their total number is in System.AudioChannelCount. This means that you may iterate through all of them and find out what is playing on them at any given time.

For convenience, make a custom function in GlobalScript:

Code: ags

bool IsAudioClipPlaying(AudioClip* clip)
{
    for (int i = 0; i < System.AudioChannelCount; i++)
    {
        if (System.AudioChannels[i].PlayingClip == clip)
        {
            return true; // found it
        }
    }
    return false; // nowhere
}

Declare this function in GlobalScript's header, this will let you use it in any room:

Code: ags

import bool IsAudioClipPlaying(AudioClip* clip);

And now you can do this in your rooms:

Code: ags

function room_AfterFadeIn()
{
     // '!' sign means logical NOT, so this means "if NOT playing"
    if (!IsAudioClipPlaying(aMusic1))
    {
        aMusic1.Play();
    }
}

[assume a side-view game]

I can't find any example or explanation about sprites collisions management, any suggestion? I see I can monitor collision of objects and characters, but nothing specific about sprites (more specifically: dynamic sprites).

The collisions in AGS may be misleading if not confusing at first; primarily because they were meant to emulate some old adventure games and also assume a side-view game.

1. Characters and Objects have Solid property. If this property is set, they actually paint "holes" inside walkable area mask, and update these "holes" as they move. These are rectangular holes positioned around their "feet", and this is what you may see on a walkable debug overlay. These extra holes prevent other character from walking over, so it looks like a collision test. The sizes of these "holes" are determined by BlockingWidth and BlockingHeight properties.
Painting over a walkable mask yourself (as you already do) would give precisely same result.

2. The "IsColliding" functions. Their behavior depends on the kind of object.

Character.IsCollidingWithChar, Character.IsCollidingWithObject functions are special, because they are testing against some rectangular areas at their feet; but I cannot remember if it's exactly the same area as BlockingWidth/Height or some arbitrary one; knowing AGS it could even be some hardcoded factors.

Object.IsCollidingWithObject tests full bounding rectangles of two object sprites.

AreThingsOverlapping also tests full bounding rectangles of two sprites (characters or objects).

But only one is documented both in offline and online help, "AreThingsOverlapping". Maybe the others have been deprecated in 3.6.0? I see that there are Character.IsCollidingWithChar , Character.IsCollidingWithObject, Object.IsCollidingWithObject  , maybe they replace the missing global functions?

There's a table of deprecated functions and their suggested replacements:
https://adventuregamestudio.github.io/ags-manual/ObsoleteScriptAPI.html

I remember now that I had the same problem a while ago, but probably forgot about it.

EDIT: right, this also happens with "Lock screen orientation" setting. It keeps resetting to default "Portrait".

I opened a bug ticket in regards to this problem.

I'm running the latest version of the APK (3.6.0.39) on my Samsung Tab A (2019). Every game runs without problems, but there seems to be an issue with the touch-to-mouse emulation. The only option that allows the imitation of a right click (by taping with both fingers on the screen) is the "Two Fingers (tap to click)" option. The "One Finger" option doesn't seem to allow for a right click. Now whenever I restart the AGS app I have to configure it again even though "Two Fingers" is selected in the preferences: In order for it to work again I have to first select one of the other options (either "One Finger" or "off") and then immediately re-select "Two Finger". Then I can start the game and use right click. If I don't reconfigure it this way everytime I start the AGS app, I'm unable to use right click.

Hmm, so, this sounds like preferences (or certain option) are not applied after you start again?

I think I got it (maybe? ). I conflated a channel being null with a channel not playing anything. But my channel was probably null because I hadn't played anything on it yet, so it hadn't been assigned one of the 16 permanent game channels. Would that make sense?

Indeed, if you have not assigned anything to a pointer, it would be null. Every pointer starts as null.

Like Khris mentioned above, if you have a "chained" structure like Channel.PlayingClip.ID, then you have to test for every nested pointer there that theoretically may be null: Channel != null, then Channel.PlayingClip != null, and so on.

Ah, good question, I don't remember if the PlayingClip property is set in the same frame or only in the next one.

I don't think this is what Honza was asking about.
But to give an answer, PlayingClip should have a valid return value immediately after Play() is called.

In other words, the non walkable area surrounding player's feet, currently used to avoid collisions with other characters, should be used also to avoid collisions with nonwalkable areas.

Cannot you make the non-walkable areas wider, giving them the extra "outline", so that the character walks at certain distance from the forbidden tiles?