SUGGESTIONS galore

[SSH]

OK, so here's some suggestions for AGS:

It would be nice if each of the inbuilt arrays like character, object, etc all had one or two extra members per item that were read/writeable and available for the use to use as they wished. Ideally, the user could control the number/type and names of these, but even if there were 1, called userdef1, then that would be great. I suppose these are like read/writeable propertty schemas, so it could be doen through that. Or through a way of getting OO extends to work on those builtins

As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.

If the user could define their own things to go on the "General settings" page, someone could write a super-template that the  let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.

OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.

Character editor should show view NAMES when choosing default, idle, talking views, etc.

Also be nice if characters, like GUIs, could have a named handler function

Be good if you could specify whether the dialog GUI goes away after an option is selected, or if it stays. Alternativley, specify a function to be called before and after any dialog

A GUI could have its own on_key_press and repeatedly execute handlers, and it would be nice if a GUI could have a click handler rather than just GUI controls, because lots of GUIs have a regularity to them that means that individual handlers would mean lots of cut-and-paste

[strazer]

Be good if you could specify whether the dialog GUI goes away after an option is selected, or if it stays. Alternativley, specify a function to be called before and after any dialog

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=289
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=380

and it would be nice if a GUI could have a click handler rather than just GUI controls

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=198 ?

[SSH]

and it would be nice if a GUI could have a click handler rather than just GUI controls

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=198 ?

That's not the same. I mean that as AGS 2.7 is adding that individual GUI buttons can have their own script, it would be nice if the GUI as a whole had a script, so that buttons which do NEARLY the same function can run in the old way (e.g. verb buttons on a SCUMM gui)

While we're here, I wish that you could access GUI controls with something like gui[2].item[3]

[Pumaman]

It would be nice if each of the inbuilt arrays like character, object, etc all had one or two extra members per item that were read/writeable and available for the use to use as they wished. Ideally, the user could control the number/type and names of these, but even if there were 1, called userdef1, then that would be great. I suppose these are like read/writeable propertty schemas, so it could be doen through that. Or through a way of getting OO extends to work on those builtins

Well, a cleaner solution here would be to make custom properties changeable at run-time, I think. It has been requested, but not a high priority.

As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.

Yeah, that's a pretty good idea; I can see it coming in handy.

If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.

I suppose an equivalent would be to add a set of Game custom properties, along with GetGameProperty/etc, since that's effectively what you're asking for. I can see the benefits, but again it's a fair bit of work for something that may well not get used very often.

OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.

I agree, script modules is something I'd really like to add. However, there are loads of things I'd really like to add and it's all a matter of time. Once all the object-ising stuff is out of the way, I will give script modules quite a high priority.

Character editor should show view NAMES when choosing default, idle, talking views, etc.

I'd prefer to change it to a proper graphical selection dialog, with a view preview and so on. Again, I'd like to, but I can't promise when.

Also be nice if characters, like GUIs, could have a named handler function

Not so sure about this one ... the interaction editor is there to handle clicks on characters, but GUIs don't have the interaction editor to handle things for them.

Overall, after reading your post I do like and agree with most of your suggestions. However, as always, there is only a finite amount of time and features that can go in, so I'm afraid I can't promise anything.

If anyone else wants to comment on any suggestions from SSH's post that they think would be particularly useful, feel free.

[Gilbert]

