AGS v2.7 Final: Yet Another Edition

[Rui 'Trovatore' Pires]

Could you consider an inv[] array, similar to gui[], character[] and object[]?

[Pumaman]

But XY, Coords or even Position wouldn't be any different than Location. No indication of what kind of coordinates. How about AtScreenXY and AtRoomXY?
StrLen(ScreenXY) = StrLen(Location) 

Ok, yeah .. GetHotspotAtScreenXY() doesn't sound too bad.

Hmmm... a Big List of All Enums would be awesome.

Ok, I'll see what I can do.

The internal FindGUIID function is included in the autocomplete pop-up.

Well spotted, I'll remove it.

So are all member variables of GameState, unless that's intentional.

Well, I'm not sure about this one. It is kinda handy to have them all there, but then some aren't supposed to be fiddled with. It really needs a proper review.

If Room and Screen were objectized then you would have:

   Screen.GetNameAt(), Room.GetNameAt()

That's not a bad idea, actually. Although it would mean that I'd have to properly object-ise both to stop it looking odd, and there are quite a lot of screen and room functions

CJ, if you just implemented overloading (and why not polymorphism while you're at it) then you wouldn't have this problem 

Quiet, you

Could you consider an inv[] array, similar to gui[], character[] and object[]?

Beta 10 has an  inventory[]  array.

[Rui 'Trovatore' Pires]

Oh, sorry. Since I didn't see it listed, I didn't know it was there.

[Pumaman]

Ok, beta 11 is now up. This includes global pointers and object pathing, so testing would be appreciated as there's quite a bit of new code in there any I don't guarantee it all works perfectly!

[strazer]

* Object-ised Overlay functions now that global pointers are supported.

How do we use the return value of Character.SayBackground now?

* Added "Built in enumerated types" page to the manual, listing all the built-in enums.

Shouldn't this be under "Reference"?

[Gilbert]

Good point, FloatToInt doesn't work properly with negative numbers. Well spotted, I'll get it fixed.

Great

Yes, the script engine has a limit of 9 parameters in a function call. If this is too much of a problem, it can probably be increased.

That's okay, I think it's not that common to call a function with > 9 parameters anyway, and there're always workaround when you need them (which rarely happened).

I asked about these two things because I mucked up a small test for the engine, which looks better compiled with beta11 now (because of the rounding fix, some of the stuff were off by 1 pixel with beta10), and the line of text on the top if I put everything into one RawPrint() call it would crash (because of more than 9 parameters) so I had to split it into two calls.

[SSH]

Changes from Beta 10 to Beta 11:
* Added support for global pointers in script, so that you can declare a global variable as a pointer. But, consequently:
* SaveGameSlot/SaveGameDialog are now delayed-response functions, just like the RestoreGame ones. This means the game won't actually be saved until the script function finishes.

NOOOOO!

This means, then, If I want to use the savegameslot function to save a temporary copy of the current game, then load it back in to get the screenshot, I have to stop the script and set a flag in rep_ex to pick up again on the next game cycle? Euugh!

[Rui 'Trovatore' Pires]

Poor CJ, work as you might we are never happy... but I'm not sure which I'd rather, either. Gloval Pointers VS delayed SaveGameSlot... that's a hard one.

[SSH]

While we're moaning, as ever, its a real pain that all the old function help is gone from the manual when yuo are converting the scripts... maybe 2.7 can have both in, as lots of people will be converting scripts...?  As it is I have to have two help files open at once, And I keep getting the wrong one, as they look the same on the taskbar... failing having the old functions in the helpfile you couldn't add the version number to the helpfile's taskbar text could you?

And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...

[RickJ]

And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...

SSH, I shall also sin for we share the same desires ... 

[SSH]

And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...

SSH, I shall also sin for we share the same desires ... 

So it was you in the Blue Oyster the other night? 

[Rui 'Trovatore' Pires]

Two issues.

1) object[1].Animate(0, 4, eRepeat);
The previous line of code, which was mighty handy in Player Enters Screen BEFORE Fadein for those objects that were ALWAYS animating even before the room was loaded, and which USED to work, now gives the following error message -

---------------------------
Adventure Game Studio
---------------------------
An error has occured. Please contact the game author for support, as this
is likely to be a scripting error and not a bug in AGS.
(ACI version 2.70.827)

(Room 0 script line 10)
Error: A text script run in the Player Enters Screen event caused the
screen to be updated. If you need to use Wait(), do so in After Fadein

