Messages

So this should be enough to support top-down movement (just set the value to 1.0). And I don't believe isometric perspective really needs any special settings, does it, as long as one of the view angles more or less matches the direction of the isometric movement.

I think I understand how this may be used now.

Maybe I've been mixing two problems. One is real direction of a particular view angle. But another is optimizing view loops.

Arbitrary isometric example:


In the above solution this may be achieved by setting an oval flatting factor, but user will have to fill very particular loops in the view (left, right, left-bottom, right-up?) and keep doing that correctly for each view.
I've been wondering if instead we could let user also define roles for the loops.

Probably we have different problems in mind. I've been thinking of configuring fixed angles depending on a perspective. For example, top-down view, or isometric movement. I don't really see how that may be done using just 1 property on walkable area (?), and frankly I don't know what "foreshortening" is.

I guess I will leave this for others to discuss then. But imo it may be worth to make such configuration a separate struct in script, then if necessary it could be applied to Game, Room, Character and Area, with override rules .

This goes out of scope of what we usually plan for the engine. Besides, how many users will actually going to use this, in a 2D point & click game?

Perhaps it may be better to provide enough script API to let users script this system themselves.

Then someone could write a module for this.

In other words, then, it may be better to investigate which data has to be available in script, and which commands are necessary to script such system.

It throws a complition error "NewScript.asc(36): Error (line 36): '.Text' is not a public member of 'GUI'. Are you sure you spelt it correctly (remember, capital letters are important)?"

You need to create a label on GUI, and assign a text to that label.

Ideally we should have access to the list of waypoints calculated by the pathfinding algorithm, so we could know the angle of the path segment as a whole.

There's a feature request for pathfinding API:
https://github.com/adventuregamestudio/ags/issues/1979

I believe this may be a valid option for AGS 4. This, along with settings to define the direction angles.

Well, I tested this in 3.6.0.51, and the labels correctly draw outlined font at runtime, as expected.
Other font settings (thickness, offset) are also applied.

They don't do this in the editor's preview, but this is an old problem.

Thanks CW. I actually have set my speech to use Font1 and it has its outline settings applied and showing correctly during runtime. But the labels that I set to use this Font1 only get the 'naked' font without any outline applied to it during runtime...

I think this may be a bug. I will need to test this.

Besides, I think that labels and any other element that can utilize text should also have the properties that Fonts have, such as OutlineStyle, AutoOutlineStyle, AutoOutlineThickness, LineSpacing, and SizeMultiplier... I found this missing when I tried to use a text label as a static speech text location, which works quite nice yet missing these features to look better.

Font properties are supposed to be applied to anything that draws a text using this Font. If you like to have a specific look on a label, then you need to create a separate Font with different set of properties.

Right now this may be inconvenient, since duplicating a font will also clone the font file, increasing game size.
This is why there's an open ticket which suggests to separate Font Settings from the font files:
https://github.com/adventuregamestudio/ags/issues/996

But in the end, these are supposed to be Font settings, not Label settings.

[position]

Indeed, you cannot change game resolution at runtime, it's fixed, and gui resolution is always equal to the game's.

Game.Camera.SetAt changes camera's position in the room, not camera's zoom.
Doing Camera.SetSize will change it's zoom, but it will zoom the room, not the GUI. There's no command to zoom into GUI at the moment.
https://adventuregamestudio.github.io/ags-manual/Camera.html

It seems you are speaking of a game screenshot loaded from saves?.. It should be the size of the game resolution, but if it's placed on GUI, then it may be resized prior to that. Find where it is loaded in script, and make it larger, perhaps that would be a solution?

By the way, I think you also need to test if PlayingClip is not null in the above code, in case the channel was assigned, but it does not play anything at the moment.

Code: ags

if (globalChannelMusic1 != null && globalChannelMusic1.PlayingClip != null)

Yes, you can access a played clip properties through channel.PlayingClip.

Mm... I tried pulling the name as a string this way but it doesn't work... I guess my code is incorrect.

AudioChannel.PlayingClip is of type AudioClip*:
https://adventuregamestudio.github.io/ags-manual/AudioChannel.html#audiochannelplayingclip

If you want to access particular clip's property, you need to also add this property to command, like "channel.PlayingClip.ScriptName".

