AGS 3.01 wishlist

[Ishmael]

I don't care as much about larger resolutions, but how about being able to specify window size up to the resolution size... like if I want to make a game in widescreen, say to match the PSP 480x272, or smaller like the DS 256x192...
or even if I want a game window that's vertical.

You can already script that, can't you? Well not window size, but playable area size. Using mouse bounds (they still are in, right?) and a 320x200/240 GUI with the game area size hole in it to hide any extra stuff easily...

[Shane 'ProgZmax' Stevens]

The ability to set the Loop number and Frame of an object as you can for characters would be nice and consistent, since I often want to update the frame of an object manually but cannot right now.

[SSH]

As mentioned before, it would be nice to be able to access things like the stack trace in the scripts, like you can in some languages like python. It would allow functional as well as debug stuff, too.

[subspark]

I wish for the ability to tell AGS to ignore unhelpful warnings like "Character (Narrator): normal view 4 has no left/right frames and could crash the game."
In my case the narrator is invisible and need not carry any frames.

Cheers,
Paul.

[SSH]

So why not use the special default narrator character?

game.narrator_speech

    Which character ID to use for voice speech within Display() command. Default initial player character. You can also use NARRATOR which uses 'NARR' prefix - special narrator character.

[subspark]

Whoops Perhaps I should do some reading!

Cheers,
Paul.

[naltimari]

Erm... maybe i'm being a zealot, but shouldn't this other thread be used instead of the current one, as CJ asked?

I've being following the other one, but it seems that this one is getting all the attention.

[Charity]

Only for practical, immediate sorts of suggestions, I think.

Anyway!

Item #1. Tentative suggestion: Would it make any sense to have pointers to functions?

Item #2. And another odd one: What about something like

Code: ags

function String.AsScript(String code)