2) object[3].Move(282, 89, eNoBlock, eAnywhere);
You'll notice I forgot one parameter, between 89 and eNoBlock - SPEED. This error was NOT detected upon compiling, but while I was playing the game aborted with a message saying that the value for BLOCKING was invalid. Shouldn't this have been detected upon compiling?

[Pumaman]

How do we use the return value of Character.SayBackground now?

Yeah I was thinking about that one, I guess it needs to return an Overlay* as well.

Shouldn't this be under "Reference"?

I suppose it could be

I asked about these two things because I mucked up a small test for the engine, which looks better compiled with beta11 now

Hehe, hey that's really cool. Nice work

This means, then, If I want to use the savegameslot function to save a temporary copy of the current game, then load it back in to get the screenshot, I have to stop the script and set a flag in rep_ex to pick up again on the next game cycle? Euugh!

Unfortunately it's simply not possible to support both global pointers and a blocking SaveGameSlot. This is because if the game was saved at that time, the reference counts for any objects used within the script function would be saved incorrectly.

However, it seems like what you're trying to do with it is rather hacky. Surely the best solution all round would be some sort of new CreateScreenShotSprite command so that you can get the current image without having to save-load it?

Poor CJ, work as you might we are never happy

Oh don't worry, it's the nature of software development; whatever you do, your 'customers' are never happy 

While we're moaning, as ever, its a real pain that all the old function help is gone from the manual when yuo are converting the scripts... maybe 2.7 can have both in, as lots of people will be converting scripts...?

Sorry about that; but I can't realistically add them all back in again.

failing having the old functions in the helpfile you couldn't add the version number to the helpfile's taskbar text could you?

I'm sure I can manage that.

And I know its a suggestion and they're not allwoed here, but how abotu being able to open other scripts read-only while editing a script? I'm often needing to quickly check something in the header, for example...

That's a possibility for a future version. Not 2.7 though, there's just too much else to do

1) object[1].Animate(0, 4, eRepeat);
The previous line of code, which was mighty handy in Player Enters Screen BEFORE Fadein for those objects that were ALWAYS animating even before the room was loaded, and which USED to work, now gives the following error message

That's because it's now blocking by default.

2) object[3].Move(282, 89, eNoBlock, eAnywhere);
You'll notice I forgot one parameter, between 89 and eNoBlock - SPEED. This error was NOT detected upon compiling, but while I was playing the game aborted with a message saying that the value for BLOCKING was invalid. Shouldn't this have been detected upon compiling?

No, enums are not strictly type checked. This is because people still wanted to be able to use 0 and 1 as the enum values. At least it is now caught as an error at run-time, which is more than 2.62 managed

[Rui 'Trovatore' Pires]

1 - Oh? Blocking by default? Ok. I'll have to remember that. Heh, probably I'll have to hammer it in my head.

2 - I'll shut up then, because I also still want to use 0 and 1. : So feel free to forget about it.

[Scorpiorus]

* Added support for global pointers in script, so that you can declare a global variable as a pointer.
* Added pathing support to script, so you can doÃ,  lstList.OwningGUI.IDÃ,  orÃ,  gui[3].Controls[2].AsListBox.AddItem();Ã,  and so on.
* Object-ised hotspots, regions and inventory items. Added script names for hotspots and inv items.
* Added gui[] array to access guis, similar to character[] and object[] arrays.
* Pointers can now be compared to each other and to base classes, so GetGUIAtLocation/GetControlAtLocation are now easier to use.

Thanks CJ, for all the hard work and efforts you put into making this new object-oriented scripting approach become more and more user-friendly and intuitive!

Can I make a struct member variable that can be written only by functions of the struct but can be read directly by all other functions?
Do I really need to make Getxxx functions for every variable?

Interesting idea, I'll certainly consider it. Can you think of a snappy keyword to represent this?
readonlyexternal comes to mind, but that's a bit unwieldy.

I think Strazer's "writeprotected" seems fine - it still tells that a member variable is protected but also specifies the actual level of protection. I'm not sure whether it should be "writeprotected", "protectedw", or maybe even "protected write" / "write protected" (two words) but I feel like the "protected" part should be there.

I really don't want to rename the old objects to something else -- that would cause no end of confusion. We do need some way to make it distinct -- perhaps have another word (totally unlike "object") for the script OO objects.

