Messages

I'm baffled by the fact that the test worked for you. My repeatedly_execute_always is in a room. I'll try to reproduce exactly every behaviour you described.

[EDIT:]

The "Display" is never reached, it's after the loop. Thinking about it, it would even crash the game because you can't call Display in blocking functions EDIT: it's Wait(1) that you can't call in blocking functions.
Also, forget about my misuse of "iskeypressed(ekyNone)"; there's still "IsButtonDown" that should do the job.

A truly infinite loop in repeatedly_execite_always definitely freezes the engine and the Editor (even clicking "pause" in the editor won't work), and have yet to find a way to intercept any player input, as in "detect" it.

[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.

There's technical information here that could be useful to someone. Why don't you just link to your new threads and we can lock this one?

Everything that is in here will be present in the next threads. I don't really mind I justs didn't want to pollute the forum.

[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 <<

[Could the admins please delete this entire thread?]

Could the admins please delete this entire thread?
I'm currently splitting this in two :
1) the GUIs relying on the "display" function (which is a curiosity not necessarily interesting everyone)
2) the advanced "breakpoints" capabilities, that I'm currently refactoring to rely on a regular GUI.

Also I forgot to post it into the Modules subforum instead of here, so it's a good occasion to start over properly

Thanks I'll experiment on that.

One last thing : Could you briefly elaborate on the differences between putting a Display in a loop in repeatedly_execute, and calling Wait(1) ?

[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?

<3

[This will allow me to continue with my plan :]

I always put my watch variables on a GUI label3 I'm still not sure why one would need this.

Spoiler

anything you change in a GUI or basic graphical element is not visible on-screen before the end of the game loop.
But what if you want to check variable values within a loop without messing with the chronolgy of AGS scripts executions? What if you want to see the real current value of every variable, including built-in AGS variables?
if you try to display values in a regular GUI, then the changes will not be seen until you do a Wait(1). Which in turn forces the engine to perform the updates it would normally perform at the of the game loop. Therefore it can mess with what you're trying to observe or is even sometimes forbidden (in blocking functions).

[close]

EDIT 2 :
    So I tried to display a variable value in a GUI and indeed it turns out that Label.Text=... or ListBox.Add..
    are immediately reflected to the screen, even within a blocking script with the game fully paused. Not the
    same behaviour as "in-game" elements such as the player, for example.

    Does that make my module useless? Not in the slightest bit. The idea is still to entirely BLOCK the game, anywhere
    within a complex script, and still being able, during that "brutal" pause, to see the value of anything... but in a
    comfortable and interactive way.

    the only way I know to entirely pause the game in a sort-of "meta" way (not only the in-game elements like Character,
    etc.) is to call Display (correct me if I'm wrong?). But then the game is entirely paused and you can't click anywhere
    in GUIs. On top fo that, mouse movements can be seen on screen (because they're handled at "system" level) but
    mouse.x is not updated and can't be watched.

    Therefore, with Khris' idea in mind, I'll use the GUIs capabilities to make the visual aspect of my module more
    appealing, BUT it's still extremely helpful to force a blocked GUI to stay interactive.

    This will allow me to continue with my plan :
    - enabling AUTOCOMPLETE in the symbols suggestions,
    - allowing the user to EDIT a variable value while code is paused
    - adding CONDITIONAL breakpoints, for them to fire up only when the critical time to debug has come.

[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]

Code: ags

Speech.SkipStyle = eSkipKeyMouse;
DisplayTopBar(...);
Speech.SkipStyle = old style;

PERFECT. Thank you!!!

[Display]

Digging out this topic because it's describing the issue I'm encountering.

According to the manual, DisplayTopBar "has the same behaviour as Display".

However, it's not true (in 3.4.0.x) :
- Display remains on screen as long as the user does not click or press a key
- DisplaytopBar disappears automatically after a (very!) short time.

Also just so you know, for what I'm doing at the moment I can absolutely not use a GUI; only an absolutely blocking function such as "Display" will do. I planned on switching to DisplayTopBar for cosmetic reasons (choice of color, etc.) but atm it won't do for the reason I described (different behaviour).

This way now you can start coloring and shading faces

Wireframe is much more science fiction.

Yeah but he could make the "rotating cube verbcoin interface" from Cryo's Lost Eden and make it a module for the community

Really cool.

You can find an AGS paint (aka "flood fill") algorithm in this module : http://www.adventuregamestudio.co.uk/forums/index.php?topic=51142.0 (for credit: algorithm stolen from another, older module).
This way now you can start coloring and shading faces

I'm not available but I must say it's a pity because that's very veryy very pretty pixel art

If you're running at 3x, for example, you won't be able to do perfectly regular 50% scaling.

That's exactmy what I was doing (3x) and you're absolutely right.

Well, this is rather a misuse than a feature.

Yes totally. If I use it I'll use it for very specific purposes. Not to mention this can only be behind GUIs and can be animated only in repeatedly_execute_always, not repeatedly_execute


At the moment the only thing that annoys me is that the nearest-neighbour downscale is not uniformly 50% even though the dummy character's scaling is 50. It creates artifacts.

OK so here is a quick, functional proof of concept

DOWNLOAD

Thanks a lot for clarifying in such a condensed way.


Are characters the only in-game "entities" affected by this?