[

As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.

Yeah, that's a pretty good idea; I can see it coming in handy.

Or, if it can be made that you can set manually which character's inventory you're displaying on a specific inventory window in a GUI (WITHOUT the need to change to that character) that'll be okay too.

[SSH]

Overall, after reading your post I do like and agree with most of your suggestions. However, as always, there is only a finite amount of time and features that can go in, so I'm afraid I can't promise anything.

Of course. You're doing a great job, CJ, and its only becuase of the great new stuff you've added in 2.7 already that I felt inspired to ask for more! I just wanted to get these in the tracker. Thanks for doing the builtin defines so quickly, btw!

[monkey0506]

As for the dialogs, you can check out my work-around for scrolling dialogs:

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=18466

With a bit of modification, "you could [easily] specify whether the dialog GUI goes away after an option is selected, or if it stays" (SSH). I think, if I understand you correctly, that you would want to do something like:

// RunningDialog(dialog, option)
if (dialog == XXXX) {
  if (option == XXXY) {
    DisplaySpeech(CHAR, "Speech");
    // blah
    SetupDialog(dialog); // turn DIALOG GUI back on
    }
  else if (option == XXYX) {
    DisplaySpeech(CHAR, "More speech");
    // blah
    EndDialog(); // turn DIALOG GUI off
    }
  }

You have to script everything manually with this workaround, but it's a bit more customizable. Just re-setup the dialog if you want to make the dialog GUI "stay", or end it if you don't. I suppose a similar setup would work with the built in dialog system:

// main global script

function dialog_request(int parameter) {
  if (parameter == 1) RunDialog(CURRENTLYRUNNINGDIALOG);
  else if (parameter == 2) GUIOff(DIALOGGUI);
  }

// dialog script
@s
return
@1
char: Speech
// DIALOG REQUEST 1 ?
@2
char: More speech
// DIALOG REQUEST 2 ?
stop

Or something like that. I don't remember exactly how that's supposed to work... Since I scripted that scrolling dialog workaround, I kind of don't recall how the built in dialogs work... Well, let me know if this helps.

[strazer]

I suppose these are like read/writeable propertty schemas, so it could be doen through that.

Well, a cleaner solution here would be to make custom properties changeable at run-time, I think. It has been requested, but not a high priority.

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=191

it would be nice if the GUI as a whole had a script, so that buttons which do NEARLY the same function can run in the old way (e.g. verb buttons on a SCUMM gui)

Why not keep using the interface_click function? I'm not aware of any plans to remove it?

As well as having inventory items, it would be nice if AGS had (at least one) another general purpose item list, which could be used for spells, icon-based dialog options, etc. It would be in the editor like the inv item list where you could set a sprite, cursor hotspot and property schema for each item. Ideally, there would be a generalised tree system where "Item lists" was the top level, with Inv items being a special case and default on the list, but the user could add other lists themselves.

Yeah, that's a pretty good idea; I can see it coming in handy.

Or, if it can be made that you can set manually which character's inventory you're displaying on a specific inventory window in a GUI (WITHOUT the need to change to that character) that'll be okay too.

That would be a nice workaround for now, we even have a tracker entry already:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=245

[Gilbert]

That would be a nice workaround for now, we even have a tracker entry already:
http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=245

Heh, because as far as I remember I suggested it long time ago.

[SSH]

Indeed, there's lots of ways to work around some of the probolems I mention, but I wanted to suggest what I considered as the optimal solution, rather than what might be a way of simplifying a workaround.

[RickJ]

If the user could define their own things to go on the "General settings" page, someone could write a super-template that the let the user change a combo box on the front page from "SCUMM FOA" to "Sierra classic" to "Broken Sword" to get various default game styles.

I suppose an equivalent would be to add a set of Game custom properties, along with GetGameProperty/etc, since that's effectively what you're asking for. I can see the benefits, but again it's a fair bit of work for something that may well not get used very often.

... and you would need the ability to have different schemas for game, character, object, etc.   

OO stuff makes include files or some kind of script module import/export easier to organise and more obviously a gap. At least the single-GUI import/export that I already mentioned.

I agree, script modules is something I'd really like to add. However, there are loads of things I'd really like to add and it's all a matter of time. Once all the object-ising stuff is out of the way, I will give script modules quite a high priority.

Oooooo baby I can't wait

Character editor should show view NAMES when choosing default, idle, talking views, etc.

I'd prefer to change it to a proper graphical selection dialog, with a view preview and so on. Again, I'd like to, but I can't promise when.

I know I am, more or less outspoken on this issue, but I have a somewhat different way of looking at this; It seems to me that animatable entities such as characters, objects, etc should own their own views.  The main objection seems to be that if this were the case views couldn't be shared.   I am not so sure this has to be the case anymore with the new scripting methodology.   

For example suppose that the editor for each of the animatable entities (character,  object, etc) had a View Editor tab.  Only the views owned by the animatable entity (i.e. character, object, etc) would be listed.   Views would be named and numbered much as they are now, except that numbering would begin from '1'  for each entity.  The names would have global scope and be enums (i.e. vEgoWalk).   The enum value then would be what is now the global view number.   
We would end up with each animatable entity having a property array called View.  The array index then is the local id number.  The value contained in the array element is the enum value  (i.e. what is now the view number).  For example if we define a view named vEgoSmile for character Ego we could do something like this:

   // We used the view editor to define Ego's view number 7 to be vEgoSmile.
   // This means that Ego.View[7] is equal to vEgoSmile.

   // To assign this view to Ego's thinking view we could do this ..
   cEgo.ThinkView = vEgoSmile;

   // or we could do this.
   cEgo.ThinkView = cEgo.View[7];

   // Now suppose we wanted to assign this view to Bob's thinking view, again this ...
   cBob.ThinkView = vEgoSmile;

   // or we could do this.
   cBob.ThinkView = cEgo.View[7];

   // And just to be clear cBob.View[7] is not equal to cEgo.View[7]. 

SSH's original suggestion, in this case can just be a drop list as he suggests or a right click menu in the view editor.  The current global View Editor (if desireable) could show and allow edits on all views as it does now, with the only difference being in the way views are named and numbered, using enums instead of name and number.

Sorry for the long post, didn't know how to express the idea otherwise.  Hope you find it.  I know it's a lot of work to implement so I understand if it never gets done.   
Cheers everyone....

[Pumaman]

It seems to me that animatable entities such as characters, objects, etc should own their own views.

I see where you're coming from on this one. I guess it would make things easier since you wouldn't have to remember that Ego's swimming view was view 145, but rather that it was ego.view[2].

But views do have (old-style) script names now at least, so it's not as bad as it once was.

What you're suggesting could probably be implemented by allowing you to link views to characters in some sort of character view list -- so they'd still all exist in the main VIews pane, but the character could have a list of relevant ones, perhaps.

Again, this won't happen for 2.7, but it's an interesting thought for the future.

[Joseph DiPerla]

I was thinking something similar to gilbot for the inventory items...

Why not allow next to each item to put an item type number. Eg 1, or 2, or3 etc...

When you put an inventory window on a gui, you specify in a text area which item types to display, 1, or 2, or 3 etc...

[Scummbuddy]

Here comes a suggestion really not on par with the previous ones in this thread....

Could you add the ability to copy the additional background frames to clipboard? We have the ability for the current main bg, but not the animating ones.

[strazer]

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=177

[Scummbuddy]

I knew I should have looked there.Ã,  Ã,  Thanks. Won't happen again.

[strazer]

Hey, no prob.
I just posted it so you can write your comment in there.

If we had some kind of voting system for tracker entries, I'm sure more people would actually read that list...

[Gilbert]

While we're at suggestions, I was suddenly inspired, that since we can have dynamic ingame sprites now, it may be useful to have the following function:

CreateSpriteFromBackground(int x1, int y1, int x2, int y2);

Which will snap the rectangular area (defined by the corners (x1,y1) and (x2,y2) ) of the current background frame (i.e. no need to care about if there're objects, characters on top of it) into a dynamically created sprite (returns sprite number like LoadImageFile() ).
This is useful in the sense that for example, if you want to draw some simple polygons ON TOP of the screen, you can make the room larger, with some areas that it'll never be scrolled to (hence invisible), you can just do whatever raw drawing on that offscreen part of the background, and then use this function to grab that area as a sprite, so, viola! we can display that sprite as an overlay, object, etc. now.

Furthermore, since the engine can save graphics as BMP or PCX format already (check SaveScreenShot() ), it may also be interesting if we can save a sprite as a graphics file, like for example:
SaveSpriteToFile(12, "face.pcx");
This is useful in places like for example you can pixel paint your face in a game then save it for later use (or for example save the face made in Esseb's good old Perpentrator for fun ), etc.

These are not important things, and are just sudden ideas, so I don't really care when they'll be implemented or will they ever be implemented at all.

[SSH]

If you're going to use it for savegame with srceenshots thumbnails, then you need to have the ability to scale the sprite to whatever size your thumbnails will be.

It would be nice to be able to crop dynamic sprites, too. For example, if you want to cut a GUI off of a savegamescreenshot. Maybe the cropping could be done before the screenshot is added to the game, with game.screenshot_area_left, game.screenshot_area_right, game.screenshot_area_top and game.screenshot_area_bottom.

[strazer]

What you're suggesting could probably be implemented by allowing you to link views to characters in some sort of character view list -- so they'd still all exist in the main VIews pane, but the character could have a list of relevant ones, perhaps.

Again, this won't happen for 2.7, but it's an interesting thought for the future.

Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=498