Adventure Game Studio

Thanks again for 3.0.1 CJ, it's fabbo! :) Since there was no suggestions thread yet and I had one I thought I'd make this, hope that's okay!

A few times I've buggered up the game slightly as I've now become reliant on the source control feature,  but the acsprset.spr file and alike aren't handled under source control so if I try and save after adding sprites, at best the changes don't happen and I have views pointing at invalid sprite numbers. If when I edited the sprite folders in any way it requested I checked out the relevant files that would be fab. :)

Also, and low priority one this, if there was a way to block out the DX5 option in games that rely on the DX9 interface, that would be great. A couple of times team members have been getting broken versions of the game and it has turned out their settings have somehow ended up on DX5. No biggie for now but for release it could cause a lot of problems.

Thanks again!

lemmy

Is there any way to know which sprite is used or not?
If it's possible it could be a nice feature for size/optimization  :)

Quote from: lemmy101 on Thu 24/04/2008 14:11:48
Also, and low priority one this, if there was a way to block out the DX5 option in games that rely on the DX9 interface, that would be great. A couple of times team members have been getting broken versions of the game and it has turned out their settings have somehow ended up on DX5. No biggie for now but for release it could cause a lot of problems.

I just started out with AGS plugin-development (and I'm not writing a .NET but a "normal" one), but can you not use GetGraphicsDriverID ( ) and then compare the returned string (pointer to const chars), strcmp ( ) it and then - if the user is running the DirectDraw 5 driver - abort using AbortGame ( ) and tell the user to use the D9D one instead?

EDIT: Oh, and there's a thread already... It's HERE (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33578.160)... :p

Nice catch thanks I'll add that! :) though being able to disable DX5 option totally would be the better option I guess this makes it even lower priority ;D

QuoteA few times I've buggered up the game slightly as I've now become reliant on the source control feature,  but the acsprset.spr file and alike aren't handled under source control so if I try and save after adding sprites, at best the changes don't happen and I have views pointing at invalid sprite numbers. If when I edited the sprite folders in any way it requested I checked out the relevant files that would be fab.

The problem is that the acsprset.spr file is large, and can easily be over 100 MB in bigger games. Most source control systems have trouble with files that big, and could become extremely slow.

However, I guess I could add an option to add the sprite file to source control and then you could use it if you wanted to.

QuoteIs there any way to know which sprite is used or not?
If it's possible it could be a nice feature for size/optimization 

You can use the "Show Usage" option on the sprite for a start -- but it's not really possible for AGS to check all your scripts and work out whether the sprite might be used in them or not, so it's impossilbe to verify this for certain.

Quotethough being able to disable DX5 option totally would be the better option I guess this makes it even lower priority

I take your point -- but there are easy workarounds like coding the plugin as suggested by dkh, or even just putting a line in your game_start to check System.HardwareAcceleration.

That's cool, thanks CJ! :)

I gotta say, really high on my wish list is the ability to change custom property values during runtime.

Or, if that's too hard/not happening any time soon, maybe we could get something along the lines of a built-in String property on everything (like character[].flag, object[].flag, etc.) that we could use for whatever.

I would fall in love with that feature.

EDIT: Second highest on my list would be to have a dialog.GetOptionText function.

Well actually what i wanted in my wishlist is already there. So thanks CJ.

Just moving my suggestion from my old list... Also SSH is running a voting poll for most wanted features. Should all check out his blog site...

Anyway, not sure if these are  3.0.2 or 3.0.3 or a 3.1 suggestions, but I would love to see this happen: From Rulaman:
- multiple speech.vox (or music.vox)
i.e. speech.en, speech.de, speech.es (or german.spf english.spf, ...)

- sprite-en.pack ( contains some sprites, shown in-game that was translated )
i.e. in-game a sign shows "Le Bakery" and in the translated version "Bäckerei" [graphical translation]

My suggestions: 1024x768x32 resolution. - Not having to resize images and keeping it at this resolution would make it a crisp looking background. Its easier for me to make a background in a 3d editor (That I made myself) and save it in that resolution.

And the next and last for now:
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.

I'd rather see the way dialogs work be overhauled than to keep adding functions to the existing system.  Being able to command dialogs from a regular scripting interface that allows you to make function calls and modify data without hopping to another script would be far more powerful and useful!

Quote from: Pumaman on Thu 24/04/2008 19:09:02
The problem is that the acsprset.spr file is large, and can easily be over 100 MB in bigger games. Most source control systems have trouble with files that big, and could become extremely slow.

acsprset.set being this big black monolith not only complicates versioning, but it somewhat undermines team work, beacuse it prevents two guys from working on different parts of the game at the same time.

Since it's a binary file, changes can't be easily 'merged'. Well, some can, but some can not. OTOH, Game.agf, being a text file, can be automatically merged, or manually, since it's human-readable, so we can always copy&paste on it. But acsprset.spr is binary, so we can not do this.

I would dare to say that the real solution to this would be to stop depending on acsprset.spr altogether, and start building the sprite index based on the filesystem. After all, the sprite files themselves could be added to version control.

I know there would be many consequences to the engine/editor, but that would be the right way to go. Maybe there is a 'in-between' solution, making acsprset.spr just a 'pointer' to files on the filesystem...   ???

I'd like to be able to export CHA files easily from my walkcycle generator. I can see two ways of doing this:

1. A Character.Export(String filename) function
2. AGS editor can import some kind of new CHA-like format that is easy to generate by concatenating some dumped BMP files or something

I'm still jonesin' for a sound and music overhaul.

-At least two music channels.
-Playing music or sound returns the channel the sound is being played on.
-Ability to change the volume of each channel individually from 0 (silent! which we can't currently do with music!) to whatever the max volume is (100 or 255).
-Ability to get the volume and current music/sound number playing on each channel.
-Ability to get the current millisecond of the track playing on each channel and the remaining number of milliseconds, if possible.
-Ability to start playing a track at a certain millisecond without a loud hiccup (if possible)

Aside from the track volume, the volume modifiers need to be fixed.
-Room sound/music volume (from 0 to 100).  This plays all channels at x percent of the channel volume.  So a room volume of 0 would make all channels silent, and a room volume of 100 would play them all normally.  Only affects channel volume when player is in this room.  (it could go over 100 too, i suppose)
-Global sound/music volume (from 0 to 100).  Same as room volume, but for the whole game.  This would likely only be set by a slider in the game's options, for example.

I second Vince's suggestions. The volume functionality is confusing and definitely needs an overhaul, and I'm glad that someone else also saw the use of millisecond (and remaing) timings of other sounds than music.

With the risk of sounding obsessive, I'd also like to restate my wishes for widescreen support (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33896.0) and a DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33578.msg442748#msg442748). The latter may seem like a minor issue to most users, but it's very important to me so that I can convert my RawDraw scripts to DrawingSurface routines.

As for the widescreen support, the sooner this issue is cleared up, the better. Currently I'm holding back on importing more art until I know if I should continue developing in 640x480 or need to switch to 640x400 if I want my game to look nice on widescreen laptops.

QuoteI gotta say, really high on my wish list is the ability to change custom property values during runtime.

This has been asked for in the past, but I've steered away from it because saving the state of all the custom properties could bloat the save game sizes. But I'll take another look at it.

Quote
Or, if that's too hard/not happening any time soon, maybe we could get something along the lines of a built-in String property on everything (like character[].flag, object[].flag, etc.) that we could use for whatever.

Well, you could use extender functions to add your own character[].GetFlag/SetFlag methods, so I'm not sure how necessary this is?

Quote- sprite-en.pack ( contains some sprites, shown in-game that was translated )
i.e. in-game a sign shows "Le Bakery" and in the translated version "Bäckerei"

QuoteI'd rather see the way dialogs work be overhauled than to keep adding functions to the existing system.

QuoteI'm still jonesin' for a sound and music overhaul.

QuoteAs for the widescreen support, the sooner this issue is cleared up, the better. Currently I'm holding back on importing more art until I know if I should continue developing in 640x480 or need to switch to 640x400 if I want my game to look nice on widescreen laptops.

I agree with the need for all these things, but obviously they are all fairly major changes and realistically there won't be time to do all of them over the next year or so. So I guess the question is, which of these things are relatively easy to work around, and which really needs to be implemented into AGS?

Also, 3.0.2 is going to be a minor release so please don't expect any major overhauls like these to be in it.

Quoteacsprset.set being this big black monolith not only complicates versioning, but it somewhat undermines team work, beacuse it prevents two guys from working on different parts of the game at the same time.

I'm starting to agree. Potentially the acsprset file could be the "compiled" result which is generated by the editor by merging together the various image files when you compile the game. The problem with that though is that it could really slow the compilation down if it was having to reconstruct the file all the time.
So I do see your point, but I haven't thought of a better alternative yet. Perhaps simply adding the right-click "update this sprite" option to re-import it from its source image would be a reasonable workaround.

QuoteI'd like to be able to export CHA files easily from my walkcycle generator. I can see two ways of doing this:

1. A Character.Export(String filename) function
2. AGS editor can import some kind of new CHA-like format that is easy to generate by concatenating some dumped BMP files or something

Well, I don't want to bloat the engine with code to export CHA files, since this is quite a specialized request. Perhaps the best option here would be for the walkcycle generator to dump some set of BMP files (or whatever) and then have an editor plugin that could import them and make a character.

Would an option to have everything in native co-ordinates (i.e. a 640x400 coordinate system rather than 320x200 when you use 640x400 mode) be a major or a minor thing?

Surely all you need to do is take out a few "x/=2; y/=2;" statements ;)

And yes, my request is a bit specialised. You never get if you don't ask, though...

Quote from: Pumaman on Tue 29/04/2008 11:44:59
I'm starting to agree [...] The problem with that though is that it could really slow the compilation down if it was having to reconstruct the file all the time.

A solution would be to cache the acsprset file, and recompile it only if one of the sprite files is modified (or 'full build' option is chosen). This is done with .h headers in C/C++ compilers (and the feature is known as 'pre-compiled headers')

Quote
Perhaps simply adding the right-click "update this sprite" option to re-import it from its source image would be a reasonable workaround.

That would be very nice to have, but as long the above one is implemented, this one is unnecessary.

This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

The two things are important, in my point of view. The second one is a 'time-saver', but it does not change the fact that two people can't work at the same time on the same game. The first one solves this problem, and also the nuisance in modifying walkcycles, animations, etc.

QuoteWould an option to have everything in native co-ordinates (i.e. a 640x400 coordinate system rather than 320x200 when you use 640x400 mode) be a major or a minor thing?

Well, I was kinda including that under "overhaul of the resolution system" along with the widescreen stuff, but I didn't really make that clear.

QuoteSurely all you need to do is take out a few "x/=2; y/=2;" statements

Haha, indeed. This is a change that I'm really not looking forward to, because getting it all working properly and being backwards compatible at the same time is not going to be a fun mission...

QuoteA solution would be to cache the acsprset file, and recompile it only if one of the sprite files is modified (or 'full build' option is chosen). This is done with .h headers in C/C++ compilers (and the feature is known as 'pre-compiled headers')

Yeah, there are various possible solutions -- in fact the editor already caches the acsprset.spr file and only updates it if you change a sprite -- but the proposed change here would probably be quite a bit of work for a relatively small reward (improved source control/teamwork compatibility). Therefore it's not something I'll be looking at as a priority.

QuoteThis feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

Well, you don't necessarily have to do all that. In most cases you should just be able to import over the existing sprite, and thus all the views will still be intact.

Quote from: naltimari on Tue 29/04/2008 14:06:43
This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

Quote from: Pumaman on Tue 29/04/2008 19:14:06
Well, you don't necessarily have to do all that. In most cases you should just be able to import over the existing sprite, and thus all the views will still be intact.

Walking cycles use many sprites, about 10 or sometimes more, and 'Import over the existing sprite' only works one sprite at a time, so, either we select one by one, or do the delete view/delete sprites/import sprites/assign to view routine again.

Neither does it work on 'tiled sprites', because AGS does not remember the coordinates it used to cut sprites from (maybe game.agf can store this information?). When I started coding my game, I was using 'tiled sprites', but I dropped them as soon as I realized that 're-imports' would be very difficult and error-prone.

Just reiterating my request in another post to increase the amount of background frames allowed per room on a per-game basis. Ex: Some games could use 2 backgrounds per room, others 8... etc.

I would like to mention again two points from my last suggestions for v3.01

- Could there be an additional character.asc and inventory.asc script, so that the GlobalScript.asc doesn't get messed up with all kind of character and inventory functions anymore and becomes more economic. Especially in large games with more than 50 characters the global script becomes to long. The search function in top of the global script shouldn't work alphabetically but in order of the existing functions from top to bottom. Character functions are shown on top at the moment, but more important script lines like "repeatedly execute" are shown on bottom of the list like it is now...
   
- It should be possible to sort Rooms not only by numbers but also by names:
Sometimes when a game is divided in different locations it has more than one room for each of them. They could be organized better if they are sorted by their names...

-The Preview Option for animations does not not support flipped loops. You still see them as normal animations...

QuoteWalking cycles use many sprites, about 10 or sometimes more, and 'Import over the existing sprite' only works one sprite at a time, so, either we select one by one, or do the delete view/delete sprites/import sprites/assign to view routine again.

This is very true.  I'll often make subtle changes to an animation and then have to:

A) Delete every view that uses frame(s) from the animation

