Messages

I am in room1, I do some actions, then I go to a special room where I have items to start the save. There I put "player.ChangeRoom (1)" to go to the room and I put ResetRoom (1), I come back to my room1 but it didn't reset anything.

Please tell, what do you have in room 1 that needs to be reset?

I just quickly tested ResetRoom in AGS 3.5.1, and it appears working. There might be something else in your case that meddles with things. Maybe it never gets called, or there's something in room's script that changes object positions (just a guess)?

neither the variables, nor the positions of characters or objects

Please note that only "room objects" are reset by ResetRoom. Characters are global objects and do not change their states. Also global variables are not changed, because they don't belong to particular room.

He enters the room, he throws what there is in the After fade in, but he does not reset anything (neither the variables, nor the positions of characters or objects).

I'm sorry, I don't understand, what throws what in "After fade in"?... where in script exactly do you call ResetRoom?

You can; exit the editor and rename the room files.

You have to enter the room number in the room properties. Renaming room file on disk will make editor not find it next time, because it has room numbers written in the project file also.

I just need to restart a room in its initial state. I try with "ResetRoom (1)" but it doesn't reset.

Could you elaborate on that, did nothing happen at all, or some particular things did not reset?

Also, like I mentioned before, if you need a room to reset each time you re-enter it, you may simply make it non-state-saved room by assigning a number above 300.

The current cons of AGS, perhaps from my personal perspective:

- Game editor is frankly subpar; user interface is often awkward and limiting.
- Game project source is difficult to read, let alone work with, outside the editor. Most of the game data is inside a big xml file, and rooms are saved in binary format so you cannot even look what's inside of them without launching AGS. Imported sprites are written into one big file, where again you cannot look into them or replace without running editor. This also makes parts of the project prone to file corruption: anything happens during saving the game may make you loose a whole room, or all of the sprites.
- For the same reason, it's complicated to work with AGS games under a version control tool (svn, git etc): as parts of the game are binary blobs, it is impossible to track the actual history of their changes.
- Lack of Unicode text support.
- Imperfect translation system, where translations may be complicated to update and easy to break. No true support for localizing other parts of the game rather than the texts: such as images, sounds, voices (you have to do this by hand, sometimes using workarounds).
- Building game packages for other platforms than Windows and Linux requires manual labour. No official support for gaming consoles.
- Scripting language is a mix of low-level and high-level concepts, but does not get any of these to the logical conclusion. So on one hand you cannot refer to plain variables and structs using their memory adresses, on another you have "managed" structs but the use of these is limited by incomplete syntax and unsupported features. It's like having bits of both worlds instead of one but complete.
- Script's implementation is slower compared to popular scripting languages. This won't be noticed if you have a regular point and click scene, but may quickly become a problem if you e.g. script a fast paced arcade sequence with physics simulation, etc.
- Most of the things may be only created at the design time. You cannot have dynamically created rooms or objects. This complicates working on anything that is not a standard point and click scene, and forces you to precreate almost everything in the editor, even if you need an object only for some temporary visual effect. If you want a "procedurically generated" scene or game, you have to precreate a number of dummy objects and reuse these.
- Game saves contain practically a virtual memory state, and may be restored reliably only if the game contains exactly same game objects.
- Lack of contemporary visual effect support: e.g. no GPU-based object rotation, no custom shaders, let alone any 3D effects. Any additional effects have to be scripted with the use of the pixel drawing (aka "software drawing") which is significantly slower.
- Engine is not well optimized for high-resolution games: the way it draws things, or loads resources, maybe works well with "classic" low resolutions, but not with higher ones.
- Abscence of debugging and diagnostic capabilities: you cannot tell what's going on inside the engine when it runs your game.

Other than that drawbacks of AGS would be <...> no real cross-platform capability in engine.

What do you mean? AGS engine is working on several platforms for about 10 years now...

I also thought Godot allows to build game for many platforms, at least its in my memory from the time was I checking it out.

But I think a big con for AGS is that it's really difficult if not downright impossible for multiple coders to work on the game at the same time.

You're correct that collaborative work on programming is difficult in AGS, not impossible but requires some coordination.  I left a project in a huff when issues with SVN meant I was getting constant compiler errors.  Ideally I wanted guys to write the new code and give me references for where they wanted it copied and pasted but I got ignored.

I wonder what were the problems that people face when code same game together. Obviously it goes down to splitting the tasks between the people, just like in any other programming project. If each person works strictly on their own, and even better in their own module(s) and/or room scripts, I imagine there should not be too many conflicts.

