Topics

EDIT: forgot the option "export all sprites in folder"

AGS 3.4.1.13 (that is 3.4.1 patch 2)

I have that GUI that I've made clickable. Inside a module, I have on_mouse_click and on_event.

Turns out on_mouse_click does detect the mouse wheel being "clicked" but not the regular left click.
For that, I have to resort to on_event (but then I don't know which button was clicked).

Is it still the aftermath of interface_click having been made obsolete? What's the proper of doing it?

[1685]

Hello,

- Download the following game project : https://drive.google.com/open?id=1CS_A6xhadFua2dKSAtmsU1oO3aWhfcDQ
- Open it with the (slightly outdated) 3.4.1 - patch 2 (that's 3.4.1.13)
- compile the game. The compiler raises no error
- put a breakpoint on lines 1685 and 1715 in VerbGui.asc.
- Run the game.
- single-click anywhere in the room (once). the character starts walking there. Then double-click on the door to the holodeck (south of the screen). This triggers a breakpoint on line 1685.
- Press F5. You never reach line 1715.

This proves that the game crashes on line 1685.

Now, for the strange part : location_id is declared nowhere.
There used to be a line "int location_id;" in this file, but the variable has been moved to a struct and you'd need to do verbsData.location_id to access that value. Proof : just above the line that causes the crash, add "location_id = 0;". The compiler will reject it.
This seems to prove that the compiler lets through this non-existing variable in some specific conditions.

Here is the scenario that I suspect :
1. the compiler lets through a non-existing variable for some absurd synctactical reason (maybe because it's in brackets : hotspot[location_id] )
2. then at runtime, the mistake is still not caught when resolving hotspot[location_id] --> that returns a bullshit pointer
3. this faulty resolution is passed as some sort of faulty this* parameter to RunInteraction(this*, ...).
4. the faulty this* makes the game crash when RunInteraction tries to propagate it as a on_mouse_click.
(but that's just my two cents. I'm just trying to understand how a non-existing variable is caught only at runtime and in some events-related built-in function)

Could it also be some sort of compiler cache issue? (I mean : does the fact that there was an int location_id previously in the code potentially play a role?)

[count]

Let's not try to make this a secret : I'm designing the "main" puzzle for a Fate-of-Atlantis-like full-length Indiana Jones game.
By "main puzzle", I mean the stones puzzle: earth stone, moon stone, sun stone.

In Fate of Atlantis, the puzzle is roughly as follows :

Spoiler

1) At 25% into the game, the player acquires the manual to this puzzle before the puzzle. The instructions are (moderately) hidden in plain sight in the Lost dialog of Plato.
2) At 47% into the game, te player acquires the first stone, which also makes it for a dumbed down version of the puzzle
3) At 64% into the game, the player needs to use two stones
4) At 75% into the game, the player needs to use 3 stones.
5) In the last 25%, the player will need to re-enact the puzzle once more, this time reverted
6) In the last 3% of the game, the player wil need to do the puzzle one last time, except this time the instructions are not inside the manual, but instead een in the background of one room (if the layter pays enough attention)

The objects count is : 3
the objects shape is : discs
The objects name is : "stones"
The objects theme is : earth, sun, moon

[close]

Now for my own game I've come here so far :
- In this game, at 3 key moments, Indy will encounter a large contraption (stone of metal machinery)
- the first one will be very primitive (might be a simple large fresco on a wall) while the last one will be huge (the size of a building) and controlled from a central, human-sized panel (but still preferably big)
- just like in FoA, the first one will be a dumbed down version, the last one will be the witty version
- the machinery relies on CONSTELLATIONS. the idea is that the player must "connect" or "dial" one or several constellations. (preferably one). If he manages to do so, the puzzle is won.
- the machine has to be powered up beforehand, but I've got that part covered.


