Messages

@lafouine88 What eri0o suggests is basically to try using player.WalkStraight instead of Room.ProcessClick(... eModeWalkto).

WalkStraight command should be much faster than regular Walk, because it does not search a path, but only tests the direct line in front of a character and stops if a wall is met. This works like "raytracing".
See https://adventuregamestudio.github.io/ags-manual/Character.html#characterwalkstraight

Other than that, you may replace AGS commands with your own that:
- Animates the character
- In rep exec moves the character into the direction pointed by the mouse by directly changing character.x,y properties with certain speed.
- Tests for a wall ahead.

That's not too hard to do, perhaps try that if WalkStraight did not solve the problem.

[MUST MATCH THE GAME PALETTE]

But then I met another problem. Color 0 (no area) cannot be achieved this way for some reason. Block color always gets converted to index 16, because index 0 serves a special meaning (transparency).

Alright, I found the way.

I had to do more fixing in the engine for this to work, not exactly related to room masks, but to DrawImage command when a sprite is of higher color depth than the surface. There will have to be a new 3.6.1 patch with this fix.
I might post a fixed 3.6.1 engine here if someone wants to give it a try:
https://www.dropbox.com/scl/fi/d3zjq91yrhddt9k3u7hrt/acwin-3.6.1-fixdraw32on8.zip?rlkey=yicgf48ixz7xzs2gnpfhrjweo&st=5egu0wqk&dl=0

Anyway, the solution is following:
1. Draw a bitmap in your paint software. This may be a 8-bit bitmap, or 32-bit bitmap. That does not matter in 3.6 because 3.6 converts everything to game's color depth, as been noted. So you might as well save it as 32-bit.
2. What is important: all the colors that you use in this bitmap MUST MATCH THE GAME PALETTE colors in slots 1-15. Check out your game palette in "Colours" tab in the editor. This must be done to make those colors match the walkable areas 1-15 when you will draw this sprite in script.
3. Another important thing: you cannot achieve "area" 0 on this sprite, unfortunately, because its treated as a "special palette color" by AGS when converting a sprite. Because of that the "walls" must be done as a transparent color instead: you should import this bitmap and tell to set the wall pixels as transparent pixels. They will become "magenta" after import, and that's fine.
4. If you followed these rules correctly, you will now be able to draw this 32-bit bitmap on a 8-bit room mask in 2 steps:
- clear the mask with color 0.
- draw the sprite on it.
The "clear" step is required because the sprite has "walls" as transparent color, so they won't be drawn.

Code: ags

  DrawingSurface *ds = GetDrawingSurfaceForWalkableArea();
  ds.Clear(0);
  ds.DrawImage(0, 0, SPRITE_NUMBER);
  ds.Release();

@Crimson Wizard if the person is me, I just never used the masks drawing with loading a file, but I drew them in script. Also I needed more than it was possible by the number of walkable or whatever areas (I remember I had an issue on this at the time). In the end I just faked everything using regular dynamic sprites - which also gave me more bits.

No, it was @Snarky originally who mentioned this, but maybe this was just an idea, and he did not need it for himself.

I made a mistake, CopyTransparencyMask does not work if sprites are of different color depth. Although I think that might be technically possible to do, but AGS does not support that at this time.

Drawing a 32-bit sprite over a 8-bit mask is still possible (after I fixed it to not cause memory corruption).
But the problem is that colors have to very closely match the game palette. This is necessary to make the engine convert 32-bit color to palette indexes correctly.

So when you draw your mask sprite you must have colors exactly as game palette colors from slots 0-15.

This works, sort of.

But then I met another problem. Color 0 (no area) cannot be achieved this way for some reason. Block color always gets converted to index 16, because index 0 serves a special meaning (transparency).

I tried to do this in two steps: choose certain different color to be the "non walkable" area, then try to remove it using RemoveWalkableArea(N) in script.
But calling RemoveWalkableArea causes room to completely restore its walkable area to original, overwriting anything that you painted over it.

It is apparent that this was not very well tested, and has a lot of limitations.

I added this ability because someone suggested, but I guess they never tried to work with this either.

I get where you're coming from and I totally understand that you don't want to follow every fashion trend, but double-clicking and interrupting a walk by a player's input has been a standard for over 10 years now. Just like the popup inventory bar, it's not going anywhere because it has proven it's worth in the adventure genre. That's why I think they deserve to have at least a basic function that can then be further defined by scripting.

