Messages

Also the above code won't compile because it's parentheses are unbalanced.

That's just a typo in a forum post. The problem in the engine is real.

EDIT: That's quite strange, I had memories of someone having these deprecated functions recreated in their game scripts. How would they work then, I wonder. Maybe these are false memories, and it was something else.

@greg that's because SetGlobalInt and GetGlobalInt are engine API functions, so engine actually calls its own functions instead of yours.

https://adventuregamestudio.github.io/ags-manual/Globalfunctions_General.html#getglobalint

Simply rename the functions, and you will see expected values.


The problem is that engine is not made to differentiate between selected script api levels, and always links its deprecated api, even if not requested by the game settings. I think this issue may be already recorded in our bug tracker, and it must be resolved.

Alternatively, you may still import these old engine functions by declaring them, but not defining their bodies.

I was planning to release a web version of my current game but wanted to find a way to test it without having to upload it to itch yet.

I'll mention this just in case, there may be numerous tools and browser plugins around that let do this.
For example. there was this plugin for google chrome called "Web Server for Chrome" that lets create a local server:
https://chromewebstore.google.com/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb
where you simply point to a folder with generated game, which has index.html in it.

@Crimson Wizard , this reminds me, should the named parameters in ags4 be behind some flag?

Do you mean parameters in script API, or the compiler's feature?

