Messages

I've got an improvement that I'd LOVE to see added: When right clicking on a GUI in the Project Explorer, have a "Duplicate GUI" option. This would copy everything from the selected GUI and create a new GUI with a standard name (E.g: gGui1) from it.

Considering all the contents of each GUI are public to each script, the duplication would have to account for buttons, etc., with the same names.
I agree, it would be a nice feature.

I'm looking into this. At least it's not a stack pointer problem :/

EDIT: Found the problem, reproduced it, sufficiently embarrassed. I have a pull request on the Git repository that fixes this.

One step closer to the final build

I've found a bug relating to for loops and 'continue' (reproducible). I created a game from the Default Game template, placed that code in the first room's room_FirstLoad() function, and tried to compile.

Example:

Code: ags

function room_FirstLoad()
{
    for (int i = 0; i < 10; i += 1)
    {
        if (true)
        {
            continue;
        }
    }
}

Error while compiling:

Spoiler

Error: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Version: AGS 3.4.0.4

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at ccCompileText(SByte* , SByte* )
   at AGS.Native.NativeMethods.CompileScript(Script script, String[] preProcessedScripts, Game game, Boolean isRoomScript)
   at AGS.Editor.NativeProxy.CompileScript(Script script, String[] preProcessedData, Game game, Boolean isRoomScript)
   at AGS.Editor.AGSEditor.CompileScript(Script script, List`1 headers, CompileMessages errors, Boolean isRoomScript)
   at AGS.Editor.Components.RoomsComponent.SaveRoomOnThread(Object parameter)
   at AGS.Editor.BusyDialog.RunHandlerOnThread()
   --- End of inner exception stack trace ---
   at AGS.Editor.BusyDialog.Show(String message, ProcessingHandler handler, Object parameter)
   at AGS.Editor.Components.RoomsComponent.SaveRoomButDoNotShowAnyErrors(Room room, CompileMessages errors, String pleaseWaitText)
   at AGS.Editor.Components.RoomsComponent.RecompileAnyRoomsWhereTheScriptHasChanged(CompileMessages errors, Boolean rebuildAll)
   at AGS.Editor.Components.RoomsComponent.AGSEditor_PreCompileGame(PreCompileGameEventArgs evArgs)
   at AGS.Editor.AGSEditor.PreCompileGameHandler.Invoke(PreCompileGameEventArgs evArgs)
   at AGS.Editor.AGSEditor.CompileGame(Boolean forceRebuild, Boolean createMiniExeForDebug)
   at AGS.Editor.Components.BuildCommandsComponent.CompileGame(Boolean forceRebuild)
   at AGS.Editor.Components.BuildCommandsComponent.CommandClick(String controlID)
   at AGS.Editor.ToolBarManager.ToolbarEventHandler(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at AGS.Editor.ToolStripExtended.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[close]

First thing I noticed was:

Code: AGS

const char *ourScriptHeader =
"import void SendData(sf::Packet, unsigned short);\r\n"
"import int ReceiveData(sf::Packet, unsigned short);\r\n"
"import sf::IpAddress getFriendIP(void);\r\n"
"import void setFriendIP(sf::IpAddress);\r\n";

That part of the plugin is supposed to follow AGSScript syntax. It's used to create the script representation of your plugin's features.
Therefore, because AGSScript doesn't support namespaces, 'sf::Packet' and 'sf::IpAddress' will cause syntax errors. You're going to have to find a way to get past the use of 'sf::'.

[The TBitField Module]

The TBitField Module

So this is my first module and it's something that I've used a few times before but haven't seen on the forums so far, so I decided to put it up on here.
If anyone has any suggestions or criticisms, then have at it I always welcome constructive feedback.

What is it?
It's a pretty basic struct with some bit manipulation functionality. Usually I use it to mask flags to save memory (just for fun), hence the name.
Sometimes bitwise operators all over the place can look a bit dirty, so maybe this will clean some of it up at least.

How do I use it?

Code: AGS

TMASK mask = 10; // can be any number from 0 to 255
TBitField field;
field.setMask(mask); // or just field.setMask(10) if you so desire
// away you go

In case the method names aren't clear enough, or if you just want to be sure, I've provided documentation with the module.

Where can I get it?
Works with AGS 2.71 and above.
Current version: TBitField Module v1.0
Mirror: TBitField Module v1.0

Bugger. Oh well, thanks for the confirmation.

I'm not sure if this has been asked before, but I can't seem to use eKeyCtrlV in on_key_press at all. Is this reserved specifically for displaying the version info, or is there a work-around for using eKeyCtrlV?

3. An easier way to bind certain tile types to game data (passability, location properties); actually I have no idea how people do this without tile engine - using regions and walkable areas sounds hell of a work.

Writing your own plugins makes those kinds of things much much easier. But then again, you need to learn how to use the plugin API

I personally think that it depends on what you want to do with the game. If you want people to be able to make their own maps or something like that, then you may benefit from a tile based engine (initially), but later stitch all the tiles together to make a single image if you'd prefer it that way (saves having to draw each tile over and over). If it's something that doesn't really change dramatically, and its something that you want the player to have no control over, then I don't really see much of a point in a tile engine (it could all be hard coded). Whether or not it makes things easier to code for yourself is up to how you would like to make it. Making a tile engine, however, may make for some easily reusable code if you wish to go down that path again in other projects.
Just my two cents.

I am so glad to see this kind of push towards continuing AGS's development!
Having used (on and off) AGS for 6 years now, its an amazing feeling to know that people from the AGS community are ready and willing to improve on what has already been a great experience.
I'm pumped to see how this pans out, no matter how long it takes

Reading the manual is also increasingly strange because many commands still mention their 2.x forerunners. Could be a nice time to clean things up a little?

I guess that's mainly to help people with the transition from the 2.x commands to their 3.x equivalents.

That is called a Wiki. Transfering the documentation to a Wiki and maintaining and using it from there is also an option.

Maybe it's just me, but I quite like the ability to press F1 and quickly find a command or whatever. It seems much faster, and less effort, than opening a web page (unless the documentation was displayed from the help files, which would be alright I guess, but it may need online access?).

Also, the 'const' keyword:

Code: AGS

struct foo { int data; };
int a = 10, b = 30;
const int c = a * b; // const would be sooo handy, or at least let 'readonly' act the same as const
foo arr1[c];
foo arr2[a * b];

Instead of having to use #define (could not use #define if we did not yet know the value of a and/or b before declaring the arrays).
AND everything that monkey said. All of it.
Cheers

My god, that just destroyed my post I don't know why that wasn't the first thing I thought of.
Thanks Snarky.

I have a grid made up of tiles (15 x 15 pixels) that I would like an object to snap to (the object is 15 x 15 pixels). The problem is that the object has to follow the cursor, snapping to the grid as it moves. I've tried a few different methods to get this to work but they've turned out a bit ugly. For example, at the moment, my script checks which direction the cursor is moving and whether its position is divisible by 15 before setting the position of the object. But once the cursor starts to move in a bit of a diagonal fashion, the object doesn't quite snap to the grid.

Code: AGS

    // in global space of the room script
    bool isDragging = false; // used to stop mouseX and mouseY from being continuously set to the cursor's current position
    int mouseX, mouseY; // used to hold the position of where the mouse used to be before it moved
    int tileSize = 15;

    // ...
    // in room_RepExec()
    if (!isDragging)
    {
      mouseX = mouse.x;
      mouseY = mouse.y;
      isDragging = true;
    }
    
    if (mouseX > mouse.x) // mouse is moving left
    {
      int i = 0;
      while (i < tileSize)
      {
        if ((mouse.x + i) % tileSize == 0)
        {
          oPlaceHold.SetPosition(mouse.x + i + 5, mouse.y); // oPlaceHold is the object
          i = tileSize;                                     // also, +5 because the grid is 5 pixels away from the left and top of the screen
        }
        i++;
      }
      isDragging = false;
    }
    else if (mouseX < mouse.x) // mouse is moving right
    {
      int i = 0;
      while (i < tileSize)
      {
        if ((mouse.x - i) % tileSize == 0)
        {
          oPlaceHold.SetPosition(mouse.x - i + 5, mouse.y);
          i = tileSize;
        }
        i++;
      }
      isDragging = false;
    }
    if (mouseY > mouse.y) // mouse is moving up
    {
      int i = 0;
      while (i < tileSize)
      {
        if ((mouse.y + i) % tileSize == 0)
        {
          oPlaceHold.SetPosition(mouse.x, mouse.y + i + 5);
          i = tileSize;
        }
        i++;
      }
      isDragging = false;
    }
    else if (mouseY < mouse.y) // mouse is moving down
    {
      int i = 0;
      while (i < tileSize)
      {
        if ((mouse.y - i) % tileSize == 0)
        {
          oPlaceHold.SetPosition(mouse.x, mouse.y - i + 5);
          i = tileSize;
        }
        i++;
      }
      isDragging = false;
    }

I'm very sure that this code could be more efficient and that there is a better way, but I'm stumped, so any ideas would be great.
Cheers, Terrorcell.

Fair enough.

So I have been trying my hand at an RTS game in AGS. I chose AGS for its engine as a sought of challenge.
Basically, I've been going at it for some time now, and I've found a fair few things that, due to some of AGS' restrictions in the coding department, have become rather difficult to implement.

I need someone to take a look at the code (I will comment it heavily) and point out any issues, give suggestions, etc, etc.
You will be added in the credits for your troubles, but I really only need maybe two people to help out. Everything will be sent over pm's here.
I started this topic in the Advanced Technical Forum because I don't want a team (so there are no time limits and so I can work on it whenever I like) and because the game is by no means complete.
Also, I would like the code and any discussions of this to be private, as it is my first attempt at something as challenging as this.

Anyway, cheers for any help, pm me if you're at all interested,
   - Terrorcell

This is very impressive. If you get the chance, you should write up some documentation for it, perhaps even expand on it

I know what he meant, but the point is that if I check if the tile is on the screen before it gets updated then the rest of the tiles that arent on the screen (as in the viewport I am guessing you mean) won't get updated, and so if a character (there are more than one that the player can control) moves around in the fog of war off screen, then the effected tiles will only stop being drawn once the player moves the viewport to that units position. That could get quite ugly I think.

The way it works now is in the drawing function for the character (the function that draws the character onto the map) a function is called with the characters x, y and range values passed into it. That function updates the tiles within the range of that character, and seperately, in the room script, the function that I posted above goes through all the tiles that are still shrouded and draws them. If the tile has been revealed, then the tile is not drawn.

@Calin Leafshade
Sorry, but could you elaborate on that a little more? Do you mean stitch the tiles together as a single graphic, save them to a room object and then draw them? :S

@Radiant
Drawing black rectangles instead and avoiding the index() function together only increased the FPS by roughly 1. Also, the tiles visibility is updated when the character is drawn, and then the tiles are drawn onto the background depending on their state of visibility. If they have been revealed already then they are not drawn.

So I'm creating a game that requires fog of war to shroud the map for the player. So far, the fog of war is made up of an array of a fog of war struct (array size depends on the map size, my test map's FOW array size is 5120, but that's a small map in regards to my bigger plans) that holds variables such as 'bool isVisible' and the sprite slot number that it uses (the sprite is a 15x15 black square).
Basically, everything is drawn onto the background every game loop, and every time a character is drawn the fog of war array is updated, changing its isVisible variable to true if the character has uncovered that tile (pretty much a view distance). Every game loop, the fog of war is also drawn onto the background, tile by tile:

Code: ags

function drawFOW()
{
  roomsurface = Room.GetDrawingSurfaceForBackground();
  
  int y = 0;
  while (y < tilesHeight) // the fog of war array is actually a 2d array, but is represented through the index() function, so tilesHeight is the width of the map (1200) / the tile size (15)
  {
    int x = 0;
    
    while(x < tilesWidth) // same goes for the width here, 960 / 15
    {
      if (!Tiles[index(x, y)].isVisible) // checks to see if the current tile in the loop is already visible, skips the drawing if it is
      {
        roomsurface.DrawImage(x * tileSize, y * tileSize, fog.Graphic); // fog.Graphic is the sprite slot used for each tile, tileSize is 15
      }
      
      x++;
    }
    
    y++;
  }
}

This is very heavy on the games FPS, as you can imagine, and I'm having a bit of trouble thinking of ways to optimise this
Iterating through an array that size doesn't hurt the FPS very much at all, but the DrawImage() function being called that many times (5120) every game loop drops it by about 10-12 FPS.
I can't just draw what can be seen in the view screen because the whole background, after the fog of war has been drawn onto it, is then drawn onto a minimap.

So I was wondering if anyone had any ideas? Would be very much appreciated