Messages

[file]

I believe it is actually just referring to end of file. With a missing closing parenthesis like that, the parser is consuming the rest of the script file looking for another parenthesis. It might be possible to catch this earlier on (e.g., if it encounters a closing curly brace before it finds the matching parenthesis). I'm not sure if there's already an issue in the tracker for that or not, but there probably should be.

[intentionally]

I'll ignore that you are still intentionally messing up the formatting of your code.

The snippet you posted compiles and runs without any problems. (Note: I graciously provided a closing brace which was missing from your snippet. This was the only "error".)

I did not test the logic of your code for desired behavior because you have not explained what the problem is or what you expect to happen ("fails to use the item on the item" literally means nothing).

Once again, the code does not produce any errors, so this:

ERROR: undefined symbol 'item'

Is just simply false.

Good day, sir.



Edit: Pro-tip:

Code: ags

function on_mouse_click(MouseButton button)
{
  if (IsGamePaused() == 1)
  {
  }
  else if (button == eMouseLeftInv)
  {
    InventoryItem *item = InventoryItem.GetAtScreenXY(mouse.x, mouse.y); // DEFINE 'item'
    // HERE, 'item' TOTALLY EXISTS
    // ...SEVERAL LINES LATER...
    // YUP, 'item' STILL EXISTS HERE
  } // HERE, 'item' NO LONGER EXISTS
  // YEAH, 'item' STILL DOES NOT EXIST HERE EITHER
}

k

There's nothing built-in, but validating this type of input is really simple:

Code: ags

function TextBox1_OnActivate()
{
  String text = TextBox1.Text;
  int i = 0;
  while (i < text.Length)
  {
    if ((text.Chars[i] >= '0') && (text.Chars[i] <= '9')) // TODO: optionally check for decimal or thousands separators
    {
      // text is a valid number...
    }
    else
    {
      // text is not a number!
      TextBox1.Text = "";
      Display("Please enter a number! Value entered was \"%s\".", text);
    }
    i++;
  }
}

Regarding the "repositories" idea, maybe what could be done would be to simply do away with the special string tags altogether in favor of another enum which would specify file location, added as parameters for File.Open, File.Exists, and File.Delete, all defaulted to game directory. I don't see a reason or significant benefit behind adding this as a new script object type.

Well, as I said, I proposed the tag for consistency's sake. If we're adding a function then File.OpenResource(const string) is fine. As noted, non-embedded resources may be opened normally. Though I would add that a File.ResourceExists(const string) should also be included.

[$SAVEGAMEDIR$]

I suppose I was thinking that resources might have some additional properties that might need to be handled by a Resource class, though in retrospect I suppose that's probably not the case (especially for arbitrary files).

In that respect I would say that the "priority" or "location" should not even be a parameter to the function at all, but instead just a new "special tag". We already have $SAVEGAMEDIR$ and $APPDATADIR$ which are compatible with File.Open, so I would suggest a new tag such as $RESOURCES$ which would indicate that the file is an embedded resource of the game package. The "default" behavior of using the game's installation directory would be preserved simply by not using this new tag. If a path is given containing this new tag with a FileMode other than eFileRead, a null pointer is returned.

This keeps changes to the engine at a minimum (no actual API changes) and is completely consistent with the existing function.

Code: ags

File *f = File.Open("$RESOURCES$/myFile.txt", eFileRead); // assume valid embedded resource "myFile.txt"
if (f != null)
{
  // do stuff!
  f.Close();
}
else if (File.Exists("$RESOURCES$/myFile.txt")) // should never happen
{
  // presumably, File.Exists should also be able to check for the existence of embedded resources
  AbortGame("Game files corrupted");
}
f = File.Open("$RESOURCES$/myFile.txt", eFileWrite); // assume the same for eFileAppend
if (f != null) // should never happen, cannot open resource in write/append mode
{
  Display("Opened resource in write mode!");
  f.Close();
}
f = File.Open("$RESOURCES$/madeUpResource.dat", eFileRead); // non-existent resource file
if (f != null) f.Close();
else Display("Made up resource doesn't exist!"); // should always happen

Any* AGS+Steam game can be launched as a standalone (no Steam features) simply by running the game's executable from the local cache ("/Steam/SteamApps/common/GameName/Game.exe"). If there is a file called "steam_appid.txt" in the folder then you would need to rename/remove it or make sure to close the Steam client before launching the game.

(There used to be a direct download of Heroine's Quest available, but now annoyingly I can only find the Steam link.)

If you absolutely don't want any Steam features, then I would suggest that you could use the Steam client simply to download the game, and then move the game files out of the Steam folder. Obviously that doesn't save you from having to have Steam installed in the first place, but...are you honestly saying that you don't have Steam installed? (I'd just find it surprising these days to find someone involved in the gaming community to not have Steam... )

*I can't speak definitively to this end on Wadjet Eye's games, but to my knowledge no AGS game on Steam uses the Steam DRM'd executables. If any of them do, then obviously this would not apply as the executable would force the game to be launched from Steam.