B) Delete every frame

C) Reload the animation and start again

It's time consuming, yes, and I'd certainly like a more efficient solution, but there are things I'd like to see changed that have no easy work around (blocking dialogs, for instance).

It's a pretty minor request, but I would be pretty pleased with a character.faceHotspot() method in the vein of the character.faceLocation() and character.faceCharacter() sorts of functions. Maybe a character.faceRegion() method, too, if it's not too tough.

FaceHotspot could be worked around if the hotspot has a walk-to point set:

import function FaceHotspot(this Character*, Hotspot*, BlockingStyle block=eBlock);

function FaceHotspot(this Character*, Hotspot* theHotspot, BlockingStyle block) {
  if ((theHotspot == null) || (theHotspot == hotspot[0]) || (theHotspot.WalkToX == -1)) return;
  this.FaceLocation(theHotspot.WalkToX, theHotspot.WalkToY, block);
}

An implemented function would be appreciated but not hard to work around.

Regions would be more difficult since there's no co-ordinates available and you would have to seek them out (making it slower as well).

However you could do Objects easily since those have co-ordinates given. I always wondered why MoveToHotspot and MoveToObject were completely removed altogether...

Quote from: monkey_05_06 on Thu 01/05/2008 03:14:52
FaceHotspot could be worked around if the hotspot has a walk-to point set:

