Messages

Ideally, it's much better to make use of the "File" functions, but for some reason (this behavior is already documented in the forum), I was having issues with Windows Defender warnings (and I was worried this might happen to someone else who might then think the game contains a virus).

Could you elaborate, which issues with Windows Defender did you have using File functions?

Would it be complicated to have a dDialog.Stop(); that would just close the gui ?

There is already a StopDialog function that is supposed to stop a dialog, but it was working only in very specific case in the previous versions.

Does it include the rotation fix for dynamicsprite too ?

This is the latest build which includes everything.

But I forgot that the above includes update of a color format, so may not be entirely safe. It's still in testing.
After upgrading, users will have to fix all of their color constants if they have these in scripts,
that is - assignments like "GUI.BackgroundColor = 123456;". These should be replaced with AARRBBGG format like, which is easier to write in hex (like "0xFFRRGGBB").
If you don't have such things in script, then it's safer, but still I recommend making a game backup.

If you don't want to do this right away, there's a temporary workaround for GetByName:

Code: ags

GUIControl *MyGetByName(GUI* parentGUI, String name)
{
    for (int i = 0; i < parentGUI.ControlCount; i++)
    {
        if (parentGUI.Controls[i].ScriptName == name)
            return parentGUI.Controls[i];
    }
    return null;
}

In regards to StopDialog, appears it does not work when called from anything that was not run directly from dialog script. Meaning it does not work from rep-exec-always either. I think that's a mistake, and I will try fixing this in 3.6.2.

There may be ways to achieve this in 3.6.1 too, perhaps more than one.

