AGS v2.7 Final: Yet Another Edition

[strazer]

I've noticed that if you tick the "Hide player character" checkbox for a room, you can't make an NPC in that room follow another NPC in that room.
There's no error message, the NPC just doesn't move.

[Scorpiorus]

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, seems fine.


I have another idea -- it's kind of a suggestion but I believe it would be very handy with OO scripting.

What if the script editor would bring autocomplete list on pressing Ctrl-Space (or whatever). Currently, we have to type at least three characters for it to pop up but in certain cases it may be very useful for it to pop up on less then three. For example, we now have character o-names, all have a 'c' prefix. But without some tricky o-names it isn't possible to view all of them. With 'Ctrl-Space' thingy we could just type 'c' and call autocomplite list to see all related names. The same goes to objects, guis, inventory items, etc. Or maybe one wants to see a list of all enumerated constants -- type 'e' and Ctrl - Space. ?

[Pumaman]

I've noticed that if you tick the "Hide player character" checkbox for a room, you can't make an NPC in that room follow another NPC in that room.

well spotted, I'll fix it

What if the script editor would bring autocomplete list on pressing Ctrl-Space (or whatever).

Sounds reasonable, I'll look into it.

[RickJ]

I've noticed some inconsistency in the way object and character views are set as follows:   

• Character walking/normal view is set using ChangeView function (i.e. cEgo.ChangeView(7)). 
  
  
• Other character views are set using properties (i.e. cEgo.ThinkView = 7)).
  
  
• Object views are set using SetView function (oDoor.SetView(14)).
  
  I know this was discussed before but I don't recall if we did a consistency check, so please take these questions/comments as an exercise in review.   
  
  1.  Would it not be more consistent to make the View property writable?  This would make the ChangeView function redundant but it would make the walking or normal view work the same as the other views for character.
  
  2.  Shouldn't objects also have a view property the same as characters? 
  
  3.  The object SetView function has optional parameters that allow the loop and frame to be set.   If the character View property were made writable then couldn't the ChangeView function be made to work the same as the object SetView function and couldn't both functions then have the same name?   
  
  I believe some folks have used characters as substitutes or supplements to room objects on ocassion and it would seem that keeping some consistentcy would be helpful (so as long as it is practical).  If this has already been discussed and well considered then just ignore the above and forgive me for missing out on the discussion.   
  
  [edit]
  I just  installed Beta11.   The Room menu is very nice but I sorely miss the room editor toolbar, especially the interaction editor and script editor buttons.  I know there are keyboard shortcuts for these two functions but is there any chance they can be added back.   Old habits die hard you know.  Btw, plain grey buttons would be fine with me as well. 

[Gilbert]

I don't know, but this inconstency thing didn't annoy me.
I think one reason for using a function to change the character's view is because it's for changing the currently displayed view he's using (while for the other talk/think/whatever views, it's usually safe to change them by directly changing the appropiate variables), using a function can ensure proper checking and that the graphics is updated accordingly at the same time (if this is changed to a variable instead, the engine might need to either check for the changes in the variables every gameloops, or should be smart enough to act immediately whenever such a variable is changed).

[SSH]

OOps, stupid question deleted!

Anyway: would it be possible to have pathing from the GetAtLocation (or whatever they end up being called) functions. i.e.

Code: ags

if (type == 1) default_verb = HSActions[GetHotspotAtLocation(mouse.x,  mouse.y).ID];

Would that mean it might have to be something like:

hotspot.GetAtScreenXY(mouse.x,  mouse.y).ID;


actually, this might be a nice solution to the naming problem, if the GetAt functions were static functions of the arrays...

[RickJ]

I don't know, but this inconstency thing didn't annoy me.

That's fine, I'm not really annoyed either because I am aware of the differences and am capable of dealing with them.  On the other hand we have been kindly asked to review and comment on V2.7 before everything is cast in stone and difficult to change.   If the "inconsistencies" I have noted are intentional then fine I have no problem with that,  if not then I thought someone may appreciate them being pointed out. 

I think one reason for using a function to change the character's view is because
it's for changing the currently displayed view ...

It is my understanding that setting properties of native objects does in fact invoke handler functions.  Clearly if there were a problem setting a view property while the view is in use then the problem would eventually occur regardless of how infrequently the view was used or changed. 

[RickJ]

I'm a little unsure as to string handling now (and in the past, too). For example:

SSH, I think you would do it like this:   

Code: ags

    string name;
    InventoryItem *ii = GetInvAtLocation (mouse.x, mouse.y);
    if (ii != null)  ii.GetName(name));
    else StrCopy (name, "");

