Messages

@Kiszonka this appears to be a mistake in PlaceOnWalkableArea. This function is run whenever a character ends up on a non-walkable area after walking (because of pathfinder imperfection), and idea is that it jumps a pixel to the nearest area.

I suspect that there may be a coordinate conversion mistake somewhere.

The easy way to reproduce the issue is this:

Code: ags

function on_key_press(eKeyCode k)
{
  if (k == eKeySpace)
  {
    Point* p = Screen.ScreenToRoomPoint(mouse.x, mouse.y);
    player.x = p.x;
    player.y = p.y;
  }
  else if (k == eKeyW)
  {
    player.PlaceOnWalkableArea();
  }
}

This puts a character on any place in room with Space key, and orders to move it to the nearest walkable area with W.

I posted this on discord this week but will mention it here too:

I am not available on discord at all times, and there's no guarantee that the bug reports will be noticed if posted in tech support chat, for instance, because nor me nor other developers read all of it consistently. It's best to post bug reports on forums or in our github issue tracker.

I found an "illegal exception" bug. This happened when I made a mistake in my code and used "%s" instead of "%c" when formatting a string to use String.Chars[]. The line that caused the error was inside a "for" statement, and looked like this:

Code: ags

String value = String.Format("%s", otherString.Chars[i]);

Changing %s to %c stops the error, but I assume there ought to simply be some kind of error message here that stops compilation of the game instead of a crash.

Added argument test into the engine. This may prevent crashes in majority of cases, but does not give a 100% guarantee. Because of how AGS script is compiled it's not always possible to know the value type for certain, and not possible at all when it is returned by a plugin's script function.

Opened a feature suggestion about implementing string format parsing in the compiler:
https://github.com/adventuregamestudio/ags/issues/2739

I moved from from 3.6.2.6 beta to 3.6.2.10, and since upgrading I've been experiencing an issue regarding characters walking.
When a character hits an edge of a walkable area, they sometimes teleport to a seemingly random location (sometimes more than 300px away).

It happens in more than one room in my game and I can repro this about 10%-20% of the time by hitting a specific corner in a specific room (image attached - teleport happens when walking from right to left).

Mask resolution of the room is 1:4.

Hello.

In order to diagnose the problem I will need a walkable area (could you export the walkable mask and upload somewhere?), and an example of walking order that results in this problem: starting and target coordinates.

Out of curiosity, why do you use 1:4 mask resolution? We've only have it in AGS as a formality, I have not heard anyone using this before (old games used 1:2 sometimes for performance reasons, and today people just use 1:1 most of the time).

Wait, what if you press the keyboard key corresponding to the empty dialog option?

I get the feeling it'd be possible to sequence skip with that. So perhaps that should also be disabled if the dialog option has no text.

This is already done. Engine keeps a list of the currently displayed options, and all actions only affect this list.

Here's an updated temporary build with all accumulated fixes so far:
https://cirrus-ci.com/task/5506729732997120

Following bugs fixed:
- Pressing Enter on Text Parser panel while no item is selected was causing an exception.
- Engine crashing if SpeechView has no loops.
- Speech displaying in a wrong place if there's a transparent GUI covering whole screen.
- Pink pixels appearing around sprites when the sprite anti-aliasing setting is on.
- Engine crashing if Character.DestinationX/Y is read while character is turning on spot after a call to FaceDirection.
- Dialog options with empty names are still displayed (as empty lines) and can be selected.



I will wait for a small while before releasing a first patch to 3.6.2, in case more regressions are found.

If there are problems then it's better to find them early.
We don't have a lot of testers, and people are usually reluctant to use a beta version unless they start a new game, so every time there's a new version release we expect more bugs to be found as larger number of users finally upgrade to it.

I tried this (using the engine exe from the new build) an cannot reproduce the problem.
I choose options 2,3,4 as you mentioned, and option 1 is still displayed afterwards and not run automatically.
After I run option 1, it goes into "search room" sequence.

Unfortunately, I do not see the script for the first option, and dFoundVictim3 dialog, so cannot tell if the dialog proceeded correctly after that.

Thanks! The empty option is now hidden, but it also behaves as if it was completely switched off. In my example, if I click options 2, 3 and 4, option 1 runs automatically (the game sees it as the only remaining one) and then the dialogue ends without option 5 being triggered.

I tested this several times, and it worked when I did.