Code Select Expand

import function FaceHotspot(this Character*, Hotspot*, BlockingStyle block=eBlock);

function FaceHotspot(this Character*, Hotspot* theHotspot, BlockingStyle block) {
  if ((theHotspot == null) || (theHotspot == hotspot[0]) || (theHotspot.WalkToX == -1)) return;
  this.FaceLocation(theHotspot.WalkToX, theHotspot.WalkToY, block);
}

An implemented function would be appreciated but not hard to work around.

Regions would be more difficult since there's no co-ordinates available and you would have to seek them out (making it slower as well).

However you could do Objects easily since those have co-ordinates given. I always wondered why MoveToHotspot and MoveToObject were completely removed altogether...

There's a bunch of pretty simple ways to work around it, I just figured I might as well suggest it because it seems like a pretty simple change and it would make programming cutscenes go a lot quicker. Facing objects already has a character.faceObject() function, by the way, and I use it quite a bit.

New tint functions:

Room.tint
Item.tint

together with the existing:

Object.tint
Character.tint

functions, I'd be able to change all screen colors any way I like. (rather then having a complete TintScreen)

This'd be killer for a night-time, day-time system. (rather then having to replace the entire background every time)

Well we do have DynamicSprite.Tint now so we could just do:

DynamicSprite *sprite = DynamicSprite.CreateFromExistingSprite(iKey.Graphic);
sprite.Tint(255, 0, 0, 100, 100);
iKey.Graphic = sprite.Graphic;

For InventoryItems. Unfortunately this requires us keeping a DynamicSprite lying around for the InventoryItems. But for rooms we can do this:

DynamicSprite *sprite = DynamicSprite.CreateFromBackground();
sprite.Tint(255, 0, 0, 50, 100);
DrawingSurface *surface = Room.GetDrawingSurfaceForBackground();
surface.DrawImage(0, 0, sprite.Graphic);
surface.Release();
sprite.Delete();

As requested in another thread, support for luminance greater than 100% would be ideal.

Cheers,
Paul.

It has just occurred to me that in order for me to create diagonal walk behinds with perspective I need to do more than a few id's with different baselines. But this is an approximation of what could be a much simpler process.

I suggest that AGS 3.02 introduces dynamic baselines that can be rotated to compensate for change in perspective.

Cheers,
Paul.