Probably you have ben spending too much time at the Blue Oyster 

[SSH]

Damn you Rick for replying before I could edit away my silliness! And I thoguht we had something special!

And you double-posted to do it, too!



Oh, and just to stay on-topic. CJ, you didn't include the mouse mode enumeration in your big list.... ah, because it is define dby cursor names. Maybe you can explain the naming convention for these generated enums in that section, too?

More:

How about a way to avoid opening the script editor when you set a GUI control's script function? Either a third button on the popup window so "OK - Edit script", "OK - No edit" and "Cancel". Or maybe a preference setting in the AGS Editor in general

Also nice would be a shortcut key in the editor for "Save and Exit". Ctrl-S would be fine!


Also, shouldn't interface_click take pointers now instead of numbers?

[RickJ]

And I thoguht we had something special!

I you didn't care ... you wouldn't be so hard on me  :

[SSH]

Earlier it was said that we can have protected static functions, but I can't seem to get them to work: they parse OK, but then it says that I'm not allowed to call one from another. Here's my declaration:

Also, I can't seem to access protected variables from inside my static functions.

Code: ags

struct sgs {
  char t[200];          // This is the string description of a save slot
  int spr;              // This is the sprite number of a save slot
  // internal fns:
  protected import static function get_slots();
  protected import static function reget_slots();
  protected import static function do_save();
  protected import static function do_load();
  protected import static function close();
  protected import static function check_do_save();
  protected import static function on_key_press(int keycode);
  protected import static function repeatedly_execute();
  protected import static function setup_gui();
  // external fns
  import static function Save();
  import static function Load();
};
sgs sgs_struct[10];   

Is this becuase it is used in an array? Should that work?

[Pumaman]

1.Ã,  Would it not be more consistent to make the View property writable?Ã,  This would make the ChangeView function redundant but it would make the walking or normal view work the same as the other views for character.

The reason for this difference is because the View property represents the current view, ie. if LockView has been used, View will return that.

On the other hand, ChangeView deals with the 'normal' walking view for the character. Therefore, it's possible that the following code:

player.ChangeView(5);
Display("%d", player.View);

wouldn't return 5, if the view was currently locked to something else. Hence, having it as a writable property would be uninituitive and confusing.

2.Ã,  Shouldn't objects also have a view property the same as characters?Ã, 

Good point, I'll add that.

3.Ã,  The object SetView function has optional parameters that allow the loop and frame to be set.Ã,  Ã, If the character View property were made writable then couldn't the ChangeView function be made to work the same as the object SetView function and couldn't both functions then have the same name?Ã,  Ã, 

I wanted to have different names to differentiate the way the views work. A character always has to have a current view, whereas an object does not (it might just have a sprite number instead).
Also, because LockView used to be called SetCharacterView, I thought that calling it SetView on the character would confuse people.

The Room menu is very nice but I sorely miss the room editor toolbar, especially the interaction editor and script editor buttons.

The Save, Edit Script, Edit Interaction and Edit Messages buttons are returning for the next beta.

Anyway: would it be possible to have pathing from the GetAtLocation (or whatever they end up being called) functions. i.e.

It'd probably be possible; the reason I'm not too enthusiastic to add it is that generally the Get* functions can return null, and people trying to path with it would be dangerous. This doesn't apply to hotspots and regions, of course.

hotspot.GetAtScreenXY(mouse.x,Ã,  mouse.y).ID;

actually, this might be a nice solution to the naming problem, if the GetAt functions were static functions of the arrays...

That's actually a very good idea, I'll do that.

That's fine, I'm not really annoyed either because I am aware of the differences and am capable of dealing with them.Ã,  On the other hand we have been kindly asked to review and comment on V2.7 before everything is cast in stone and difficult to change.Ã, 

Yes, please do continue to review things like this. If you disagree with my reasoning above for leaving things as they are, feel free to say so.

you didn't include the mouse mode enumeration in your big list.... ah, because it is define dby cursor names. Maybe you can explain the naming convention for these generated enums in that section, too?

Good point, I'll add it.

How about a way to avoid opening the script editor when you set a GUI control's script function? Either a third button on the popup window so "OK - Edit script", "OK - No edit" and "Cancel". Or maybe a preference setting in the AGS Editor in general

Yeah I know, I don't like the way this works at the moment -- it was very much put in as a 'quick hack' to allow you to get at the functionality (in case you hadn't guessed, I hate coding user interface stuff ).

Also, shouldn't interface_click take pointers now instead of numbers?

Well, interface_click is obsoleted now by the individual control handler functions, so I'm not planning to update it.

