AGS 2.72 Final 2 - World Cup Edition

[RickJ]

Here is another Sting thing:  The variable system.version returns a string that is incompatible with String.  For example the following produces an error somrthing about not being able to convert string to String.

String  MyString;
MyString = system.version;

I did the following to make this work ...

String  MyString;
MyString = String.Format("system.version");

The workaround isn't that annoying or ugly but I thought this may have sliiped through a crack and that CJ may want to know about it.  If this is a know issue then please disregard.  Chers.

Btw, working with the new String stuff is a breeze.  The code is creatly simplified.  Thanks.

[Pumaman]

And just curious...does the Label.Clickable property do anything?  I was going to say that it would be more sensical to let the user decide whether Labels would absorb mouse-clicks than the engine just saying yes or no, but there's already Label.Clickable and Label.Enabled properties.  The manual entries on these properties just redirects to the GUIControl property entries...so...

This is a good point, Clickable is now false by default for labels but you can turn it back on in the script if you want.

There's an issue in this version where it will get reset back to false whenever you load a save game, but I'll fix that.

Yes, the relative button in the character panel show "none" but if you click it the dialog show 1.

Yeah, this is related to the bug I mentioned earlier; it's a bit annoying but not too serious.

Whenever you obsolete old functions, CJ, can you provide a #define so that module-writers can make code work on the latest beta or the previous stable release, please?

Lots of my old modules that used GetGameParamter are broken, but I don't want to maintain two versions of them if I can avoid it.

That's a good point, I'll look into it.

--
Edit by strazer:

AGS v2.72 Beta 5:
* Added #ifver/#ifnver commands to allow script modules to determine which version of AGS is being used.
--

If you have a function in a module (and probably global) script that took a "const string" and you change it to take a "String", then when this function is called in a room script with a string literal, it fails unless you add a blank line to the script or somesuch to make it become "dirty".

This is true in various scenarios -- for example if you change a parameter type from string to int, if it's called from a room script then things can go funny until you recompile the room.

I'm not sure if a solution to this is possible really, other than forcing all rooms to be rebuilt whenever you edit the global script...

Here is another Sting thing:  The variable system.version returns a string that is incompatible with String.  For example the following produces an error somrthing about not being able to convert string to String.

Thanks, I missed that, I'll look into it.

Edit by strazer:

AGS v2.72 Beta 5:
* Added system.Version property to return a new-style string.

[RickJ]

Cleanup unhandled_event() ?
This not a very high priority item but I thought it would be a good time to mention it since there are already a  number compatibility issues.   I was wondering if now would be a good time to cleanup the unhandled_event() handler so that it passes in  consistent values through the WHAT and TYPE parameters.    The new and old parameter values could be tied to the "Enforce Strict OO" setting so that it would be possible to define and use enumerated values for the WHAT and TYPE parameters.

I am asking now because perhaps later on it will no longer be practical to introduce changes that may break compatibility. 

[monkey0506]

I did the following to make this work ...

String  MyString;
MyString = String.Format("system.version");

Erm...you created a String holding the text "system.version"?  Or you used MyString = String.Format("%s", system.version);?  Just clarifying this of course...

And just curious...does the Label.Clickable property do anything?  I was going to say that it would be more sensical to let the user decide whether Labels would absorb mouse-clicks than the engine just saying yes or no, but there's already Label.Clickable and Label.Enabled properties.  The manual entries on these properties just redirects to the GUIControl property entries...so...

This is a good point, Clickable is now false by default for labels but you can turn it back on in the script if you want.

There's an issue in this version where it will get reset back to false whenever you load a save game, but I'll fix that.

Thanks again Chris.

[RickJ]

Hehe, yeah you're right.    I should have said this:

String MyString = String.Format("%s",system.version);

I wanted to pass system.version into a function and found that it wouldn't wort if the parameter was a defined as String.

[monkey0506]

Well you could do:

func_name_here(String.Format("%s", system.version));

Instead of storing the String...unless you need it after the function call.  Save yourself a couple lines.  Or a line.  Or whatever.

[RickJ]

Well that's what I in fact did.   But, IMHO, the function call and parameter pass aren't really the problem and so that wasn't the simplest way of reporting the problem. 

[monkey0506]

Okay...I understand now.

I wouldn't have posted that except I found this out...if you manually set the Label's Clickable property to true, then it is detected by GUIControl.GetAtScreenXY...So it seems that I can in fact continue on without the next version.  Which upsets me because...well...if I can get the highlighting to work...I'm going to work on the module...whether I like it or not.  But I really wanted to play games right now.  Oh well...back to work I guess.

[Radiant]

Minor bug: the script parser puts those "#sectionstart" lines around any function name starting with "repeatedly_execute", even if the function is named "repeatedly_execute_a" or if the entire function is within a /*block of content*/.

By the way I am somewhat annoyed by the huge letters "DO NOT MODIFY THIS LINE" popping up all over my code (especially considering that if the line was removed or modified, AGS will simply put it back). Sorry if I'm nitpicking, but would it be possible to turn that off?

Also by the way, would it be possible to increase the maximum string length for GUI labels? SetLabelText chokes over messages longer than 200 characters, but e.g. a GUI showing a book with text could feasibly use longer ones.

[SSH]

Also by the way, would it be possible to increase the maximum string length for GUI labels? SetLabelText chokes over messages longer than 200 characters, but e.g. a GUI showing a book with text could feasibly use longer ones.

Changes to beta3:
* Increased permitted length of GUI label text from 200 to 2048 characters.

