AGS v2.7 Final: Yet Another Edition

[Ishmael]

I like the closing brace handling as it is in the newest version. Don't change it, is my opinion.

[Radiant]

Apparently I'm the only one who frequently adds new code below a line containing a closing brace } (because if you press enter from that line, that line gets de-dented regardless of where the { was). Could you please do an option to turn if off anyway?

We've been discussing overloading a bit... would this be workable...
character[EGO].Face (charid)
character[EGO].Face (x, y)

(you can tell from the # of parameters whether it's FaceChar or FaceLoc)
(also if you're doing lots of constants anyway, Face (LEFT) may be useful (although it's easy to code yourself, of course ))

[Hollister Man]

I haven't programmed extensively since high school, and even that was a (non-visual) C++ compiler, so I'm a bit lost here.  Anyway, BUG REPORT:

I am using RawDrawImage like a crayon for drawing. What its set up to do is every 10 game cycles, it RawDrawImage([crayon object X], [crayon object Y], GetObjectGraphic[crayon object]) (pseudocode)

Now this object is animating, so the frame changes.  It looks like the engine has got the right image, just not the right colors.  I'll post a demo if you like.

[Ishmael]

Apparently I'm the only one who frequently adds new code below a line containing a closing brace } (because if you press enter from that line, that line gets de-dented regardless of where the { was).

I got used to the 2 char diffrences right from the start.. that's why it doesn't bother me..

[Pumaman]

I know that one of the things AGS is known for is it's "compatibility" in a way (ie, recently-made-useless commands take a looong time to quit the scene so people don't have to re-script the whole thing, like InterfaceOff or the PlayerStandsOnHotspot interaction). But I'll ask anyway. How much longer AFTER 2.63 is out can the old commands be expected to work, do you think?

I have no plans to remove support for the old commands. Before doing so, I'd want to make sure that a tool was available to automatically upgrade old-style scripts. People have invested a lot of time in writing their game scripts, and I don't want to suddenly go and render them all useless.

- Autocomplete doesn't properly display struct members if they are indented with tabs within the declaration.
- The context-sensitive help for the old SetActiveInventory doesn't point to the new ActiveInventory property.

Well spotted, I'll get those fixed.

I think the ALLAREAS define for the Walk command is slightly confusing. I like Rick's ANYWHERE better.

Yeah, I'm not sure about this one either. My personal preference would be for   eWalkAnywhere  and  eWalkAreasOnly, if enum support gets added.

And shouldn't StopMoving be called StopWalking? Or do you intend to use it later for stopping animationless movement as well?

Aye, I left it as StopMoving because it will cover both walking and any future Move command as well.

I propose to rename SetSpeed to SetWalkSpeed since we also have animation speed.

Good idea.

Will you eventually rename (capitalize) all character variables like .walking and move them into the appropriate section in the help file? I was just wondering why you only chose .Room for this beta.

I'm not sure about this one. The reason I did .Room and .PreviousRoom was because I made them read-only, but I didn't want to break old scripts by making the normal variable read-only; therefore the new readonly properties were added.

I'm not sure what to do with the rest -- comments welcome.

I think it's good we're discussing function names and the like. Since so much is changing anyhow, now's our chance to make it right from the get-go.

Indeed -- this is a rare chance to actually change things, because once people have started scripting with the names then they become much harder to change.

I also had an idea, but I don't know how feasable it is:
Would it be possible to have members default to the struct the current function is called by, so you could do
  character[EGO].FaceLocation(.x - 10, .y);
for example?

Like the VB With block thing? Sounds kinda handy; but if pointers are added it would only be  Ego.FaceLocation(Ego.x, Ego.y)  which wouldn't be such a handful anyway. I'll leave it on the backburner for now.

Apparently I'm the only one who frequently adds new code below a line containing a closing brace } (because if you press enter from that line, that line gets de-dented regardless of where the { was). Could you please do an option to turn if off anyway?

Remind me once all the actual scripting engine changes are done. I'll probably re-visit the script editor and add a Preferences dialog for options such as tab size, auto-indent, etc at that time.

We've been discussing overloading a bit... would this be workable...
character[EGO].Face (charid)
character[EGO].Face (x, y)

That would be possible, but I'm a bit nervous because it's rather prone to error. I'm not sure if the benefits outweigh the confusion factor in this case.