Can the retrieval be dynamic? I mean, if a global variable is set as an Audiochannel* and I dynamically change it to other sounds, can the name of the actual sound that plays be retrived?

Yes, you can access a played clip properties through channel.PlayingClip.

@Gal Shemesh I don't know which version of AGS are you using, but i copied ScriptName property and GetByName function to 3.6.1, for all types that may have them. Here's a temp build that may be tried:
https://cirrus-ci.com/task/6689087789203456


EDIT: simple example of how this may be used:

Code: ags

System.Log(eLogInfo, "This game's audio clips:");
for (int i = 0; i < Game.AudioClipCount; i++)
{
    System.Log(eLogInfo, "---> %d : %s", i, Game.AudioClips[i].ScriptName);
}

Support handling multiple mouse clicks per game frame, similar to how multiple key presses were supported since 3.6.0.

Ah, I just realized that there is still an oversight in this. on_mouse_click should probably have mx,my parameters, in case the mouse moved between clicks?

I primarily added this multiple clicks support after being asked by a person who was doing a tool-automated speed run of AGS games. So, it was supposed to support multiple simulated clicks in a row. But since mouse.x,y properties are only updated once per game frame, then this is still useless... (except when clicking on gui and interactive objects that have proper events, perhaps)

EDIT: also I noticed that some engines have "modifier keys" as a part of the mouse event (let know whether player did  Ctrl + Click, and similar).

Hello, I tried to open my project with this version and I got the following error.

Please tell, does this happen all the time, in any room, or in particular room?

There are two general approaches to waiting for something to finish in AGS:

1. A (simulated) blocking approach where you run a loop with Wait(1) inside, checking for some condition.
2. A non-blocking approach, where you start something, save in a global variable, and then checking this in repeatedly execute.

The most primitive blocking approach looks like this:

Code: ags

Overlay* over = player.SayBackground(text);
while (over.Valid)
{
   Wait(1);
}

A non-blocking approach requires you to save the thing you are checking in a global variable when you start an action, and check that variable in a rep exec.

But if there are several actions that may be run in sequence, or in parallel, then you would need to schedule following actions in an array. In more complex cases you'd need to have a struct with multiple data inside, or array of structs.

You would also need to store an index of a sequence state, because you must somehow tell which next action to run after the previous was completed.

This altogether may lead to necessity of designing a system, which stores and handles all this data...

For some relatively basic example, this is running consecutive saybackgrounds (one at a time):

Code: ags

// global variables declared somewhere
Overlay* BgSpeech; // current bg overlay
String BgLines[100]; // store text here
int TotalBgLines; // total scheduled background lines
int BgSpeechIndex; // next line to play


// Schedule a bg line
function AddBgSpeech(String text)
{
    BgLines[TotalBgLines] = text;
    TotalBgLines++;
}

// Reset all bg lines
function ClearBgSpeech()
{
    for (int i = 0; i < TotalBgLines; i++)
    {
       BgLines[i] = null; // clear strings from memory
    }
    TotalBgLines = 0;
    BgSpeechIndex = 0;
}

function RunNextBgSpeech()
{
    if (BgSpeechIndex >= TotalBgLines)
    {
        return; // nothing was scheduled or completed all lines
    }

    if (BgSpeech != null && BgSpeech.Valid)
    {
        return; // previous bg speech is still visible
    }

    // Choose which speech to run next
    BgSpeech = player.SayBackground(BgLines[BgSpeechIndex]);
    BgSpeechIndex++; // increment speech index for the next time

    // Check if completed all scheduled lines
    if (BgSpeechIndex == TotalBgLines)
    {
        BgSpeechIndex = 0;
        TotalBgLines = 0;
    }
}

function repeatedly_execute()
{
    // In rep exec update Bg Speech state
    RunNextBgSpeech();
}

function TriggerBgLines_RunAtSomePointInGame()
{
    AddBgSpeech("first speech cue text");
    AddBgSpeech("second speech cue text");
}

I don't remember if .ags packages have some magic number identifier. But I could imagine a version of multifilelib that has support for both regular .ags packages and also .zip files, and if there is some unique magic number they could even have the same extension and then it would use whatever is the format it was packed.