In summary: script API contains numerous layers, some ~20 year old. We are trying to be consistent with the chosen naming style when we add new things, but unless we replace old things completely they remain. And replacing old things randomly make old users unhappy; in fact any replacement makes users unhappy: since certain time the tech support forum is littered by questions like "where did command xxx go, it used to work, but now it's not recognized".
The only things that are "safe" to rename until now are function parameters, but that's because user does not have to type these, you only see them in tooltips.
(and then there's a new proposal for ags4 script compiler, to support function parameter list with named args, which may make this suddenly more fragile)

The chosen naming style used today is this:
- Names of structs and functions is in CamelCase.
- Names of attributes (aka properties) in structs is in CamelCase. Character.x,y is a very old inconsistency, because this struct was probably among the first to be added to script API.
- Names of function parameters are in camelCase with the first small letter (hence it's property 'X', but parameter 'x').
- Names of raw variables, whether global or struct members, is in small case with underscores (iirc), but we try not to add these to API today, so 99% of those are remains from non-OOP API times.

We might fix inconsistencies more in AGS 4, where breaking backwards compatibility is expected.

Please, also mention AGS 4 in the topic titles, because this version may be different from AGS 3 in a number of ways, and not many people have a knowledge of it yet.

Hello Agser I am using AGS-4.00.00.06-Alpha11 and I was trying to use the functions Remove/Restore WalkableArea but it gives me undefined token. Altough the manual doesn't say this is an obsolate command and I was wondering to know how to do that?

We don't have an updated manual for AGS 4.0 yet.
The only documentation of new functions or changes to old functions may be found in change notes in the 4.0 release thread: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-4-0-early-alpha-for-public-test/

All the walkable area commands are now accessed through "WalkableArea" struct and "walkable[]" global array.

For example, if in AGS 3.* you had:

Code: ags

RemoveWalkableArea(3);
RestoreWalkableArea(3);

In AGS 4.0 you do:

Code: ags

walkarea[3].Enabled = false;
walkarea[3].Enabled = true;

NOTE that you may still enable these original commands back if you select "Script API Version = 3.6.x" in the General Settings.

In Java, when you create a floating-point literal like 0.5 it is a double by default, and double is the recommended type for floating point variables. A double can store any int value exactly, so implicitly "promoting" int values to doubles in mixed expressions is much less problematic than it would be in AGS (which doesn't have double).

Aright, that makes sense. So having implicit conversion in AGS may not be a good thing.

But I brought Java up as an example of a type conversion opcode, not an example of implicit conversion.

A conversion operator would be a hidden additional operator afaict from the discussion. I don't like this approach at all. And I don't think we should add opcodes without thinking too, that loop is a critical part that affects everything.

Conversion operator may be explicit or implicit, or either, or depending on a case etc, that's a choice in programming language design.

Opcodes are not to be added to random places in program where they are not needed, they are to be added where they are obviously needed - in the current context that would be places where you would use IntToFloat and FloatToInt. The conversion operator would be a replacement for these function calls, not something extra on top of them (or anything else).

For instance we could replace IntToFloat with (float) cast operator, which would be few times faster than a function call, being just 1 opcode. That is just an example, to illustrate what I mean.


Also, I did not just randomly fantasized this idea about opcodes, this was a logical conclusion when I tried to think how it could work.
Then I found examples of conversion opcodes in other programming languages which create bytecode. For example there's a list of opcodes in Java:
https://javaalmanac.io/bytecode/mnemonics/

i2b   145   Convert int to byte
i2c   146   Convert int to char
i2d   135   Convert int to double
i2f   134   Convert int to float
i2l   133   Convert int to long
i2s   147   Convert int to short

I would also argue that I prefer to never pay for things I don't use, a lot of things I have to do a lot of times per frame and AGS Script isn't super fast, so I prefer to not add things that could slow it down - more API calls.

Which unnecessary API calls would be there, what case are you refering to?
BTW the conversion operator may be faster than a function call in ags script, being only 1 opcode.

After all, all ints fit within a float.

That's not true. Both int and float are 32-bit types, so both have just as many possible different values (2^32). Since many of those possible float values are not integers, it follows that not all ints can be stored as a float. In other words, casting from int to float will sometimes produce the wrong value (either a different integer or a non-integer).

BTW we have a specific limits of this mentioned in the manual, after a user's request:
https://adventuregamestudio.github.io/ags-manual/SystemLimits.html#integers-and-floats-limits

In AGS integers and floats are 32-bit.

Integers are signed and can be from -2147483648 to +2147483647 (from -2^31 to 2^31-1)
Floats are a bit more complicated: an IEEE 754 32-bit base-2 floating-point variable has a maximum value of (2 − 2^(-23)) × 2^127 ≈ 3.4028235 × 10^38.
A float should then be able to reliably represent integer values between -16777216 and 16777216 (from -2^24 to 2^24).

In brief, integers have a strict min and max limit, by exceeding which they "wrap" their values (from positive to negative and vice-versa). Floats, on other hand, do not have a "hard" limit, instead they begin to loose precision as their integer part reaches high numbers. Occasional "even" values may still get stored correctly, but majority of values between them are not guaranteed to be precise.

in the game I'm currently developing I wanted the Wait function to wait for a fraction of a second or something like a second and a half, and I found myself having these kinds of calls.

Code: ags

FloatToInt(IntToFloat(GetGameSpeed()) * 0.5 + someValue);

Just a note, this looks like a good case for a global helper function that converts N float seconds to an number of game frames.

I think Tween module has this in its interface.

Yes, why is there none? I understand why a float shouldn't be implicitly cast as an int, but why can't an int be implicitly cast as a float?

I have two guesses:
- the original compiler and script executor were limited in this regard, and no one bothered to fix this still;
- original author of AGS have decided that implicit casts will confuse beginners with suddenly changing values. Majority of users in AGS are people who barely have any programming experience, or not at all, and a number of design choices were seemingly made having that in mind.

Implemented around AGS 3.6.1.

Maths is only floats, so in theory they would have to be floats.

There's no restriction for Maths class to work only with floats. It has only functions with float parameters now by coincidence.
Functions like Max, Min, Clamp and Abs need to have variants for ints too, because there's no implicit cast between int and float in AGS, and users will have to call IntToFloat in order to simply use Max, which is annoying.


EDIT:
There was this module by monkey0506:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-mathsplus-v1-0-abs-absint-ceil-floor-max-maxint-min-minint/

He made Abs, Max and Min to work with floats, and AbsInt, MaxInt and MinInt to work with ints.
I argued that majority of users would need these for integers more often, and suggested to do it other way around (e.g. Abs / AbsF, Min / MinF etc).
He said that it's for consistency with existing function that have float parameters.
(this discussion may be found in the linked thread)
This may be polled again among users here.


The naming situation may improve if we support function overloading (i had plans to look into this soon, unless fernewelten does this first).

I would not mind if these are added to script api, it's just that nobody bothered to do this.

Something to keep in mind though, since ags does not support generics or templates, there have to be separate variants for ints and floats.

They were never added.

On another hand it's easy to write them in script. People were writing modules for these math functions that they can use in multiple projects.

[Editor:]

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

Contains all the new features from 3.6.2 Betas 3.

Own changes:

Editor:
 - The "Watch Variables" panel has an option to automatically enlist local variables (relative to current position in script) when testing the game.
 - Added "Add to Watch Panel" command to Script Editor's context menu.
 - Support dragging a text from the script window into the "Watch Variables" panel.
 - Fixed mistakes occuring when overwriting existing room files by a imported room.

Scripting:
 - Managed structs may have constructors. Constructor is a member function which name is identical to the struct's name, and type is "void". Constructor will be called automatically when the managed object is created with "new" command.
 - Dialog Scripts dropped support for a number of obsolete commands: "run-script", "new-room", "set-speech-view", "set-globalint", "play-sound", "add-inv", "lose-inv". All of those have contemporary equivalents.


Using constructors is more or less how you do it in C++/C#, except it has to be declared having a type "void", as opposed to no type at all (this is kept so for simplicity of compiler's work, idk if it's critical, but maybe we could look into letting to declare it completely typeless later).

Example:

Code: ags

// header
managed struct MyStruct
{
     import void MyStruct(int data); // this is constructor
     import readonly attribute int Data;

     writeprotected int _data;
};

// script
void MyStruct::MyStruct(int data)
{
     _data = data;
}

int get_Data(this MyStruct*)
{
     return _data;
}

// elsewhere in another script
function game_start()
{
     MyStruct *s = new MyStruct(10); // this actually calls constructor
     Display("%d", s.Data); // should display 10
}

I think if there's a need there could be an API for that like Point* GetRelativePosition(int x, int y). Does GUI.ProcessClick(int x, int y) uses screen or GUI relative coordinates? (I don't remember)

There's no need for this in ags3, as there are no complex transformations, it's simply a matter of subtracting GUI.X or Y. There's already a function for this in ags4, where gui may have more transformations.

But I'm asking not because there is a problem of converting, but because I cannot decide what makes more sense in the context of event params.
Also, I don't remember if it's now in this particular case, but at least in theory triggered events may be processed not instantly, but with certain delay, in which case it may be important to describe the exact state of the context in which the event occured.


EDIT: GUI.ProcessClick uses screen coordinates, because it's not called for specific gui, but for the whole "gui layer".

I am in doubts about something again...

In the latest update I've expanded eEventGUIMouseDown and eEventGUIMouseUp events with following parameters:
- mouse button
- mouse x
- mouse y

the position is given in screen coordinates.

Would it be better to have them in respective GUI coordinates instead?

First of all, this effect has to be defined as a program (shader, or bitmap distortion code), that has a distortion algorithm and input parameter(s).

Then, there should be a way to apply this effect to a character or object directly, without walkable area.
Since this is a new visual effect, first we apply it to the character, then someone will request this be available in other objects. So ideally it should be available everywhere (characters, room objects, overlays, maybe even guis). *

Then we may consider applying this to walkable areas.


* - The engine has a long time problem of not having a base class for "drawable object". It would be nice to have one implemented first, so that we could move these graphical effect properties there, and have them present only once, instead of copying to each type.


Besides other things, there's a problem of multiplying properties in Character type. Right now there are properties that tell:
* if character has explicit scaling applied
* if character has explicit tint applied
* if character has explicit light level applied
* should character be affected by region tint
* should character be affected by region light

If we add another visual effect, do we also need equivalent properties? In the long run this may overload this class with properties for each requested effect. Perhaps existing property design should be reviewed and simplified somehow first.