AGS 3.2 Final 5 - Recession-busting edition

[Ryan Timothy B]

If you declare a variable at the top of the global script, it's accessible throughout the entire global script.  I'm not sure why you import it in the script header.

BUT.. from what you just said there, you're switching tabs (going from the script to the header), therefor, it doesn't add to the autocomplete without switching tabs.  Unless I understand you incorrectly.

[TerranRich]

Heh, well I don't use global variables other than those you can define in the editor (at least not yet), so I'm not surprised I did it wrong.

To answer your question, simply saving the script, closing the tab, and re-opening the tab are enough. Simple hanging tabs (e.g. opening the header, then going back to the global script) also refreshes the list.

[monkey0506]

Heh, well I don't use global variables other than those you can define in the editor (at least not yet), so I'm not surprised I did it wrong.

To answer your question, simply saving the script, closing the tab, and re-opening the tab are enough. Simple hanging tabs (e.g. opening the header, then going back to the global script) also refreshes the list.

Yes, we already know that...

AFAIK the autocomplete cache should be updated any time you switch tabs, compile, or run the game. I could be wrong though.

Making it update when typing a semi-colon could maybe be useful, but might be impacting to the editor's performance.

The question was why it doesn't update more often.

[TerranRich]

I forgot what issue I was addressing then, if at all. Man, I must be losing it.

[Khris]

I've encountered some erroneous behaviour with tooltips and optional parameters:

Code: ags

// import line in header:

import void ShowBox(String message, int width = 256, int x = 160, int y = 200, bool stay);


// declaration line in script body