The way working with the spritefile is done now, it cannot be worked with while it's compressed whole, it has to be plain data with strict offsets that are known beforehand. This means that either the compression should be applied not to all assets, but to individual ones (where some assets may have it and some not); or the current streaming method should be dropped and replaced with another strategy; or spritefile would need to be decompressed to a temporary file on disk elsewhere at the game launch, and read from there.

This is going to be a major issue if AGS would support a game packed in a regular zip file. I don't know whether zip allows to store different entries with different compression.

I guess this is a common problem for big files that contain lots of data, where not all data is necessary at once. Like the spritefile is a data package inside a data package.

I know the last reply on this thread is from a few years ago, but just wondered if we can easily grab the name of audio clips for debugging by now?

At the moment this may only be done in AGS 4, where I added ScriptName properties to everything which has them, as well as GetByName method.

I guess I could backport these to 3.6.1...

In regards to a custom solution, earlier I mentioned a switch, but perhaps array of Strings would be better.

[Editor:]

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

This is AGS 4.0 Early Alpha 4.

Contains updates and fixes from 3.6.1 Beta 7 and 8.

Other changes:

Editor:
- Translation sources are now saved in PO format.
- Fixed room data xml was saved without linebreaks and indentation.
- Fixed all room images (backgrounds, masks) were rewritten on disk each time a room is saved, even if they are not modified.

Compiler:
- Fixed forward-declared but unresolved function not reported correctly.
- Fixed accessing dynamic arrays with a numeric literal index was not tested for "out of bounds" mistake.
- Fixed multidimensional array index delimiters (",") were confused with function parameter delimiters in call to a function.

Script API:
- Added Joystick struct, meant to work with joystics and gamepads in script.

Engine:
- Support joystick and gamepad input.
- Fixed DynamicSprite.CreateFromSaveGame producing invisible screenshot sprites.
- Fixed an attempt to read screenshot from a save with no screenshot could cause engine to crash.
- Fixed 16-bit sprites in 32-bit games turning completely transparent.


WARNINGS:

1. SpeechCenter plugin will stop working with this AGS 4 update. It won't crash, but won't see translated strings. This is because Translation storage had changed in the Editor. The plugin will have to be updated to work with AGS 4.

2. AGSJoy plugin will not compile with AGS 4, because its Joystick struct will conflict with the AGS own Joystick struct. The solution is to either disable newest script API level (by lowering to v3.6.1, but that will also disable anything else), or adjust the code to work with the new Joystick API. The API is relatively simple, so upgrading should not be a huge problem. The plugin is no longer needed after that.

[Common features:]

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

Changes in this update:

Common features:
- Implemented Deflate compression option for sprites. (This is an algorithm used in PNG and ZIP formats, and testing shows about x1.5-x2 compression improvement compared to LZW).

Editor:
- Fixed Line tool in the Room Editor triggering sometimes after a context menu was called with Shift + RMB.
- Fixed Autocomplete not treating certain struct members as "static" or "protected" if their declaration is too long.

Engine:
- Fixed Character's idle animation getting reset to frame 0 when the speech is played without a valid speech view (idle animation should continue playing in such case).
- Fixed idle animation sometimes not starting immediately after Character finishes walking.
- Fixed a crash occuring if script tries to get or set a custom property for a non-existing Room Object (this seem possible to do by iterating over `object[]` array).
- Fixed invalid gui could be interacted with if a previous interaction displayed a message box on screen, sometimes leading to engine crashes (regression since the previous Beta).

Compatibility:
- Implemented "dataver_for_legacysaves" override option in config, which lets to instruct the engine which game data version to assume when loading legacy (pre-3.5.0) saves. This "hack" appeared to be necessary because of a mistake done during development of the older engine versions, where the save format was changed, but engine was made to rely on the game data version instead of incrementing save format index.
- Fixed engine could try to load game data from game.exe without checking whether data is actually appended to it when restoring a legacy save in a game with a different file structure.
- Fixed number of GUI elements were not tested when loading a legacy save, which could lead to GUI data getting overwritten incorrectly without a warning if number of controls changed since.

Plugins:
 - Fixed potential "index out of bounds" exceptions in the built-in PalRender plugin.


Some of the fixes mentioned here will likely be also backported to 3.6.0 and released as a part of next patch.