I am using RawDrawImage like a crayon for drawing. What its set up to do is every 10 game cycles, it RawDrawImage([crayon object X], [crayon object Y], GetObjectGraphic[crayon object]) (pseudocode)

Are the room background and the crayon image the same colour depth?

[Pumaman]

Right, beta 4 is now up.

This updates the object functions to the new way. There's a new global array "object" that works just like "character". So you can do stuff like:

object[2].Move(100, 50, 5);

and so on.

Also added is Enum support along with autocomplete for it -- so the horrid BLOCK/NOBLOCK defines are now gone completely, and have been replaced with nicer eBlock-type enums.
Because autocomplete now shows you the possible values, you don't have to remember anything so is there any point allowing it to accept 0/1 as well?

Finally, type checking has been significantly enhanced. You used to be able to do stuff like this:

int i;
i = character[EGO];

which was highly illegal and would cause strange results at run-time; it shouldn't now be possible to compile a script like that.

Anyway, as far as the object-based functions go, I'm not sure whether to change over anything else. The characters and objects were the main reason for doing this -- can anyone see a benefit in object-ising any other parts of the script functions?

One possibility I'd like to do would be the GUI objects, but realistically that would require pointer support, because asking people to do stuff like  gui[3].listbox[4].Add()  would be rather messy.

Anyway, comments on the naming and behaviour of the newly converted object functions would be welcome. I'm still open to changing things there.

On the character functions front, I'd like to freeze the new names now so that people can start to use them and test them out. So if anyone has any last-minute issues with the character function/property naming, now is the time to shout.

[Snarky]

Is it now legal/possible to give a struct as an argument to a function? I seem to remember being told some time back that that was not allowed.

And what about passing arrays as arguments?

[Pumaman]

No, neither of those is possible. However, the difference is that in previous versions it would appear to work, but actually just corrupt bits of memory. Now, the compiler stops you from doing it.

[strazer]

* (...) When calling a function which takes an enum parameter, autocomplete has been enhanced to pop up with the valid options.
* Improved function calltips so that it highlights the current parameter.

This rocks!

But:
  object[1].B // does suggest "Baseline"
  object[1].Bs // closes pop-up
[BACKSPACE]
  object[1].B // does NOT suggest "Baseline" anymore

Also, with object-based scripting enforced, how do I return a character's current view? character[CHARID].view is not allowed.

Edit:
Another suggestion: I've noticed you have an internal define NARRATOR -1 so you could update the manual to propose that for the game.narrator_speech game variable.

[Radiant]

Does this mean, for instance, that object movement is analogous to character movement? Specifically, can objects use anti-glide mode? Ideally a character should be a superset of an object.

For consistency, it may be useful to create structs for rooms, regions, areas and hotspots - for all the functions GetHospot*, SetRoom* etc. Then again I don't see a very high need for this.

And thanks for all the good improvements!

[RickJ]

Wowee!  Am I a couple of versions behind.  CJ thanks for kindly reading my previous lengthly post, I'll try to be a bitmore to the point this time round.     

The grey background was deliberate, mainly because of the #sectionstart / #sectionend lines, to make them obviously different to the rest of the code.

What would your preference for preprocessor directive colouring be?

I would be happy with any color as long as there wasn't  a backgound color.   

Well, the reason it's split up as it is at the moment is so that sprites, views, etc can be shared between different characters and different objects, which adds a degree of flexibility and stops you having to load duplicate copies of graphics.

I do understand the difficulty of team working on a project, and I'm hoping to add some sort of rudimentary diff/merge support at some stage.

I understand the need to avoid unnessary copies of graphics, sounds, music, and other entities that consume relatively large amounts of disk space.   I have some ideas how a degree of modularity can be achieved while maintaining the use of shared resources and would make a diff/merge or import/export functionality easier to implement.   This is obviously not the time or place to have a discussion about this  so I'll leave it for another day. 

Anyway, as far as the object-based functions go, I'm not sure whether to change over anything else. The characters and objects were the main reason for doing this -- can anyone see a benefit in object-ising any other parts of the script functions?

One possibility I'd like to do would be the GUI objects, but realistically that would require pointer support, because asking people to do stuff like  gui[3].listbox[4].Add()  would be rather messy.