RTFT!

[Radiant]

RTFT!

Doh!

[monkey0506]

Well that and...even if you don't enforce new-style Strings...then the Label.SetText function still takes a const string as a parameter so you couldn't use more than 200 characters.  So RTFM...

Speaking of...with beta 4a (not sure about the earlier betas)...old-style string functions don't autocomplete whether you enforce new-style Strings or not.  Not that it matters to me...I use the new-style Strings.

[Ghost]

yay, naming the dialog topics was on my wishing list for SO LONG. the other features sound, as they often do, sensible and useful: Downloading now.

[monkey0506]

Just a thought regarding the autocomplete parser.  Clearly it's too late to implement any changes to the parser for older versions, but could you implement some sort of value so that functions will only autocomplete for certain versions of AGS?

The reasons for this might not be obvious right now, but if it had been implemented before then modules could be released for more than one version (one module compatible with more than one version) and only the correct functions would autocomplete.

It might seem pointless to implement it now, but I think in the future it might find its uses, depending on the way the language evolves.  Right now it might not seem like the language will be undergoing any huge changes any more...but who would have thought back when Adventure Creator was around that it would one day have an OO language of its own?

Thanks either way!

[Pumaman]

Cleanup unhandled_event() ?
This not a very high priority item but I thought it would be a good time to mention it since there are already a  number compatibility issues.   I was wondering if now would be a good time to cleanup the unhandled_event() handler so that it passes in  consistent values through the WHAT and TYPE parameters.

I'm still not sure about this one. I'm not really sure if it's worth the hassle of changing it, when effectively it would still work exactly the same way. Needs further consideration.

Minor bug: the script parser puts those "#sectionstart" lines around any function name starting with "repeatedly_execute", even if the function is named "repeatedly_execute_a" or if the entire function is within a /*block of content*/.

The #sectionstarts should only be added once -- if you manually remove the lines around a function they shouldn't reappear. The automatic wrapping is only done if no #sectionstarts are detected in the script.

By the way I am somewhat annoyed by the huge letters "DO NOT MODIFY THIS LINE" popping up all over my code (especially considering that if the line was removed or modified, AGS will simply put it back). Sorry if I'm nitpicking, but would it be possible to turn that off?

I'm not sure about this one, I think it's important to have the DO NOT MODIFY there, because AGS will not put it back automatically and it can really screw up the script editor if you delete the start but not the end, or vice versa.

Well that and...even if you don't enforce new-style Strings...then the Label.SetText function still takes a const string as a parameter so you couldn't use more than 200 characters.  So RTFM...

I'm not sure how this is relevant, the Label.Text / Label.SetText now have a 2048 character limit, you could pass in a literal string of 250 characters if you wanted to.

Speaking of...with beta 4a (not sure about the earlier betas)...old-style string functions don't autocomplete whether you enforce new-style Strings or not.  Not that it matters to me...I use the new-style Strings.

Can you give an example of a function that doesn't work? I just tried StrComp, StrCopy, etc and they seemed to autocomplete just fine.

Just a thought regarding the autocomplete parser.  Clearly it's too late to implement any changes to the parser for older versions, but could you implement some sort of value so that functions will only autocomplete for certain versions of AGS?

I suppose it's possible that autocomplete could detect the new #ifver directives and work out what to autocomplete based on that, but for now it's not a priority.

[JLM]

Oh, thanks forever! You really added an option to mark read/unread topics!

Now I can start to script my game... Or perhaps I still wait for the final version of AGS 2.72.

Thanks!

[monkey0506]

Well that and...even if you don't enforce new-style Strings...then the Label.SetText function still takes a const string as a parameter so you couldn't use more than 200 characters.  So RTFM...

I'm not sure how this is relevant, the Label.Text / Label.SetText now have a 2048 character limit, you could pass in a literal string of 250 characters if you wanted to.

Erm...I thought because Label.SetText took a const string as a parameter it wouldn't be able to handle more than 200 characters.  I know that Label.Text has the 2048 character limit, he was just referring to the deprecated function...

Speaking of...with beta 4a (not sure about the earlier betas)...old-style string functions don't autocomplete whether you enforce new-style Strings or not.  Not that it matters to me...I use the new-style Strings.

Can you give an example of a function that doesn't work? I just tried StrComp, StrCopy, etc and they seemed to autocomplete just fine.

Well...I start a new game with the Default template, uncheck "Enforce new-style Strings", go to the global script, and type "Str" and the only thing I see in the autocomplete is "String".  I'll try unzipping the files to a clean folder and try again, as well as trying the new beta, and let you know...probably just something I did to screw up the computer again.

Just a thought regarding the autocomplete parser.  Clearly it's too late to implement any changes to the parser for older versions, but could you implement some sort of value so that functions will only autocomplete for certain versions of AGS?

I suppose it's possible that autocomplete could detect the new #ifver directives and work out what to autocomplete based on that, but for now it's not a priority.

Okay...that's understandable.  Acceptable.  Good 'nough.

Thanks for the new version Chris.

[xenogia]

* View preview window now cycles through whole of multi-loop animations.

Ahh this is a great bug fix, considering this was an issue for me because most of my animations take up at least 2 loops each

Thanks Chris

[strazer]

* Added system.Version property to return a new-style string.

Is it me or this nowhere to be found in the manual yet? It still refers to system.version. FIXED

[Wretched]

Sorry if this has been reported, but Acwin.exe (I've copied it to the games folder for quick testing) still looks for music in the root directory and not in the new Music folder.