Messages

In the verb coin template, the setup happens in the Global Script's game_start function.
Can you show what you have in there?

Here's what specifically causes this error:

Code: ags

function a()
{

}

function b()
{

// } is missing here

function c() {  // <--- error will point to this line

}

As you can see, the problem isn't function c but function b. The error occurs because the compiler encounters the function keyword while still being inside the unclosed function b.

I'm not sure about the order of scripts but my guess is the dialog scripts are wrapped in functions and appended to the global script.
Did you check the very last function in the global script?

Can you post the dialog script in question?

You could try the gamedev forums: https://www.gamedev.net/tag/godot/

This isn't the critics lounge, but given the great sprite art I have to say I'd probably only rotate the wheel without the lighting, then paste that on top at 50% transparency or something like that.

The module calculates the four positions based on a given radius. You can skip that and manually place the buttons on your GUI, then remove the place_button(control, position); line from VerbCoin::RegisterButton.

Bah, it was really late

Code: ags

  if (gc != null && gc.AsButton != null || ii != null) mouseAnimFrame++; // hovering

Yeah, I should've listened to my gut and not changed these.

Replace the offending lines with

Code: ags

  GUIControl* gc = GUIControl.GetAtScreenXY(mouse.x, mouse.y);
  InventoryItem* ii = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);

(lower case mouse.x and mouse.y)

Also note that you have to use your own view's name (or number) where it says MOUSE_ANIMATION in my code.

Also please go easy on the quotes, this is really messy to read

Put this somewhere above the repeatedly_execute function in the global script:

Code: ags

int mouseAnimFrame;

function HandleMouseAnim() {
  GUIControl* gc = GUIControl.GetAtScreenXY(mouse.x, mouse.y);
  InventoryItem* ii = InventoryItem.GetAtScreenXY(mouse.x, mouse.y);
  
  if (gc != null && gc.AsButton != null || ii != null) mouseAnimFrame++; // hovering
  else mouseAnimFrame = 0;

  int view = MOUSE_ANIMATION; // view name here
  int frame = (mouseAnimFrame / 5) % Game.GetFrameCountForLoop(view, 0); // speed: 5
  ViewFrame* vf = Game.GetViewFrame(view, 0, frame);
  Mouse.ChangeModeGraphic(Mouse.Mode, vf.Graphic);
}

Now add this line inside the repeatedly_execute function:

Code: ags

  HandleMouseAnim();

This won't work. You still need a way to reference the positions.
(Also note that you can comment out multiple lines using /* and */ instead of putting // in each line)

Simply expand the enum like this:

Code: ags

enum VerbCoinPosition {
  eVerbCoinPositionNorth,
  eVerbCoinPositionNorthEast,
  eVerbCoinPositionSouthEast,
  eVerbCoinPositionSouth,
  eVerbCoinPositionSouthWest,
  eVerbCoinPositionNorthWest
};

You will now get errors where eVerbCoinPositionWest and eVerbCoinPositionEast are referenced, you can use these errors to find the lines you need to fix / add to.

I also encountered the Sprite 19 issue; the module is based on my old AGSKart code, and I simply hardcoded a bunch of stuff, including sprite slot 19 which ended up in Mode7::_DrawGroundSprites.
The workaround is to assign a random sprite to slot 19.

The two color block is probably due to the hard coded animated question mark; whatever you choose as sprite 19 ends up drawn to the ground on top of the main texture.

I found the missing piece: the module only draws to its DynamicSprite, and you have to draw that to the room:

Code: ags

function room_RepExec()
{
  ThePlace.Draw();
  DrawingSurface* ds = Room.GetDrawingSurfaceForBackground();
  ds.DrawImage(0, 0, ThePlace.Screen.Graphic);
  ds.Release();
}

Only, these memes and video are not POV.

That is... wow. I googled POV meme and one of the first results was "20 POV memes" from MemeHeist. And like not even half of them are even remotely POV in the physical sense, just in the "you know that feeling when" sense. Which is apparently what POV means now.

Those keys only work if they are handled accordingly, which isn't the case with just the module.

Not sure how to debug this tbh; can you maybe start with the demo game instead?

I believe there is a drawback with @Khris's code, in that characters walking along a straight line can end up flickering

Yeah, that's why I implemented the delay and emphasized that the resolution should be high. Without the delay this "algorithm" is almost useless.
Given how often people want to customize how walking works it would be a real boon if we had more low-level access to the pathfinding.
Years ago there was a FoA sequel in the works; they used vectors to define walkable areas; that way you could have interpolated lighting, scaling and areas on top of each other. It would be amazing for AGS 4 to support this.

It's not supported by AGS but it wouldn't impact the performance.

You can in theory code this: you would have to
1) make the actual player character invisible
2) track where they move
3) manually display a second character with the appropriate sprite in their place

