Messages

they are from too old versions and fail.

AGS currently supports loading and run old projects too, but it may require adjusting "Backwards compatibility" options in General Settings. (Normally the Editor should guess and enter the values itself, but occasionally fails, it seems).
EDIT: if the game is really old, it may require upgrading via AGS 2.72 (load in 2.72, save, then load that in modern AGS 3.*)

That said, older games in the list indeed use deprecated script commands, some were even already deprecated at the times when the game was created.
Of course there's also no guarantee about the quality of code either, many AGS games were written by amateur hobbyists. While the game itself may be good, the underlying code is horrible .

PS. Every now and then people talk about making a proper demo game for AGS, here's the latest thread:
https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/crowd-sourced-of-an-open-sourced-ags-example-game-collaboration/
idk if that had any progress.

Yes, the background matched the color depth of the game and other background.

Please tell, which version of ags are you using, what is the color depth of your game?

Could you post the backgrounds themselves for us to see how they are supposed to look like normally?

I bump this again with a suggestion to make this topic sticky, or create another sticky topic with an updated list of open source games (not certain about the appropriate forum section for this).

EDIT: updated a game list in the first post.

Please tell if it works? @Dungeonation

I released a new 3.6.0 update with these fixes last night.

[Engine:]

Updated to RC11 (3.6.0.46).
(use download links in the first post)

Engine:
- Fixed touch-to-mouse emulation not working at all on certain devices (for example:  iOS Safari).
- Fixed touch-to-mouse emulation had mistakes when interacting with the game GUI controls.
- Fixed D3D9/OGL renderers could crash during a crossfade transition (under certain circumstances).
- Fixed clips scheduled with `AudioClip.PlayQueued()` are started with a noticeable gap between clips.

There's an experimental build with a supposed fix, but I do not know what would be the convenient thing to download for test.

Here's a full Editor downloads:
https://cirrus-ci.com/task/6188279393943552

Here's emscripten only part:
https://cirrus-ci.com/task/5906804417232896

Just tested, that bug doesn't occur for me.

Hmm, I actually have it; it also happens if you
1) touch the button
2) touch the empty spot on gui
the button will still be pressed on the second time.

Does the background match the color depth of your game and another background?

AGS Demo Quest would be a horrible example, imo, with bad gfx and using deprecated script.

There's a list of open sourced AGS games gathered here:
https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/a-sticky-list-with-open-source-ags-games/
This includes both adventure and non-adventure games (arcade, sims).

I suggested to make a sticky topic with the list somewhere, but to no avail...

Yes, apparently this is because of how GUI interaction is coded in AGS, it updates the new cursor position too late, after the "click" event already happened. This is normally not an issue with the mouse (at least not for engine itself, for script maybe), as it's tracked all the time, but this breaks with the touch as with touch it's tracked only when you drag around.