Edit:
I would also like to suggest a sound property in the regions pane of the room editor. Having to ViewFrame *frame = Game.GetViewFrame(WALKING, 2, 4);
for each view is no less than a headache and could easily be managed by a simple 'footstep override' property in the regions pane. Cheers.

Hi CJ! Thanks for adding the sprite stuff to source control.

One problem that caused a few crashes and game corruption was I didn't realise that sprindex.dat isn't handled under source control. Could this also be added at some point?

Thank you!

lemmy

SUGGESTION:
I think a 'notes' pane would be really useful. I've got so many ideas and it would be handy to be able to write them into AGS so that I can logistically implement them one by one. It would also be helpful for anyone working in a team environment so that members can read each others notes and write their own.

I also made an icon for your convenience:

(http://www.shuugouteki.net/paul/Development/notes.png)

MORE SUGGESTIONS:

• The baseline for objects is never visible and can't be dragged. Could this be added?
  
• The ability to hide/unhide objects via a toggle for easy comparative placement would be fantastic. Perhaps the 'visible' parameter in the object pane of the room editor could actually hide the object in the editor as opposed to just the engine alone.
  
• In the room editor, assign SHIFT to lock line drawing to 90 and 45 degree angles.
  
• cEgo.SayBackground(); currently doesnt support speech playback. Could this be added?
  
• The ability to name loops and call them via their 'would-be' script names would be neat.
  
• The Vista Game Explorer integration currently doesn't support .ico format. Theres this ugly border around my game icon where other games such as Minesweeper or Solitaire do not. Is there a way to mimick this behaviour? I've tried Vista Game Explorer Editor already.
  
• The ability to run short scripts on view frames might be a useful feature. Instead of ViewFrame.Sound you would just type PlaySound(3); in the frame script. Does anyone else agree?
  
  
  Cheers,
  Paul.
  
  Edit: Added more suggestions.

I know these'll probably go in 3.03 or whatever but I'd like:

a) A "global" search that can either search ALL scripts (including rooms?) or possibly even searches dialogues, gui, view, control, character names, too
b) A spell-checker that's clever enough to know about script and dialogue script syntax.(e.g. GNU Aspell with Ccpp Filter Mode which only checks comments and string literals)

Quote from: SSH on Thu 08/05/2008 12:49:02
I know these'll probably go in 3.03 or whatever but I'd like:

a) A "global" search that can either search ALL scripts (including rooms?) or possibly even searches dialogues, gui, view, control, character names, too
b) A spell-checker that's clever enough to know about script and dialogue script syntax.

