Messages

@Mehrdad , could you upload examples of the starting, stopping and turning animations, for our reference?

After lots of debugging, I found what the problem with buttons is.

There's a option in General Settings called "GUI controls clip their contents". If it is set to "False", then controls let things like text to display outside of their bounds (in historical way).

So there's a weird bug in 4.0 engine, where if the Button has a text which does not fit the button's frame, then the click detection starts at the text's leftmost position, not at the button's leftmost position. In other words it works as if the button was located some pixels further left.

This is combined with another mistake: if the text is "New button", the button has a graphic assigned, and so the text is not displayed in game, but it still is accounted for when detecting clicks...

Possibly other controls have similar issue, but I haven't tried them yet.

Also I have to mention a small issue in editor : some controls have their On_Click function called "FonctionFouille(GUIControl *control, MouseButton *button)". If I double click on one of these controls, the editor doesn't find the function in the global script, and creates a new one at the end. Even if the function already exists with the same name. Perhaps because there is no "On_Click" on the name ? I wanted to remove it to have it shorter, I don't know if it's a problem.

I found that this happens if there is a comment on the same line right after the function's name, like this:

Code: ags

function Fonctionfouille(GUIControl *control, MouseButton button) // comment
{

This happens in previous versions too (3.6.2 etc).

I had to use your project to test this out. In general, please always post exactly what you have in script when reporting issues, because every tiny detail may matter.

OK So I just encounter the "mouseclick goes under the control to click the control paced under it" bug randomly again. I think it's because of "Perfect Click" option (that is enabled in my game). I can't explain why it could be another reason.

"Pixel-perfect click detection" is not applied to GUI and controls at all. It simply is not implemented for them. We have a feature request for this, but it was never done.

The image pixels are never tested when testing which control player clicked on. This is very easy to check: assign a sprite with transparent parts and try to click through it. This won't work.

All GUIs and controls always detect clicks with their full rectangle.

On another hand, the Button's rectangle is not defined by the image. It's defined by Width and Height properties. When you assign an image to the button, the button will resize itself to match the Image. But if you later modify Width or Height, then the button's rectangle will not match its image anymore, and it may look like you are clicking through the sprite.

If @Crimson Wizard you could test it on your side and tell me if you encounter the same thing, it could be great !

In order to test this properly, I need to know full details about how the controls are arranged. I must know their:
- position
- size (Width, Height properties)
- ZOrder property

Example of a button that sometimes I can't click on (depending on where the mouse is) :

Again, I need to know actual button's size (Width, Height properties).
It would also help if I knew full situation:
- GUI position
- Button position and size
- mouse position when click does not work (this may be told by logging it or printing mouse x,y on screen, for example_

Also I have to mention a small issue in editor : some controls have their On_Click function called "FonctionFouille(GUIControl *control, MouseButton *button)". If I double click on one of these controls, the editor doesn't find the function in the global script, and creates a new one at the end. Even if the function already exists with the same name. Perhaps because there is no "On_Click" on the name ? I wanted to remove it to have it shorter, I don't know if it's a problem.

The function prototype that you cite looks wrong. You have "MouseButton *button", but it should be "MouseButton button" with no asteriks. Is that a typo in your script, or in your post?

For inner blocks, yes. Local variables overriding global variables, yes. For a loop, I haven't seen that in a million years.

But the loop is a type of inner block. For a compiler there's no difference whether it's inside a loop, or inside a "if", etc.

Whether compiler should warn users about such thing (when the variable of same name is used in loop's condition) is another question. Maybe it's possible to teach compiler to deduce what is used in a loop condition.

Found a bug : when changing the sprite of several buttons at the same time within the GUI Editor, only the "selected" one (the one with the red squares) got its height and width adjusted. The  others change their graphic but keep their old width and height.

This bug is also present in 3.6.2, where the multiple controls edit was introduced.

EDIT:
Also, if you try changing Name property to multiple objects at once, the Editor shows unhandled exception error.

[1. Is it better to have them also in a "walking view" or have a separate "turning view"?]

I've been thinking about the "turning" animations, and how they could be organized in principle.

Right now we have a "Walking view" in AGS, which loops are designated certain fixed roles (walk Up, walk Down, and so forth). Suppose we want to also have "turning" loops. There are following questions here:


1. Is it better to have them also in a "walking view" or have a separate "turning view"?

Having them in a walking view would keep things together, but increase number of loops. Also, if we keep fixed loop roles, this may make it more difficult and inconvenient to expand walking view in the future (for example, if we like to add more directions).
If we have them in a separate view, then there will be another property, such as Character.TurnView, which is optional and may be left unset if you don't need that.

A certain downside of having a separate view is that previewing character movement may require switching views.
OTOH we might require a different preview controls anyway, which let switch direction/action more conveniently, rather than select loop number.


2. How many turning animations do we support?

There are 4 walking directions by default, and 8 directions if diagonal dirs are enabled.
How many turning transitions are going to be there?

Should there be animations per clockwise and counter-clockwise turning only, such as Left->Up, Up->Right, Right->Down etc, and turning from Left to Right would play two animations like left->up + up->right.
Or should there be animations between any pair of directions, like left->up, left-down, left-right?

In the second case, the number of turning transitions between cardinal directions will be 4 * 3 (each direction turning to each other direction). In case if there are diagonal directions, then there are 8 * 7 transitions.
So we will need to assume that the maximal possible amount of loops is 8 * 7 = 56.
Is this logic correct?

On another hand, I assume that not all combinations are necessary, as user may like to have only few of these animated in their game. And all of these are considered optional.

We need to know what should happen if turning view is set but particular loop is abscent.
What is the logic of selecting and playing a animation when turning character from direction A to direction B?


3. How do we designate loop roles for turning?

The assumption is that:
- we may have loops with roles in multiple views (e.g. WalkView, TurnView, etc)
- we may have a big number of max possible loops
- not all of these loops may be useful.

Currently only "Walking view" has loop roles. If other views will have loop roles, then Editor will need to display different hints. How will Editor know which hints to display?
Currently there are only 8 walking loops with defined roles. What if there is going to be more?
What if user needs only few of the many possible loop roles, what will be the convenient way to work with the view?

This makes me think that we need a different approach.

If we like to stay in the existing AGS View/Loop paradigm, then I can see following options:
1. A view may have a "View Role" selection in the Editor, which tells how to interpret this View, and how to call its loops.
2. Additionally, Editor may allow to set a role freely for each loop. Or, on contrary, display only loops of certain roles.

The difference between a) assigning a role to a loop and b) display a loop of fixed roles, is that:
1. If a loop has a custom role, then this data must be passed into the engine, and engine must modify its logic. It no longer will be able to decide loop by its number, but will have to decide the loop by its "role" parameter. If such rule also applies to a walking view, then this means that Character.Loop property will no longer directly correspond to the walking Direction.
2. Alternatively, if Loop roles are still fixed, then Editor may simply hide unused loops and display only ones that user selected. The loop numbers will still have a role attached to them, but some may not be displayed in the editor and remain empty.

"Why is this an issue to make one in script, and which "fps loss" are you speaking of?"
=> It's not an issue, I can make it by script, just I wanted to ask if it was going to be done in AGS

Having a gui following cursor, or located e.g. at the bottom of the screen, is trivial, this is same as making one for hotspots.
Having a text selected by gui control under the cursor is also simple. There are 2 fast ways I can think about:
1. Have 2-dimensional array of strings, and use Gui ID + GuiControl's ID as array indexes. This may be done in AGS 3 too (2-d array can be emulated).
2. Use GuiControl's Custom Property to tell its description (custom properties are added to Gui Controls in AGS 4).
Both solutions should be fast  and simple. 2nd solution seems more convenient, especially now when custom properties are displayed right in the list of object's properties.

New issue I encountered : if I use Display function during a Room Transition, the mouse disappears (is not visible but usable). Room Transition is set to CrossFade wen it happens.

Do you mean that it disappears for the duration of transition, or also not become visible after transition?
Where exactly "during transition" do you use Display in which script event? Please give exact details when reporting issues.

This is intended behavior, corresponding to a standard behavior of all the C-like languages (and maybe many others), where a local variable inside a block overrides a variable of same name outside of a block.

Similarly, it should be possible to have local variables, overriding global variables of the same name.

- I can't explain why, but in some cases, I encounter a weird thing : when several buttons (2 or three in my case) are one on another, the mouse click doesn't seem to apply to the upper one (the one with the higher ZOrder). I'm using the last AGS 4.0 build, and it was not doing this in 3.6 that I used before. It is something similar that I reported before, with OnCLick functions switching between HotSpots/Buttons with no reason, but this last thing I don't encounter anymore.

We cannot do much unless there are steps to reproduce. If you could try and narrow down this case to a minimal setup, or figure out under which conditions this happens, then we may diagnose this issue.
If not, then perhaps you could send me your game and tell how do I observe the issue there?

- Is it planned to have a natively built-in system of "description" for GUIControls ? Like, the mouse goes over the control, and a text (usually the description of what it's going to do) appear near the mouse. Just like in windows. It could be very practical, and if built-in, it could be without fps loss.

No, this was never asked before, and never planned. This does not seem like a good thing to have built-in either, rather something for a script module.
Why is this an issue to make one in script, and which "fps loss" are you speaking of?

- I tried the "show usage" function by right clicking in a sprite in the sprite tab, I knew it was used for a button in a GUI but it said that it wasn't used by anything. Is there something broken in AGS 4.0 regarding that ?

I cannot reproduce this. Tried with default Sierra template, and "show usage" for sprite lists buttons that use that sprite. Please clarify the situation: which buttons is this sprite used on, and which exactly button properties is it assigned to?

You can upgrade your game from version 3.3 (and even earlier) to the latest AGS 3.6.2.
Usually it may require to toggle few switches in General Settings -> Backwards Compatibility, if you got some errors in script.
The manual has some info about that:
https://adventuregamestudio.github.io/ags-manual/GeneralSettings.html#backwards-compatibility

For example, you may need to set "Script compatibility level" to whatever version you've been using prior to upgrading.

On another hand, if you like to start a new project with the old 9-verb template, you may get the template by downloading older version of AGS and copying template file out of Editor program files. Or download it directly from a github repository here:
https://github.com/dkrey/ags_9verb-template/releases
But I suspect that you may also need to use Backwards Compatibility options in this case.

Do you mean that you need a 9-verb template files themselves, or that you want to upgrade an existing game to 3.6 but met some problems?

Besides performance, you need to be aware that scaling 2D games down works quite badly, so anyone who cannot run in 2240x1440 will see a lossy, distorted image. It's much safer to do 720p or 1080p and then let engine scale it up to your bigger display, but then it will also run well for most people.

EDIT:
In theory it may be possible to readjust game camera based on display resolution, and have it display less portion of a scene at once. I've never tried, but I believe it may be done. Whether it will be convenient or not for the player, I cannot tell.

Just for the reference, all the template sources are available in our repository here:
https://github.com/adventuregamestudio/ags-template-source

You may download any files, or all the source awhole.

I still don't know what were you trying to do, but if you like to use GUIs in dialog, here's another method.

Dialogs may have their options turned on and off, and there's also a rule that if only 1 option is enabled at a time, then it's run automatically as soon as Dialog starts.

In summary the method therefore is this:
1. Disable all dialog's options.
2. Bring your GUI on and let player do something with it.
3. Depending on player's actions, enable a single dialog option, and start a dialog.
4. After dialog stops, disable that option and continue.

No, you cannot have any GUIs active during a dialog.

If you like to have buttons for dialog options, look into the Custom dialog options rendering:
https://adventuregamestudio.github.io/ags-manual/CustomDialogOptions.html
Or use existing module:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-customdialoggui-1-9/

If you want certain game GUIs to work along with the dialog, then you'll have to either script your own custom dialog system, or script particular scene without a use of a standard dialog. I cannot give any other advice here without knowing details about what you are trying to do. Please tell more about your case and goal.

I think I can imagine use-cases where this would be useful, but is it such a generally useful feature that it makes sense to build it into the engine rather than rely on some fairly simple scripting with the Tween module?

That is why in my earlier post I added a "if we'd like to implement "tweening" into the engine".

"tweening" into the engine (at least to functions like Animate).

This looks interesting but I don't understand how tweening works in a frame by frame animation. Is this for the frame offsets?

No, my meaning was frame timing. If the whole animation duration is represented as 1.0, the tween controls the current progress between 0.0 and 1.0, and engine would choose a frame based on that value.

I'm observing a seam between contiguous walkbehinds.  (I noticed this with patch 1, and I'm seeing it with patch 2 as well.)

You mention patch 1 and patch 2, did it happen before, or started only with 3.6.2 patch 1?
Does this appear with particular graphic driver / graphic filter combination, or all of them?
Which is the game scaling ratio which you run with (native game res vs window size)?

I've seen a similar issue in much older games, and that was caused by uneven texture scaling which caused subpixels. The only way to fix that seemingly was to either adjust walk-behinds by couple of pixels or replace walk-behind with an object and let it overlap another a little (although I cannot tell if that might work in your case).

I believe we may have both, both methods seem useful.

https://github.com/adventuregamestudio/ags/issues/2792