My requirements are :
- There must be some mystical mystery (the objects are not everyday objects. There's loaded with an aura of magic or legend). Think : "cross of coronado", "headpiece of the staff of Ra", "earth/sun/moon stone". Of course there's also a non-mystical object always coming along (the journal of the Grail) but that one I've already taken care of separately. That object will also play the role of the Lost Dialog.
- It must not be a copy of the sun/earth/moon stone. That's a very tricky part :
    - because of the shape - It's always either a disc or a sphere that comes to mind,
    - because of the number : and it's very easy to end up having 3 of them. Yuck.
    => I was thinking of either a rope/thread/gold string, OR an arrow/lightning bolt/pointy stick OR a staff/set of tall cylinders OR a plain spherical stone with carvings on it.
- There's a twist coming from the fact that the player will not always be on the same hemisphere, therefore the sky will not always have the same constellations. The twist within that twist is that the constellations don't use the same stars depending on the cultures. Therefore the player must recognize a handful of "key" stars rather that the so-called constellations. For the first occurrence of the puzzle, though, happening in North hemisphere, we'll start with our well-known Zodiac constellations, drawn as-is.

So, with all that, the question I'm trying to sort out is : how does the player perform that "connection" to the constellation(s) in a fun and tricky way?

I've had a few ideas :
- the simplest version that immediately comes to mind is : paint all the constellations on the fresco, and have the player point some sort of cursor towards the right one. But that's not good for two reasons: 1) It cannot be "complexified" later on in the two subsequent occurrences of the puzzle, and 2) the player can simply win by trying all the constellations one by one.
- for the intermediate versions : Since the player won't always be in the same hemisphere, i thought that at some point I might have a map of the entire sky (South+North hemisphere projected onto a flat map) and he must "draw a line" or half circle that represents the horizon line. That would tell us exactly how the player would see the sky if he was physically present at that location on Earth. Somehow, choosing the two (or more) constellations located low on the horizon (and defining the horizon curved line) could be the puzzle? And the constellaiton he must dial is the one at the center of the circle? But now that makes me stuck with a half circle or full circle, which is not an easily transportable object like the earth/sun/moon stones. Hence my idea of a thread, but... Meh.
- In the last occurrence of the puzzle, he will have to pinpoint the stars he wants to include in the targetted constellation, and "draw" te constellation. That's not hard, but the difficulty will come from somehwere else -- I've got that convered.

So anyways as you can see I've got this puzzle stuck half way. Anything that would create a sense of "opening gates through time and space" is welcome. At some point I was considering also including osme sort of dial to choose a year (since there's a connection between the PLACE where you are when you look at the sky, the TIME at which you do that, and the POSITION of the stars in the sky when you do that). Choosing the yea and the position of the stars could reveal a place on earth, or something like that. But these three variables could create some cool puzzle but it makes the puzzle overly complicated.

I'm not happy with the fact that I can't decide if the puzzle should be solved based solely on KNOWLEDGE (which constellation to dial) or if some OBJECT(S) are required too (like the 3 stones in FoA). I'm terrified to create yet another one of those puzzles where you need "the three legendary pieces of whatnot" or "the seven pieces of the broken whetever".

What do you think?

[Would you have a community to recommend]

I'm currently analyzing in-depth what makes Fate of Atlantis so thrilling to play.
It relies on a few things that most wouldn't notice unless they pinned them down meticulously, but are essential.

Spoiler

Non-exhaustive list of technical tricks :
- Immediately starts with exciting credits ("Indiana Jones" written in large letters, fanfare music, Indy enters screen swinging from his whip)
- Immediately starts with a small, dumbed-down adventure (simply left-click on random stuff during intro). It's action-packed because Indy keeps falling (physical, non-point'n'click action) --> after that you can make the game as much of a walking simulator as you want, the player stays under the impression that the character can do offroad physical stuff.
- Immediate mystery (mysterious small statue)
- Physical threat (Kerner points gun + fistfight)
- CHARACTERS GET INTRODUCED : you see a close-up of Indy, Sophia, and Kerner's faces in the first 5 minutes ,and later on you see Ubermann's face)