Hi to all,
what about some markers on the scripts? I could use that a lot, sometimes searching for pieces of script can be hard specially the globalscipt.asc
Imagine this:
REM 1 code for opening stuff goes here
   {code
REM 2 code for blah blah
   {code
...
A pane that we could easily go to REM 1 would be great
It's obviously not a primary request.

Can't you just use comments and search for the texts? Like:

//This is a comment.

/* This is a comment, too.*/

I have to agree here. If your not commenting your code, how can you or anybody else keep track of what everything does?

Paul.

Very easily, speaking for myself. Judge not.

Following the KISS principle (http://en.wikipedia.org/wiki/KISS_principle), it probably makes more sense to turn code that does different stuff into different functions, at which point the function dropdown will fulfil your needs.

Quote from: Gilbot V7000a on Thu 08/05/2008 14:35:28
Can't you just use comments and search for the texts? Like:

//This is a comment.

/* This is a comment, too.*/

I do comment my script and never said I didn't, but I would like to have access to parts of it quickly,
As you know, a function can have hundreds of lines and looking for it can be exhausting.
Adding a mark on line xxxx could really help.

Then just do it like this:



// TODO: add real value
Wait ( GetGameSpeed ( ) );



Now press CTRL+F and enter the mark-ID "TODO" for example and it'll always take you there.

Sorry to have wasted your time,
ignorance makes a man blind,
looks like it was a simple thing to do.

thanks dkh, it will help me a lot.

Also, REM is just the keyword for comments in some programming languages, we don't need another way of putting comments in the scripts, otherwise it will be confusing.

It would also be great to have a Colour picker and a Font picker as "..." buttons on Font number and Colour number properties in GUIs, characters, etc.

Indeed. :)
This would be handy.

Quote from: Gilbot V7000a on Fri 09/05/2008 01:45:37
Also, REM is just the keyword for comments in some programming languages, we don't need another way of putting comments in the scripts, otherwise it will be confusing.

Yes, I agree with you totaly, it's just that I didn't know about Ctrl+F.

Module import suggestions:

1. Have a MAIN menu item  as well as the right-click on scripts in the game tree: this is hard to find for newbies to 3.0, even those used to 2.72. This was actually Edmundo's suggestion (https://www.blogger.com/comment.g?blogID=7586301806456122785&postID=98042963766414900).

2. Drag and drop of SCM files into AGS window should import the module (ditto for sprites, .CHA, translations, etc). I uses Filezilla's drag-and-drop support all the tiem and its very handy.

Quote from: SSH on Mon 12/05/2008 17:22:04
1. Have a MAIN menu item  as well as the right-click on scripts in the game tree: this is hard to find for newbies to 3.0, even those used to 2.72. This was actually Edmundo's suggestion (https://www.blogger.com/comment.g?blogID=7586301806456122785&postID=98042963766414900).

I second that. I was just about to post something about it, too, but SSH beat me to it. :D

What about including a patchmaker feature? (like you mentioned at least in 2002 in the Kings Quest II remake thread that you maybe was gonna add as a feature in AGS in the future).
(at least in one of the AGS 3 versions.=


Peder.

I don't understand why it has been removed the interaction editor in the last version.
It saved a lot of time and it was easier to use.
I know that most games we make need scripting but the editor made possible to anybody to make a game without looking for scripts all the time.
That's why i chose this program on the first place. Because everyone could make an adventure game easily.

So you can guess what is my request for the next version  ;)
Until then I'll keep using an old version.

Actually a pretty gigantic request would be the ability to choose, perhaps in the General Game Settings pallette, where the savegames would go. I know I would much prefer to be able to keep the savegames in a separate folder within the game folder than clutter up the player's My Documents folder.

Maybe its seems idealist but...

I wish to be, as the help file, little incorporated tutorials to do some things (as scripts examples) for miniarcades (colisions, health..), or ideas for GUIs, examples of IAs.... Simpy examples or ideas to make the way to the script-dumbs as me :P

Maybe a little recopilation of forum helps to do specific things, but in the AGS help, to not have the need of forum-hour-seekings...

Quote from: Makeout Patrol on Wed 14/05/2008 03:34:34
Actually a pretty gigantic request would be the ability to choose, perhaps in the General Game Settings pallette, where the savegames would go. I know I would much prefer to be able to keep the savegames in a separate folder within the game folder than clutter up the player's My Documents folder.

You can already do this, and it can even be changed via the script using Game.SetSaveGameDirectory.

Snake's having trouble avoiding a hotspot when randomly placing objects in this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34517). Surely it wouldn't be too hard to have Hotspot.GetAtRoomXY to match the GetAtScreenXY?

What I would really need is the possibility to change hotspots and objects names (description as it is called in the editor) via script commands.
If I want to make a dark room like it was in the archeological excavation of Indy FoA, I have to create two/three objects overlapping. One with the name 'metal thing'. The next one would be 'light switch?' and the last one, after I switch the light on, would be 'light switch' (without question mark).
See how much easier it would be to just use one line of code like object.Name='light switch'?

Would be nice to see that implemented in the next version.

A couple of things i'd love to see in a further version of ags  :=

  The ability to alpha blend (i can imagine this would be a pain to code, but then my knowledge of C or C++ is infinitecimal so who knows) this would be great for ghosts etc obviously
  It can get really confusing when you have loads of views and folders for more as you cant delete them (i dont think)
  another thing i think would be really difficult (what do i know :P) would be a cool way to set each room as a tile for tiled games and be able to tesselate rooms hundreds at a time to create a zeldaish level style (i can dream i doubt this would happen :o)

Quote from: Aljoho on Fri 16/05/2008 19:08:01
The ability to alpha blend (i can imagine this would be a pain to code, but then my knowledge of C or C++ is infinitecimal so who knows) this would be great for ghosts etc obviously

It can do this already.

I would like a way to draw/erase walkable areas in code.  For example, to make a game out of tile-based rooms where characters can walk freely on some tiles but not others.  With only 16 walkable areas this gets tricky and even more tricky if you want the tiles to be able to be moved via a built in level editor, such as to make it look 3d by adding height to some tiles.

Something like, say, this (http://www.personal.psu.edu/bjr231/IMG/isometric%20paper%201.GIF), I could code to display via drawing commands and with a lot of finesse, could make a level editor to build such levels.  However, editing the walkable areas on the fly?  Not currently possible as far as I know.

If there were rawDraw-ish commands for walkable areas, some cool things could be done.  For the above game idea, I'd probably make the whole screen a walkable area and then block out certain areas on the fly to shape the walkable surfaces.

I'm pretty sure this is already on the to-do list, but now that I got my bitmap based scaling module fully working for characters, it would be awesome to have an Object.Scaling property so the module can fully replace walkable area scaling.

Edit: Oh, and also an Object.ManualScaling property.

   You can alpha blend to the extent of having an alpha channel but can you have a character with the background showing through him (i.e translucsent characters like ghosts etc) if so how?

it would be awesome to be able to set coordinates of where to start with the scaling of characters (and objects?) and where to end.
So if MaxScalingLevel X:10 Y:10 and MinScalingLevel X:100 Y:120 the char would get smaller if he walks to the lower right corner.

Quote from: Aljoho on Sun 18/05/2008 16:10:12
   You can alpha blend to the extent of having an alpha channel but can you have a character with the background showing through him (i.e translucsent characters like ghosts etc) if so how?

First, your game need to be using at least 16-bit color depth. There are two ways to do this:

• Applying an alpha channel to your character sprites (only works in 32-bit);
  
• Setting the Character.Transparency between 0 and 100 (for this to work, though, the character sprites must NOT have alpha channel);
  

CJ, I'd like to ask of a favor(hope you see this), well ok I've been using sprite manager a lot. A lot. So well I noticed sth that would help me greatly(if it's already there please do say). I want to be able to select some sprites and when i right click on them i can have a selection like export selected sprites. That would be ultimately useful.

Well, I have a constructive idea, and I will defend it to the dead (well, to the finish release of the idea in the AGS xD)

Customizable Sierra-Style Portrait Location in each character. I'm not saying nothing to dificult as X,y positions, not, Only Left or Right. This is because Neither of the Sierra-Style Portraits Locations in the General Settings is useful to me (more than twenty) speech views. Some characters have the heads towards left, rigth.. and when are dialogating, not ever the "Based on character Position" works (or even be tottaly wrong. And Alternate the same, When the character has a head towards the rigth, the portrait is in the rigth, and viceversa. xD

A Simple Checbox in every Character Speech View section with "left" or "rigth" will be a great improve to Dialogs based in SierraStyle, Best (sometimes or for some programmers) than a General Settings selection

^^

Another thing that would be handy:

Translucent Overlays

Dinamically use existing .png or .bmp files as walkable areas, or even better, change walkable areas directly from the script (i dont found nothing of that and it could be very usefull to be able to create random rooms).

Jp

Function prototypes like in C (http://opencbp.sourceforge.net/en_US.ISO8859-1/books/opencbook/func.prototypes.html).

I'm writing a tiny tile based platform as a tutorial: function prototypes would help me much to get easily through my code / to show others what's all about.

I was reading the thread "Topic: Scripting for objects in separate rooms" and I found a work around solution in it thanks to Monkey _05 but I was wondering

could it be possible to make this really easy (controling room objects,hotspots, ect) in globalscript files like this...

Room[ID].Object[ID].Visiable = false;
or
Room[ID].oObjectName.Clickable = true;

I hope you get the idea. The reason why I would like this is because I'm interacting with an animal that I made a character so it can be in several different rooms. But 'Character' interactions go in the globalscript. Thus makes it difficult for script in the globalscript Files to have an effect on Room properties, objects and what not.

Is this possoble to code for future versions of AGS?

That has been requested for several times. But it's not easy to implement as it seems.
The problem is, when it's not the current room, the engine won't know if there's such an object in that particular room. Especially for oObjectName, which is specific to a room file.
Unless the editor will compile an room-item list while saving a game, which will cause the editor to scan all the room files and may hinder performance, this is not easily done. Moreover, in this way we will lose the expandability of the compiled games (currently you may add room files or update a room file by simply dropping a .crm file into the game's folder, which is possibly impossible := if that above feature is adopted).

If objects were room-independent that would fix the problem, but this too seems like a considerable effort to implement.  The easiest way to work around it is to use variables to track your changes and then before fading into a room check those variables and do whatever you need.

After all the discussion about automatic lipsync (and hopefully its implementation in smiley's audio manager plugin), I'm wondering how much work it would be to allow lipsyncing for LucasArts speech.

While I agree that mouth movement doesn't need to be very accurate with the distant characters of classic LucasArts style, the mode is a useful workaround if you want character portraits to work differently from standard Sierra style. For instance I use LucasArt speech to emulate the Gabriel Knight dialog interface (hiding the actual speech with an invisible font and displaying the same text on a GUI). And now that true lipsync will hopefully be much easier to implement, I'm sure we'll see lots more people taking advantage of it.

I will be taking full advantage of it. No doubt in my mind there.

Cheers,
Paul.

As I mourn the demise of indication of the scaling level under mouse in the editor, I still dream of something that would be even better: a dummy character/object that could be placed on a walkable area in the editor to see how it obeys the scaling/lighting settings without having to "test game" all over again, apply corrections, "test game", apply more corrections etc.

DynamicSprite.CreateFromFile support for PNG files would be very much appreciated since it's the only format that allows alpha channels. I'm coding a small paint application and it would be great if the user could use his own custom brushes with alpha channels without having to import them into the sprite file first.

PNG support for SaveScreenshot and DynamicSprite.SaveToFile would also be nice, because PCX isn't that widespread anymore (Windows' Paint application can't even open it!) and BMPs tend to be huge, but it's not as essential.

Edit: Speaking of alpha channels, is there any chance for DrawingSurfaces with alpha channel support? As it is now, if you use DrawImage with the transparency setting or alpha channel sprites on a DrawingSurface set to COLOR_TRANSPARENT, it will show that lovely magic pink color through or around the edges of the sprite.

QuoteAs I mourn the demise of indication of the scaling level under mouse in the editor,

That's gone?!?! I didn't notice it because I haven't been using scaling, but I do recall a project in which that was an INVALUABLE help, needed all sorts of complicated scaling to get things right. I'd love to see this back, please!!

I will happily get down on my knees and beg you for this one, but please please please can we have scroll arrows or a scroll bar or something in the dialogue options gui? :)

Mmm

since 3.0, I have problems to select the Talkie animation sprite cause they're more little in sprite screen xD Can you adjust the resolution without we need to change the resolution of our screen everytime we would to select talkie animations, or hurt our eyes? xDD

thanks xD

Perhaps a mouseover for a few seconds of a sprite in the sprite viewer could show it actual-size as a tooltip?

That'd be great. I miss double-clicking them and getting a preview.

Well, I don't miss the double-clicking, of course. I miss the preview.

Actually I would prefer double-clicking bringing up the preview and perhaps Shift-Doubleclick opening it for editing. I often forget the new functionality, doubleclick a sprite to see it larger and end up having to wait for Photoshop to load before being able to get back to editing my game.

Serves you right for not picking a much lighter program for fast editing like M$paint. ;D

(just joshing, btw)

Is there an important reason why you can't pass a zero to the run-script command in the dialog manager?

Also, how hard would it be to get something like a readonly int dialog.ID (which is the topic number, I know, but it would help me with me with a module I'm creating)?

EDIT: Also, must run-script only allow me to pass a 16-bit number? Could it be a full 32-bit integer? Not trying to nag, but I guess that's what this thread's for afterall.

Quote from: skuttleman on Mon 09/06/2008 22:33:26
EDIT: Also, must run-script only allow me to pass a 16-bit number? Could it be a full 32-bit integer? Not trying to nag, but I guess that's what this thread's for afterall.

I think this thread should be renamed to 3.03 wishlist soon though (or start a new one), as 3.02 should be released shortly, I doubt how many suggestions could make into this release. (I think 3.02 takes longer than it's supposed to, as it's originally intended to be a quick release to fix essentials like able to compile the demo game, etc.)

Assuming this will be become a 3.03 wishlist: I already mentioned (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34365.msg451833#msg451833) the usefulness of Object.Scaling and Object.ManualScaling properties.  Now I also find myself missing an Object.IgnoreLighting property. I'm working on a couple of different modules, one that replaces the built-in region lighting with lightmaps and another that replicase the lighting of an object on a DynamicSprite. But since I can't check if the objects are set to ignore lighting or not, I cannot know which to modify and which to leave unlit/at manual settings.

I'm just refering to my two already suggested improvements and hope that they will be included in a 3.03 (or 3.1?) version of the editor;

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34365.msg451518#msg451518
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34365.msg451928#msg451928

Would it be possible to modify or at least add another type to guis to freeze EVERYTHING except themselves and mouse control (like an EXCLUSIVE tag)?  Everything would include processing Waits,changerooms,animations, anything except gui scripts, mouse movement and control and keypresses.  This would allow people to, without significantly messy workarounds, to completely pause games and interrupt game flow during cutscenes or whenever to ask for user input.

Currently I've found no reliable workaround for bringing up a gui with mouse control during cutscenes.

Quote from: ProgZmax on Mon 16/06/2008 20:46:22Would it be possible to modify or at least add another type to guis to freeze EVERYTHING except themselves and mouse control (like an EXCLUSIVE tag)?  Everything would include processing Waits,changerooms,animations, anything except gui scripts, mouse movement and control and keypresses.

Not repeatedly_execute_always() either, please. It's necessary if you want to do custom animations of the GUI or cursor mouseover text.

Don't know if something like this has been mentioned before but I think it would be really nice to be able to do the following...

In the room editor, right clicking on an object, hotspot, etc. would bring up a popup menu (like it does) which includes choices for every interaction event you've already specified, and clicking on one of the choices would take you directly to the script function for that event. I think it would really speed up the process when you don't always have to select the object, select the events page, select the event and click on the "..." button.

Wow! So many new ideas! I hope CJ has the time to implement some of them in the near future. I must say people, your ideas and suggestions coupled with Chris's incredible programming skills make AGS even stronger. Keep up the great suggestions because you might see them in AGS before you expected.
Theres a huge backlist for Chris to look through so I won't clutter this thread with anything else but I just wanted to say great work to Chris, and thank you guys for being such a devoted community.
            \|/
Beers! [=]
Sparx.

Any chance of finally implenting anti-alias fonts capability for dialog/speech for us high-resolution designers? This is the only thing that I'd REALLY like to see added to a possible next version. It's already on the suggestion tracker but with it being blocked due to spammers Chris isn't seeing the amount of people who would really like to see this in the next revise.

If it's too much to ask for then I do apologise - I'm already 110% - no, 120% - appreciative on what you're already doing for us

thanks Chris for adding all these great things to the new editor 3.1.
but I have some things that I would like to see in a future version of ags to make it 'mega' ags :):

!- System.Windowed should also be settable.
!- System.GraphicsFilter(enum filter) should be added as gettable and settable. So we are not forced to use winsetup.exe any longer.
- Option to change dialog options color.
- Change hotspots/objects description names via code.

I know the first two are much work to implement but they would be worth that effort.
And the other ones are just some little things that would be really helpful as there is no easy workaround. (at least for the last one).

Those are good suggestions mate and have been suggested a few times before including by me. Hopefully these will make it to the near top of the new features list. Hopefully...
Cheers,
Paul.

A workaround to changing some of the setup things dynamically would be being able to hard-restart the game so that we could write code to edit the setup cfg and then restart to re-read it.

Hey Pumaman.

Any chance of Object.Z support just the same as Character.z?

Delta

Man a built in sprite / character editor (a la SciStudio) would be a nice feature! Doing it in paint and stuff is really getting to me and annoys the **** out of me!

Apologies if AGS already support this but an Character.ScalingOffset feature would be useful.

Consider a scenario where a character has drunk a shrinking potion. Basically, if the walkarea is scaled at 80% and the ScalingOffset is set to 3, the character would be scaled at 83%.

This is useful for lazy people like myself who would like to avoid the trouble of manually scaling the sprites especially when they are unsure wot the level of shrinkage ought to be. I understand this is already possible using repeatedly_execute but this feature would still be useful.

Please consider. ;D

Does the latest AGS have the ability to play sound effects that you can name whatever you want?

If you have like three hundred sound effects named SOUNDX, it's a huge mess to script that will often lead to  duplicated files because it's hard to find that spesific sound effect's number. Something like PlaySound(char_ego_cough.wav) would be immensely helpful.


edit to the guy below me: since it's a plugin, won't it effect mac / linux support? oh... seems it's down anyway. well, using descriptive filenames for sounds and music should be a quick fix, shouldn't it?

LeChuck, try the audio manager editor plugin....

I would like multiple sprites to import in the order they're named.

Right now when you do a quick import, the last sprite becomes the first, then the rest are in order (as per this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=22728.0)). This is a pain, as it makes you either re-number the sprites after you import them, or you have to import them one at a time.

I think it would be nice for inventory items to have an optional second sprite number that you could assign so that one sprite would be used when viewing the item in the inventory, and another would be used when the item becomes a cursor.

This way, you would have more options than just the few built in options for adding a well-defined hotspot to the inventory cursors.  For example, in LimpingFish' Heartland, he could have easily made fancy new cursors for his inventory items without rescripting the inventory system.

Oh, just found it on the tracker.  I support this! (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=216)

Also, though maybe I'm pushing it, a separate setting for animate-on-mouseover for each inventory item so you can do the same as above, but also define an loop to use on mouseover of a hotspot/character/object?

So I recognize that 3.01 has changed the resolution behavior and that this is probably why you can't change the resolution of your game anymore, but it presents (for me) two problems: as my game is in 320x200 but my computer runs at 1440x900, doing the 'test run' of the game makes it extremely difficult to see - the text is almost unreadable, because the game window is so small. I've gotten around this by compiling the game and running the .exe in full screen mode, but it's simply ugly - I used to run the game in 640x480, which made the edges nice and crisp, but running it in full screen 320x200 frankly makes it look blurred and ugly. Would it be at all possible to introduce some way to view the game in 640x480, like what used to be the case?

EDIT: Hurp de durp looks like I should RTFM before I post

It would be great if there was an option to compile a game so that AGS gave a dialog box warning if it was run without a setup file (e.g. when run from a zip without unzipping) saying "Game could not find setup file, if you are running this game from a zip file it is recommended that you unzip it first"

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.

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...

**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

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.

Quote from: SSH on Wed 23/07/2008 12:57:13My 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...

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?

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.

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

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 ;D. 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).

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.)

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.

Quote from: KhrisMUC on Wed 30/07/2008 23:20:32
-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.

Quote from: KhrisMUC on Wed 30/07/2008 23:20:32
-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.

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:

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.

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. ;)

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

Quote from: Gilbot V7000a on Thu 31/07/2008 07:23:43
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 Select Expand


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.

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.

You mean, like my SpriteFont module?  ;)

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.

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.

I would like a preview of the transparency settings in the sprite import window. So when using top-left corner the sprite will get all pixels with that color deleted (in the preview and of course in-game).
Leave-as-is should work with alpha-tranparent pictures. So if I use one as button, the button will be alpha blended in-game.
Alpha-blended buttons should be shown correct in sprite manager preview and gui/room preview.

OFF-TOPIC: I have a non-transparent gui and an alpha-blended button. But the button isn't alpha blended in game. What can I do to make it transparent?

It would be nice if CJ could tell us what he thinks of all this suggestions (from the whole thread).

Quote from: Lt. Smash on Thu 07/08/2008 10:13:01
OFF-TOPIC: I have a non-transparent gui and an alpha-blended button. But the button isn't alpha blended in game. What can I do to make it transparent?

Well, it is really off-topic, but that one is a quickie: apply an alpha channel to your GUI background sprite, even if it is going to fully opaque. Last time I checked, that's the way it (oddly) works.

See further info on this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=34537.0).

I'd like to second ProgZMax's request (previous page) for a name property to be added to Gui controls. Or custom properties.

Either one would be great.

I'd really like to know if it is bossible to get PCX support back. Is it? :)

Quote from: GarageGothic on Thu 29/05/2008 02:26:24

Edit: Speaking of alpha channels, is there any chance for DrawingSurfaces with alpha channel support? As it is now, if you use DrawImage with the transparency setting or alpha channel sprites on a DrawingSurface set to COLOR_TRANSPARENT, it will show that lovely magic pink color through or around the edges of the sprite.

Whooops, I was just having problems trying to draw some semi-transparent particles on a DynamicSprite surface...  :-\

I second the GarageGothic feature request :)

