AGS 3.3 Wishlist

[G]

Hi there!

I don't know if this has been asked for, but while using the room editor y like to use the "eraser area" to fix little imperfections in walk-behinds, walkable areas, hotspots and all the like. But when i use it a warning pops up from the point I click on that says "You are currently using the eraser. To draw new areas change the selected area number" And it is nice to be warned about that, but please, could it be placed somewhere around instead of over the place I'm erasing? It's quite disturbing.

Thank you

[Vince Twelve]

Ooh, I agree with G!  That always annoys me too!

[Trent R]

Personally, I never use the eraser (hotspot 0, etc). I just use the right click if I have to remove something.


~Trent

[Khris]

Apologies if this has been mentioned already in this thread:

I'd love for the room editor to have checkboxes to switch on and off what's displayed.
E.g. when drawing regions, I'd be able to see my walkable areas at 50% opacity.

[RickJ]

When the editor opens a game made with an older version it would be nice if the message say what the older version actually is instead of having to guess.

I would be even better if the user was asked if he would like to open the selected game in that older version or at least asked if he would like launch that older version (provided the older version was installed) 

[Ryan Timothy B]

Pardon this if it's already part of 3.1.1.

It would be really nice if the scripts were independent from the room editor.  It's a pain having to open the room editor for each and every room making you have to use the Events pane just to add, for instance, the event where the character leaves a room.

I feel if you add it in the script (typing it manually) the room should check for the functions and update itself.

[Gilbert]

I feel if you add it in the script (typing it manually) the room should check for the functions and update itself.

The problem is, you can change these functions to whatever names you like, though there are sorta default names for these functions. If for some reasons (though this rarely happens) you want to use these "default" function names but don't want to link them to events it would be annoying to have the editor act "smart". Moreover, if you want to use another name for a certain event function, you still need to change it in the Events section anyway.

There are exceptions though, that functions like repeatedly_execute_always(), on_key_press(), etc. still need to be typed in manually (I think, correct me if I am wrong) and they'll be used automagically if you typed them correctly in the room scripts. However, you can't change their names and they're not linked to any events in the editor.

[RickJ]

Quote from: Ryan Timothy on Today at 09:01:45pm
I feel if you add it in the script (typing it manually) the room should check for the functions and update itself.

What Ryan is saying is that he would prefer to edit the script file rather than doing pointy and clicky stuff in the properties pane.   

The problem is, you can change these functions to whatever names you like, though there are sorta default names for these functions....

This is not really a (the) problem.  There are lots of reserved words and built-in functions in AGS already and all Ryan is suggesting is that there be a few more.   

The problem is that in some cases one may want to use the same handler function for multiple events.      For example one could create a module to handle an extended verb/cursor modes (a la Lucas Arts) where there was just one handler function that decoded the verb and responded accordingly.  This is not uncommon with modules created to service GUI events.

A script based interaction system is of course possible and could be implemented a number of different ways.  It would AGS easier to use for some.  However, eliminating the pointy an clicky system would make it more intimidating and difficult to learn for others. 

[Shane 'ProgZmax' Stevens]

I think I suggested this a long time ago, but I think it would be highly useful for most people if there was a property for characters that let you specify their own speech font number, which AGS would internally switch to during the say functions.  This would save tons of time for people who want to display a range of fonts at different times, since they could just have blank characters with the fonts they want.  This would also add a touch of individuality for different characters, especially for the Lucasarts style since there aren't portrait pop-ups.

Aside from my earlier suggestions, I think the only other thing I'd like to see would be the ability to visually place characters in a room so you can see exactly where they will appear in the game rather than having to mess with coordinates until you have them right where you want. I'm not sure how difficult this would be, but since you already have the code in place for displaying objects you could probably just create an extension to the objects that would display characters in much the same way based on their normal view, right?

[Gilbert]

What Ryan is saying is that he would prefer to edit the script file rather than doing pointy and clicky stuff in the properties pane.   

I understand. But the pointy and clicky stuff was just when you add an event to the room. You can always edit the script directly for changes afterwards. If we want the editor to be able to recognise all the function names and add them automatically to events after closing the script we may need to have the names of all these functions fixed (which IMO is not a bad thing but that would change the current feature of the possibility of using different names).

The problem is that in some cases one may want to use the same handler function for multiple events.      For example one could create a module to handle an extended verb/cursor modes (a la Lucas Arts) where there was just one handler function that decoded the verb and responded accordingly.  This is not uncommon with modules created to service GUI events.

Well it's not really difficult to handle if you want multiple events to have the same function called, just do something like:

Code: ags

function blah(){
  //blabla
}

function event1(){
  blah();
}

function event2(){
  blah();
}

A script based interaction system is of course possible and could be implemented a number of different ways.  It would AGS easier to use for some.  However, eliminating the pointy an clicky system would make it more intimidating and difficult to learn for others. 