Something I am missing about this, but why do you need to animate your cursor manually at all, could not you use plain view animation?

[Editor:]

Unfortunately I got very distracted from AGS recently, so this took more time since the last update... but here's the new one.

Updated to Alpha 11
(use download links in the first post)

Editor:

* Added "Use graphical font height in game logic" property to the General Settings, that makes your game use real font's pixel height when arranging text and text-based UI elements, as opposed to the nominal font's size. This is important for TTF fonts, because importing them with N point size does not guarantee N pixel height. Unfortunately AGS used to "lie" about their height all those years, which could lead to some fonts not fitting into gui controls right or even have their bottom parts "cut off" when displayed as a speech. Now you may prevent that using this setting.
* Fixed "Use old-style custom dialog options API" was not set when importing pre-3.4.0 projects.
* Fixed comboboxes' drop-down arrows were not painted with the right color from a color theme.

Script compiler:

* Removed 500-characters line limit.

Script API:

* Debug(2, 0) command that displayed walkable areas is superceded by Debug(2, n), where "n" is a mask type: 0 - none, 1 - hotspots, 2 - walkbehinds, 3 - walkable areas, 4 - regions. This command also works as a toggle switch, calling it with the same mask index will turn it off.
* Debug(5, n) command that displayed character's walk paths now also works as a toggle switch.

Engine:

* Support "borderless full-screen window" mode in addition to the real (exclusive) fullscreen.
* Support scripts using functions and variables (imported) from any other scripts, regardless of the script module order in the project. These still have to be declared as "import" above their use though.
* Engine now supports using real pixel height of the TTF fonts when arranging text and UI elements on screen; using nominal import size of the font is used as a compatible mode for the old games.
Note that you may always configure the vertical line spacing using font's LineSpacing property in the editor.
* Engine now ensures that in threaded audio mode the script's AudioChannel's state only changes once the game is updated, and not while the game script is running. This prevents situations when the clip could begin playing before all properties are set in script, or when AudioChannel's properties' values (such as Position) could change while running a game script.
* Character.SetWalkSpeed() is no longer restricted by an arbitrary limit of 50.
* File.ReadRawLineBack() now always reads full line, and not limited to 200 characters anymore.
* Debug displays, such as showing room mask and character walk paths, are now implemented as non-blocking translucent overlays, allowing you to keep playing the game while they are on.
* Engine config now has graphic modes defined as a simplier string options: "[graphics] fullscreen" for the fullscreen mode setup, and "[graphics] window" for the windowed. Fullscreen option can explicitly define a "borderless full-screen window" mode. (See below for the new config explanation; it will be also added to documentation later).
* Fixed engine could crash due to incorrect disposal of resources if its startup was interrupted for any reason.
* Fixed some TTF fonts were not centered correctly and/or cut from below when text is displayed.
* Fixed crash in case there were too many reserved audio channels.
* Fixed new sound panning implementation.
* Fixed character may have incorrect Frame values while turning.

Android:

* Fixed reading of separate game files (not merged with the main AGS game file) from inside the APK.

WinSetup:

* Added "Fullscreen as borderless window" checkbox.



New graphics mode configuration:

Instead of having several detached options that combined would result in a window size definition, there's now only 1 option (per mode) that contains all possible variants in a single string:
* WxH - explicit window size (e.g. 1280x720);
* xS - integer game scaling factor (e.g. x4);
* desktop - use current system's desktop resolution;
** in windowed mode will try to create largest possible resizing window, while keeping game scaling style (max stretch, proportional stretch or max integer multiplier);
* native - use game's native resolution;
* full_window - special option for the fullscreen mode, this means a borderless window covering whole desktop;
* default - currently we default to (this is also a fallback option in case config parsing went wrong):
** in fullscreen mode to full_window;
** in windowed mode to desktop;

In [graphics] section fullscreen mode is defined by the option "fullscreen" while the windowed mode is defined by the option "window".

Config examples:

Code: ags

[graphics]
fullscreen=1280x720
window=x2
game_scale_fs=proportional
game_scale_win=round

Code: ags

[graphics]
fullscreen=full_window
window=native
game_scale_fs=stretch
game_scale_win=round

Trying this code in a test project seem to produce desired effect. Maybe there's something else in your game interfering with the mouse looks?

Here's the test project based on sierra template:
https://www.dropbox.com/s/3q9hh49emif0ohh/test--animcursor.zip?dl=0

I test this by having a blocking walk on pressing Space, and calling Wait() in a loop on pressing Enter/Return.