Quote
I'd like to second ProgZMax's request (previous page) for a name property to be added to Gui controls....

I also second Progy's suggestion of adding some kind of descriptive text property to gui controls.  A module would be able to scan a gui for controls having specific text tags and then connect to them automatically. Anyway, thats what I would use it for.   

A function that would immediately cancel Wait timers would be extremely useful, particularly when running repeating introductions in a room's repeatedly execute function.  Right now it's unnecessarily difficult to override a room using wait calls should you want to start a game or have it do something else.  Alternatively, being able to make a custom key that StartCutscene() will respond to would resolve this.

Am I missing something in my scripts, or the Character.z works only with positive values?

I quickly managed to workaround the problem playing with the Baseline and an object to put in front of the character, so obviously this isn't a serious problem, but maybe having a consistent behavior with negative Z (letting a character "fall down" and not only float) might be nice.

Another small and not-really-important suggestion:
we have Character.LockViewOffset, and I managed to find it time-saving in case of little errors in some animations.
Having to do some small frame by frame scripted animations with Character.LockViewFrame, I missed the possibility to offset the frames in the same way and having to manually offset the character before/after the frames.

Nothing worth introducing a Character.LockViewFrameOffset function, but having two optional xOffset, yOffset parameters might come handy.
At your place, I'd do the same with LockView, getting rid of LockViewOffset and adding two optional parameters to LockView.
I suppose it wouldn't be a problem for backward compatibility: it would be a matter of substituting "LockViewOffset" with "LockView" and nothing else. :)