2) means continuously reading their coordinates and determining the walking direction from that using inverse trig functions to figure out the loop, and also how far they moved to increment a walk cycle frame counter.

It's possible, and in high-res game it will probably work reasonably well.

Edit:

Put this in the main script of a new module and add a label called lblDebug to a persistent GUI.
This script tracks the movement and displays loop and frame. It has to be adjusted precisely to the walkcycle frames to look though. Again, only a high-res game will allow tracking on a scale that makes it reasonable to do this.

Code: ags

float prev_x, prev_y;

void on_event(EventType event, int data) {
  if (event == eEventEnterRoomBeforeFadein) {
    prev_x = IntToFloat(player.x);
    prev_y = IntToFloat(player.y);
  }
}

int loop, frame;
float total_dist;

int delay;

void repeatedly_execute_always() {
  delay++;
  if (delay < 4) return;
  delay = 0;
  float x = IntToFloat(player.x);
  float y = IntToFloat(player.y);
  float dx = x - prev_x;
  float dy = (y - prev_y) * 1.8; // perspective causes foreshortening, so we compensate
  float dist = Maths.Sqrt(dx * dx + dy * dy);
  if (dist == 0.0) {
    frame = 0;
    total_dist = 0.0;
  }
  else {
    float a = Maths.ArcTan2(dy, dx);
    loop = FloatToInt((a * 8.0 / Maths.Pi) + 7.5, eRoundNearest) % 16;
    total_dist += dist;
    frame = FloatToInt(total_dist / 7.0, eRoundDown) % 10 + 1; // 7 pixels per frame, 10 frames per loop
  }
  lblDebug.Text = String.Format("Loop: %d, Frame: %d, dx: %0.2f, dy: %0.2f", loop, frame, dx, dy);
  
  prev_x = x;
  prev_y = y;
}

You're welcome

Maybe the plane has the origin at its center? I.e. you'd need x = Random(2999) - 1500; and same for z.

Is this about making the object move across the screen? Why not just ask us how to do that?
All you need is a blocking Object.Move() call.

You don't have to go over every single pixel. All you need to do is check the color of the map after you generated random coordinates.
Assuming you're going to place 100 objects and assuming the track covers 20% of the ground, you will make roughly 120 GetPixel calls (since about one in five times you need to choose a new location).

Code: ags

  int x, z;
  for (int i = 0; i < 100; i++) {
    bool found = false;
    while (!found) {
      x = Random(2999);
      z = Random(799);
      int c = ds.GetPixel(x, z);
      found = c != 12345 && c != 7890; // actual yellow and black go here
    }
    track.AddObject(x, z, factor, graphic);
  }

(Even if you had to do it backwards, you said it yourself: use blocks of 50x50. As in: resize the map to 1/50 of its original size before running GetPixel over it. But again: you do not have to do that at all.)

Maybe the camera position and angle causes the mode7 ground to be off-screen?

Try

Code: ags

 ThePlace.SetCamera(0.0, 10.0, 0.0, 0, -0.1, 100.0);