No, "double click to exit" is a way too specific behavior to add it inside this engine.
AGS already has enough basic functions to do "double click to exit" in script rather easily.

We might definitely add a explicit "double click" event for the script, and we might even consider adding an individual "double click" event for hotspots too.
But not more than that. What happens on "double click" is a task for s game script, not the engine.
We like to suggest and encourage users to write game templates that define standard control schemes, and share these.

For the last several years we've been trying to remove some of the overspecialized engine's behavior, or replace it with more basic functions that would let users recreate and customize these in script. You've mentioned a "popup inventory bar". In the past we've been considering to remove the builtin "Popup when mouse is at top of the screen" gui style from the engine completely in the next major version, because it's at the same time a) limited, b) has a number of hardcoded quirks that sometimes contradict user's expectation. If you check out BASS template, for instance, it is not using the built-in "popup at y" gui style, but has one coded right in script. So we're sort of been going into the different direction lately.


As for the "exit", having any interaction leading to "exit" requires to have "exit" as a game element. Something that may be created and configured in the Room Editor. Unless that is implemented, any kind of special interaction regarding "exit" will be overcomplicated to do in the engine.

Maybe it would make sense to implement such type of game element. But this is a engine design question that I cannot discuss right now, it touches bigger subjects, such as, where is the line between what should be in the engine and what should be in script. Like I said, every engine has its own. Without defining that, any feature addition will bring a risk of complicating the engine and increasing inconsistency. I have my own opinion on this, others might have theirs.
If someone would like take control and responsibility over AGS design, they could decide which other game elements AGS needs, and their standard behavior.
I cannot do this, because I already have enough of work, and I am actually at the edge of deciding to leave this project, been working on it for over 12 years and grown very tired of it.

If by "game encoding" you mean the current text encoding mode, that may be received by

Code: ags

GetGameOption(OPT_GAMETEXTENCODING)

https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#getgameoption

Note that this value will change whenever a translation loads, if translation has a different encoding.

EDIT:

there's also IAGSEngine.GetGameOptions, but it returns a raw pointer to engine memory, and thus this function is deprecated in AGS 4.

I cannot use drawing surfaces to import my walkable areas (maybe because of the 8/32bit transformation.

So, I tried that and there seems to be a bug in the engine, when you try to draw non-8bit sprites on walkable surface it corrupts the game memory. This must be fixed first, and after that see again if it might work at all.

There's also a chance that this may be done differently, if DynamicSprite.CopyTransparencyMask works between sprites with different color depth. If it does then:
* create dynamic sprite from walkable area's drawing surface (the sprite should be 8-bit)
* fill the sprite with color 1
* use DynamicSprite.CopyTransparencyMask to copy only transparency from the imported sprite to 8-bit sprite
* paste 8-bit sprite back onto walkable area.


I will have to find some time and experiment with this.

You just throw that into an If statement, and there you go.
Something like this:

Code: ags

if(move_player(248, 178))
{
  player.ChangeRoom(2,7,75);
}

It would be nice if there was a function that already did this though.

Alright, it might be possible to add a modified variant of Walk function, that is interrupted by player input and returns a boolean result.

But this raises a question: how do we customize the interruption?
Right now there are several separate skipping settings already in AGS: for speech, for video, for cutscenes. There's Wait command that accepts a "input type" as an argument, but does not let to e.g. specify exact button or key.
Supposedly we could add similar argument to the Walk function. Which other functions may require that, which will eventually be asked by users?
Character.Walk and Character.Move, Object.Move; what about other blocking functions such as Animate, will it need interruption too?
Is it good to have this as an argument to each function call, or this should rather be a game-wide setting?
This has to be well designed.

If there were this "Actions" feature that eri0o once suggested, where you define "Action" and setup controls for it, then we could utilize that. But without one, I'm afraid this will just add another bit to the pile of mess.

**EDIT:**

Hypothetically, if I had to do this in the engine, then I'd probably introduce a new BlockStyle type, something like eBlockCancellable (can't figure a better name now). This will allow to tag commands which you want to be interruptible per case more easily. Then add a game-wide setting that defines skipping controls for ALL functions that are run with eBlockCancellable.



