Messages

[32]

@Eon_Star I did not realize that at first, but now when I double check your project files, and look at the error message again, I see that it mentions version 3.6.1.22. The latest 3.6.1 update is 3.6.1.32. There's a chance that this problem is already fixed.

I could not make out why this happened. At least I know it happened after adding or creating the dialog. The dialog error occured. Then this error came to be. I tried to run AGS 3.6.1 again but it showed me this error.

So I transfered the game to 3.6.0, which I think is more stable.

I won't be able to fix this error in 3.6.1, and it will remain less stable, unless I have an opportunity to observe and diagnose the problem.

If you get little spare time, could you, please, try making a copy of your game in 3.6.1 again and see if it still crashes? If it does, could you send me your project made in 3.6.1 for testing?

Hi,

Here is the screenshot:

Could you please clarify, at which point does this happen? is this related to this dialog script, if so then at which point in this script it occurs?

PS: Problem solved on AGS 3.6.0 but AGS 3.6.1 crashed. I will go with 3.6.0

Crashed how? Please post details, I would need to know if this is a problem in the engine that needs to be fixed!

Also see Game.DoOnceOnly in the manual: that function is commonly used for a one-time action in game:
https://adventuregamestudio.github.io/ags-manual/Game.html#gamedoonceonly

Hi All!! Can someone share ags262.zip? It would be greatly appreciated!!!

Here's a agsarchives torrent:
https://www.agsarchives.com/agsarchives.torrent

It contains all the AGS editors starting with v1.

Speaking of AI... There's something that I might mention. Recently (last couple of years or so) there have been certain number of spambots pretending to be humans posting on the AGS forums. Some of them were later uncovered as ones, some only suspected. Personally, I suspect [redacted], and also couple others recently active new users, but I also understand that it's not correct to blame without evidence, so won't. It's moderators' business.

Usually my suspicion triggers when there's a combination of following factors:
- It's a new user who just registered today or a couple of days ago;
- Has a simple forum name which looks auto-generated (this may be a subjective impression, of course);
- Makes a seemingly random or generic post, or several generic posts, very simple in nature (no actual useful information, citing stereotypic opinion, etc);
- Does not give any information about themselves (who they are, what games they play, what games they make, etc)
- Never replies back in the same thread, regardless of anyone replying to them.

My argument is that it's unlikely for a human to register on a adventure gaming tool forum only to immediately make a generic post or two and not engage in a conversation. Note: if you go to the user's profile, you may click on "Show Posts" link, and see everything they posted on forums so far.

Often, when checking on these users again, we can notice that they have spam links appearing either in their posts (by edit) or their signatures.

Could you please post the dialog script as a text here? I'd like to make a test and see if the problem will reproduce.

Please, don't post the screenshots of the code!, post the code text itself. It's much easier to read text then to read text on a image, and also makes it possible to paste your code into a temporary project and test things.

About the error: usually the cause of such error is that you forgot a closing double quotes or a brace somewhere.

Is this the only dialog that you have? Does the error mention exact dialog or the line number?

Of course, I would need to know coordinates of starting, middle and ending position of a walk, and character walk speeds. If a middle position is not known, then I also need a walkable area in order to replicate this kind of movement.

Sure, I've sent you a private message with the walkable area mask, the relevant information (start, end, speed), and a screencast of the behavior.

I checked this out, and what is happening is that somehow the pathfinder is confused by character walking too close to a 45-degree diagonal non-walkable wall: when the walk is from down-left to right-top position the pathfinder creates a path consisting of about 15 small chunks. When the walk is reverse, there are only 3 chunks.

You may see this, if you enable pathfinder debugging using "Debug(5,0)":
https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#debug

This is not seen using above debug mode though, but I learnt from reading the path data in engine memory, that they are following a zig-zag pattern. This cannot be noticed because the zig-zag change in direction has a very small deviation so it looks like it's a straight movement.
Then, the current walking logic in the engine restricts character step by the end of each walking chunk. Meaning that if the next character's move crosses past the check point, that move will be interrupted and clamped to the end point. This makes the character make much smaller steps than it could have.

