Messages

If it turns out that you need "overlaying" areas, then this may be solved by adding a second row of transparent objects, duplicating these cards. These transparent objects do not move and stay in down position, but have their baselines adjusted along with their visible counterparts.

Ah-ha, this might be the solution! I'll give it a shot today and let you know if it worked.

I suppose that you may use hotspots for this.

The problem with this approach is the one I mentioned earlier to eri0o: "trigger" areas would stop corresponding to their visual representations. (Not to mention that because the cards are rotated at runtime, drawing the hotspots in the editor would be a huge hassle. Doable, though.)

For example, if I used these hotspots:



Moving the mouse over the purple area would bring the queen up. But then things would look like this:



Now the hotspots don't match the cards. Moving the mouse into the green area would bring the queen card down again, even though the player still has the cursor over it.

The way I see this, the logic should be following:

On each game tick:
- check which object is under the cursor and remember it, in local variable
- for each object, in a loop:
  - if this object is the one under the cursor:
    - if it's already up or moving up
         then keep it that way
    - else
         start moving it up
  - if this object is not the one under the cursor:
    - if it's already down or moving down
         then keep it that way
    - else
         start moving down

Just looking at the logic without implementing it, this would not avoid the flickering, right?

If we have the cursor barely touching an object, our logic tells us to move that object up. That object is no longer under the cursor, so it needs to move down. Upon moving down, it touches the cursor again, and so up and down ad infinitum.

It looks like you have memory of at most 1 action, so if you can overwhelm your memory of 1 it could cause the behavior of the card getting stuck.

The issue of the edge case that causes the card to pop up and down and the previous issue also seems to be an issue of having the behavior and the presentation being mapped on top of the same thing - the object both is how you show things on screen and how you detect things are clicked. When things are moving, this may not be a good idea, it may make more sense to look at the same region of the screen and then execute the behavior - you could use like a hotspot (or 99 transparent stationary object) to detect clicks and mouse over and then animate the other thing.

Hey eri0o,

The problem with using hotspots or zones defined by angles is that the interactable area will no longer corresponde to its visual representation. So basically, if a card (say, the Queen) is up and you move the cursor out of its hotspot, the card will go down even though the cursor is visually still on top of that card.

I have managed to solve the issue of cards staying stuck by modifying my code like this:

Code: ags

function room_RepExec()
{
  Object* o = Object.GetAtScreenXY(mouse.x, mouse.y);
  
  if (o == null) {
    if (previouscard != null) {
      previouscard.Baseline = previouscard.Baseline - 3;
      for (int i = 0; i < 5; i++) {
        object[i].StopAllTweens();
        descendCard(object[i]);
      }
      previouscard = null;
    }
  }
  
  else if (o != null && previouscard != null && o != previouscard) {
    o.Baseline = o.Baseline + 3;
    ascendCard(o);
    previouscard.Baseline = previouscard.Baseline - 3;
    for (int i = 0; i < 5; i++) {
        if (object[i] != o) {
          object[i].StopAllTweens();
          descendCard(object[i]);
        }
      }
    previouscard = o;
  }
  
  else if (o != previouscard) {
    o.Baseline = o.Baseline + 3;
    ascendCard(o);
    previouscard = o;
  }
}

With this, cards no longer get stuck since they're always forced downwards. However, this makes the flickering of the edge cards even more noticeable now:



I have also tried using simple Move commands instead of tweens (I prefer tweens because it allows me to use easings, but it's not a dealbreaker), but the issue remains the same.

I'm implementing a card minigame in my game and I want the cards to "pop" up and move to the front when the mouse moves over them. When the player moves the cursor at a "reasonable" speed, things go well:




However, if the cursor moves too fast, some cards will get "stuck" in their top position and won't go back down:



Also, if I leave the cursor at just the right spot, the card will start jumping up and down, since it will constantly move in and out of the cursor's hotspot:



This last case doesn't worry me too much since it's kind of an edge case, but the cards getting stuck is a real problem that makes the whole thing look kind of bad. Is there any way I could avoid that?

My code:

Code: ags

Object* previouscard;

void descendCard(Object* card)
{
  int ycoord;
  switch(card)
  {
    case oObject1:
    case oObject4:
      ycoord = 220;
      break;
    case oObject2:
    case oObject3:
      ycoord = 205;
      break;
    case oObject0:
      ycoord = 190;
      break;
  }
  card.TweenY(0.25, ycoord, eEaseOutBackTween, eNoBlockTween);
}

void ascendCard (Object* card)
{
  int ycoord;
  switch(card)
  {
    case oObject1:
    case oObject4:
      ycoord = 210;
      break;
    case oObject2:
    case oObject3:
      ycoord = 195;
      break;
    case oObject0:
      ycoord = 180;
      break;
  }
  card.TweenY(0.25, ycoord, eEaseOutBackTween, eNoBlockTween);
}

function room_Load()
{
  
  oObject1.Baseline = 189;
  oObject2.Baseline = 190;
  oObject0.Baseline = 191;
  oObject3.Baseline = 190;
  oObject4.Baseline = 189;
  // there's a series of dynamic sprite rotations here which I'm omitting because they're not relevant

}

function room_RepExec()
{
  Object* o = Object.GetAtScreenXY(mouse.x, mouse.y);
  
  if (o == null) { // to empty space
    if (previouscard != null) {
      previouscard.Baseline = previouscard.Baseline - 3;
      descendCard(previouscard);
      previouscard = null;
    }
  }
  
  else if (o != null && previouscard != null && o != previouscard) { // from one card to another
    o.Baseline = o.Baseline + 3;
    ascendCard(o);
    previouscard.Baseline = previouscard.Baseline - 3;
    descendCard(previouscard);
    previouscard = o;
  }
  
  else if (o != previouscard) { // from empty space to card
    o.Baseline = o.Baseline + 3;
    ascendCard(o);
    previouscard = o;
  }
}

I can add options to disable these.
Because Accessibility group may contain a wide range of settings, then they probably will require separate disable settings per subgroup (or even per individual options in certain cases).

Of course this will open an opportunity for game developers to prevent players from having these options when they might actually need them.

Appreciate it, CW. I definitely see no need to remove them completely, just giving us the option to disable them like you just said is perfect.

Won't this defeat the purpose of these options? The whole point is to let players override the game in case developer made it impossible for them to play the game. If a game developer will disable them, then players who might need them won't be able to use them.

Ultimately I think the final control over what can or can't be done with the game should belong to the developer, and while accessibility features are something that the engine should definitely offer, in the end it should be the decision of the developer whether to actually implement them or not, or which ones to implement. If my game is designed in a way that I feel that overriding my design decisions will cause issues or change the experience somehow, I would prefer to prevent users from tampering with those options.

[WinSetup:]

- Expanded `on_mouse_click` callback, now supports two more parameters: click x,y coordinates.

This is amazing, I've been wanting this functionality for so long. No more hacking it with GetAtScreenXY!

WinSetup:
 - Redesigned winsetup into a tabbed dialog.
 - Added "Accessibility" settings for skipping speech and text messages.

Will it be possible to disable these options with the [disable] tag in the cfg file, as we can already do for other options like gfxdrivers, filters, etc?

Hey @glurex, sure, feel free to change what you want, although like CW said, this module is basically obsolete thanks to the new Pause and Resume functions.

I have no idea why the module should fail when pausing audio type "Sounds", so if the solution is to only being able to pause Ambient and Music types then it's not super useful anyway. Maybe it has problems with very short sounds, like footsteps, or does it affect all "Sound" type clips?

(Also, I have no idea why I hardcoded the number of channels when I could / should simply have used System.AudioChannelCount. Oh well!)

Is there actually a use case for having 2 separate settings with different values?

I'm sure other devs will have their own use cases and specific applications of this, but these are some of the ones we're working with now:

The most simple case is that sometimes we want some characters to use their full turn but not others (main characters vs. secondary ones, for example), so this would be the basic application of having "turn to face direction" as a character property.

As to having 2 separate settings with different values ("turn to face direction" vs "turn when walking"), I can think of two cases right off the bat.

In the first case, we want to disable "turn to face direction" for some characters because we have custom animations for their turns, while at the same time keeping their default "turn before walking" behaviour enabled.

In the other case, we want to have "turn to face direction" enabled for some characters, but we keep "turn before walking" disabled because the way they turn looks a bit janky because of the way the walking loops are designed or whatever.

From the looks of it, this will be trivial to add. But if added, this is going to be in the next 3.6.x version, not in 3.6.1 patches.

Sounds great to me!

EDIT:
On second thought, would not it be convenient to have this as a parameter in Face* functions? Because I may easily imagine situations when same game may have a need to turn the character quickly or slowly depending on circumstances.

I think it's more practical to have it be a character property, and to be able to enable/disable it in script for punctual situations, than to have to specify it as a parameter for every face direction / character / object command. I would imagine that the most common scenario would be to want a consistent behaviour for the character, and only want to change the "speed" of the turn for very specific moments, if at all.

[not]

The issue, at least for me, is that this forces you to enable or disable "Characters turn to face direction" for all characters.

The manual is a bit confusing, what with the double negation, but what it says is:

If the character has Turning enabled (i.e. the "Characters turn to face direction" game option is turned on, and the character does not have the "Do not turn before walking" option checked), then the character will turn on the spot in order to face the new direction.

Simplifying the double negation for better readability (and also, the property is now called "Turn before walking", not "Do not turn before walking"):

If the character has Turning enabled (i.e. the "Characters turn to face direction" game option is turned on, and the character has the "Turn before walking" option checked), then the character will turn on the spot in order to face the new direction.

So we can create a truth table, kind of like this:


Characters turn to face direction: ENABLED - Turn before walking: ENABLED
- Character turns when facing a direction, and when walking.


Characters turn to face direction: ENABLED - Turn before walking: DISABLED
- According to the manual, the character should not turn to face a different direction, but my tests show they do. I think there there are two distinct cases here: one is issuing a FaceDirection command that simply makes the character look in a different direction, and the other is when there is a Walk command that will result in the character facing a different direction before walking.


Characters turn to face direction: DISABLED - Turn before walking: ENABLED
- Characters will only turn when walking (whether it's from idle to walking, or when changing directions while walking).


Characters turn to face direction: DISABLED - Turn before walking: DISABLED
- No turns at all.


So the logic seems to be that these two properties are completely independent of each other. If "Characters turn to face direction" is enabled, then it is enabled for all characters, which is something you might want for only a few of them.

I don't know if 3.6.x is considered pretty much closed and done, but I was wondering if it would be possible to implement a small QOL feature to make "characters turn to face a direction" a character property, the same way as "characters turn before walking". The latter is adjustable on a per-character basis as well as from script, but unfortunately the former isn't.

I don't know if people have simply lost interest in the contest or if recent themes have been less interesting or too difficult for some reason. Maybe the novelty of a new contest has simply worn off.

I personally love reading the crazy (and hilarious!) solutions people come up with, but I don't have the imagination to take part myself. Also, since I don't drop by the forums too often, I don't always make it in time for the voting round. That's definitely my fault!

Also, like cat said, there used to be more activities and competitions in the past (a couple of years ago we had a communal detective game that was super fun, for example), but we seem to be in a lull right now. I guess it's just the natural ebb and flow of any online community, but personally (and selfishly) I would love to see these puzzle-making challenges continue. They really brighten my day

Failing that is there a way for the script to access an object or frame's size? I could just tell the thing to adjust Y to Y + height. I expected there to be something like Object.Height but there isn't, just the blocking height which I have to set manually, so that's no good.

There isn't a direct Object.Height, but you can get the object's sprite using Object.Graphic, and then get this sprite's size using Game.SpriteHeight and Game.SpriteWidth.

Haha, my Italian summer vibe is a lot more chill and a lot less disco than this

Gianfranco Plenizio did a bunch of movie soundtracks that are well worth checking out. Most of them are on Spotify, if you have access to it.

Ah, very nice, I didn't have him in my sights. I've been digging quite a bit into some of the 60s-70s Italian composers featured in those compilations, and Stelvio Ciprani, Piero Umiliani or Piero Piccioni, to name a few, are all really good, ranging from the kind of chill easy listening I posted above to experimental electronica like the soundtrack of L'uomo elettronico. Very, very cool stuff in general!

Now, I already choose my vibe for this summer:

Haha, my Italian summer vibe is a lot more chill and a lot less disco than this

I don't know how I came across these "Easy Tempo" compilations, but they're * chef's kiss *

Oops, apparently the site's code doesn't support embedding playlists, so here is the link to the whole album: https://www.youtube.com/watch?v=pU2TsVcjDCk&list=PLRQKT-Cu2_2TsjKan5BuakLJBNHnkjuO8

And another one of my faves from this series,

[Compiled]

@Laura Hunt I also added the Debug folder but it didn't help

I only have the Compiled folder added to my Defender exceptions, nothing else, not Debug either. Just tried running my game with F5 (AGS version 3.6.1.23) and I have no issues whatsoever. I'm running Windows 10 though, so maybe it's a Windows 11-specific issue.

Adding the AGS folder to the whitelist in Windows Security had no effect either, so I was looking for another solution.

Aren't you supposed to add the game's own Compiled folder as an exception to Windows Defender, rather than the AGS folder? This is what I do and I haven't had this issue in ages.

And what do we do? I'll let another one of my heroes explain:

Eek! * blushes *

Wow, that was a while back! Now that I'm more knowledgeable and I also have less time to check out and play games, you're more likely to find me on our Discord server helping new users out with scripting questions and testing new engine features than commenting here. It's interesting to see how people find their places and "roles" within the community, and this award is just the least we can do to acknowledge that, I think.

That is to say, well deserved, @heltenjon! And huge props to everybody else, organizers, developers, attendees, and the community as a whole for making this happen year after year. See you all again on the dancefloor in 2025!