Agreed. IMO we can't remove the insert-function feature in the Events pane (the removal of the Interaction editor is already a pain to some new users) as not many people can remember all the function names well and may prefer to have the editor add them rather than typing in stuff themselves. So, it must be two sided, i.e. you should be able to add functions via clicking in the Events pane in the editor and the script parser should be able to recognise functions and add them as events at the same time.

[Snarky]

I'd like for old saves to work even after you change settings in winsetup, please.

[Khris]

I think the only setting that affects savegames is a change of resolution, something that's not possible with the latest versions anyway (and was a bad thing from the start, IMO, and also became pointless since the filters were introduced).

[RickJ]

I understand. But the pointy and clicky stuff was just when you add an event to the room. You can always edit the script directly for changes afterwards. If we want the editor to be able to recognise all the function names and add them automatically to events after closing the script we may need to have the names of all these functions fixed (which IMO is not a bad thing but that would change the current feature of the possibility of using different names).

That may work out ok for room events but I think it would not be as nice for GUI events, and especially for GUI support modules.   

If function pointers were possible then it would be stright forward to have a property that contained a pointer to the actual handler function.   Such properties could then be set either by pointy/clicky method or an assignment statement in the script.   So the above example would end up looking something like the following. 

Code: ags

function blah(){
  //blabla
}

room.LoadRoom = *blah();
room.LoadFirst = *blah();

Reserved function names could also be used as defaults as you suggest.  For novice scriptwriters everything would be nearly the same as it is now.  Being able to change this via script not only offers a convenience to some but also provides an opportunity to do things currently not possible.

[Ryan Timothy B]

Yep that's pretty much what I meant, the 'point clicky' as you call it.

At first I didn't know this was a mandatory thing, doing the whole pointy clicky to add common events.  I had copied a script from another room.  Kept playing the game over and over and reviewing my script trying to find out why nothing was working, yet it worked on the other room (I believe the rep_exec worked, just not room load, or before fade in).  I was ready to give up and delete the room thinking it was some kind of glitch, then realized I didn't touch the damn properties pane in the room editor.  Doh.
I think that moment sucked up at least 10 minutes of precious programming time.  lol

[Rulaman]

1. I suggest to make the Sound and Music folders 'path selectable'.

It is annoying, when you have many games of an series (e.g. german MMM) and have to copy the musics and sounds to all the game folders.

An option in the General settings would be nice to set the search-path for this folders. So you have to have only one folder for some games of the same kind and don't have to copy this.

It is the same thing when you put your games under source control. It duplicates the same binary files...

Sure, disk memory isn't such as important as it was in the past. But do you save your documents in several folders to have it twice or more, only because you have the memory?

2. Its more an idea than a real suggestion.

Include a Pre- and post-compile option to the Editor. So you can include a batch-file and copy the compiled game to an ftp-server, check-in all files when you compile (F7, and not F5) or make other things. You could even update the 'Version.asc' with an string and show ingame the exact version of your game (e.g. 1.2.79123).

3. Idea too

Deliver two reg-files (e.g. simple-Interface.reg and Expert_Interface.reg) to make some features (e.g. the upper named) for experts, due to confising new users.

[Rocco]

At least 2-dimensional Arrays.
Missed that very often.

[Nickydude]

Sorry if this has been asked, but an extra perimeter to the .Say command to specify the time the text is displayed on screen:

cCharacter.Say("Stay on for 3 game cycles",120)

So shorter texts can stay on screen longer. If left off, just use the default speed 

[monkey0506]

Game.SaveGameFileExtension

Currently (AFAIK...and I've been looking for over an hour) there's no way to retrieve the extension set up for save game files. This is important if using enhanced save games and trying to use a custom function to list the save files instead of just ListBox.FillSaveGameList. Basically I'm storing additional information about the save game files in an external DAT file and the only way to properly update it is to know the exact file names in use.

Actually I was just being daft. I'm using a ListBox in my custom function, so I can just use ListBox.FillDirList and agssave.* :

Sorry if this has been asked, but an extra perimeter to the .Say command to specify the time the text is displayed on screen:

cCharacter.Say("Stay on for 3 game cycles",120)

So shorter texts can stay on screen longer. If left off, just use the default speed 

That's actually the reason I wrote the PersistentSpeech module. I believe the link is currently broken (most of them are!) But I do have all my old files back now (yay!) so if you're interested I'll see about getting an updated version of that released.

As a matter of fact it's well in need of an update as it's still using a structure approach instead of the new beautiful extender methods...No promises but you might see that before the new year. If not, I'll say definitely within the next month.

[Nickydude]

if you're interested I'll see about getting an updated version of that released.

You betcha! Thanks M0506.

[monkey0506]

That was relatively simple.