AGS 3.02 Wishlist

[Baro]

I've noticed that in 256 color games, the outline fonts are black, the default buttons are grey, etc, but if you modify the pallete, they still pick the same color indexes (and I had to adapt my pallete to that, otherwise the outlined fonts used wrong colors). There should be a way of telling AGS what indexes to use in these cases.

[SSH]

My walkcycle generator is now being adapted to run in 1024x768 mode, but some people may prefer 800x600 or 640x480. The code is written such that any of these modes should work, so it is a shame that this cannot be selected at runtime or at least in the user config: what it is compiled with is fixed so I have to give people 2 or 3 versions of the compiled exe...

[Sektor 13]

**Hi**

1. I was wondering how long can hotspot name be , now that the 30 characters limit is removed

2. Is it possible to add option for the font "auto-outline" to choose the outline color (i would need white color instead of black).
And to add outline thicknes (now is only 1 pixel). -> for TTF fonts


thanx

[Lt. Smash]

I would like an inbuilt audio/video manager, were you can put your files in. Using the manager you can play audio/video.
And it would be nice if videos would also be compiled so there is no need to put them into the compiled folder.

[monkey0506]

My walkcycle generator is now being adapted to run in 1024x768 mode, but some people may prefer 800x600 or 640x480. The code is written such that any of these modes should work, so it is a shame that this cannot be selected at runtime or at least in the user config: what it is compiled with is fixed so I have to give people 2 or 3 versions of the compiled exe...

Couldn't you use the System.ScreenHeight and System.ScreenWidth properties?

Oh wait...I see what you mean...funny...I always for some reason thought you could choose to run high-res games in a lower resolution...

[Khris]

Before 3.0 it was possible to add two RunScript actions to an event which wasn't really useful other than to execute more code after a dialog.
Could this be brought back in some form to avoid having to use the bad workarounds (use Global Ints / clutter up dialog_request)?

I was thinking of being able to manually put e.g. "cBobTalk; cBobTalk2" into the event linkage page.

Would that make sense?

[Shane 'ProgZmax' Stevens]

I'd just like to bring back my suggestion of a visible color rectangle next to the character's text color setting that can be clicked on to quickly bring up the color wheel.  That way you can 'see' the color you've selected right away in the property pane and alter it more easily.

I'd also like to see a font property added to characters so each one can be given a unique speech font.  There are a few times I've wanted certain characters to have a different font but found it too unwieldy (having to switch the main font back and forth each time a different character is talking).  I don't think this is a high profile request, but I do think some people would find it useful.

[Sektor 13]

What about "shaded" fonts like in Simon the Sorcerer (fonts were brither at the top and darker at the bottom) ?

[zabnat]

I haven't read the whole thread and haven't tried out the 3.1 so these might haven been implemented and/or requested before. But here is a peace of my mind:

General:

• All changeable properties to the editor. Like Object.Visible etc. so you could more easily change the initial state of thing. I understand that this may make the list of variables bigger, but maybe this could be an option in preferences to use "advanced mode" or "simple mode".
  
• Dynamically changeable custom properties. This would help lot of things. As well as dynamically changeable hotspot descriptions etc.
  
• Double clicking a tab should close it. This would help the management of tabs a lot.
  
• Separate editor colors for hotspots etc. I stumbled to this while making the Retroron game. As I had only four colors in my palette, and everything else was black. So while editing the hotspots every hotspot except the first four was black. So the editor should use its own internal palette for this so you can enjoy pretty colors of your hotspots if you like to turn off the "Show non-selected masks greyed out"
  
• Clickable walk-to point for hotspots and walk-to point for objects. I'm not sure if 2.72 had this, but I do somehow miss it.
  

Script

• Code folding. This would be a really great feature, especially when your script glutter with functions.
  
• Auto prototyping. As I'm used to program with higher level languages, I'm really annoyed about the fact that I can only use functions I've written above where I want to use them. I can't see the benefit of this, but I can see the benefit of autoprototyping all the functions in the script, so you can decide how to organize your code.
  