Earlier it was said that we can have protected static functions, but I can't seem to get them to work: they parse OK, but then it says that I'm not allowed to call one from another. Here's my declaration:

Good point, that won't work. Because the static functions don't have a this pointer, they are denied access to the protected members. I'm not sure of a clean way to fix this.

Also, I can't seem to access protected variables from inside my static functions.

Non-static variables cannot be accessed from static functions -- it doesn't make sense (there's no way of knowing which instance of the struct to access).

[Rui 'Trovatore' Pires]

Small bug - sometimes the window holding GUI properties disappears, I have to restart AGS to get it back. I have been unable to see WHEN this happens, but I think it has to do with resizing - maybe even the change of resolution involved upon using "Test game". Maybe the window just moves offscreen, but in any case it's lost until AGS is restarted.

[RickJ]

Yes, please do continue to review things like this.  If you disagree with my reasoning above for leaving things as they are, feel free to say so.

Thanks for your confidence.  Regrading Character/Object differences your explanation sounds reasonable to me.   I think it's one of those things where there just isn't any one right way of doing things. 

For what it's worth, in my world view objects and characters are pretty much the same thing.  One has global scope and the other has scope within a specific room.    I suspect that other people have other points of view.    It seems to me that the new OO script language, at some future point, could take advantage of these similarities by having each inheirit functionality from a common parent, etc, etc...   Ok, I'm getting way beyond the scope of this thread, so I'll leave this discussion for another day.  Well it's food for thought anyway (or at least junk food).

    Cheers

[SSH]

Indeed, if I'm writing code for a character who only appears in one room, why does it need to go in the global script? But then, I may have a solution for that... 

Come to that, maybe Objects, Characters and Hotspot shoudl all be extensions of some base type, so we could do:

Thing *thingy =GetThingAtLocation(mouse.x, mouse.y);
if (thingy == null) {
  // do something here
} else if (thingy.IsObject()) {
  thingy.AsObject.SomeFunction();
} etc...


Also, it would be nice if there was a way for a script to call a GUI control's handler function:

gui[X].Controls[Y].AsButton.CallHandler(eMouseLeft);


 

[Pumaman]

Small bug - sometimes the window holding GUI properties disappears, I have to restart AGS to get it back. I have been unable to see WHEN this happens, but I think it has to do with resizing - maybe even the change of resolution involved upon using "Test game". Maybe the window just moves offscreen, but in any case it's lost until AGS is restarted.

Strange, I haven't seen that myself. I'll bear it in mind but it doesn't sound too serious so I'm not going to thoroughly investigate it.

For what it's worth, in my world view objects and characters are pretty much the same thing.  One has global scope and the other has scope within a specific room. 

In a sense, that's true. Perhaps they should both inherit from some sort of "actor" class. But on the other hand, I think the implementation details are just too different to make it work intuitively if that was the case.

Come to that, maybe Objects, Characters and Hotspot shoudl all be extensions of some base type, so we could do:

Thing *thingy =GetThingAtLocation(mouse.x, mouse.y);
if (thingy == null) {
  // do something here
} else if (thingy.IsObject()) {
  thingy.AsObject.SomeFunction();
} etc...

Interesting idea; that's something that could be added at a later date without causing disruption, so we'll leave it for now.

Also, it would be nice if there was a way for a script to call a GUI control's handler function:

gui[X].Controls[Y].AsButton.CallHandler(eMouseLeft);

Yeah, I'm still not sure how to deal with the GUI button handlers. One thought I had was that each control type would have its own handler, so you'd script:

function Button::OnClick(MouseButton) {

}

that way, you'd have the "this" pointer to identify the object, but on the other hand you'd have to stick all the code for all the buttons in there, so it wouldn't be much better than the one big interface_click.

On the other hand, now that we have the AsButton, AsListBox, etc it would be viable to just pass a GUIControl* into the handlers as a parameter, and not have to worry about the editor checking the types or anything.


Anyway, beta 12 is now up. This tidies up various things -- notable the custom inventory, which works much better and more intuitively than it used to.

Note that it *should* be backwards compatible, but I'd appreciate it if people would just have a quick check to make sure it still does work. Basically, if you change the "game.top_inv_item" variable then it switches into Compatibility Mode and all the inventory windows redirect themselves to look at the old-style game.num_inv_items style variables.

[strazer]

I was wondering what would be the best approach to allow a smoother transition to future seperation of LEC and Sierra speech views (see Tracker).
Currently, the Character.SpeechView property applies to both, so renaming it is not an option...

Note that it *should* be backwards compatible, but I'd appreciate it if people would just have a quick check to make sure it still does work.