which would read the String (as it would be displayed on the screen, in the case of characters like % and ") as if it were a line in the script.  Coupled with an input box you could do all sorts of Debug type functions really easily (like getting/setting variables, for instance.)  I'm sure it would also be useful in a ton of work-arounds, though no specific examples come to mind, immediately.

A function that checks whether a given String will crash the game (or whether it would have compiled as a normal, preexisting line of code) would probably also be a handy accompaniment, if not strictly required.

I have no idea if such a function is technically possible or not, but I thought I'd throw it out there.

[Shane 'ProgZmax' Stevens]

Function pointers would be quite useful in some circumstances, yes.  I'm not sure most people would have a use for them, though.

[deadsuperhero]

How about multiple hotspots on characters?

[subspark]

How about multiple hotspots on characters?

Do you mean if the player is clickable you could for instance move the mouse over the character's arm or face and the text name updates based on those regions?

I'm no programmer but I imagine this is a pretty specialized feature that I'm guessing could be coded in per user rather than be added to AGS for all. However saying that, this is an interesting idea and 'Character Regions' could well be something everybody wants!?

Cheers,
Paul.

[naltimari]

From the manual:

Because there is no new keyword, you cannot create object instances.

Well, this certainly isn't true anymore, as we now do have a 'new' keyword, hehehe.... Seriously, creating Objects and Characters dynamically would be a big feature for me.

Another need, especially for module writers, is the ability to use struct pointers inside other structs (allowing complex data structures, or 'object-oriented-ness') and to return custom struct pointers from functions.

I realize this is more likely to be in AGS 3.1 than 3.0.1, but somebody has to ask for it...

[monkey0506]

One of the biggest problems with dynamically-created Objects/Characters/Hotspots/Regions...etc...is that they all have interaction events. If they were created dynamically, how would these be handled?

One solution would be using function pointers. Then we could have something like this:

Code: ags

// internal
managed struct DynamicCharacter {
  // constructors
  import static DynamicCharacter* Create();
  import static DynamicCharacter* CreateFromCharacter(Character*);
  import static DynamicCharacter* CreateCopy();
  // destructor
  import void Delete();
  // set interaction functions
  import bool SetInteractionEvent(CursorMode, (*evtFunc)());
  // etc.
  };

// user-code
DynamicCharacter* egoCopy = DynamicCharacter.CreateFromCharacter(cEgo); // create a copy of EGO

function egoCopy_UseInv() {
  if (player.ActiveInventory == iRottenfish) {
    egoCopy.Tint(0, 250, 0, 30, 100); // used rotten fish on copy of EGO
    }
  }

egoCopy.SetInteractionEvent(eModeUseInv, egoCopy_UseInv);

Of course this would become very cumbersome in practice because you would first have to define the DynamicCharacter globally (to that particular script) then inside some function set it, then define the interaction function outside of all other functions, and then finally inside a different function set the interaction function.

Struct-within-struct support as well as pointer-to-struct support have both been discussed several times before, but AFAIK haven't really been feasible due to internal limitations. Hopefully this new version of the editor will have cleared some of that up.

Clearly pointer-to-struct support (with pointers-to-structs being allowed within custom structs of course ) would be the most flexible and powerful solution in this case. Perhaps now that CJ has finished his revamp of the editor he could take another look at the current status of this request.

[DoorKnobHandle]

Struct-within-struct support as well as pointer-to-struct support have both been discussed several times before, but AFAIK haven't really been feasible due to internal limitations. Hopefully this new version of the editor will have cleared some of that up.

Clearly pointer-to-struct support (with pointers-to-structs being allowed within custom structs of course ) would be the most flexible and powerful solution in this case. Perhaps now that CJ has finished his revamp of the editor he could take another look at the current status of this request.

I know, offtopic (mentioned before), but I just HAVE to throw this in once again: that above would be the only left part of functionality that I miss in AGS... big, big time. Although it clearly isn't necessary for most simple adventure games, especially the new OO-aproach to modules/scripts etc. would hugely benefit.

Anyways, coming back to the topic, I have two small additional ideas/suggestions:

#1: would allowing the user to overload functions like in C++ be possible? This would mean the coder can define functions with the same name where the parameters are different? This can always be worked-around etc. but it'd be nice to have. Example:

Code: ags

// in "Renderer.asc"

function CRenderer::DrawPixel ( int x, int y )
// draws a pixel
{
      // draw pixel using int-type coordinates
}

function CRenderer::DrawPixel ( float x, float y )
// draws a pixel
{
      // draw pixel using float-type coordinates
}

Again, I know this can always be worked around, but I'm just pointing out the elegance of such an approach, I realize this might be low-priority though...

#2: People have discussed different ways of structuring the Script-tree in the side-window thingie, my suggestion here would be to sort by type like this:

Code: ags

- Scripts
      - Script Files
            Renderer.asc
            Tile.asc
            Sprite.asc
            Particle.asc
            GlobalScript.asc
      - Script Headers
            Renderer.ash
            /* etc. */

This is how it's handled in MSVC 6.0 and it seems like a very clean and usable solution.

[SupSuper]

A simpler approach would be to just add Script Folders so everyone can organize their scripts however they wish.

Though at this rate we're gonna end up with folders for everything!

[Pumaman]

Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?

[Joseph DiPerla]

Not continuiing this conversation...

I was thinking of a way to add a certain feature for a game I am helping to program.  Regarding dialogues, can there be an option when you add a dialog option that says "show on all dialogs"?  In other words, we have a "say" option and a "show" option in the editor. But this option would allow that line to be displayed on all dialogs at the bottom. Is that possible?

Another script function I was hoping to get... Actually a few... Are:

AddDialog(DialogName)
AddDialogOption(DialogNameToAddTo, Dialog String, ScriptToRun)
And is there a way to check what the current dialog option is?

These are some crucial items for this particular project I am working on. And it SEEMS (But I know its not as easy as it sounds) that this is not too difficult to add, I hope. The first option is really for convenience, but this can be done, with a lot of coding by just using the script functions I Requested. But at least it would be possible, unless this is possible already.

Thanks for listening.

[CaptainBinky]

Any chance of bringing back support for PCX files?

Only, DPaint Animation only supports PCX and LBM formats, so ditching support for PCX files means an extra conversion stage for every single sprite

Cheers,

CapnBinky

[subspark]

Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?

I like the current layout. There is a purpose for every element of an adventure game production and it's immediately obvious and accessible. I don't imagine collapsing everything up into another folder would aid accessibility no matter how convenient it sounds.
Thats simply my opinion however.

Paul.

[naltimari]

Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?

I think that, as long as we can delete any item (characters, views, fonts, guis, rooms, etc), i'm happy with the current layout.

In AGS 3.0.1 b2, pratically all items can be deleted (if not all), as opposed to AGS 2.72, in which we could only delete GUIs, if I recall correctly.

Besides that, the current folders act as a cue to newcomers that all those elements are part of a 'normal' AGS game, and the designer can, if he chooses to do so, include items under them.