void ShowBox(String message, int width, int x, int y, bool stay) {

I tried to call the function using:

ShowBox("Hello, this is a first test of the message box function!", true);

I got the "not enough parameters in call to function" error.

Edit: I moved the bool param after the string param and it works now. Maybe the manual should mention that optional parameters have to be declared last.

The other thing is minor: the string contains a comma and thus the tooltip is showing the wrong parameter in red and the true/false auto-complete window for the bool appears one param too early.

[monkey0506]

The other thing is minor: the string contains a comma and thus the tooltip is showing the wrong parameter in red and the true/false auto-complete window for the bool appears one param too early.

It's done that for quite some time. And regarding optional parameters the idea is that you can't pass "nothing" as a parameter so if you have an optional parameter followed by a required parameter then how can you get to the required parameter without being forced to pass something for the optional parameters as well?

I believe AGS will allow the import to compile that way, but it logically doesn't make any sense. From a logical standpoint you should put all of your required parameters first, optional parameters last. That way anything that is optional can be optional.

[abstauber]

Hi,

I somehow create currupted save games.

Whenever I try to restore, this is the error I get.

---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x0043AD2A ; program pointer is +25, ACI version 3.20.1099, gtags (8,0)

AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and post the details on the AGS Technical Forum.



Most versions of Windows allow you to press Ctrl+C now to copy this entire message to the clipboard for easy reporting.

An error file CrashInfo.dmp has been created. You may be asked to upload this file when reporting this problem on the AGS Forums. (code 0)
---------------------------
OK   
---------------------------

[Crimson Wizard]

Not sure if it's a bug, but I guess it may cause some irritation.
It is about using ALT-drag selection in script editor. Apparently, selection box is being limited by the shortest string in the selected lines range.

For example, if you have some code like:

Code: ags

import function AVeryLongFunctionNameHere();
import function AFunctionName();

If you try to select everything except "import" keywords using ALT-drag here, on the 1st line only a part of function name will be selected.

Detected this in AGS 3.1.*, still present in RC2.

[abstauber]

Hi,
I somehow create currupted save games.

The bug has been isolated

In room_load, do the following:

[...]
SaveGameSlot(1, "QuickSave");
aSomeMusic.Play();
[...]


Try to load that game and BAM
At least that happens in AGS 3.2 RC2 on my machine.

[RickJ]

It appears that extender functions share the global namespace rather than the Object's namespace.  In the example below I had expected that the name of extender function would be seen by the compiler as "String.Token" rather than "Token".   Not sure if this is a bug or a feature so I thought I'd mention it.   It's easy enough to avoid by just using another  name.

Code: ags

*** Global Script ***

String IndexOf;   // Does not conflict with String.IndexOf(..)

String Token;       // Name conflict with extender function String.Token(..)

// String extender function
String Token(this String*);  // Causes an error "Token is already defined"

[monkey0506]

There actually is a way around that Rick. Once an extender method has been declared, AGS accepts it as part of the struct and you can use the normal namespace resolution to resolve the collision. That is:

Code: ags

// script header
import String Token(this String*); // some extender function declaration
import String Token; // global string, this import must come after the extender to prevent collision

// script file
String Token;
export Token;

String String::Token() { // once it's declared by the import you can use normal namespace resolution
  // blah
}

This also works even if the function isn't global. You can define a localized extender with the same name as a local variable like this:

Code: ags

// script file

import String Token(this String*); // import just like you would in a header file, but in the main script
// this declares the extender to AGS

String Token; // local variable

String String::Token() { // again, using normal namespace resolution
}

[RickJ]

This also works even if the function isn't global. You can define a localized extender with the same name as a local variable like this:

Ah!  Yes, I am using local extenders within a module script that are not to be exposed outside the module.   Thanks for the info; it's very useful.   

[edit]
Tried your second example and got the following error ... I'll just use fdifferent names.

Modoc.asc(241): Error (line 241): extender functions cannot be part of a struct

[monkey0506]

I tried the second example and it worked fine. The only condition in which you would get that error would be something like:

Code: ags

struct MyStruct {
  import function Extender(this String*); // wait, what? it's in the MyStruct type but it's a String extender???
};

Extender methods obviously can't be within a struct coz they don't make any sense there. And that is exactly what the error message says.

Edit: (eatingmywordssomewhat) Or if you're using the normal namespace resolution and defining it as an extender at the same time:

Code: ags

String String::Token(this String*) {
}

See my next post after this.

[RickJ]

No! it's not in a struct.  The error ocured with the declaration

String String::Token(..)

If it's working for you then and not for me then I must have mistyped something somewhere or had gotten something out of order?

[monkey0506]

You didn't per chance put:

Code: ags

String String::Token(this String*)

Did you? Coz you're already resolving that it's a String function with the String namespace and it doesn't need to be defined as an extender.

I have this exact code snippet in game and it works fine:

Code: ags

import String Token(this String*);

String Token; // local variable

String String::Token() { // again, using normal namespace resolution
}

function some_func() {
  String s = "";
  s = s.Token();
}

Trying to put the "this String*" part inside the function definition gave the same error though. So yeah, that's what you did.

[Crimson Wizard]

I have this question: when I create a new room for 320x200 or 640x400 resolution game, default black background matches the resolution. However, if resolution is set to 320x240 or 640x480, default background does not match the correct height, it is either 200 or 400. Why is it so?
(One may need black rooms for displayng credits for example, or some other purposes, and with this behavior user must create a black image to manually set it as a background)

[Crimson Wizard]

I just found that it is possible to assign dynamic array of invalid type to a pointer, without getting any compiler error or warning, causing problems in future usage (as well as hard time debugging). For example:

Code: ags

int MyArray[];


function MyFunc()
{
   MyArray = new short[100];
}

Well, I know that plain C/C++ does not treat this as something incorrect, but since AGS scripting language is considered to be memory safe, I thought that something should be done here like warning user.

[monkey0506]

I just found that it is possible to assign dynamic array of invalid type to a pointer, without getting any compiler error or warning, causing problems in future usage (as well as hard time debugging).

I believe this is due to the fact that this is one of the instances where AGS has an implicit type conversion defined. For example:

Code: ags

short s = 10;
int i = s + 2;

Works without any problem (as you would logically expect). From a logical standpoint however I'm not sure what type the array would actually use so it is confusing (i.e., what would be the size limits of each member of the resulting array; based on int as declared or short as defined?).

You can't however perform an implicit conversion doing this that AGS wouldn't normally allow with regular variables. For example:

Code: ags

int arr[] = new GUI[5];

Fails in error.

The current behaviour wouldn't bother me at all so long as I knew definitively which type the array was acutally using.

[Crimson Wizard]

Anyway, here's another bug.

I have a custom struct, and another one, extended from that first. For simplicity, they are T1 and T2.

T2 extends T1

I have extender functions made as "members" of T1 and those that are "members" of T2, like

function T1Func(this T1*, ...);
function T2Func(this T2*, ...);

So, problem is that if I have an object of type T2, let's say

T2 ObjectT2;

when I type "ObjectT2." and a list of members appear for quick selection, there are no functions that were declared for type T1. There are only variables of that type.
These T1 type extender functions work, however, as expected (i.e. I can type ObjectT2.T1Func(...)), they just are not listed in this hint box (or whatever this is called), and also if I click "Go to definition of T1Func" it does nothing.

Not a big deal, perhaps, but can be confusing.

[monkey0506]

I pointed this one out before.

As I said in that thread the only way I've found of getting these inherited extenders to autocomplete is actually defining an explicit overload for the child class(es). I also found that the overloaded version is being called, that is, AGS supports polymorphism! Chris, if you fix the autocomplete issue, please don't fix the polymorphism. I like it.

It does work though, as you said, so it's possible to just use the functions without the autocomplete.