So, what if, as Snarky mentioned, they'd be refered to as instances of struct? I see, it may seem confusing to some people at first but on the other hand it's both completely distinct from "object" and, indeed, a word that's used in OO terminology?

But I also see benefits in what Rick suggested, i.e. struct is a type and structure is an instance of struct.

Well, there is a wider issue of whether all functions that take a CHARID as a parameter should now take the actual character object instead; what do people think?

Yeah, this seems very reasonable to me since, for instance, character.FollowCharacter() could accept character's pointer name rather than id. It would also be wonderful if the editor listed all character names once an opening bracket (comma) is typed.

By the way, I think it worth mentioning somewhere in the manual all the managed types so that people could write thier own functions having pointers of these types as parameters:

function SomeFunction(GameCharacter *pointer) {...}

[Gilbert]

Surely the best solution all round would be some sort of new CreateScreenShotSprite command so that you can get the current image without having to save-load it?

Heh reading this I was suddenly inspired of some feature additions, but since this is the beta thread and I don't think that should be made into this release I posted that in the suggestions thread instead.

[Rui 'Trovatore' Pires]

There seems to be a problem with objectised hotspots, or something. "null" as a value in GetHotspotAtLocation(mouse.x,mouse.y)!=null doesn't have good results - matter of fact, I think it screws up... and "0" isn't recognized by the engine, saying it can't change "int" to "*hotspot", or something.

Try it yourself - paste this in repeatedly_execute

if (GetHotspotAtLocation(mouse.x,mouse.y)!=null) mouse.Mode=2;
else mouse.Mode=0;

For it, it was always stuck on mode 2. The manual says that this function returns 0 instead of null (unlike the others; VERY strange). But

if (GetHotspotAtLocation(mouse.x,mouse.y)!=0) mouse.Mode=2;
else mouse.Mode=0;

says

---------------------------
Compile Error
---------------------------
There was an error compiling your script. The problem was:

In: 'Room script'

Error (line 7): Type mismatch: cannot convert 'Hotspot*' to 'int'



Do you want to fix the script now? (Your room has not been saved).
---------------------------
Sim   Não   
---------------------------

And I got the same result whether "Enforce Object-Based Scripting" was on or off.

[Pumaman]

Thanks CJ, for all the hard work and efforts you put into making this new object-oriented scripting approach become more and more user-friendly and intuitive!

No problemo!

I think Strazer's "writeprotected" seems fine - it still tells that a member variable is protected but also specifies the actual level of protection.

Yeah, I rather like "writeprotected" too; it neatly sums up what it does.

So, what if, as Snarky mentioned, they'd be refered to as instances of struct?

Indeed - or even perhaps just as "instances" rather than "objects"?

Yeah, this seems very reasonable to me since, for instance, character.FollowCharacter() could accept character's pointer name rather than id. It would also be wonderful if the editor listed all character names once an opening bracket (comma) is typed.

Yeah that would be neat if autocomplete did that, I'll look into it.

By the way, I think it worth mentioning somewhere in the manual all the managed types so that people could write thier own functions having pointers of these types as parameters:

function SomeFunction(GameCharacter *pointer) {...}

Good point. I think that really, I need to write an Introduction to Pointers manual page, since a fair few commands return them now, so it's probably time to make sure people know what they are.

Heh reading this I was suddenly inspired of some feature additions, but since this is the beta thread and I don't think that should be made into this release I posted that in the suggestions thread instead.

Interesting idea you posted, I'll bear it in mind

There seems to be a problem with objectised hotspots, or something. "null" as a value in GetHotspotAtLocation(mouse.x,mouse.y)!=null doesn't have good results - matter of fact, I think it screws up... and "0" isn't recognized by the engine, saying it can't change "int" to "*hotspot", or something.

The manual says that hotspot 0 is returned, not 0. So you'd do:

if (GetHotspotAtLocation(mouse.x,mouse.y) != hotspot[0])

however you raise a good point. The wording in the manual could be better, so I'll update it to clarify matters. The reason for it not returning null is because Hotspot 0 is still considered a hotspot, and it's possible for it to have interactions,etc.

[Rui 'Trovatore' Pires]

Oh, ok. Bugger, these things will take some time to adjust to... I apologise in advance for any more silly posts in the future.

[Pumaman]

Please do continue to point things out if they aren't immediately obvious. Remember, in a couple of months time we'll have a load of people upgrading from 2.62 and the less confusion and questions they have, the better; so let's get it all clarified properly while we can