There are a bunch of Get/Set functions, and never-ending request to add more, for game and room that would perhaps be better/easier handled as object properties?   

Do you mean for just for this release or forever?   Eventually, I think you would want to objectise everything that lends itself to an OO paradigm.

As for the GUI stuff I agree that it would logically be the next biggest one to change over.  It seems like you are still pondering the possibilty of adding support for pointers at some point.   If so then add the GUI stuff next time around, otherwise just do it now, IMHO.
   

Also added is Enum support along with autocomplete for it ..

Yeah....

Great work CJ ...

[Rui 'Trovatore' Pires]

Me, I'd say leave the rest as it is... with characters and objects it was fine, but the rest might turn out a bit too confusing/messy, methinks.

EDIT - Just read this:

Because autocomplete now shows you the possible values, you don't have to remember anything so is there any point allowing it to accept 0/1 as well?

Yes, allow it to accept 0/1. I ALWAYS use numbers unless I can't help it.

EDIT 2 - Ok, here's an issue I found.

So I have 11 objects that animate at random times, like flashing stars, yes? Therefore, I used to have the following code:

  if (IsTimerExpired(1)==1) {
    SetTimer(1,Random(14)+1);
    randomizer=Random(10)+1;
    if (IsObjectAnimating(randomizer)==0) AnimateObject(randomizer,4,4,0);
  }

(and yes, the timer WAS set previously). And this worked wonderfully. But with the NEW code, which is:

  if (IsTimerExpired(1)==1) {
    SetTimer(1,Random(14)+1);
    randomizer=Random(10)+1;
    if (object[randomizer].Animating==0) object[randomizer].Animate(4,4);
  }

what happens is each object WAITS UNTIL ALL OBJECTS HAVE FINISHED THEIR ANIMATIONS before animating, giving an undesirable effect. Now, I have tried switching back and forth between these two snippets of code - the 1st ALWAYS works, the second NEVER does. What's happening?

BTW, I can upload the thing if necessary (accourse).

[Radiant]

quote]Because autocomplete now shows you the possible values, you don't have to remember anything so is there any point allowing it to accept 0/1 as well?

Yes, allow it to accept 0/1. I ALWAYS use numbers unless I can't help it.

I second that.

[Pumaman]

But:
Ã,  object[1].B // does suggest "Baseline"
Ã,  object[1].Bs // closes pop-up
[BACKSPACE]
Ã,  object[1].B // does NOT suggest "Baseline" anymore

This has always been the case -- if you start to type "baseline" again, autocomplete will reappear. Basically, backspace doesn't check for autocomplete; do you think it should?

Also, with object-based scripting enforced, how do I return a character's current view? character[CHARID].view is not allowed.

Hmm oops, good point, I'll add a property. If there's anything else like this that's accidentally dropped off, do let me know.

Another suggestion: I've noticed you have an internal define NARRATOR -1 so you could update the manual to propose that for the game.narrator_speech game variable.

Well spotted, I'll update that.

Does this mean, for instance, that object movement is analogous to character movement? Specifically, can objects use anti-glide mode? Ideally a character should be a superset of an object.

No, objects can't use anti-glide mode. Since animation and movement are two completely seperate things for objects, this seemed the best way to have it.

For consistency, it may be useful to create structs for rooms, regions, areas and hotspots - for all the functions GetHospot*, SetRoom* etc. Then again I don't see a very high need for this.

Yeah, I thought about that. I don't really think the benefits are great enough to merit obsoleting more functions though.

Do you mean for just for this release or forever?   Eventually, I think you would want to objectise everything that lends itself to an OO paradigm.

Ideally I would like to completely OO-ise it, but practically speaking I don't think I will. Global functions like SetScreenTransition, while you could argue should be a static member function like  Game.SetScreenTransition, doesn't really bring any benefit in doing it that way; whereas things like characters, objects, GUIs, etc really lend themselves intuitively to OO.

As for the GUI stuff I agree that it would logically be the next biggest one to change over.  It seems like you are still pondering the possibilty of adding support for pointers at some point.   If so then add the GUI stuff next time around, otherwise just do it now, IMHO.

Yeah, I am still pondering pointers... I definitely would like to add them once I've worked out how to take care of the technical issues.

Yes, allow it to accept 0/1. I ALWAYS use numbers unless I can't help it.