And that's only the extended intro.
Later on, more stuff is packed in the first 20 minutes :
- Supernatural threat : Sophia's neckclace shines and shows ghost
- Feeling of exploring: Sophia sets the McGuffin for you and sets several places in the world to be explored (even though they're just one-room or two-rooms locations)

[close]

Additionally to that, the "parallel" puzzles are not as parralel as they seem, and yet the player feels like he/she can travel around. The backgrounds or the 3 paths (wits path, fists path and team path) are mostly recycling the same backgrounds very cleverly.

All of that to say : I'm struggling to pack that amount of information and thrill in the first 5 minutes of our game, while keeping it to only a handful of backgrounds, and I'm having trouble "breaking" our current script to make it possible for the player to come and go between places, instead of being stuck in 100% linear "corridors" (they go in, but they can only go out when you're finished with that set of rooms).

I need advice on all that. I'm worried that this community (AGS community) might not have the expertise on these story-development questions in full-length games; there are a few geniuses or pros in the forums who are able to produce such elements by following their intuition/guts/experience, but they're busy with their own games.
Alternatively, I'm sure that some writers or screenwriters forum would be packed with people who understand the issue, but then they would not understand the point-n-click side of it.

Would you have a community to recommend where there would be people focusing primarily on the story writing, but who can understand the point-n-click aspects (parallel puzzles and such)?
I've considered joining communities of text-based adventures (e.g. the community of "Quest" -- the editor for text-based adventure).
Any advice?

EDIT: as expected it was a ridiculous copy and paste mistake

[this gem.]

I was searching for an old thread in Google and I found this gem.

So I'm reposting so that all of you can enjoy this old thread on all its glorious insanity.

The best part imho :

I'm going to be perfectly honest.
Your views on everything annoy me. (...)
So in conclusion, I don't like you at all, and even though I never actually used the CJ JC thing.... from now on, I'm going to start. Just for you. Just because it shows disrespect for you in a special way that I never knew existed before.

Oh, the AGS community knew how to have fun, back in the day.

=========

So I thought we could make use of modern technology to cast light on that diffiult question, just like Gilbert did in the thread back then.
It turns out that the answer is more cryptic than I expected. what do the Norwegians theologians know that we don't know?

How about we start allowing games with MonoAGS (AGS 5) in every forum tat would normally only allow pure AGS games?

I'm lookin at you, MAGS.

If people started making small games using the new engine, it would:
- be an incentive to use it
PLUS
- it would slowly make some people acquire some knowledge about it. They would start being able to answer questions in the Technical forum and such. Buildibng the knowledge base, y'know.
PLUS
- the best way for the community to acknowledge its existence and slowly adopt it is to talk about it, and actually see it here and there. The good ol' visbility concept.

[Things to add in the "get started" wiki:]

I intend on trying to develop a tiny game with monoAGS.
This will be a test run to assert by myself how mature and/or easy-to-use it is. I will post my progress here.
If I succeed, I will try to convert a medium-size AGS game into MonoAGS. again, I will post my progress here.

This sort-of blog is meant to deliver tips to anyone trying to do the same, and maybe be an incentive to start something.

If you wonder why I'm posting this on the AGS forums, then please read this thread and all the other threads about the same topic.


Edit by cat:
MonoAGS Repository
MonoAGS Documentation

EDIT 2 :
Things to add in the "get started" wiki:

- if you can't build an Android project, it means you might need to install Xamarin (read more in the posts below)
- if you can't build any of the other projects, try these :
    1) make sure you have .Net Core installed (see posts below for links and version). To do so :
       - Open the Windows Command Prompt
       - type this and press return :
         dotnet --info
       - if you get an error message: then it means dotnet core is not installed. Otherwise you get the exact version currently installed.
    OR, if it still doesn't work:
    2) try to delete global.json and then rebuild the solution. This should specifically solve the error "The current .NET SDK does not support targeting .NET Standard 2.0. ..."
- If the solution builds fine but the project won't start, check if you have a message similar to "you cna't trun that type of project". If so, right-click on the actual game project in the solution (asopposed to the other projects : shared libraries and whatnot) and select "Set as Startup Project".

EDIT 3 : those comments are now included in the FAQ : https://tzachshabtay.github.io/MonoAGS/articles/faq.html

Release candidate.

- the backpack makes zero sense in terms of size and straps. But at least it makes the sprite more acceptable to the player's eye.
- The character's face in the front cycle is too narrow.