The dumb way is to use "custom dialog options" API, which lets you manually control how dialog options are run. It may be possible to have a hidden dialog option that just exits the dialog, and run that option from "dialog_options_repexec".
The problem with this way is that "custom dialog options" require you to script options drawing and selecting as well (you can't replace only part of behavior). If you go this way, you may use some default implementation, shown in examples.

But maybe there are other easier ways.

First of all, you have to make sure that "Run game loops while dialog options are displayed" is enabled in General Settings.

Then, Dialog.CurrentDialog is introduced in v3.6.2, this is mentioned in "Compatibility" note in its article.
StopDialog may also be working differently in older versions.
Which version of AGS are you using currently? Depending on version you may need to use different solution.

I noticed a problem with the GUIControl.GetByName function : I didn't change anything in my game, just ported it to AGS 4.0 (last build, the fix erioo sent me), and I have a null pointer instead of something working like before.

GetByName got broken again, you will need to use the most recent unreleased build to make it work:
https://cirrus-ci.com/task/6345700029497344

Please clarify your intent, do you want to abort a dialog when dialog options are displayed, or in virtually any point of a dialog script (like, in the midst of characters talking, etc)?

Although the link on the FAQ has been fixed, the "legal" page is still present in AGS website, and people somehow may get there: https://www.adventuregamestudio.co.uk/site/ags/legal/

Not sure how, but maybe it's indexed in the search engines like Google.

This came up recently when a user PMed me asking if the MPEG license is still an issue.

BUMP.
Maybe there's a way to either delete that page, or replace the text with the copy&paste of the contemporary license, or delete all text and post a link to the contemporary license?

Honestly, that's overdue, and it's baffling, considering this may be important to some.

Past few changes, AGS 4 now features full 32-bit ARGB colors, the next PR actually adds support for raw drawing operations with alpha:
https://github.com/adventuregamestudio/ags/pull/2661

Next we'd need to see how standard items work if one assigns a translucent color to them (GUI and speech texts).

Move's actual speed may be different from Walk if you have "movement linked to animation" setting. In which case the character's walking speed is restricted by animation speed during Walk, but not during Move.

You never mentioned if you have this setting on or not.

It's on by default and hidden away. So it's safe to say that yes it is.
Whenever anyone makes a post complaining about any problem involving moving characters in any shape or form, this setting is almost always the culprit, because people are unaware of it and its function.

If THAT is a problem, then we may look for solutions.

1. A global setting could be made in General Settings (where it maybe will be more visible), defining the default value of this property for new characters.

2. This setting can be made "false" by default in order to force users to figure it out before using. Each template has its settings, that's something that is template's issue. But "Empty" template may retain editor's defaults.

3. The moving/walking rules may be clearly documented in the manual, in its own dedicated article.
I've been suggesting a "Game Features" section in the manual for the last several years. Started to write them, but the progress is very slow, because I'm busy with other things, and become unenthusiastic:
https://github.com/adventuregamestudio/ags-manual/wiki/_GameFeatures

Clearly something that this community members could do in the past 13 years since this engine became open source.

It is a bit confusing why we have to adapt the Walk speed and the Move speed.
Do they both calculate speed differently?

As I said in my previous reply:

Move's actual speed may be different from Walk if you have "movement linked to animation" setting. In which case the character's walking speed is restricted by animation speed during Walk, but not during Move.

You never mentioned if you have this setting on or not.

If we speak about alternate functions, there's a Tween module, where you can just do Tween.TweenPosition, which moves a character from one pos to another in a strictly given time.

Ive read the manual and forums too, but im still confused on how it works. Even though ive added the code, the game isnt displaying what i want. My screen is 1920 x 1200 and my background is 2200 x 1875. It displays the lower part of the background which i dont want (the upper body and part of bg i want to be visible).

Please always post your code with the question like this, don't just say "i've added the code and it does not work". We need to see your code to tell what's wrong with it.

Have you tried changing speed before calling Move?
https://adventuregamestudio.github.io/ags-manual/Character.html#charactersetwalkspeed

Move's actual speed may be different from Walk if you have "movement linked to animation" setting. In which case the character's walking speed is restricted by animation speed during Walk, but not during Move.

I used "Replace sprite(s) from source" to refresh all the character's sprites, and the alpha channel is now displaying correctly.

Hmm, interesting, I did not expect "Replace from source" to work like that, but probably it works because it remembers "Use Alpha Channel" option, and automatically combines that with the new knowledge about the source image.

@greg Please try this experimental build:
https://cirrus-ci.com/task/6105885866459136

If the Editor does not start, you may need to install a different VC redistributable on your system, because we are switching to another version:
https://download.visualstudio.microsoft.com/download/pr/5319f718-2a84-4aff-86be-8dbdefd92ca1/DD1A8BE03398367745A87A5E35BEBDAB00FDAD080CF42AF0C3F20802D08C25D4/VC_redist.x86.exe

Strangely, this only can be done via script:
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#setgamespeed

Sure, here's the png I'm testing with:

https://www.dropbox.com/scl/fi/z1fgxxvnahpw0yfwjw84v/NE-01-SS-000.png?rlkey=w9i6bj0dqhp4cp6z4vzw3pkmm&st=lap4p1ze&dl=0

I can see what is happening now.
When importing this file in previous versions, they see this file as "32-bit ARGB".
When importing the same file in 3.6.2, it sees this file as "8 bit indexed", and thinks that the image does not have any alpha channel.
This is displayed at the left-bottom corner of the Import Sprite window; and "Alpha Channel" property is false in the sprite's properties after import.

The PNG file is actually 8-bit, but I suppose that it contains translucent colors in its palette, and 3.6.2 misses this fact.

@greg could you upload a original png that you are using so that I could test this? I was not able to see this black outline with the random sprites; and I cannot see any difference from 3.6.1, or 3.6.0 for example, regardless of the options.

About TransparentColour=NoTransparency, I tried with the same random sprite, and it maintains alpha transparency for some reason, although I did not expect that. I am not fully certain, but i think that this option was supposed to make the sprite opaque.

This is a tiny patch, mostly done because there's a regression with Character.Animate(), where it incorrectly reports a "wrong loop" under some conditions.

Besides that there were no new issues found in 3.6.1 in the recent few months. As 3.6.2 is in preparation for the next stable release now, I suppose this may be the last 3.6.1 patch.