Just my 2 cents,
D.

Quote from: Dusk on Tue 12/08/2008 03:20:23Am I missing something in my scripts, or the Character.z works only with positive values?

I've added "if (keycode == 32) player.z--;" to a default game and Roger sinks down fine.

Quote from: KhrisMUC on Tue 12/08/2008 11:59:45
I've added "if (keycode == 32) player.z--;" to a default game and Roger sinks down fine.

Whoops, I should have double checked... it seems that as I said i was "missing something in my scripts" :P

If I have time I'll try to replicate what happened...  ???

Would it be possible, in the Sprites, when adding a new sprite using the "New sprite using last sprite..." which uses the same graphic to import several sprites, to retain the zoom level from the last time the user imported a sprite from this sheet. This would be very useful for me, because I typically import a series of sprites from one sprite sheet, and I need to zoom in to make sure I grab the right part. With each one, I have to zoom back in again, and I think it would make a lot of sense to stay zoomed in.

Hey, I really liked the feature in the Views, that when you add a new frame after an already established frame with a designated, it just uses the next sprite from Sprites. That has saved me a lot of time!!!

I'm not sure if it is possible, and not quite sure if it has been already implemented in the last versions i havent tried... but is there a possibility to make Strings importable from the headers without using GlobalStrings?  Like functions and ints....

Thanks.

EDIT:  Oh... Sorry... I figured out I way arouund it... He, the "new"style strings from 2.7 on  are really cool.

I would like to see masked hotspots for transparent buttons in a GUI. :)

Cheers,
Paul.

Voice speech support for the SayBackground command seems a logical thing to have.  I'm quite surprised that it doesn't work, actually!

Also, I'm thinking a PlaySpeech() command which works like PlaySound and PlayMusic would be highly useful when speech is active and would round out the functions.

I'd love to allow clickable property for buttons to be defined like visible for objects. Via the editor and if it would be possible to allow alpha blended sprites to have transparency when they are used as button images. Or allow button transparency.