I suppose that for the long term solution engine could propagate character movement amount further after the checkpoint. E.g. if we take movement step as 1.0, we may calculate how much the remaining part of the first chunk takes from that, subtract, and then apply the remaining fraction along the new chunk. That might generally make walking around corners smoother in terms of speed (when no turning on spot is required).

Another possibility that comes to mind is to analyze the returned path, and if we notice the zig-zag pattern with very small direction deviations in between (capped at certain difference), then we smooth the path, replacing it with 1 chunk.

As for the immediate solution, I may suggest experimenting with walkable area a little, maybe adjusting it a bit would solve such issue.
EDIT: one idea i have, try to make a "cut out" 2-3 pixels into the diagonal wall, but leave the corners intact. This maybe will keep the non-walkable pixels away from path when character goes around the corner.

An update, I've revamped script API, for the purpose of supporting custom shader parameters, and now it looks like this:

Code: ags

builtin managed struct ShaderProgram {
  /// Creates a new ShaderProgram by either loading a precompiled shader, or reading source code and compiling one.
  import static ShaderProgram* CreateFromFile(const string filename); // $AUTOCOMPLETESTATICONLY$
  /// Creates a new shader instance of this shader program.
  import ShaderInstance* CreateInstance();
  /// Gets the default shader instance of this shader program.
  import readonly attribute ShaderInstance* Default;
};

builtin managed struct ShaderInstance {
  /// Sets a shader's constant value as 1 float
  import void SetConstantF(const string name, float value);
  /// Sets a shader's constant value as 2 floats
  import void SetConstantF2(const string name, float x, float y);
  /// Sets a shader's constant value as 3 floats
  import void SetConstantF3(const string name, float x, float y, float z);
  /// Sets a shader's constant value as 4 floats
  import void SetConstantF4(const string name, float x, float y, float z, float w);
};

Here ShaderProgram represents a compiled shader itself, and ShaderInstance is shader's setup with certain constant values. You may think of ShaderInstance as a kind of a limited "material" type.

Game objects (characters, etc) now assign ShaderInstance pointer to themselves, rather than a numeric "shader id".

Each ShaderProgram has a "default" instance which is always present, and may be used when either this shader does not have custom parameters, or you don't want to set them up. On another hand, if you want to use same shader on multiple objects but with separate sets of parameters, then you can create more "ShaderInstances".
ShaderInstance may be assigned to multiple objects, in which case they all will share same shader setup.

For example:

Code: ags

player.Shader      = myShaderProgram.Default;
cCharacter1.Shader = myShaderProgram.CreateInstance();
cCharacter2.Shader = myShaderProgram.CreateInstance();
cCharacter3.Shader = myShaderProgram.CreateInstance();

cCharacter1.Shader.SetConstantF("CustomConstant", 1.0);
cCharacter2.Shader.SetConstantF("CustomConstant", 2.0);
cCharacter3.Shader.SetConstantF("CustomConstant", 5.0);

More details are in the updated PR post:
https://github.com/adventuregamestudio/ags/pull/2716#issue-2987287896
Downloaded experimental build here:
https://cirrus-ci.com/task/6359903394070528

AGS built-in save system creates saves that keep full state of a game, meaning they contain a dump of all game objects properties and script data, both statically and dynamically allocated. This includes states of all visited rooms too. This is done regardless of whether this is actually necessary or not, because the engine does not know what has to be saved. There's currently no way how a game developer may instruct AGS to exclude particular objects or script data from saving, or save only chosen data. Therefore, the size of saves does not depend on game's linearity or complexity of its story logic, it depends only on the number of things in game overall.

The only way around that for the game developer is to write their own save system that only tracks story progression. But very little people bother with that, it seems. There's also a feature that allows to skip certain types of data, but it's only available in the newest version of the engine, and has restrictions to how it may be used.

Normally, the total sizes of game objects in save should take maybe hundreds of kilobytes (unless the game has absurd amount of content). If the save is tens of megabytes large, that usually means that something big is allocated in script. Sometimes this may be an indication of leftover dynamic data created for one scene and never deleted; in which case it may be fixed. There may be other ways to reduce it. But, in any case, this is something that game author should be addressing. One would have to investigate the contents of the save, or what the game does, in order to find out what causes this exactly. 