• Closing bracket indentation when pressing enter. Everytime you press enter after entering a closing bracket or moving the cursor after closing bracket and pressing enter the bracket moves left one tab. This would be great if you were able to write the code like just copying the whole thing out of head. By I can't. So I always write like this: function foo(){} -> function foo(){ dostuff(); } -> etc. So in my opinion this feature is more trouble than benefit.
  
• Autocomplete should close when user has typed in the keyword. This has annoyed me some. When for example I want to do same operation for variables rgbR, rgbG and rgbB, I make the line that does it for rgbR, duplicate the line and change the variable names to rgbG and rgbB for other lines. But when I change R to B the autocomplete comes on and doesn't disappear, even though I've just written a variable name completely and there are no other options (for example a rgbBB variable) in the list.
  
• Management of script/interaction functions. I somehow feel that all the interaction functions really glutter the script and the way they are created they tend to be all around the script file. So a better option would be more accurate analyze of the script when adding the interaction functions to the script. Usually you'll want your objects interaction scripts in one place. One option for this would be putting them all in one function like: function object1_interaction(int what){ if(what == eModeInteract){ } else if(what == eModeLookat){} }. Or you could use those #sectionstart object1_interactions tags around the different interaction functions for that object. This feature with already meantioned folding feature would help the management of script a lot.
  
• Exports at the bottom. Since exports are supposed to be at the bottom of global script they should stay there. So when I add interaction for inventory item or character, their functions should be created before the exports.
  
• Hashtables + dynamic arrays. This a pretty long shot as these usually belong to higher level languages. But there has been a lot of instances that I would have benefitted greatly if I had these. But for now I have found a way (if sometimes clumsy) to overcome this. And by dynamic arrays I don't mean the ones that declare the size at runtime but the ones you can pop, push (un)shift and splice.
  

I know I'm a little hard to please, but after all this is a wishlist, not a demand list . I still have some other things in my and when I'll be able to write them down I'll post them.

ps. has there been any discussion about using a existing scripting language instead of the custom one AGS has now? I know this would be a really big change and would probably put off all the non-programming-types who have just learned their way around the script. But incorporating a existing language such as Python would bring all the high-level functionality of that language for free (for example hashtables and lists).

[Khris]

About your third and second to last points:

-You can call ProcessClick(mouse.x, mouse.y, eModeInteract); after a left click, then check for mouse.Mode in whatever_Interact(). Just fine-tune this method to your needs.