I have 6 options, 1 of them without a name. Only 5 are visible, I click these in any order, and neither of them is run automatically. After the 5th are switched off, the 6th invisible one is run on its own.

Where can I see this dialog in your game?

Ok, here's a link to yet another test build:
https://cirrus-ci.com/task/5506729732997120

@Monsieur OUXX we also have an upcoming custom shaders support:
https://www.adventuregamestudio.co.uk/forums/engine-development/experiment-ags-4-custom-shaders-support/

Updated the first post with the new download link, now this version supports up to 3 secondary textures attached to a shader. Instructions are also updated in the first post.

For a quicker reference, the update contents are explained in this comment:
https://www.adventuregamestudio.co.uk/forums/engine-development/experiment-ags-4-custom-shaders-support/msg636683542/#msg636683542

The behavior of empty options was never documented, so I never thought about them.

I just tried this in various versions of AGS, starting with 3.2.1, and in 3.2.1 you could still select an empty option if you click on a 1-pixel high location after the options. Somewhere between 3.2.1 and 3.6.0 it changed to not being clickable. In 3.6.2 empty options are displayed in full line height even if they are in the middle of other options.

Not displaying them seems reasonable, and they were already used in older games, then I must revert this, and document this behavior in the manual.

After re-reading the question and trying to guess what the scene looks like, I think the more natural solution is to go opposite direction and don't use GUIs representing something that a character's hand may interact with, and use room object or room overlay instead. These may too display health bars, although it may be bit more work than with buttons (i don't see the picture so can only guess how it's made now...)

It turned out that the crash was caused by reading Character.DestinationX or DestinationY property while character is turning to face location.

The new temp build with a fix will be available here:
https://cirrus-ci.com/task/5641890608971776

I needed to create an animated rain overlay. So what I did is create an object that's full screen (for me it was 1280*720) .
I made sure the baseline puts that object in front of everything .

I was refering to a case when you need to display something above GUI, since that's what a OP asked. Room objects cannot be displayed above GUI.

@Honza I cannot reproduce this problem with your script alone. There must be something in the game's setup that contributes to this.

Since I've already got your game earlier, could you tell how do I get to this scene and reproduce this error?
(or, do you have any save made just before this?)

If engine displays a message with "Illegal exception" in the title, and similar structure ("An exception 0xxxxx" occured..."), that's a bad error in the engine, not a game's mistake. Please report such errors as AGS bugs.

This is not a regular "missing loop" error, this is a unhandled exception in the engine, which must not happen.

Only screen Overlays may be layered above GUIs. Overall room objects are always on their own layer and screen (ui) objects are on their own, they never mix.

The solution may vary depending on a situation. I could not completely understand what your case is, but in general, if you need something displayed over a gui, then the two obvious choices are:
1. Buttons can display any graphic and have Animate command. It may be button on the same gui, or a different gui made just for this button.
2. A screen Overlay (but if you need to animate that, then it has to be animated by changing its image frame by frame in script).

EDIT:
Of course there's a opposite solution: don't use GUIs representing something that a character's hand may interact with, and use room object or room overlay instead.

Besides that, (unrelated, or maybe not so much) I was also wondering if it is convenient to use as few views as possible or if that's irrelevant. In my case, I've started the game creating individual views for each character (even when some characters only have 1 or 2 views). Now, in the late stages, I'm using one same view to fit other's characters (or background) animations

Number of views does not affect performance in any noteable way. You may have 1 view per character, or split its animations into 1000 views, the result will be about same. View is simply a logical unit used to organize a list of sprites together.

What affects performance first of all:

1. Game resolution and sprite resolutions (sprite dimensions).
2. Amount of objects displayed at the same time.
3. Amount of animations run at the same time.
4. Rate of animation (how many frames per second).
5. Sizes of sprite cache and texture cache (latter since 3.6.1), which are set in game config. Small cache sizes means that sprites have to be reloaded and recreated often.
6. Lots of "raw drawing", creating Dynamic Sprites often and using Drawing Surfaces to draw stuff anywhere.
7. Complex scripts with lots of operations per game frame.
Obviously, if scripts are written in a suboptimal way, then they may be slower than could have been.

Also, different versions of AGS have different performance. For example, 3.6.1 had a significant boost to both script and graphics efficiency compared to previous versions.

Each situation should be analyzed separately, and solution will depend on the case and what's causing the performance issue.