[imgzoom]https://78.media.tumblr.com/e8100f5a4b8acd373808807f18003ff6/tumblr_p6zq1kztIF1tsfksfo1_75sq.gif[/imgzoom]
[imgzoom]https://78.media.tumblr.com/18a2663fffe1992c42a8f09113410959/tumblr_p6zq1kztIF1tsfksfo2_75sq.gif[/imgzoom]
[imgzoom]https://78.media.tumblr.com/05a91c9306d6c47e08d91b83a2e5a494/tumblr_p6zq1kztIF1tsfksfo3_75sq.gif[/imgzoom]
[imgzoom]https://78.media.tumblr.com/513128dacbe61b8b1cf4c49aad38f350/tumblr_p6zq1kztIF1tsfksfo4_540.gif[/imgzoom]

Links to Photoshop source files :
back
front
side

[scale]

Meet this guy (on the right). He's a Tibetan mountain guide from 1940.
You can consider that he's the same kind of guy who assist the nazi interrogator in Marion's bar fight scene in Raiders of the Lost Ark.


This is a concept art. It's not even finished, there are holes in the body and the backpack is a rough draft. But you get the idea.



[imgzoom]https://78.media.tumblr.com/d063fb94d03c5ba878cb8172cea34450/tumblr_p6oiaozfDW1tsfksfo1_75sq.png[/imgzoom]
4x
[imgzoom]https://78.media.tumblr.com/16c3390dbdb1d6183c2060323a9740e9/tumblr_p6oiaozfDW1tsfksfo2_400.png[/imgzoom]

Concept :
- his backpack is huge. Like sherpas.
- he's a cowardish villain.
- Some reference for the clothing : http://photogrvphy.com/tibet-life-in-forbidden-lhasa-1940s-and-50s/


Critics :
- I'm not sure about the scale. I don't like that he seems slightly bigger (both by face and by body) than Indy.
- I didn't design the color scheme. For now I've just copied the scheme of the other character on the left. But I don't really know in which direction I should go.

If you feel like painting over the face then suit yourself.
For the body, don't make the backpack overly complicated please, as his walkcycle will be animated.

[Known defects:]

This post is about the side walk, not the two other views (any paintover of those views will be ignored)

Known defects:
- shading is a bit dirty
- bad contrast in hat
- walking character one pixel too short in frame where he is standing up
- there is a weird gray pixel under his chin.


[imgzoom]https://78.media.tumblr.com/d5e8b7ab044427919ad9af62e5cf1e10/tumblr_p3c7tvuZ5w1tsfksfo1_250.gif[/imgzoom]
4x
[imgzoom]https://78.media.tumblr.com/d96047e3953960d02d80f9130985eb07/tumblr_p3c7tvuZ5w1tsfksfo2_500.gif[/imgzoom]

[EDIT : everything that is written in this hidden section was my original post but you should not consider it my opinion -- it was more of a conversation starter and has been contested. The table is better.]

Following post-mortem this thread and all the previous threads http://www.adventuregamestudio.co.uk/forums/index.php?topic=55657.msg636578880#msg636578880

Spoiler

EDIT : everything that is written in this hidden section was my original post but you should not consider it my opinion -- it was more of a conversation starter and has been contested. The table is better.

I'm starting this thread in this forum for two reasons :
1) there was no thread dedicated specifically on MonoAGS
2) This is virtually a sub-thread to the "AGS 4"  thread (aka "why this project is screwed up"), only dedicated to MonoAGS as one of the many options.


What I like about MonoAGS