Why the standard saves are not compressed - that is a good question, I suppose they could be, but this was never implemented.
I thought about doing this many years ago, but kept forgetting. I'm not very good at planning and prioritizing tasks. Unfortunately, users did not give much feedback about this problem either.

Please post the code that you are using, then it will be possible to tell what you are doing wrong.

Thanks, CW!  From the fix list from 3.6.1 Patch 10, I'm still hitting the following issue in 3.6.2 RC3:

- Fixed Character movement recalculation when changing move speeds while walking, and movement path contains 45-degrees diagonal segments.

When the character moves right horizontally, then up-right diagonally at a 45-degree angle, they move at the expected speed during the horizontal segment but slow down substantially during the diagonal segment.

When the character repeats the same pattern in reverse (moving down-left diagonally, then left horizontally), they move at the expected speed through both segments.

(If you'd like me to share the walkable area mask, let me know.)

I see now that I did not describe the fixed bug properly. The bug that I referred to occured when you call Character.SetWalkSpeed() during walk. In that case the character started walking into a slightly different direction.
If that is not what is happening, then that might be a separate issue.
Of course, I would need to know coordinates of starting, middle and ending position of a walk, and character walk speeds. If a middle position is not known, then I also need a walkable area in order to replicate this kind of movement.

- Fixed a number of region or hotspot's "Stand on hotspot" events may unexpectedly run after a blocking character's walk, even if character is no longer standing on that region/hotspot.

I just noticed that if the player walks onto the region during room_AfterFadeIn(), regionX_WalksOnto() is no longer triggered.  Is this intended?

It is intended to NOT run region "walks onto"/"walks off" during blocking walk, and IIRC that was always the case in AGS. What I have fixed is that AGS accidentally scheduled these events and could run much time later, after all the blocking actions have finished.
Is your walk blocking? Does it matter if it's "After fade in" or not?

I posted your first code snippet into 3.6.1 editor, and it compiled fine...

But, it has changed recently ? I remember errors while compiling, with the message " 'ressource' is already defined". I didn't know it was possible now...

No, it has always been like this. The error happens when you have 2 variables of same name in the same scope. Like, two global variables.

The games are not real world, and have their own rules. In real world I know that I can pick up any item around me, but I do not pick everything up, instead I am searching for items that match my purpose. But in the game that's not the case. Not only I cannot pick up any random visible object at will, but often I don't even know what's the purpose, for example, if I entered a location with a quest item without having a quest yet.

For that reason, I think that the good game should hint which items can be picked up, either using a visual cue (distinct positioning, animation, highlight, difference in colors, a label with item's name under the cursor), a cue in a dialog, or else. Otherwise a player will be forced to click every piece of the room trying to figure out what they are supposed to do.

But then I thought, half the fun of these games is exploring the screens and figuring out what you can interact with.

Hmmm.... that's very subjective. This may be a part of the gameplay in particular sort of games, but in general adventure game trying hard to find what you can interact with in every room quickly becomes a tedious experience. Especially if there are multiple extra verbs (push, pull, open, etc). But then, this is also a issue of "adventure game logic". In adventure games the logic is traditionally "inverted". In life we know the purpose first and look for solutions after. In adventure games it's often other way around, and I cannot say if that's a good thing.

EDIT:
I might add, that in case of very small items one approach is to provide a close-up view of a part of the room, like a table, where the items are located.
For example: let player "look at" table, which brings a close up view of that table. Again, in real life you may take a closer look at things, but in 2D games that's not a general mechanic unless you implement it in specific cases.

For example :

Code: ags

// In another script :
int ressource [TOTAL_RESS, TOTAL_CATEG];
// This is exported and shared with all other scripts
// ...

// Then in Global Script :
function Myfunction ()
{
  int ressource=Random(8);

That is the situation that I was speaking about: a variable of same name but in another scope.

Following is a valid case in AGS script, as well as many other programming languages (C++, C#, Java, Python, etc):

Code: ags

int variable; // global variable

function f()
{
    int variable; // local function variable

    if (condition)
    {
        int variable; // local variable of a inner scope (1)
    }

    if (condition2)
    {
        int variable; // local variable of a inner scope (2)
    }
}

The compiler does not treat this as error.

Usually it's advised to invent a naming style in which global and local variables will have different names.
For example: call global variables with some prefix, like "gl_" , or use capital letters in their names, and call local variables in small letters only.
That will also help to quickly distinguish if that's a global or local variable when you see one in code:

Code: ags

int gl_Ressource [TOTAL_RESS, TOTAL_CATEG];

function Myfunction ()
{
  int ressource=Random(8);
  ....

[Editor:]

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

This update contains all the new features and fixes from 3.6.2 RC3 (excepts ones related to backwards compatibility).

Editor:
- In General Settings added "GUI common controls handle only left mouse button" option.
- Fixed default values for Character and Object's Enabled and Visible properties set when upgrading a pre-4.0 game project.
- Fixed default value for "Use old-style voice clip naming rule" setting set when upgrading from older 4.0 alpha versions.
- Fixed newly created WFN fonts had their size multiplier property discarded when a game is compiled.

Compiler:
- Fixed a bug where naming a parameter like its function led to a crash.

Scripting:
- Support regular (non-managed) struct and array variable initializers, where you can specify their element values either in the order of their declaration or as a "name1: value, name2: value" sequence. For arrays the latter would be "0: value, 1: value" and so forth.
  NOTE: this works only for global variables at the moment.

Script API:
- Added DialogOptionsNumbering enum, to use when setting dialog options numbering mode.
- Added multiple new properties to Dialog type: OptionsBulletGraphic, OptionsGap, OptionsGUI, OptionsGUIX, OptionsGUIY, OptionsHighlightColor, OptionsMaxGUIWidth, OptionsMinGUIWidth, OptionsNumbering, OptionsPaddingX, OptionsPaddingY, OptionsReadColor, OptionTextAlignment. Most of these are replacing previously existing old-style variables in "game" struct and OPT_* options. OptionsGUIX/Y and OptionTextAlignment are completely new features.
- Added new game-wide option OPT_GUICONTROLMOUSEBUT that defines whether common GUI controls are affected by the right mouse button or not (InventoryWindows are excluded from this, because they have their own special handling for RMB).

Engine:
- Standard Dialog options now support Right-to-left text mode.
- Fixed a number of Room's script indexed properties not working correctly, such as: Room.Hotspots[], Room.Objects[], Room.Regions[], Room.WalkableAreas[], Room.Walkbehinds[].
- Fixed blend modes not handled correctly by Software renderer.
- Fixed certain blend modes not respecting transparency with OpenGL renderer.
- Fixed default dialog options highlight color had wrong value.
- Fixed Character.FaceDirection() not respecting blocking style parameter.
- Fixed characters and objects not making last planned step when moving.


This update has a new script syntax feature that allows to initialize a struct or array using a "initializer list". Unfortunately, this feature was not fully completed, and only works for global variables. There's a chance that it will be expanded to local variables too in the future updates.

Example for structs:

Code: ags

struct Location 
{ 
    float Longitude, Latitude; 
};
struct PointOfInterest
{
    int AdmissionFee;
    Location WhereItIs;
};

PointOfInterest EiffelTower = {
        WhereItIs: { Longitude: 48.8584, Latitude: 2.2945 }, 
        AdmissionFee: 20 + 3,    // ← Simple 'int' or 'float' expressions are possible
};

Example for arrays:

Code: ags

int Primes[10] = { 2, 3, 5, 7 };

Code: ags

bool IsPrime[10] = {
    2: true,     // ← means, IsPrime[2] is 'true'
    3: true,     // ← means, IsPrime[3] is 'true' etc.
    5: true,
    7: true,
};

There's a problem with the manual, in the description to GiveScore it never mentions or references game variables, but sais "Adds SCORE to the player's score." I suppose it's easy to misunderstand that as that score is a part of the "player" object in script.

I will add a correction there.