Messages

But what if I am developing a module that use this property and don't want to rely on module's user setting it.
How can I protect my module from crashing the game?

I searched a bit, but could not find an answer for this.

Suppose I have a custom property "X" that some hotspots have and others does not.

I iterate over every hotspot and do "h.GetProperty("X");" the game will crash because some do not have this property set.

Is it possible to provide default value for properties or to test if a hotspot have this property set before accessing it?

PS. Then again, the biggest problem of AGS is very limited UNDO command.

+1 Caused me some wasted work


A different approach to solve the original problem could be to make an automatic backup each time auto save saves the game/room.

How is it possible to actually display the overlay on the screen?

Code: ags

function Bubble::Render(int x, int y)
{
  int radius = 10;
  
  DynamicSprite* sprite = DynamicSprite.Create(radius, radius, true);
  DrawingSurface* surface = sprite.GetDrawingSurface(); 

  surface.DrawingColor = 100;
  surface.DrawCircle(radius, radius, radius);  
  surface.Release();

  Overlay* myOverlay = Overlay.CreateGraphical(x, y,  sprite.Graphic,   false);

  // what now?  
  
  sprite.Delete();
}

The only way I found that worked displaying a dynamic sprite on the screen was to draw on the "Room.GetDrawingSurfaceForBackground()" surface:

Code: ags

  DrawingSurface *roomSurface = Room.GetDrawingSurfaceForBackground();
  roomSurface.DrawImage(x, y, sprite.Graphic);
  roomSurface.Release();

But the problem with this approach is that it is not possible to delete the sprite afterwards.

The goal is to create random bubbles that will slowly raise to the to the top of the screen.
The creation process of the bubbles should be dynamic.

Look here:
https://github.com/adventuregamestudio/ags-template-source/blob/master/Verb%20Coin/VerbCoin.asc

The RegisterButton and RegisterGui functions should explain the code above.

Inuse the VerbCoin template.

I was thinking of ways make the VerbCoin script easier to integrate into existing games(add the script and make as few editor and main script changes as possible)

Currently, to work properly it requires to register a callback in the main script for the  OnClick event for each verb button, and call VerbCoin::OnClick function from inside it.

I was thinking that since this button is registered at the beginning in RegisterButton, I could also set it's OnClick cllback.

Is it possible to assign a function as OnClick event to a bunch of buttons through script (at runtime)?

Regarding the first question.

The connection between the button and the mode is established when you register the verb. It is stored inside VerbCoin.

Therefore, you can add a lookup function to the VerbCoin and call that function from bLook_OnClick.

Assuming you base your work on the template coin verb:

Code: ags

static function VerbCoin::GetModeByControl(GUIControl* control) {
  
  if (control.OwningGUI == interface && control.Visible) {
   
    return modemap[control.ID];
  
  } else {
  
    return eModePointer
  
  }
  
}

Thank you!

Whichever method it use for graying out, it is not working well with this sprite. I would have expected an option to provide custom sprite for this, similar to mouse over image.

This happens in AGS 3.4.1, on a project that was created from a 3.4.0 default template.

When the game is in "blocking" mode, such as if a dialog is open or the character is saying something, then button's image will look distorted.

Is this a bug or could have I done something wrong?

Button parameters:


How it looks normally:


How it looks with distortion:

If I want a character to walk to a specific location in the room using script, I need to use the mouse pointer to find the coordinates, then I can write a script command similar to:

Code: ags

cEgo.Walk(14, 22);

or better:

Code: ags

int ladderX = 14;
int ladderY = 22;
cEgo.Walk(ladderX, ladderY);

To demonstrate that this is not just my noobish ignorance of a better way, here is an example from Dave Gilbert's Unavowed devstream #4 - Doors doors doors doors doors:



(the culprit is "player.placeAt(382,294);" )

I think that it would be nice if one could mark a coordinate on the screen, give it a name and use the name in script, similar to how regions, walk able areas etc. work.



This will be more intuitive, more maintainable and possibly prevent some mistakes.

Code: ags

cEgo.Walk(coordLadder.x, coordLadder.y);

or even

Code: ags