• It's started by one (seemingly skilled) person, who has leadership
• he sources are immediately available on git.
• Some thought has been given to follow in AGS legacy (programming-wise). Specifically: Not being unncessarily anti-Microsoft, while still focusing on cross-platform tech
• Some thought has been given to having a good, flexible scripting language (i.e. C# as a scripting language that can still be compiled separately from the engine or Editor source)
• Some effort in the documentation

What I don't like about MonoAGS

• The Editor is not part of the initial vision. It's envisionned as some sort of tool "external" to the engine, that can come after. It means there's no vision on assets management and game-creation pipeline.
• It's focusing a lot on basic graphics rendering (SDL), with no vision regarding the other components, such as sound engine, controllers input, GUI, timing, etc. That's my biggest concern with many wannabe game engines: they lose steam after they manage to render the graphics of the game, but that's only 25% of the whole picture.
• It doesn't do vectors, even only just by wrapping some basic directX primitives/data structures. There are many vectors usages that you might not think about until they're missing and it's too late (graphics scaling, walkable areas, perspective, camera control, tweens, parallax, etc.).

What I don't know about MonoAGS

• Is the build automated? Like, do you maintain a solution made with something such as cmake to generate the .sln file and all? That's one of the weaknesses that CW pointed out in AGS. Those tools are real magic to generate soluions for any IDE/compiler/Visual Studio version in one click

Apart from that,I have no opinion on the switch from Mono to .net Core. That's a side discussion.

There should also be threads to discuss Blade Coder and Adore.

[close]

Engine	AGS	Bladecoder	MonoAGS	Adore	Escoria	Placeholder 1	Placeholder 2
Middleware / underlying game engine	Allegro	libgdx	None	Löve aka Löve2D	Godot	Placeholder 1	Placeholder 2
Editor included	Yes	Yes	Not yet (plans on making things editable directy in-game)	No editor provided but many frontends suggested (e.g. Notepad++ with a plugin) See link in footnote	Yes	Placeholder 1	Placeholder 2
Platform/VM for the engine	None (direct  C++), but has binds to some Windows libs.	Java	Non-Microsoft .Net Framework, aka “Mono” (considers moving to .Net Core)	Lua		Placeholder 1	Placeholder 2
Platform/VM for the Editor	.Net framework	JDK required	Mono (considers moving to .Net Core)	-		Placeholder 1	Placeholder 2
Hardware supported	Windows desktops. Existing ports : MacOS (outdated) ]PSP Android iPhone(?)	All++ (not only the build+execution, but also subtle things for mobile devices such as tapping, hand motions and accelerometer)	All (but for subtle things meant for mobile devices such as tapping and accelerometer, you'll need extra code/libraries)	All+ (not only the build+execution, but also subtle things for mobile devices such as tapping, hand motions and accelerometer)		Placeholder 1	Placeholder 2
Engine's language	Old-school C with big chunks of C++	Java	C#	Lua		Placeholder 1	Placeholder 2
Editor's language	C#	Java	C#	-		Placeholder 1	Placeholder 2
Main libraries used (apart from DirectX+OpenGL which are included implicitly in most cases)	allegro 4	I don't know how much of libgdx is self-sufficient	OpenGL+OpenAL bundled in OpenTK	I don't know how much of Lua is self-sufficient		Placeholder 1	Placeholder 2
Proper versioning	Yes (git)	Yes (git)	Yes (git)	Yes (git)		Placeholder 1	Placeholder 2
Automated tests	No ?	?	?	Yes (“busted”)		Placeholder 1	Placeholder 2
Automated solution generation	No	Not needed ? (Java all the way)	No	Not needed (Lua all the way) ?		Placeholder 1	Placeholder 2
Automated build and release	No	Most likely	Yes	?		Placeholder 1	Placeholder 2
Native support for Photoshop (PSD) files	No	No?	No	Yes?		Placeholder 1	Placeholder 2
Localization mechanisms	Yes, up to 256 characters per font	?	?	?		Placeholder 1	Placeholder 2
Good manual + community + tutorials	Yes	Yes	Yes (at least it has some doc and a proper home page)	Yes but only one demo game		Placeholder 1	Placeholder 2
Maintainers	Approx.. 4	Many for libgdx,  +1 very efficient for Bladecoder, +approx. 4 from the AGS community if we go there	1 +approx. 4 from the AGS community if we go there	Many for Löve2D, +1 for Adore, +approx. 4 from the AGS community if we go there		Placeholder 1	Placeholder 2
Sound engine	Not really, apart from just playing sounds	Yes (libgdx)	Yes (OpenAL has good features, that tzachs has wrapped into MonoAGS)	Yes		Placeholder 1	Placeholder 2
Controllers input	Just the basic : keyboard+mouse (and joystick with a plugin)	Yes+ (including mobile device gesture)	Just the basics	Yes		Placeholder 1	Placeholder 2
Subpixel management / maths / vectors (see in an other post in this discussion what I mean by that)	No, apart from basic float management and the Tweens module	Yes+ skelettal animation out of the box	basic OpenGL stuff + everything that was ported to C#. Anything else has to be binded manually	Yes		Placeholder 1	Placeholder 2
Multithreading inside the game	No	Probably	to be implemented by the game designer	Probably, using Lua	?	Placeholder 1	Placeholder 2
Data structures / serialization / database-like processing	No, apart from arrays of structs	Yes (XML, Json and everything natively)	Yes? (classes from Mono and/or .Net Core)	Yes? (Lua has everything)	?	Placeholder 1	Placeholder 2
Pixel-perfect low-res graphics	Yes	?	Yes?	Yes?	?	Placeholder 1	Placeholder 2
Collaborative work / compatibility with versioning	Possible with scripts and rooms, but not recommended with the main game file (.agf) nor sprites library.	?	Editor doesn't exist yet	?	?	Placeholder 1	Placeholder 2
Game scripting language	custom (AGS script)	NONE YET	C# (but some people think that things are little too hard coded yet)	Lua	custom (Gdscript, aka something similar to strongly-typed Python)	Placeholder 1	Placeholder 2
dialogs scripting language	custom (AGS dialogs script)	Ink	C#	Lua	?	Placeholder 1	Placeholder 2
in-game GUIs	None/custom (poor set of native graphic controls)	Yes (offered by libgdx)	custom (partially implemented)	Lua libs	?	Placeholder 1	Placeholder 2

Escoria : https://github.com/godotengine/escoria/blob/master/README.md
MonoAGS : https://tzachshabtay.github.io/MonoAGS/
Bladecoder: https://github.com/bladecoder/bladecoder-adventure-engine/wiki
AGS: https://github.com/adventuregamestudio/
Libbgdx : https://libgdx.badlogicgames.com/features.html
Löve : http://www.love2d.org/
Suggested editors for Löve : http://www.gamefromscratch.com/post/2016/01/25/Editors-and-IDEs-for-Lua-and-Love-Development.aspx


Ink : https://www.gdcvault.com/play/1023221/Ink-The-Narrative-Scripting-Language
Java :
Mono : https://en.wikipedia.org/wiki/Mono_(software)
Mono versus .Net Core : https://stackoverflow.com/questions/37738106/net-core-vs-mono
Adore : https://github.com/CalinLeafshade/adore

[- Messy artifact-y foliage :]

Hello,

Normally Critics Lounge is to sho something that you've made and ask for constructive criticism.
But it's also a space for discussing the drawing techique used -- so, not to set a precedent, but I'd like to ask you tips on a specific topic : drawing foliage in pixel art.

Foliage in pixel art looks differently for every pixel-artist, but in the end I still think you can categorize the result in 3 families :

- Messy artifact-y foliage : That's usually when the artist simply scaled down a picture of a tree.      Caracteristics :       x There are almost as many pixels as there are leaves       x There are almost as many shades of green/brown as there are leaves       x The contrast is usually very high and there are way too many black pixels -- because in the original tree picture, the areas that were in the shadows (especially the self-cast shadows of the tree) were rather dark, and the artist failed to adapt that original shading to match the overall shading of his/her pixel scene.           Example 1 (background foliage): PLEASE NOTE: I'm not criticising the guys who drew the backgrounds for this "Tanis" demo as I think they made an outstanding pixel art job for everything else. Only the foliage bothers me.       Exampe 2: these ones were probably drawn by hand, and yet they still have this messy aspect and exagerated contrast :       - Overdrawn/overstylized foliage : That's when the artist actually drew the leaves one by one and got carried away with the shading. It gives everything a cartoony look or a "pillow shading" look.           Example 1: (see the leaves in the foreground)       Example 2 :  (notice how each leaf is drawn one by one in the middle tree) (The crystal shard team produces amazing graphics but that's not the style we're aiming for)       - The magic look : (the look Id like to achieve) the foliage has exactly the right level of detail and number of colors. It has a crisp ascpect and yet it's not busy.                 Example 1 (Fate of Atlantis as always      Example 2        Strangely, FotAQ artist succeeded here. Even though there's a lot of copy and paste.

So, now, the discussion: any ideas on how to achieve that render effect?


I was thinking the following transformations/filters in photoshop:
- gaussian blur (to remove unnecessary details)
- color quantizer (it's like a better posterize) to reduce the number of colors
- denoiser to remove the few rogue pixels remaining and giving an overall smooth (yet crisp) aspect
- and of course at the end a brightness-contrast (or better yet: curves) adjustment.

Any better idea?

how do you get the alpha of a pixel in a drawingSurface? By parsing the highest bits of the value obtained through GetPixel?

Scenario :
- I import a sound into the game
- In my room_load (before fade-in), I call aMySound.Play(eAudioPriorityNormal, eRepeat);
- I am able to play that sound fine from the "sound" panel
- the game compiles properly. I then run it from within the Editor, with F5.
- when I enter the room, the game crashes with error "an internal error has occurred(...) Error: Unable to create local script (...) Unresolved import 'aMysound'"


Why?

Note: I've tried compiling it for real ("build EXE") beforehand, but it didn't help.

[EDIT:]

Here is a simple experiment :

EDIT: code below was edited to take in account CW's feedback in next message)

Code: ags

void repeatedly_execute_always()
{
    while (!mouse.IsButtonDown(eMouseRight))
    {
        mouse.Update();
    }
    Display("Done!");
}

You'll notice that the engine freezes and you can't exit the loop even by pressing a key or left-clicking.
What are your thoughts on this?

I'm looking for ways (as inconventional as needed!) to intercept user input during repeatedly_execute_always. Oh, and to reflect something on screen.

[interactive]

This module lets you display an interactive GUI relying on the "Display" AGS built-in function rather than a regular function.





In a nutshell:
- it transforms any "Display" popup into an interactive popup
- it has the wams "flow" as the Display function (or Wait(1)): it blocks the game but still lets repeatedly_execute_always run once after each time it's called.
- you may have 3 types of controls : Labels, Buttons, TextBoxes
- it's based on text (because of the "Display" function) but you can still use pixel-perfect positioning of controls (horizontally, not vertically)
- you may use the keyboard left/right/up/down keys (to select the button or textbox), use "return" to validate your choice, or "escape" to close, etc.
- you may use the mouse to click on the buttons or textboxes

More generally, it's a basic toolbox that could become handy for anyone wishing to implement a GUI based on text, independently from the AGS context.

As a demo I implemented a Yes/No popup but you can also implement easily a popup window that prompts the user to enter text into an interactive textbox (moving cursor, backslash, "del" key, etc.).

>> DEMO GAME <<

[Consider this piece of code :]

I'm asking a question which answers are everywhere in the foruls and in the manual, but I need to have it discussed in one place to make sense of it.
What's the chronolgy/order of operations within one game loop?

Consider this piece of code :
(pre-requisite : create a GUI with a label called TestLabel somewhere)

Code: ags

bool valueChangedCount=0;
void repeatedly_execute() 
{
    for (int i=0; i<10;i++) {
         Display(String.Format("i=%d, valueChangedCount=%d, mouse.x=%d", i, valueChangedCount, mouse.x));
        TestLabel.Text=String.Format("%d", i);
    }
}

void repeatedly_execute_always() 
{
    valueChangedCount++;
}

Now run the game. You will observe this :
- While the Display popup is displayed, the mouse will move on the screen because it's handled at a very low level by the engine.
- However mouse.x is not updated
- when i changes, the change is reflected into the Display popup AND in the TestLabel
- valueChanged does get updated.

All of that demonstrates  :
- that an instruction like Display (which can't be called in a blocking script) really blocks the engine.
  Proof: the game does not switch to next game loop (mouse.x not updated). So its behaviour is different from,
  let's say, Wait(1).
- however repeatedly_execute_always is called at each Display call (proof: valueChanged becomes true),
  which tends to demonstrate the opposite
- GUI changes are immediately rendered(even though the GUI not interactive since mouse is technically frozen). It means
  that GUI rendering is "outside" of game loops, i.e. outside of the repeatedly_execute/repeatedly_execute_always
  chronology.


Is there some logic in there? (not asking in a mean way, just trying to get the whole idea to avoid mistakes)
Is there some queued instructions black magic that I'm missing? Is this snippet code changing game loop each time yes or no?

[EDIT:]

EDIT: this module was actually heading towards two unrelated directions (on the one hand, experiments on blocking GUIs, and on the other hand the so-called "breakpoints" feature).

Therefore I'd rather start over and split it in two.

- the part concerning the Display-based GUIs : http://www.adventuregamestudio.co.uk/forums/index.php?topic=55331.msg636572545#new
- the part concerning breakpoints : working on it!

Spoiler

Indiana Jones and the seven cities of gold development team proudly presents :


             AGS Breakpoints
                     (a.k.a. "DisplayGUI" module)




Click on image to watch video




What does it do?
In a nutshell :

• 100% blocking interactive GUI in any script (well, any script where you could normally use function "Display")
• Easily watch variables' values anywhere in your script, like a real breakpoint (and in future version : edit them)

In detail :

• Watch the video above (url : www.youtube.com/watch?v=Ww0n18qlsKQ&feature=youtu.be ) or read this :
• AGS is a very cool engine, but one of its downsides is that it has no real useful breakpoints. Breakpoints can pause the game (hurray!) but you can't watch the variables values, so the Breakpoints are mostly useful to check that your script goes nto a specific code branch (if...then...) but it won't help you debug a complex code with values changing everywhere.
• Until now, your only solution was to use the "Display" function, but it was really a pain in the neck when you want to display several variables at once (you'd need to write a different "String.Format..." for every occasion). You could use a GUI, but since the whole point of this is to entirely "pause" the game (GUIs included) then the GUIs would be disabled (therefore becoming non-interactive).
  
  Well now you have a way to entirely pause the game anywhere in the script AND still be able to click around and benefit of useful features. This makes it much closer to a regular "watch" as seen in Visual Studio and others

How to setup:
Basic use setup:
1) import the DisplayGUI module,
2) import the modified Font0 provided in the demo game (you can simply swap the files in your game folder. Fear not! It only modifies the first 20-or-so characters in the font, which should be harmless since they are very rarely used by anyone. If you need those, you can modify the ascii codes in the module and you can quickmy edit the font using Rulaman's "TtfWfnSci" tool (you can find a link here).
3) Import the sprite that represents a small 3x*3px red square, that you may export from the demo game in the "displayGUI" sprites folder
4) Make sure that mouse mode "userMode1" uses this sprite as cursor
5) Before you call any instructions of the module, call "DisplayGUI.Init(myFont)" where myFont is the font that you just swapped

Advanced use setup:
1) Get the original "UltraVariables" module by SSH, or export the one present in the module's Demo Game.
2) Check the DisplayGUI's header to see what custom instructions you need to add to the Ultravariables module. There are only two : One export instruction, and one export instruction.