-exports are best put directly after the declaration. (They don't have to be at the bottom.)

[Makeout Patrol]

In the "general settings" pane, there is an option called "Allow speech to be skipped by which events." I think it would be great if setting game.text_speed to 0 had the same effect as setting this general settings option to "mouse & keyboard only" rather than crashing the game, as is the case right now. I would really like to give players the option to choose the setting they want for this particular option.

[zabnat]

-You can call ProcessClick(mouse.x, mouse.y, eModeInteract); after a left click, then check for mouse.Mode in whatever_Interact(). Just fine-tune this method to your needs.

Yes, but it would be easier if this was done for me by the editor when clicking that ... button on events. But I think with folding the #sectionstart way would be better.

-exports are best put directly after the declaration. (They don't have to be at the bottom.)

I might have to disagree. I'm not sure if this has been changed in version 3, but I recall I had problems with this in 2.72.
If you do (not a working code):

int foo = 1;
export foo;
foo = 2;

Then in room script foo == 1. I'm pretty sure this was the case as I did have some problems with this.

[Gilbert]

I'll say there's no 'best place' where exports are to be put, as long as they're after the declaration it'd be okay.

I remembered the manual did advise putting them all at the end of the script, this guarantees that stuff won't go wrong but you cannot see the correspondence immediately.

Putting the exports immediately after the declarations give you the idea of the variables immediately but can be a mess if you don't organise your codes well and stuff are scattering around.

Whichever approach one chooses is down to personal choice (so, Khris, no, though personally I perfer putting the exports immediately after the declarations also).


But zabnat, the example codes you posted are not quite right, because the last 'foo = 2;' line is an assignment. It must be inside a function.

If the codes you posted are to be outside of a function it would just cause a compiler error because of the assignment; if it's inside a function the variable foo will be destroyed after the function ends anyway (which I'm not sure, that you probably get another compiler error anyway as there's an export inside a function). So I don't think the codes can illustrate whether there is a problem (AFAIK putting the exports immediately after declarations should work).

Unless what you're mentioning was:

Code: ags

int foo = 1;
export foo;

function blah(){
  foo = 2;
}

If blah() hasn't been called yet it's understandable that the room script will receive 1 as the value of foo.

[Khris]

Of course it's down to personal choice, but the only two sensible options are after the dec or at the very bottom. And the second option is bad because add another character or inv interaction and you'll have to move stuff around. Putting them after the declaration is nice'n'tidy and of course will work fine.
So I'd actually go as far as to say yes, it is the best way to do it. IMO.

[Shane 'ProgZmax' Stevens]

A description category for gui controls would be nice, as long as @overhotspot@ could pick them up. 

[zabnat]

But zabnat, the example codes you posted are not quite right, because the last 'foo = 2;' line is an assignment. It must be inside a function.

If the codes you posted are to be outside of a function it would just cause a compiler error because of the assignment; if it's inside a function the variable foo will be destroyed after the function ends anyway (which I'm not sure, that you probably get another compiler error anyway as there's an export inside a function). So I don't think the codes can illustrate whether there is a problem (AFAIK putting the exports immediately after declarations should work).

Unless what you're mentioning was:

Code: ags

int foo = 1;
export foo;

function blah(){
  foo = 2;
}

Yes, that is why I wrote "(not a working code)" . But ok, I tested this and it does export it correctly. I'm not sure what kind of problems I had, because it's been over a year so I can't remember. Maybe it was related to something else then. So maybe I'll start exporting them after declaration then.

[DoorKnobHandle]

I just got an idea, how about giving AGS's users the ability to import bitmap-fonts?

In addition to the possible font-types right now (such as importing *.ttf-files), we could choose to import a font using a sprite (this sprite works like all other sprites that we import into our games, it consists of a transparent background and all characters, similar to how normal fonts are presentated in AGS at the moment). I would picture it working something like this: once the option to add a new bitmap-font is selected, a new dialog will pop up reminiscent of the sprite import dialog, with a button allowing the user to select a simple sprite from the hard-drive and then allowing her or him to either a.) set up a character width and height (a grid will be drawn over the selected sprite for the user to confirm her or his input) or b.) to draw several selection rectangles (similar to the ones you draw for importing a portion of a sprite) defining where what character is. Of course, that last step (either a or b) is necessary in order to tell AGS from what part of the bitmap it is going to read the characters for the font from.

This would allow fonts that use characters which are hand-drawn one by one using more than one color. People could also add in shadows via alpha-channel manually or outlines etc. All of this is somehow "workaroundable", but I still believe this feature would make a great addition to AGS. One thing that has to be considered is that, unlike normal, one-colored fonts, bitmap fonts already would have the color pre-defined. So, if you change the color in the code (by calling the SetFontColor ( )-function or whatever its equivalent is called right now or by letting a character use it for speech and then having set up a speech color) it's not quite clear how that would work best.

I'm a little uncertain about this at the moment, just wanted to throw it out there.

[SSH]

You mean, like my SpriteFont module? 

[Ghost]

Dear Santa CJ, for the next AGS I'd like:

Changing the numbers of views just like you can already change the numbers of   rooms. Helpful when you wish to keep sets of animations in a certain order- when a folder just isn't enough.

Allowing a right-click on a room's tree entry to quickly change that room's name, as it is possible for views.

I also would love to the the "show outline" and "lock position" options for GUI controls back in a future version.

Totally trivial, but really nagging me: The commands to tamper with the player views:
player.SetIdleView(x, y);
player.SpeechView = x;
player.ChangeView(x);
A consistent set of commands would look so much neater- though I admit that this really is a trivial request.

[Makeout Patrol]

I'd also like an option to have text-only buttons, if that's possible; if I set the button graphic to the transparent one, I end up with the default button picture, when I just want to have text buttons that change colour when you mouse over them.