And I need to clarify again: because this function is blocking, nothing else will work during its run. It may be only "interrupted", but it won't be possible to do things like:
- issue another command while character still walks (you'd have to do 2 clicks: first interrupt current walking, then order something else);
- interact with any GUI
- open a menu
- pause the game
- exit the game
etc.

All the above cannot be fixed without scripting this in a different way.
So, I am in doubts here.

I still think that the fact that the default settings of a hotspot is to make the mouse cursor invisible is anything but intuitive.

There's no setting of a hotspot that makes cursor invisible.
A number of things must be clarified here.

The only case in which hotspot does something automatically is when:
* you use its "WalkTo Point" property. I don't remember if there's a way to disable this other than not having this "WalkTo Point" set. This is one of the unfortunate quirks of AGS.
* have "automatically walk to hotspot in Look mode" option set in General Settings. That's another ancient quirk, which is there mostly for backwards compatibility.

If you do not have "WalkTo Point" set, nor that option enabled, then AGS is not supposed to do anything on its own. Instead it does what you command it to in script.

In any case, when AGS is running a blocking action, like function that you call with eBlock argument, or Wait() command, it enables a "waiting" mode, where all GUI is disabled, and mouse cursor switches to "Wait" cursor mode.
Each cursor must have a graphic assigned to it. If none is assigned then none is drawn. If you do not have such graphic assigned to Wait cursor, then during waiting mode you will see no cursor.

The rest depends on whether you want a blocking or non-blocking action.

1. The game engine is a system of multiple levels of functionality. There's a core level which provides most basic functions, and then there are advanced levels that have more complicated and specialized ones, but any advanced function is ideally built of the basic ones. These levels are usually divided between the engine itself as a program executable, and the game script, written by its users. The game script futher may contain several of such levels. It is possible to write your own "game framework" fully in a script, which is then used as a foundation for your own games, or given out to other people to base their games on.

The thing here is that the lower the level the harder it is to customize the functionality, and the more difficult is to change anything. If a function is inside the engine, it will affect everyone, whether they want it or not, and they won't be able to modify its behavior without hacking and recompiling the engine. If a function is in a game script - then it will affect only people using that script, and these people will be able to modify the behavior easily.

The balance, the distribution of what is implemented inside engine program itself, and what is implemented in the script, is the significant problem of program design. Each game engine may decide this in its own way.

AGS is the engine purposed initially for adventure games, so it already has a big number of specialized things in its core functionality: things like inventory, speech, etc. But at the same time it provides more basic functions which are enough (at least in many cases) to customize, or remake any kind of behavior from scratch.

But it is a very old engine, and its core behavior sort of "solidified" in its state. Changing it now may be difficult for programmers, because it has to be "plunged" into existing system, and also because it will affect every user. Adding complex functions into the engine may also be difficult, because it's not easy to design them universal or customizable enough to suit majority of users.

This is why today we prioritize adding "basic" functions instead: something that will increase user's ability to script things the way they prefer in their own game.

2. AGS is a very old engine, it was created 25 years ago. Back then the standards and habits were different; people mostly wanted to replicate classic adventure of 80-ies and 90-ies. The initial AGS functionality addressed these wishes.

Supposedly, it might be possible to add new functionality that addresses todays "adventure game standards" into the engine. But how wise that would be?

Let's take "double click to exit" example.

First of all, AGS does not have a concept of "exit", at all. There are things like hotspots, characters, objects, but none of them are "exit". The thing serving as an "exit" is defined only by the commands that user types in script. So, if we want such function built-in into the engine, we will have to introduce a complete new concept. Whether that is a new type of object, or a new property of hotspot, etc, something that would let users to tell "this is the exit".

Then, having such exit to trigger when player double click on it, that's a quite a specific behavior. It may be a "standard" today, but what would happen if users will suddenly want a different one? Hold mouse button for 1 second, or make a gesture with the mouse. Should we modify the engine every time a "fashion" changes?
What if users will want to support hotkeys on keyboard too? Or another device, such as touch-screen on mobiles. What about porting the game to consoles that don't have a mouse at all: there would have to be certain combination of buttons and stick moves on gamepad.

If that's done inside the engine, that will be an endless annoyance for both the engine developers, and also users who want something else.
If that's done inside the script, provided engine lets script this easily enough, - each game developer will be able to customize their game as they see fit.

Of course, requiring each individual user to do this from scratch may not be a good thing. But this is where shared script modules come into play. If someone writes a module, or a whole "framework" in script that implements "modern standard" for game controls, then others could use that too.
Engine's responsibility here would be to provide all necessary basic bits, from which such framework could be scripted.

(I've previously argued that this should be the default setting. What template are you using?)

So, we forgot to change that.

This would need 2 changes:
1. Change this setting in all affected templates.
https://github.com/adventuregamestudio/ags-template-source
2. Preferably change the "default value" attribute for this property in the Editor (this defines when to mark properties in bold font and when not).

Right, I missed this question:

It would be also nice, to support double click to skip the walking instantly to change the room.

AGS provides you with basic functions, but requires that you script any advanced behavior yourself.
It has everything necessary for you to script double click which skips the walking to destination.
There's "on_mouse_click" function that detects clicks, alternatively mouse button state may be tested in "repeatedly_execute" function.
Skipping Character's walk may be done using SkipUntilCharacterStops() function, or simply moving character to the target walking position, referenced by Character.DestinationX/Y properties.

I'm just quickly overviewing this here, maybe there are other things that will have to be addressed in your particular case.
There also may be existing script modules or templates that do what you need.

Overall, I recommend to rather begin with asking "how to do this in AGS?" questions in the "AGS Support" section of the forum, because for the most part there are existing methods to do what you want, even though they may not be obvious at start.

[FURTHER EDIT:]

The basic way which lets player to cancel a continuous action in AGS is to call such action with eNoBlock argument.

Such as:

Code: ags

function stairs_Interact(Hotspot *theHotspot, CursorMode mode) 
{
    character.Walk(248, 178, eNoBlock);
}

And then detect when the character actually arrived at the location and call ChangeRoom in a separate event, using either "stand on hotspot" event, using a Region, or Room's "crossed edge" event, whichever seems more suitable.

That is, so to say, a foundation of scripting non-blocking sequences of actions in AGS, when some things (like character actions and reaction to player input) are supposed to happen in parallel. You break the chain of actions in 2 or more parts: the start and the end (etc), and separate them in script.

If you need another event to happen after certain previous action has finished, while player retains ability to control the game, but detecting a "position" is not suitable, then this is done by testing current character or game's state in "repeatedly_execute" function. There's a related article in the manual:
https://adventuregamestudio.github.io/ags-manual/RepExec.html

I suspect that certain blocking actions may be cancelled with player input, if you test for mouse button states in "repeatedly_execute_always" and issue a command that cancels the current action, e.g. character.StopMoving(). But that may not be convenient for a number of reasons, so above method is preferrable.



FURTHER EDIT:


I suppose that it could be technically possible to support interrupting blocking Walk by a player's input. After all Say command and few similar ones (Display, etc) are intended to be interrupted by input (mouse key). So why not do the same to Walk (and others)?
The simplest answer is probably: that won't be enough to solve your problem, and may create more inconsistencies in the end.

The problem is, AGS scripting system is made in such way, that it does not allow to have two or more script functions run simultaneously, nor have player input events (mouse clicks, key presses, etc) be handled while the script function is running, or any blocking action within it. The script functions also cannot be interrupted or aborted from elsewhere.

If player "cancels" the Walk command, the script execution will return to the same function and continue running next command (ChangeRoom in your case).
In order to fix that , you would have to check for Walk's result. Like in this pseudo-code:

Code: ags

result = character.Walk(248, 178, eBlock);
if (!result)
    return; // break out of the function
character.ChangeRoom();

Here it looks simple enough, but imagine you have a longer sequence, then your script will have to be littered with these result checks.

Furthermore: since in AGS you cannot handle player's input events in script while a blocking command is running so functions like "on_mouse_click", "on_key_press" and similar - won't work during blocking walk. That will prevent from freely scripting and customizing reaction to input during this action. Because of that, if we have a "cancellable" Walk, then we'll also have to introduce extra input configuration for cancelling, just like there's a configuration for skipping speech now, because each game developer will want their own control style.
And still the list of what is possible to do during a blocking Walk command will be very limited. For example, GUI won't work, so player won't be able to access menu while character is walking, and so forth.

Therefore such function support will solve one tiny issue, but won't raise general restriction, won't make things much easier.

So it is rather essential to learn how non-blocking actions can be scripted in AGS instead.

Is the purpose to have mojoAL as a submodule, or have our own branch of it?
I don't recall, do we still have any changes of our own that are not applied to upstream; or are any planned?

What happens when the engine is run on an incompatible macos, is there an error on launch, or random errors later?
If it still launches, is there a way to detect that the OS is too old and report the warning?

Hmm, I have a suggestion to separate a question of executable's compatibility out in its own problem.

From my perspective (for instance), the first issue with macOS port is that there's no clear and fully detailed information on how the game is prepared for it in the "official" place, such as a forum thread (where this will be in a first post) or a article in the manual.

Because there's none, it's easy to miss or forget information (since I am personally not working with mac), and also difficult to help if someone asks. If there were an "official" article explaining how to make the mac game bundle step by step, possibly providing a minimal working template, that would be a good start.

Such instructions would assume that executable is available, but not specifying how just yet.

Then, the executable itself is a distinct problem. There will be 2 user groups:
1. Ones that cannot build it themselves (no mac machine, have no skills, etc). These will have to use the one that we provide. In such case they will have to live with the fact that this exe may not work on old systems. For those we would need to provide an active download link.
2. Ones that can build it themselves, or can ask someone to build for them. These will handle the situation on their own. For those we would need to provide build instructions (i think this is what readme.md is in our repository).

At least that's my vision of the situation...

Alright, so these are the instructions:
https://www.adventuregamestudio.co.uk/forums/engine-development/ags-engine-mac-os-x-port/msg636660447/#msg636660447

In these instructions "app" is likely the Mac engine executable. "Resources" folder should contain game files from "Compiled/Data" from AGS project.

In regards to "Info.plist", current instruction is that it should be "xml", and it should have an entry "CFBundleExecutable" inside. But that's not enough to write one for someone who never did that before.

Is there any example of how "Info.plist" should look like inside? At the very least a user must know how to form this xml, the opening tags etc. How does "CFBundleExecutable" points to the executable, is that a relative path?

EDIT: alright, I found one in our repository:
https://github.com/adventuregamestudio/ags/blob/master/OSX/xcode/AGSKit/AGSKit/Info.plist
So this likely may be used as a template.

There's also information about this in the Apple docs, but I'm afraid that many users may find it not easy to understand:
https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html

@Crimson Wizard everytime I try to put the binary release from macOS in the release assets of the CI people complain it won't work in their unsupported version of macOS

Could you elaborate, what are "unsupported versions"? Is this about old versions, or unofficial versions?
Does this mean that one has to build an executable for individual versions of macOS, and they won't work on others?

EDIT: alright I found quick info about this too in that thread:

A person noted it won't work for all macOS in existence, specially old versions, but I don't think this is relevant, it should work from the latest version to the old version supported by Xcode, which usually goes down to 6 versions. Yeah it moves fast but macOS updates are free, you get one per year. Building for older versions is way too much hassle as you will be working against Apple. This is the sole reason I haven't put macOS binaries in the release. If others agree with me this is ok for Apple users, we can release those.

So this is a problem of people not upgrading their old versions of macOS in time.

There's the fact that I don't want to post my game online, like send her my game separately so she can play it on her Mac, or do I have to do what you say?

If you look in Compiled/Data folder in your game project, these are "raw" game files that may be packaged for any operating system in theory, but they also need a Mac engine executable to run them.

So the questions are:
- where to get this Mac engine executable.
- how to organize game files (afaik they have to have certain folder structure on Mac).
- if there's a need to configure these files additionally.

Two first things may be done on Windows, but the last one probably has to be done on Mac (i may be mistaken here). I suppose that your friend can do it too, if somebody provides instructions.

You can make an unsigned and non notarized but the person that will play has to then click all the Apple security warnings to be able to run it and you will need some way to pack it and mark the AGS engine binary as executable.

It would be great to have these instructions step by step.

The new topic unfortunately is still not ready, so I cannot give people any link to the forum thread, or an article in the manual.
I don't even know where are the latest correct instructions in this existing thread.

https://www.adventuregamestudio.co.uk/forums/beginners-technical-questions/how-to-package-the-game-for-mac-platform/

Right, closing this then.

For what it's worth, in the global script, in repeatedly_execute(), I have this :

Code: ags

 
Game.TextReadingSpeed = 10;
Game.MinimumTextDisplayTimeMs = 2500;

If you put this in repeatedly_execute, that would run N times per second over and over again for no reason.
Settings like that are supposed to be initialized once in game_start, and perhaps when player uses some menu control if you support changing them in game.

Adding such things to repeatedly_execute is a lazy way when a person does not know the correct way, just because it suddenly works. It seems that AGS users used to do this a lot in the past, and older forum threads mention this kind of examples, but that is wrong.