How to use:
Basic usage:  (no Ultravariables)
1) Don't forget to call DisplayGUI.Init(...) before anything
2) To display a Yes/No popup window, do as follows :

Code: ags

YesNoResult result = DisplayGUI.ShowYesNo("line of text 1", "line of text 2");
if (result==eDisplayGUI_Yes) 
    Display("player clicked YES");
else 
    Display("player clicked NO or exited the popup (by pressing ESCAPE or right-clicking)");

3) To display the Watch interface :

Code: ags

//Obviously, myVariable must exist. Oh, and it does "int" only, sorry!
BREAKPOINT("myVariable name", myVariable); 

//You can watch up to 7 variables, and only 5 can be displayed simultaneously 
//(but you can see the others if you enter their name in the interface)
BREAKPOINT("myVariable1 name", myVariable1, "myVariable2", myVariable2 /*, up to 7 */); 

Advanced usage:  (with Ultravariables)
1) make sure you have followed the setup instructions above
2) Set  and get the value of any variable like this :

Code: ags

SET("myVariable", 7);
int value = GET("myVariable");

3) Display them at will in your Watch interface by typing their name whenever you want.
4) Careful though! These variables are GLOBAL variables by design. In other words : There's only one ultraVariable with the same name in the entire game.


License:
Free to use for any purpose whatsoever, provided you credit us in your game credits (if any ). Don't forget to credit SSH too for his UltraVariables module.


=====================================================================

Version 1.1 :
Added simple graphic theme (because prettier things are more attractive)
              Pro : prettier
              Con : makes the popup blink because AGS function "DisplayTopBar" doesn't behave the same way as "Display". I would suggest: use the theme for Yes/No popup, but not for the Watch interface.






>> DOWNLOAD <<

[close]