Works fine here.

I've only noticed that the Item width & height properties override the old SetInvDimensions function, it has no effect. To preserve compatibility with old scripts, I think the function should have priority.

* Renamed structs from GameCharacter and GameObject to Character and Object respectively, to make it more intuitive.

Good call. The Character.GetAtScreenXY in the manual still refers to "GameCharacter" though.

* (...) each inv window can display inventory for a specific character (...)

This should make a lot of people happy. Great job, CJ!

Edit:

Oh, and may I re-suggest to rename

  GetLocationName -> GetNameAtScreenXY
  GetLocationType -> GetTypeAtScreenXY
  Mouse.SaveUntilLocationChange -> Mouse.SaveCursorUntilChange

as I think they're slightly confusing.

Edit 2:

Shouldn't we obsolete the GetPlayerCharacter function since we now can simply use player.ID?

Edit 3:

How about
  SetAreaScaling -> SetWalkableAreaScaling
?

[Pumaman]

I was wondering what would be the best approach to allow a smoother transition to future seperation of LEC and Sierra speech views (see Tracker).
Currently, the Character.SpeechView property applies to both, so renaming it is not an option...

Interesting point. I suppose it could be changed to two seperate properties SierraSpeechView and LECSpeechView or something. As we're still in beta, it's viable to scrap the current SpeechView property and replace it with those two; but on the other hand people wouldn't be able to easily switch between speech styles if they had to set seperate properties.

I've only noticed that the Item width & height properties override the old SetInvDimensions function, it has no effect. To preserve compatibility with old scripts, I think the function should have priority.

SetInvDimensions is supposed to override all ItemWidth and ItemHeight properties of inv windows for backwards compatibility; does that not seem to be working at present?

The Character.GetAtScreenXY in the manual still refers to "GameCharacter" though.

Well spotted, I'll fix it.

This should make a lot of people happy. Great job, CJ!

Hopefully, yes   It's one of those funny ones where the main thing holding me back from implementing it was a clean way of doing it; the new OO system provided the perfect opportunity

Oh, and may I re-suggest to rename
GetLocationName -> GetNameAtScreenXY
GetLocationType -> GetTypeAtScreenXY
SetAreaScaling -> SetWalkableAreaScaling

Although I do agree in principle, I'd rather not rename functions if they haven't actually changed. In 2.7, a lot of things have new names from 2.62 because of changed functionality; and I'd rather not confuse people by renaming a few functions where they actually do the same thing.

Mouse.SaveUntilLocationChange -> Mouse.SaveCursorUntilChange

I agree with renaming this, but finding a good name for it seems to be impossible. "SaveCursorUntilChange" implies that it waits for the cursor to change, but that's not the case. Anyone got any bright ideas?

Shouldn't we obsolete the GetPlayerCharacter function since we now can simply use player.ID?

Good point, will do.

[strazer]

SetInvDimensions is supposed to override all ItemWidth and ItemHeight properties of inv windows for backwards compatibility; does that not seem to be working at present?

It didn't work for me. I loaded my v2.62 game up, changed a few local variable names (gui, object and so on), then tested it. The inventory items didn't show up (as they used to).
I resized the inventory control to the default dimensions set in the properties window, then they showed up.
I had used SetInvDimensions in game_start.

Although I do agree in principle, I'd rather not rename functions if they haven't actually changed. In 2.7, a lot of things have new names from 2.62 because of changed functionality; and I'd rather not confuse people by renaming a few functions where they actually do the same thing.

Ah, ok. I'll shut up then.

I agree with renaming this, but finding a good name for it seems to be impossible.

I know what you mean...

Another thing: Is InventoryItem.RunInteraction still a delayed function? If so, it should be noted in the manual.

[Scorpiorus]

Greet job indeed!

* Ctrl+Space now allows you to pop up the autocomplete list at any time, like in Visual Studio.

Sweet!

May I, however, suggest one more thingy about the autocomplete list?

All the names in autocomplete are alphabetically sorted (and that's cool I think, because we can for example group the related properties, variables and functions together by adding a lowercase prefix). But would it be possible to make sorting case-sensitive so that instead of:

cEgo
CentreGUI
ChangeCharacterView
cHero
ClaimEvent
cMan

there would be:

cEgo
cHero
cMan
CentreGUI
ChangeCharacterView
ClaimEvent

I think people will find this useful in getting used to using of pointers (o-names)

"SaveCursorUntilChange" implies that it waits for the cursor to change, but that's not the case. Anyone got any bright ideas?

Mouse.SaveCursorUntilLocationChange ?

A bit unwildy but the autocomplete feature should safe us there