cEgo.Walk(coordLadder);

Ok, now I understand what you meant regarding the regions.

I have one more question.

The "ApproachCharacter" function now looks like that:

function ApproachCharacter(this Character*,
                           Character*    npc,
                           int           offsetX,
                           int           offsetY
                           /*BlockingStyle blockingStyle, 
                           WalkWhere     walkWhere*/)
{
  int trueOffsetX = 0;
  int trueOffsetY = 0;

  // Facing npc allows calculating direction of approach
  this.FaceCharacter(npc);
 
  switch (this.Loop) {
   
    case eDirectionUp:
      trueOffsetY = offsetY;
      break;
    case eDirectionDown:
      trueOffsetY = (-1) * offsetY;
      break;
    case eDirectionRight:
      trueOffsetX = (-1) * offsetX;
      break;
    default:
      // fall through to eDirectionLeft
    case eDirectionLeft:
      trueOffsetX = offsetX;
      break;
  }
 
  this.Walk(npc.x + trueOffsetX, npc.y + trueOffsetY, eBlock, eWalkableAreas);
 
  this.FaceCharacter(npc);
  npc.FaceCharacter(this);
}

It is working fine as is, but I want to change it a little. I want to be able to interrupt the walking sequence and move the character to a different location.

For this to be possible, this.Walk should be non-blocking.

My question is, how do I determine that the player finished walking and reached it's destination so that a dialog can start?

I had an idea that it is possible to busy-wait for the "Moving" property of the player to become false, but how do I know that it became false due to the player reaching it's destination and not because the walking was interrupted?

Thanks, "SayToCharacter" function does makes it more simple.

Does the "magic number" depend on the character (e.g. with cAlice you should always be 10 pixels away), on where they are on the screen (e.g. if you're talking to a character who's behind the desk, you should always stand in a certain position), or both? Does it need to change depending on the character scaling? Do your characters stand in one of a number of pre-defined locations, or do they wander about anywhere on the walkable area?

This question is not for a specific game, I just experiment with AGS and try to see what is possbile, so it can depend on any of the things you listed.

I just thought about additional problem. If the player character is already near the NPC character, but the offset makes it walk to a different position, the player will walk to it instead speaking to the NPC from the current position.

If characters can be anywhere on the screen, with different WalkTo behavior in different parts of the screen, you might need to define regions, and a lookup table from each region to its WalkTo point/offset.

This part I do not understand.

If a WalkTo point falls outside a walkable area, the character should walk to the closest point it can reach. If that's not acceptable, what is it that you want to happen?

Great! Did not know about this.

Is it possible to add a keyboard shortcut to the "stop" command?

Something like "SHIFT + F5" would be nice.

If a WalkToPoint of a hot-spot is set, every interaction with that hot-spot will automatically make the player walk to that point.

I do not see similar property for characters. Interacting with characters will make the interaction immidiate, without walking the player first to face the character.

It is of course possible to add some code:

Code: ags

function cNPC_Look()
{
  // Walking and orientation boilerplate
  cPlayer.Walk(cNPC.x, cNPC.y + 15, eBlock, eWalkableAreas);
  cPlayer.FaceCharacter(cNPC);
  cNPC.FaceCharacter(cPlayer);

  // What I actually want to happen
  cPlayer.Say("I have no idea who is this");
}

This approach has problems:

• Every interaction (look, talk, interact etc) type of every character needs to have this boilerplate code.
• The "15" magic number needs to be separate for each character and updated after every change to the position of the character.
• If a mistake is made, there is no way to catch it before testing. Even indirect changes can have effect. For example a walk area can be reduced to exclude this point.
• If the character can move during the game, it requires "15" to be calculated dynamically (how?)

Is there a better way doing the same thing?

Great, thank you.

Can you point me to the relevant manual entry? I was not able to find anything relevant in http://www.adventuregamestudio.co.uk/manual/

When is it preferable to use room messages instead of simply using a string?

It seems to me that

Code: ags

cChar.Say(Room.Messages[1]);

is much less maintainable than

Code: ags

cChar.Say("Hi!");

so I guess there are specific use cases that room messages are required.