Android is planned, but a long way off yet. I don't know anything about deploying for iOS, but as far as I have read it would require a Mac (which I don't own). Certain other tools lead me to believe it may be possible to create a base package which can be amended from Windows, but I have no idea on that (and this goes way too far beyond this thread, once I do get around to integrating an Android builder then I will come back to it).

That all sounds reasonable to me. I wonder how much work it would be to get the setup program to 1) output to PLATFORM/acsetup.cfg and 2) enable/disable options based on PLATFORM. If we allow using the same setup program to edit the config file for other platforms, then it should also disable things that don't apply to that platform (e.g., graphics driver selection).

As an update on this, I completely abandoned the old source code. Everything I was doing was such a mess, it was just easier to start from scratch.

I did have one major face-palm moment though. As I was doing in the prior version of the plugin, I attempted to write some data to the LocalApplicationData folder (SYSTEM_DIR/Users/AppData/Local), except this time I was trying to create a hard link. The problem I ran into was one I was already well aware of but had simply failed to accommodate. Hard links cannot exist across physical disks. My AGS files are on a separate physical disk from my Windows installation, so I can't create hard links there.

I was able to add a dialog to select an alternate folder for caching (hard linking) the library scripts, and I write out some meta-data to the system folder instead (this is also necessary to keep track of the extra module info like author and description).

The new version is almost functional. So stay posted for that.

[first]

Simply returning from the function isn't really very user friendly. Probably best to at least have the player say something first, and then call return:

Code: ags

  if (quantity >= 3)
  {
    player.Say("I've already got plenty of those.");
    return;
  }

Sorry if my earlier snippet wasn't clear on where it needed to go. As a head's up, any time you see "function XXX_YYY(...)", then that's a pretty clear indication the code doesn't belong inside of any other functions (like rep execute). If you haven't already, make sure to run through the scripting tutorial in the manual, it should help clarify these things.

As for this snippet (in this post), it should be merged into the Pebbles_Interact function as Chamber has shown, I just added the hint for the player so they know why they can't pick up more.

Yeah, I don't know that a stuck key is necessarily likely, but I was just trying to think of some reason for the behavior you experienced. If it becomes a persistent problem (especially one you can replicate ) then you know where to find us!

P.S. Nice to see you 'round these parts again!

[Edit:]

If the only reason you're using different inventory items is to keep track of how many pebbles the player has, then I'm afraid to tell you that you're doing it completely wrong. You should set this up as a single inventory item (iPebbles) and use the InventoryQuantity to control how many pebbles the player has as well as updating the graphic:

Code: ags

function on_event(EventType event, int data)
{
  if (((event == eEventAddInventory) || (event == eEventLoseInventory)) && (data == iPebbles.ID))
  {
    int quantity = player.InventoryQuantity[data];
    if (quantity == 1) iPebbles.Graphic = PEBBLES_1_GRAPHIC; // fill in actual sprite slot numbers
    else if (quantity == 2) iPebbles.Graphic = PEBBLES_2_GRAPHIC;
    else if (quantity == 3) iPebbles.Graphic = PEBBLES_3_GRAPHIC;
  }
}

function Pebbles_Interact()
{
  player.Walk(500, 330, eBlock); // '1' is not a valid value for BlockingStyle, either use eNoBlock or eBlock
  player.AddInventory(iPebbles);
}

Edit: Gurok posted while I was typing, but I stand behind my solution.

You might also want to take a look at Game.MinimumTextDisplayTimeMs and Game.IgnoreUserInputAfterTextTimeoutMs, which I believe are both new since you were last around here Matt. Dunno if it's definitely related, but at the very least it should safe-guard against it happening.

As to why it actually happened, you didn't have any keys stuck on your keyboard or anything perchance, did you?

Which could all have been easily avoided if only his game had been coded in Lua.

I noticed elsewhere that someone had commented about this issue, and I meant to ask about it.

I've made a separate thread for it.

[always]

Since the editor can now target different platforms, there is a very good chance that users will need to maintain separate config files. It would seem obvious that when running the debugger, it should use the Windows config file. This would also make the debugger respect config changes made if the developer has run winsetup.exe directly from Compiled/Windows. However, there is also the "Build -> Run game setup..." option, which I have more of a question about.

Should this always be considered as modifying the Windows config file only? Or should it modify the global/default config file (Compiled/acsetup.cfg, copied when platform-specific config doesn't exist)? Should perhaps an option be added if the setup program is launched from the editor to specify which platform you want to change the settings for? Obviously "winsetup.exe" isn't going to be released on Linux, but it might make sense as part of the editor suite to edit the Linux config file that way.

Can anyone comment on that?

Also, make sure you haven't actually got a file named room-1.crm in your project folder, as I recall that causing problems.

Game.DoOnceOnly, followed by RTFM.


I wasn't going to, but with a thread title like that...