Template is simply a collection of starting resources, where everything may be altered or erased completely.

For switching UI styles, I see two possible approaches:

1. Create multiple script modules, each controlling its own UI style, with all the standard event handlers in each of them (on_mouse_click, on_key_pressed, and so on). They will have to check some global variable to know which style is currently active, and those modules which are not active would simply skip doing anything (not respond to mouse clicks, etc).

An alternate to approach 1 is to script UI style right in the room, because room scripts are also allowed to have "on_mouse_click" and similar event handlers. Because only 1 room is active at the same time you would not even need a global variable telling which style is active.

2. Similarily create multiple script modules, one per style, but don't place any actual event handlers in them. Instead make custom functions that ought to be called from global script. Global script would choose which module to call when events happen.

[import]

Also, don't declare variables in a header. This will create multiple separate variables. Not sure if it matters if you only use the variable in the global script but it's a good idea to not do that in general.

Yes, this is a common reason for weird errors, where you change the variable in one script, but when using it in another its value does not appear to have changed.
Which may be a cause of your problem here too.

If you need to share a variable among scripts, then declare it inside a script, and declare its import in the header.

Note: the "Global Variables" panel in the editor basically generates a hidden script that does all that for you. But if you are making variables of custom types you have to do that by hand.

Related articles from the online manual:
https://adventuregamestudio.github.io/ags-manual/TheScriptHeader.html
https://adventuregamestudio.github.io/ags-manual/ImportingFunctionsAndVariables.html

I do not have a spare time to reply to your scripting problems right now, but the crash you depicted seems an error in the engine, and I definitely would like to check that out.

(Placement of the export command doesn't appear to need to be at the end of the script after any functions that use the variable...?)

Right, export command may be anywhere below the declaration, because export itself is not for this script, it's for other scripts.

In a nutshell, "import" tells your script(s) that this variable exists somewhere else; and when the game is run, it tries to link each "import" with the "export". "Script link failed" error means that there was an import but no matching export found.

[.asc]

So in the GlobalScript header, I declared:

Code: ags

String region_direction[AGS_MAX_REGIONS];

In the room script, after the "room_Load" function that sets the region direction, I exported the variable:

Code: ags

export region_direction;

No, this is wrong, you need to put both of these lines in GlobalScript.asc, as mentioned in the example in my previous post.

You declare variables only inside the script bodies, not headers, and export them from the same script where you declared them at.

On contrary, you declare the import in the script header, this is where every other script would see it. Alternatively you may put import declaration in each script where you are using this variable (I think this is what you did with the verbcoint script).

Also, if you're using this variable in the verb-coin script, then likely you need to declare the variable right there instead of globalscript. Because in AGS you can only use variables in the same script or scripts located below in the list, and globalscript is by default the last in that list.

[Error: Attributes of identifier do not match prototype]

Arrays have been beyond my current skill level.

Arrays may be thought as multiple variables sticked together. You access them by the name and index (like myarray[5]) instead of just name. Index is 0-based, but you seem to already had experience with that as you have "region[0]" in your code.

I'm getting an error on the first line:

Code: ags

String region_direction[AGS_MAX_REGIONS];

Error: Attributes of identifier do not match prototype

Any ideas? Something to do with my global variable, perhaps? (It is set as String type with "left" as the initial value.)

Ah, I forgot to mention that indeed you need to delete your global variable in this case, as in my example you are creating one yourself by hand in script. Unfortunately, the "Global Variables" panel in the editor does not allow to create arrays (idk why).

But depending on which room or rooms you are planning to use this variable (or array) might be declared elsewhere, like in GlobalScript, to let use it everywhere. I don't know your game's specifics. If you want to use same method in multiple rooms, then it's best to declare this in global script, and have the arrow-changing code in global script too (or do you have already? I might have missed this).

There is an article in the manual that explains how to share variables between scripts: https://adventuregamestudio.github.io/ags-manual/ImportingFunctionsAndVariables.html
When you use "Global Variables" panel editor does the same for you, "secretly".

To achieve this, you need to have this in the GlobalScript.asc:

Code: ags

String region_direction[AGS_MAX_REGIONS];
export region_direction;

and this in the GlobalScript.ash:

Code: ags

import String region_direction[AGS_MAX_REGIONS];

Also how much of a impact on performance does too much repeats have on overall game play, am i going to run into problems doing it in such a way.

To clarify, it's not exactly too much repeats that have an impact, it's a) frequency of repeats multiplied by b) amount of work done within one repeat.


