Messages

There's a basic PO support, but barely any PO features have been implemented yet.

[EDIT:]

What about something like this:

The Y/X relation of diagonal directions at which Character switches from horizontal to vertical walking loops. Default is 1.0. <1.0 would use horizontal loops for more angles, >1.0 would use vertical loops for more angles.

EDIT: actually, maybe the direction of diagonal loop is a more important use case rather than "how many angles" use vertical and horizontal loops.
So above may be reworded as
< 1.0 would make diagonal direction more vertical, > 1.0 would make it more horizontal
or something along these lines.

The manual may contain more thorough explanation with diagrams.

Probably was overthinking this problem.

This is resolved then.

Argh, it's been a full year, but I forgot to write a ticket for this, and it completely fell out of my mind. Someone reminded me of this just now...
But 3.6.1 is so close to release now, and I am afraid to hack it further.

I opened a ticket now:
https://github.com/adventuregamestudio/ags/issues/2311

There's a chance we may have a "smallish" update after 3.6.1 to cover this problem. But this may be done in AGS 4 right away, and backported later.

This was resolved in 3.6.1

I need help with writing description for this property in the editor, something that is brief, but clear enough for users to understand what it does.

The cases like this may be difficult to diagnose within a full game. It would be more convenient if one makes a dummy test game with just this module and commands that set it up, and does this SetWidth change.
If that alone does not work, then keep copying any parts of the code that may affect the module or overlay that it creates.

@noblonski

I found the module here:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-floating-hotspot-label/msg636606047/#msg636606047

When I check the code for the SetMaxWidth, here how it looks like:

Code: ags

static void FloatingHotspot::SetMaxWidth(int width)
{
  MaxWidth = _clamp(width, 10, System.ViewportWidth);
}

In other words, it limits hotspot to the range 10 -> ViewportWidth.

I am not sure how this may have different effect between 3.6.0 and 3.6.1.
Could there be another reason why it became invisible in 3.6.0?

On a side note, I think it's a design flaw that there's no function that would hide this overlay explicitly, like FloatingHotspot.SetVisible.

[Engine:]

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

Engine:
- Updated to SDL 2.28.5 and SDL_Sound 2.0.3+.
- Display critical alerts as message boxes on all platforms that support that (unless engine is run with "--no-message-box" parameter).
- Fixed failing comparison between character[] script array's element and a Character* pointer (regression since the recent 3.6.1 RC).

iOS:
- Fixed some game elements could potentially be rendered incorrectly in "Render in screen resolution" mode.
(NOTE: this is NOT related to Dave Gilbert's problem described above.)

Well, wording may be changed to a more affirmative of course, but my only intent was to make it clear that, unlike other builds, you have to do certain things by hand.

I have a ready Mac VM (I think the version is called Catalina), but I am not a Mac user, and don't know much about it. I only tested changing game file in a precreated bundle and running the engine so far.

I had an opinion that 64-bit engine should be made default, and 32-bit provided as an option which is not enabled to build by default, in case someone would like to build for 32-bit systems too.

Also we could still provide a separate 32-bit engine for download for the time being, in case someone would want to package a game with 32-bit exe by hand.

I think the post should first of all overview the situation, and explain that you cannot build for Mac from the Editor at the moment

Ahn, the steps for that are basically

I meant to have a simple paragraph at the top of the post, literally explaining the situation that:

AGS Editor cannot prepare game for Mac automatically at the moment. This may be changed in the future, until then this has to be done manually. Your options are:
1. Build engine yourself;
2. Use someone elses built engine;
3 ....?


And then go on with explaining each variant.
This is to make the situation clear for end-users from the start.

[syntactically correct]

Frankly, I was expecting missing brackets or something similar.

This could solve the problem. But I do not understand. Should AGS not warn me about the missing code parts, if the brackets are missing?

AGS cannot know which part of the code was supposed to be under condition. It can only check the script syntax, but not the meaning.

For example:

Code: ags

if (condition)
    action1;
action2;

Here only action1 is under condition, and action2 will be run always.

Code: ags

if (condition)
{
    action1;
    action2;
}

Here action1 and action2 will be run under the same condition.

Both variants here are syntactically correct, but they are logically different. Neither of them is "forbidden" though, because you may have a situation where variant 1 is fine, and another situation where variant 2 is fine. Yet only you know which one is correct for your case, AGS cannot detect this.

@Eon_Star please post the actual script from your game, the part where an item is used on this hotspot (wardrobe, as you say) and the keys found. I need it to determine whether this is a script mistake, or a engine's mistake, and also to be able to reproduce the issue myself in a test game.

I must see the real script, because it's not always clear what is happening from simple explanation, and small details may also matter.
"Using inventory item on hotspot" may be done in many different ways, and I do not know which one you're doing.
If it's an engine's mistake, then I still must know which exactly script is causing it.

Playing game for this test is very inconvenient for many reasons. First, I will not see actual commands that you are using, so I will have to run it step by step under debugger, which will take alot of my time. Second, even if I'll find out what is happening, I will not necessarily know what is intended and what is not intended.

Opened an experimental PR:
https://github.com/adventuregamestudio/ags/pull/2304

My proposal for the name is "FaceDirectionRatio". I added "Face", because theoretically there may be other directions (like direction of movement etc).

EDIT: I added properties to Game, Room, Walkable Area and Character.
These may be set in the Editor and changed in script too (not all covered yet). I think for Character I'll only leave the script property for now (no design-time setting), because it seems like something that has narrow use and purpose to be changed dynamically in special cases (?).

Hi  I recently made a game using this version. I was informed that there is a bug in AGS. UseInv on hotspot function issue was found. Player can use any inventory item on a hotspot which should not happen. I only made one invent item to be used on that hotspot. The script is clear. Can this be fixed?Thanks for you efforts.

When you have problems with a script, please always post a relevant part of the script and explain your intent for it, otherwise we cannot help you.

We would like to know if these are the only resolutions available, or is there also an option to set custom resolutions?

@Crimson Wizard , could you possibly shed some light on this?

AGS has a custom resolution setting. The Editor only provides a list of common ones for a quick pick, but user may set virtually anything, including "vertical" layout where height is bigger than the width.

Building from Editor is the thing that interests users most. I think the post should first of all overview the situation, and explain that you cannot build for Mac from the Editor at the moment, so either you need to build Mac engine yourself on Mac machine or VM using Xcode, or get an engine built by someone else (that matches your game).

If there are two different routes, like, with embedding game files in some container, and just placing them near engine by hand, then both options should be explained.

We may update the post later if situation changes.

What I was referring to is if the game is running on a 4K monitor, keeping it in linear interpolation mode still looks decent.

Ah, alright.

Have you tried "smooth scaled sprites" option? I think it uses linear interpolation for scaled sprites, while keeping the final game scaling using nearest neighbour.
This may or may not improve things with zooming things even without "render in screen resolution", but I cannot predict how that will look like.