I suspect this probably can even lead to more distinct bugs, like if you first click on button 1, and then on button 2, will button 1 click again? (not sure if that's the case though)

Upon testing all the touch emulation settings, I still can't get GUI buttons to take one tap to press, it still takes two. Could it be something I'm not doing correctly?

To double check, is this your game or someone elses, are these buttons handled normally in script, using regular OnClick event or some other workaround?

However a much better way to solve this is to use  Mouse.SetBounds(); this way the user doesn't suddenly "lose" their mouse.

I must mention that Mouse.SetBounds is implemented by forcing mouse position to stay within the rectangle, which makes player unable to move it outside the window too when they play in windowed mode.

Another thing to consider, is how the mouse can still interact with the GUI, if there's one in game at that scene.

PositionMs is calculated based on sound data, not timer. The decoder converts every supported input format to a uniform sound wave format, after which the current position may be calculated, roughly speaking, as (DATA_SIZE_PLAYED / DATA_SIZE_PER_SECOND).

Certain lags cannot be avoided completely, as there's a difference in time between audio playing and game updates, but this difference should not accumulate and would rather stay in some range.


That said, as eri0o mentioned above, in adventure games the conversations are usually done split into pieces for the convenience of a player. Not every player can understand voice well (if it's not their native language), or read the text as fast as you expected. For that reason it may be more convenient to have a pause in between "sections", where text still stays on screen. This behavior may also be configured: whether a conversation continues automatically or awaits for player's input, how long it waits, and so forth. I thought I'd mention this too just in case.

I'd use the 1 column inv window as CW suggested, then use dynamically drawn sprites for the inventory items (and put the image on the left, then a wrapped description next to it).

That's doable, although I think splitting this into multiple controls may make it more flexible. Especially if you like to add interactivity on separate "parts" of each item.

As for your explanation on strings, I litterally just understood that it really meant... "STRINGS". I thought it was a concept or a name, like variable or integrer. Not the actual "guillemets". ^^'

Well, there's type String, which means a variable that contains text, and then there's concept of "string literal", which means that you put text in quotes (guillemets?) right in script. Functions require the arguments of String type, and if you print literal string in "" there, it will be automatically converted to one.

Now I just need to find in the Dialog Manual how to do line breaks inside the ListBox' strings,

ListBoxes only support single-line items. If you need multiple lines per item, then either:
* add multiple items to listbox, but then you'd have to split them manually somehow. Probably you will have to write your own function that splits one string into multiple, by the pixel width it takes (GetTextWidth function may give an idea).

Another approach would be to have multiple Labels instead of a ListBox. Labels can have multiple lines and wrap text automatically. Hmm... maybe even one label, but then you'd have to program it to arrange the text somehow, so maybe that will become less convenient.

and how NOT to display any background in the ListBox (or a transparent one), and the inventory will actually look nicer.

ListBox itself does not have a background, so you see a GUI background underneath... or do you mean background under selected item? that's ListBox.SelectedBackColor, but I do not remember if it can be transparent. There *may* be a workaround, where you'd handle the "SelectionChanged" event in ListBox and unset the selection to "none".
Then again, given your previous question, maybe ListBoxes won't work here.

But first, when I try this as you corrected:

Code: ags

ListBoxInventory.AddItem(1);

I get the error: "Type mismatch: cannot convert 'int' to 'const string'". Would you be able to help?

Ahh, sorry, I did not notice that. Yes, ListBox's AddItem require strings. If you're adding explicit values you could write

Code: ags

ListBoxInventory.AddItem("1");

but if you have an integer as a variable, which you want to convert to string, it will be:

Code: ags

ListBoxInventory.AddItem(String.Format("%d", value));

String formatting (printing values in string) in AGS is done in C-language-style; it's quite flexible, but may be found complicated at first:
https://adventuregamestudio.github.io/ags-manual/StringFormats.html

However, I can't seem to find any way to get to the object coordinates when it is drawn in the inventory. I wanted to have slots under slots, and not next to each other.

You may probably achieve wanted result if you make a narrow and tall InventoryWindow, making sure only 1 item is fitting in a row.
Also check for ItemWidth and ItemHeight properties of the invwindow, they define the expected item sizes (it ignores actual sprite sizes when calculating item positioning).

Then place a ListBox for textual descriptions to the right. Or buttons, if ListBox does not look right for any reason. You may also use rows (or columns) of buttons for displaying extra images and whatnot.
In fact, you may use buttons for everything there, it just will be more work, as you'll have to update button images as you scroll this inventory.

But it simply doesn't work and return this very enigmatic error: "Must have an instance of the struct to access a non-static member".

That's because you are not refering to an actual list box's script name, but to a type ListBox.
Instead your code has to be

Code: ags

myListBox.AddItem(1);

where "myListBox" is how you called your list box in properties.


In the worst case, when you cannot achieve this using built-in gui controls, you may try DynamicSprite / DrawingSurface solution. AGS lets you create a sprite in script, and then draw anything on it. Then you may assign it to GUI background, and update / redraw as necessary. That's additional effort to program though, and I recommend keeping standard buttons, as it will be difficult for a beginner to program their clicking behavior in script.

About drawing surfaces:
https://adventuregamestudio.github.io/ags-manual/DynamicSprite.html
https://adventuregamestudio.github.io/ags-manual/DrawingSurface.html

But in any case, this is the last solution to try.

[First priority to fix:]

Currently there following known issues, counting the critical and regressions:

First priority to fix:
FIXED1. Touch controls on some iOS devices (for web port, but may relate to iOS port too); I believe eri0o is working on the fix now.
FIXED2. A potential crash when restoring a save, related to Crossfade transition; found in very particular scenario:

* Game begins in room 1 with regular fadeout.
* Room 2 has crossfade fadeout set in "after fade in" event. (SetScreenTransition(eTransitionCrossfade))
* Player saves in room 2.
* Player quits the game, restarts, appearing in room 1
* Restores the save made in room 2, which leads to crash.

Not overly critical, but annoying:
FIXED3. PlayQueue not playing next clip seamless (ticket), there's a small random gap. This affects cases when one music track transitions into another (e.g. non-looping intro continues into the looping main track). There are "manual" workarounds though. The problem is due to the differences in audio "systems" in 3.6.0 and earlier ones. I postponed working on this, as was not completely certain how complicated that would be, and thinking that 3.6.0 will be released soon... I'd like to look into this again in the following days and see if there's a "quick" solution. If not, then I'd likely leave this for the next 3.6.* patches / minor updates.
EDIT: have an idea of a temporary "hack" in the engine...
4. AudioChannel.Position not working for MIDI and XM/MOD clips (ticket). PositionMs works though. Position property was returning "sample" index for MIDI/MOD, which is difficult to retrieve with the new sound decoder library we're using. So this is mostly a matter of updating the library , either doing that ourselves, or nagging library authors to do this. I am leaving this for the future 3.6.* updates.
5. Problems with MIDI, or rather with loading config and sound fonts. This is a long and complicated story, in brief, not all soundfont packs work as-is, and engine can only find them in a few preset locations, which may not be convenient for some users. Again, for the future updates (dealing with the decoder library).
6. It's been reported that Direct3D "real fullscreen" mode sometimes hangs when alt+tabbing. The behavior was improved, but according to reports it is still possible to make it hang if you alt+tab alot. The situation is not understood well, and personally I was not able to reproduce this on my machine.

[Editor:]

Updated to RC10 (3.6.0.45).
(use download links in the first post)

Editor:
- Fixed "export sprites" command run with an option to export sprites with absolute source paths.

Engine:
- Fixed that `Animate` command did not work for room objects with ID >= 100.
- Fixed `SimulateKeyPress` command could break some engine mod-key combinations (such as alt+ctrl for mouse lock, and so forth).
- Fixed initial positioning of a game window on desktop.
- Restored `--gfxfilter` command arg support for explicit scaling multipliers.

Templates:
- Updated to the latest project format.
- Fixed Sierra-style template relied on a human text on a button for switching voice modes (this could break if you change the text, or use a translation).

If done upon the compilation, the script compiler gathers a list of functions, which one may request and pass to the "upper level", where it's compared with the patterns and check existing events as a post-compilation step.

I also know that some compilers optionally warn about functions that are defined but never called from within the program itself.