Anyway, like Cassiebsg meant, it's a good habit to only update things when it's really necessary. To do so you need to answer a question: what does my variable/label/object depend on, and only update when their dependency changes.
The example of this: you are printing "health" on the label, then you might change the label only when the health changes, within same function that changes this variable.

But note that this is not always possible or convenient to merge both variable and GUI update in one function, because it may go against the code organization. Like, you may have your person data handled in one script, and visuals and GUI handled in another. That's perfectly fine. But in such case you will have to check for the change in rep-exec.

Also sometimes you're tracking something in the game that may change anytime, like character's position. It does not necessarily change all the time, but may, so you again have to check for the changes in rep-exec.

In such circumstances, if you're only updating few things, like a label text, you may do that unconditionally, like you're already doing.

If you are updating a lot of things, and begin to worry about perfomance, the usual solution is to save the last state of an object or variable you're tracking, and only update when there's a difference between an old value and a new one.
But I must underline, this is only worth it when you're updating alot of things, or do some time-consuming data processing, like lots of math, generating dynamic sprites, and so on.

In general, point-n-click games rarely have perfomance issues, because they don't have as much to update each game frame. Today computers are very powerful and they likely "sleep" most of the time when you run an adventure game. Several characters on screen, and updating several labels won't cause anything. If they do, there's likely something wrong with the engine, maybe it's not optimized well enough on its own.

It's only worth being concerned when you are doing something unordinary, like perfoming raw drawing operations on a fullscreen dynamic sprite realtime, or doing physics simulation in script.

Also, keep in mind that your script is one thing and the game objects is another. Game itself is updated by the engine, so if you have a lot of these simultaneously, or have alot of high-resolution animations running, or something like that -- the game may become slower even if your script is mostly empty.

In the end (almost) anything could be optimized when you or your players noticed your game has slowdowns.

Your first code snippet (one with room_Load) does not make much sense, you only test a region under the mouse cursor once at the room load, what if the mouse is not over the region at that time? Then the variable is never set.

If you want to configure additional properties for the regions, then you should not rely on where the mouse is at the room start. Instead make an array of region directions and set it up unconditionally for all regions.

Code: ags

String region_direction[AGS_MAX_REGIONS];

function room_Load()
{
  region_direction[1] = "up"; // for region 1
  region_direction[2] = "left"; // for region 2
  // and so on
}

Then when you found a region under the mouse, use that region's ID number to get its direction:

Code: ags

Region* r = Region.GetAtScreenXY(mouse.x, mouse.y);
if (r != region[0]) {
  String dir = region_direction[r.ID];
  if (dir == "up") ...
  else if (dir == "left") ...
  // and so on
}

Aside from that, you may perhaps simplify this by storing directions using existing enum called "Direction", which has values like "eDirectionDown", "eDirectionLeft" and so on:

Code: ags

Direction region_direction[AGS_MAX_REGIONS];

function room_Load()
{
  region_direction[1] = eDirectionUp; // for region 1
  region_direction[2] = eDirectionLeft; // for region 2
  // and so on
}

But that is a matter of preference.

Would it be possible to remove the limit for the functions like ReadRawLine ? Also for the length of the lines in the editor ? That's why it's an obligation to use string.Append to stock long texts into a string.

Yes I think this may be done.
I've already removed the script line limit, it's going to be added to 3.6.0.

Although, proper fix would also be to allow to wrap strings in script, as many programming languages allow to do. But idk if it's easy to make with the current script compiler becuase it is a complicated program, and also written in a "dirty" code.

Note that you also may use String.Format to combine strings, this might be slightly more convenient to write:

Code: ags

String s = String.Format("%s%s%s",
      "first part",
      "second part",
      "third part");

Hmm ok, well I found out that if the function was called in a game_start function, buttons won't have their graphic changed (why ? I don't know !). So I ran my script in the room 1, before fade in, and in a DoOnceOnly condition.

I never heard about such problem. There are few issues with game_start, for example the room is not loaded yet so you cannot access anything from the room. But I did not know that buttons work differently...

But what's the number of button.Graphic if this button has no sprite ? (I mean : the button is the grey default button in the editor).


Because my script seems to not do anything. And I wrote if (button.Graphic==0) to detect buttons without any sprite.

Oh, I misread the question. I think Button.Graphic can be <= 0.

How it's noted in the manual:

readonly int Button.Graphic;

Gets the current image on a GUI button. If a value less than 1 is returned, then no image is currently displayed on the button.