Hehe. I guess my hatred for 0/1 stems from seeing things like this:

AnimateObjectEx(0,2,0,0,0,1);

I mean, seriously, what the hell does that do?

Anyway, I'll re-instate it for Blocking, WalkWhere and Repeat. However, for Direction I don't think having 0/1 is appropriate, because there's no obvious meaning to whether forwards is 1 or 0; so unless you have any strong objections I might leave it banned for that parameter.

what happens is each object WAITS UNTIL ALL OBJECTS HAVE FINISHED THEIR ANIMATIONS before animating, giving an undesirable effect. Now, I have tried switching back and forth between these two snippets of code - the 1st ALWAYS works, the second NEVER does. What's happening?

Animate is blocking by default. You need to supply the optional blocking parameter and set it to eNoBlock.

[Rui 'Trovatore' Pires]

Hehe. I guess my hatred for 0/1 stems from seeing things like this:

AnimateObjectEx(0,2,0,0,0,1);

I mean, seriously, what the hell does that do?

Anyway, I'll re-instate it for Blocking, WalkWhere and Repeat. However, for Direction I don't think having 0/1 is appropriate, because there's no obvious meaning to whether forwards is 1 or 0; so unless you have any strong objections I might leave it banned for that parameter.

Fine by me.

Animate is blocking by default.

Er, that so? I'm not sure that's a handy default... maybe it's just me, and maybe I've just gotten used to the old non-default-blocking AnimateObject... but I do think it shouldn't be blocking per default... especially since it's a bit of a (truly minor, however) bother to set the "No Repeat" parameter (already a default in it's own right) just to change the blocking parameter... but that tiny, tiny issue aside, I do believe that object animations should be kept non-blocking per default.

[Pumaman]

Animate is blocking by default.

Er, that so? I'm not sure that's a handy default... maybe it's just me, and maybe I've just gotten used to the old non-default-blocking AnimateObject... but I do think it shouldn't be blocking per default...

That's fine, this sort of thing is precisely why we're having these betas. At the moment it is a bit inconsistent with Walk being non-blocking but Animate blocking by default.

What does everyone else think? Do you tend to use Animate more often in a blocking or non-blocking manner?

[strazer]

Basically, backspace doesn't check for autocomplete; do you think it should?

I think so, yes. I often start typing beyond the first letter, only to lose the pop-up when I mistype... 

What does everyone else think? Do you tend to use Animate more often in a blocking or non-blocking manner?

Personally, I use most functions non-blocking but I think they should be consistently blocking by default to make them easier to use for newbies.

[Radiant]

I agree with strazer. However, it seems to me that any default value should be zero, for clarity's sake - so the parameter may have to be called 'background' rather than 'blocking'.

I mean, Function (a,b) sounds similar to Function (a,b,0) right?

[Snarky]

I don't care whether you allow 0/1 parameters in place of enums as long as it doesn't interfere with anything else. It doesn't affect me. But if we're talking about renaming parameters to accomodate it, I say get rid of it.

I don't want to have to care about whether TRUE is defined as 0 or !0, or which value of an enumeration comes first. The whole point of abstraction is to get away from that level of detail.

Any parameter of boolean or enumeration type should have the simplest, most intuitive name possible, and its default value should be whatever value corresponds to the desired default behavior, whatever that may be. All default boolean parameters must be FALSE? Please no.

While on that subject: now that we have enums, what about providing a bool enum with entries True and False? Actually, that's a bad idea. Forget about it. I was just looking for a cheap way to "typecheck" boolean arguments, but "bool.true" is inelegant, and people who prefer 0/1 should probably be allowed to go on doing that.

[strazer]

While on that subject: now that we have enums, what about providing a bool enum with entries True and False? Actually, that's a bad idea. Forget about it. I was just looking for a cheap way to "typecheck" boolean arguments, but "bool.true" is inelegant, and people who prefer 0/1 should probably be allowed to go on doing that.

Actually, this is already implemented.
You can use true/false for several things, including:
.Clickable
.DiagonalWalking
.IgnoreLighting
.IgnoreScaling
.IgnoreWalkbehinds
.ScaleMoveSpeed
.Solid
.TurnBeforeWalking

P.S.: I'm posting this from Linux, woo! Gonna test some AGS games later.