Adventure Game Studio

Hello,

Now, I'm aware that we already have an AGS 3.01 Wishlist thread. But that has all sorts of suggestions, ranging from minor to extremely major, and it's useful as a long-term goals type of list.

I'm planning to do a 3.0.1 release in a relatively short timescale of a couple of months, and I want to fix up those little things in the new editor that annoy you, and implement any relatively minor improvements that would make a difference to your everyday experience.

These are some that have already been suggested and that I'd like to do:
* Bring back drag & dropping sprites around in the sprite manager
* Drag & drop views into different view folders
* Ability to delete views

So, if there are any other minor things that are bugging you about 3.0, please post them here.
However, please keep your suggestions reasonable such that they could be implemented in a short time frame. If you've got more fanciful suggestions such as a new interaction editor, please put them in the 3.01 Wishlist thread instead.

I reserve the right to delete any large suggestions from this thread  :=

*Stick the header and main script of script files into their own node, similar to how the rooms work.

I actually suggested this once Dan, but it was turned down. Maybe if we see more support for the suggestion the decision will be overturned?

Not sure if this is necessarily appropriate for a 3.0.1 release, but for some reason I never got around to mentioning that:

*While File and similar functions work with the Compiled directory when running the debugger, RunAGSGame still seems to work with the current directory instead and can't load games, even if they are found by File.Open.

If it's easy enough to fix I would appreciate it, but understand if it's better suited to a later version. ;)

I would also like to state my support for Rui's following suggestion. I don't actually use the My Documents folder for anything, but I find the behaviour quite annoying. When I actually do open the My Documents folder for any reason I find it quite cluttered with empty folders! :o

By default, the editor fills the SaveGameFolder in General Settings with the game's name. It means that by default my My Documents folder is gonna get seriously crowded as more games are released. Could the default behaviour be to leave it blank, like standard AGS behaviour so far?

In the edit room view, I'd like to be able to select the listboxes and use the arrow keys to cycle through the options. This kind of works currently, but it seems flaky, takes two keypresses to move one entry, and if you go off the end of the list you start tabbing through the other controls.

The ability to zoom the room background to make it easier to draw walkable areas and walkbehinds in the editor?

It would be nice if the room list would auto-sort by number. Changing a room's number now keeps its position within the list, so that you can have Room 4, 9, 1, 3, 7. I use consecutive room numbers (with gaps) to "group" my rooms, and this is pretty much impossible with the current system.

The ability to a) LOCK and b) OUTLINE GUI elements, while certainly not used too often, were quite useful, and I wonder if we could have them back?

Apart from that, yes, drag'n'drop for sprites and view groups, that'd be ace.

The bug I mentioned to you about the editing scripts right-click menu often not having cut/copy/paste available would be a nice fix :).

Perhaps making the room edit crosshair match the resolution of the rooms rather than display properties and give it a transparent center?  It might make it easier to draw with, and it's terrifically small on my widescreen LCD even @ 1024x768.

And of course a toggle to allow rawdrawing over sprites/objects, but that's probably a tall order for a quick release.

Only one thing: MI & FOA GUI Template.

The pestering guy : "a serious detection of wether or not the .NET framework is installed (in the installer or during execution)"

Quote*Stick the header and main script of script files into their own node, similar to how the rooms work.

I haven't done this because it would mean you'd need an extra click to expand the node and get to the header. However, if people want it to work like this I can look into it.

Quote*While File and similar functions work with the Compiled directory when running the debugger, RunAGSGame still seems to work with the current directory instead and can't load games, even if they are found by File.Open.

Thanks, I'll look into this one.

QuoteBy default, the editor fills the SaveGameFolder in General Settings with the game's name. It means that by default my My Documents folder is gonna get seriously crowded as more games are released. Could the default behaviour be to leave it blank, like standard AGS behaviour so far?

Not really -- the reason for this defaulting as it does is because of Vista and its permission issues around Program Files. Therefore, if the default was to write save games to the same folder as the game EXE, it could fail on Vista systems.

I appreciate that this way could clutter up your My Docs folder though, I'm not sure what the best compromise is? I guess it could create a single "AGS Games" folder in My Documents and then create the game save directories under that, but people would probably think that didn't look very professional for their game.

QuoteIn the edit room view, I'd like to be able to select the listboxes and use the arrow keys to cycle through the options. This kind of works currently, but it seems flaky, takes two keypresses to move one entry, and if you go off the end of the list you start tabbing through the other controls.

The strange behaviour at the moment is to work around an issue whereby pressing Ctrl+E for example would take you to the Edges section rather than selecting the Rectangle mode. If I can find a way to sort it out properly, I will do.

QuoteThe ability to zoom the room background to make it easier to draw walkable areas and walkbehinds in the editor?

Ah yes, this old chestnut. I should really get this done.

QuoteIt would be nice if the room list would auto-sort by number. Changing a room's number now keeps its position within the list, so that you can have Room 4, 9, 1, 3, 7. I use consecutive room numbers (with gaps) to "group" my rooms, and this is pretty much impossible with the current system.

Ok, I think the easiest thing here is just to add a right-click option to "Sort rooms by number" for this sort of situation.

QuoteThe ability to a) LOCK and b) OUTLINE GUI elements, while certainly not used too often, were quite useful, and I wonder if we could have them back?

Fair point, I'll think about this one.

QuoteThe bug I mentioned to you about the editing scripts right-click menu often not having cut/copy/paste available would be a nice fix

Yep, I think I can get that in.

QuotePerhaps making the room edit crosshair match the resolution of the rooms rather than display properties and give it a transparent center?  It might make it easier to draw with, and it's terrifically small on my widescreen LCD even @ 1024x768.

Does anyone else have any problems with this crosshair?

QuoteAnd of course a toggle to allow rawdrawing over sprites/objects, but that's probably a tall order for a quick release

I'm not really sure what you mean by this. RawDraw normally draws onto the room background. If you want to draw something on top of objects, then create a dynamic sprite, raw draw onto it, and place it on an object/overlay in front of everything else.

QuoteOnly one thing: MI & FOA GUI Template.

Well, this isn't something I'm going to be writing. If anyone wants to volunteer to provide one, I would of course include it.

QuoteThe pestering guy : "a serious detection of wether or not the .NET framework is installed (in the installer or during execution)"

What do you mean by this? The installer should already check that the .NET framework is installed.

Well, I'm saying it would be nice to be able to rawdraw over sprites/objects through the regular drawing functions for convenience; take DrawLine, since I'm writing a rain module of my own that uses DrawLine and detects impact sites (solid characters/objects/and marked regions), but it cannot currently draw in front of them as well, which would be great.  I could just have a sprite overlay version raining in the foreground, but maybe you see what I mean when I say it would be useful simply to be able to rawdraw over chars/objects with some kind of z-order setting.

I too can see how Prog's suggestion would be useful, but perhaps if there were some way to apply a Z-order to screen Overlays that could be integrated with the GUI Z-orders. GUIs I think should take a higher precedence to Overlays but this isn't currently the case, so if we have, for example, a room with a raining effect using an Overlay then we turn on a menu GUI we would have to turn off the rain or it would be drawn on top of the GUI. Another example would be the Flashlight module which does allow for a GUI mode to by-pass this issue, but I think idealistically we should have some type of z-control for Overlays.

Quote from: Pumaman on Sun 27/01/2008 23:29:45

QuoteThe ability to zoom the room background to make it easier to draw walkable areas and walkbehinds in the editor?

Ah yes, this old chestnut. I should really get this done.

I`d love the ability to have semitransparent walkable areas and walkbehinds. I find drawing a bit painful not seeing the background under the area.

• Validation of GUI Dimensions - It appears that both height and width are validated if either height or width are changed.  It the GUI is initially purposely set larger than the screen dimensions to host dynamic controls, since both dimensions can't be set at the same time, a runtime error is generated when the GUI is resized.    Perhaps it would be better to validate only the property that is being changed.   Also, how about instead of compile warnings, just pop a message when someone enters an invalid  dimension in the property grid.   Someone who had made a mistake would get immediate feedback and someone who had done it on purpose would only get nagged once instead of repeatedly.
  
  
• New Game From Template - When creating a game from a template a dialog pops up displaying the template.txt file.  If the template.txt file is too long the OK button that closes this dialog is in accessible and off screen.   I believe in the previous version of AGS, display of the template.txt file was truncated so that the complete dialog box fit on screen.
  
  
• Game Locations - I ran the whole installation and the Demo game got installed in c:\Win\All Users\Application Data\AGS Demo and it took awhile to find it.  I think this is somewhat related to the comments above about new games being created in MyDocs in that there may be a common solution.   Couldn't we please have the ability specify a games folder where we can do our development.   The installer could ask for a location where new games are to be created.  MyDocuments could be the default so the uninitiated could just click through.  This would also be specified via File->Preferences menu.   I believe many of us would be grateful and that this would also satisfy Vista's needs.
  
  
• New Game - The initial dialog box that comes up when creating a new game requires that the descriptive text be read each time to determine which is the title and which is the folder name.  While this may be nice for new users, it's annoying for the rest.   Perhaps words similar to "Folder:" and "Title:" could be displayed to the left of the entry fields.   It appears that there is enough room to shift the fields right to accomodate the additional text.
  
  
• Module Script Order - Currently when new modules/scripts are created or imported they are prepended to the script list so that the global script remains at the end of the list as it should be.  This however, makes it difficult to manage module dependencies.  For example, suppose you wanted to have a module that defined some things that future modues or scripts would use.  With the current scheme, whenever a new module is added, it and all preexisting modules would have to be exported, deleted from the game, and then re-imported in the correct order.  A better and more intuitive scheme would be to insert new modules just before the global script so that the first module is always the first module, the second is always second, etc.  This is the way it used to work in 2.72
  
  
• Script Editor Search - When searching in the forward direction the found text is displayed in the last line in the window and searching in the reverse direction the found text is displayed in the first line of the window.   For me this seems backwards in that when searching forward I would prefer to have the found text displayed near the top of the window.   I think it was suggested in another thread that the found text be displayed in the middle of the page.   This is an acceptable compromise but perhaps a better solution is let the user specify a search margin of X lines in File->Preferences.    So when searching forward, for example, the found text would be displayed X lines from the top (or bottom if it's easier or clearer to define it this way).
  
  
• _blank.crm - This was really useful and is sorely missed.  However, I would be willing to wait if a NewRoom/NewModule templating system is on the books.
  
  
• Tab Update Feature -  Someone mentioned in another thread that if a lot of changes have been made to a script file and the bookmark and auto complete features are a bit out of synch with the current file, they can be updated by switching to another tab and then back.  Perhaps the update could also be performed just by clicking on the currently open tab, eliminating the need to switch back and forth. 
  
  ===========
  
  

  Quote
  

  Quote
  *Stick the header and main script of script files into their own node, similar to how the rooms work.
  

  I haven't done this because it would mean you'd need an extra click to expand the node and get to the header. However, if people want it to work like this I can look into it.
  

  For me, it's ok the way it is but if you wanted to do something to make things more consistent but not add extra clicks then perhaps something like the following could be considered. 
  
  Room Edit - Combine "edit room"  with the node  so that clicking on the node text does the same thing that clicking on "edit room" does now.   The property grid is displayed and the room background is displayed and the area editor is active.  Clicking on the
  [ + ] box would then reveal only the "room script" branch.
  
  [-] 1: Splash Screen
  |
  +----() Room Script
  
  
  Scripts - Make Module.asc into a node.  Clicking on it opens the *.asc file and displays the proiperty grid.  Clicking on the [ + ] box would then reveal only the *.ash header file.
  
  [-] Module.asc
  |
  +----() Module.ash
  
  Yeah I know,  I'm not being much of a purist here ;) and shame on me for thinking like this.  But it's just food for thought about how to achieve both results, albeit in an impure manner.     

Dialogue options on a GUI in a text-box, allowing for nicer customisation of topic selection without having to write an entire custom system.

Quote from: RickJ on Mon 28/01/2008 09:03:27Validation of GUI Dimensions - since both dimensions can't be set at the same time

Erm...GUI.SetSize (http://americangirlscouts.org/agswiki/GUI_functions_and_properties#GUI.SetSize)? I'm curious as to whether this would help you to by-pass this issue, though a "fix" would probably be in order here.

Quote from: RickJ on Mon 28/01/2008 09:03:27Game Locations - Couldn't we please have the ability specify a games folder where we can do our development.

You mean like I suggested in the beta thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=31519.msg432387#msg432387)? :P

Quote from: RickJ on Mon 28/01/2008 09:03:27Module Script Order - With the current scheme, whenever a new module is added, it and all preexisting modules would have to be exported, deleted from the game, and then re-imported in the correct order.

Uh...[Module name].ash/[Module name].asc->Right-click->Move Up/Move Down? I don't personally care so much about where the new item is added at because I can just move them all around as I see fit.

Quote from: RickJ on Mon 28/01/2008 09:03:27Script Editor Search

Actually, probably not fitting for a 3.0.1 release, but I really like the way Firefox handles this. When I press Ctrl+F a small pane appears at the bottom of the window, but doesn't inhibit my ability to move about the page as I see fit. I can then use the search function as needed without having to close it if I want to look around a bit. Another thing I would like to see here is the option of case-sensitive searches. Since AGS is case-sensitive it would make sense to have this ability (though case-insensitive searching can be useful as well). Oh, also a "Find previous" option? I know I'm being a bit picky and needy here about the way I want my search function to work, but if it's not too much of a hassle to implement it would make it much more useful to me personally...which is clearly why Chris started this thread. To find out what I want for AGS. 8)

Quote from: RickJ on Mon 28/01/2008 09:03:27Room Edit - Combine "edit room"  with the node  so that clicking on the node text does the same thing that clicking on "edit room" does now...

Actually I personally prefer the way its handled now to this method.

Ahoj,
a useful thing could be the follwing:
the ability to place the main character on the screen like an object and the coordinates are automatically placed in the character section.It's complicated to get a xy position with the mouse and remember(or write it down on a piece of paper^^) it in the character section.

*When you change the description of a room, it doesn't update the list
*When you create new subfolder in sprites or views you can't move the existents views into the new folder, some kind of copy/cut/paste would be nice
*When you are editing a room, and you change to do some walkeable areas or walk behinds all the objects hide and you can't see where they are, it'd be nice if there were a checkbox where you could hide or show them.
*Add 5 Ctrl+Z level (I made doble click and I lost all because I fill the screen twice) it should have a few more undo levels
*Add windowed mode the posibility of zoom like 1x, 2x or 3x I have a 1280 resolution and I work with windowed because it's easier but.. it's really small and I can hardly recognaize the things
*Add editing room zoom, it can't be so hard, just a + button and a - button.
* (I don't know if you are working on it but...) I don't know what is the use of the break point in AGS it should allow you to see a value when you stop the code at least that is what I do when I program in VB.NET and It helps a lot when you are looking for an error or just seeing what a function return in a easier way.

Here are some things that is really bugging me with the new editor (other than that it works great!):

* "Assign to view..." doesn't remember previous view used. This means that if you for example want to add a couple of sprites to the down, left, right and up loop of some view (other than 1) you have to reenter the number between each assignment. And if you forget you might end up overwriting some of the loops of view 1. Very irritating and should be an easy fix!

* When doing tiled import and selecting the area for import (right mousebutton) the selection
  can go outside of the image. This makes the whole procedure more time consuming.
* Moreover, the import area is not remembered as it was in 2.72, so you have to define the area for each animation you import even if it quite often can be the same.

* Suggestion for further improving tiled import: Being able to specify size of import area (x times y pixels) for tiled import. This would remove the need of precision work with the mouse, which often ends up in the wrong import area because you accidentally release the mouse button prematurely.

These are things I've come across many times in the few days I've been working in AGS 3.0, and they really become a pain after a while. None of the things should be very time consuming to implement, but would really improve the smoothness of my work flow.

Thanks for the great work, CJ!

It's great that all the tabs open at the top of your screen, but I keep trying to re-order them as I do all the time in my firefox, but doing that just opens a different tab. Being able to order them would be a lot handier. Just a simple drag and drop, like Firefox. Or an auto sort by alfabet (or type) if a new tab is opened, perhaps?

CJ, i ;ve asked before but you seem to nevermind my post all the time..
Can you put a File.Delete() function so that we can internally delete all types of files put on the game's folder?

Not really a suggestion, more of a bug:

I like to have the room editor and room script editor open at the same time so I can toggle back and forth (for getting mouse coordinates, checking exactly where a hotspot begins, etc.)

However, it seems that whenever I test the game after editing the script in the room, the room editor closes and leaves me at the script editor. It kind of annoying to have to open the editor again every time I test the game.

Quote from: NiksterG on Wed 30/01/2008 00:09:39
However, it seems that whenever I test the game after editing the script in the room, the room editor closes and leaves me at the script editor. It kind of annoying to have to open the editor again every time I test the game.

And here I thought I was going insane and forgetting that I'd closed the room.  I completely agree with this point.



Myself, I would like it if you could make the room script split into its different parts, like you had in the previous version.   For organizational purposes really, so I don't have to scroll through lots of script to get to what you need.

And maybe Double-clicking on an Object in the room editor brings up the dialog to choose an image.

How about better tint screen support to deprecate the tint screen features of the aging flashlight plugin. In particular, support for tinting in 32-bit would be cool.

The current TintScreen function does not allow for negative tints which makes it impossible to apply night time effects to a screen. It also appears to be buggy as I noticed it prevents screen transitions.

My game currently uses a-v-o's flashlight plugin to simulate night-time effects using the simple tint screen features. It would be cool if AGS had native support for this because the MAD engine (used for Hero6) supported this.

The MAD engine had a function that was something like this:
SetScreenTint(red, green, blue, alpha)

which could deal with tint and darkness at the same time within the 32-bit domain, thus allowing for very fine tints.

Since we can already tint characters and object using regions, I don't see why Tinting the whole screen should be much of a problem. But support for fine 32-bit tinting would be excellent.

Quote from: Pumaman on Sun 27/01/2008 23:29:45

QuoteBy default, the editor fills the SaveGameFolder in General Settings with the game's name. It means that by default my My Documents folder is gonna get seriously crowded as more games are released. Could the default behaviour be to leave it blank, like standard AGS behaviour so far?

Not really -- the reason for this defaulting as it does is because of Vista and its permission issues around Program Files. Therefore, if the default was to write save games to the same folder as the game EXE, it could fail on Vista systems.

I appreciate that this way could clutter up your My Docs folder though, I'm not sure what the best compromise is? I guess it could create a single "AGS Games" folder in My Documents and then create the game save directories under that, but people would probably think that didn't look very professional for their game.

My Documents\My Games := That's where most games put their stuff nowdays anyway, with some annoying exceptions.

QuoteWell, I'm saying it would be nice to be able to rawdraw over sprites/objects through the regular drawing functions for convenience; take DrawLine, since I'm writing a rain module of my own that uses DrawLine and detects impact sites (solid characters/objects/and marked regions), but it cannot currently draw in front of them as well, which would be great.

The thing is that there's no image layer there to draw onto. You've got the room background, then the objects/characters/etc, then overlays and then GUIs. The only way to draw something onto an upper layer is to draw onto an overlay or GUI.

QuoteI`d love the ability to have semitransparent walkable areas and walkbehinds. I find drawing a bit painful not seeing the background under the area.

I agree this would be useful. Last time I tried it, it made the editor go painfully slowly but it's about time I re-visited the idea, I think.

QuoteValidation of GUI Dimensions - It appears that both height and width are validated if either height or width are changed.  It the GUI is initially purposely set larger than the screen dimensions to host dynamic controls, since both dimensions can't be set at the same time, a runtime error is generated when the GUI is resized

I don't see the big deal here -- as monkey says, just use GUI.SetSize instead.

QuoteNew Game From Template - When creating a game from a template a dialog pops up displaying the template.txt file.  If the template.txt file is too long the OK button that closes this dialog is in accessible and off screen.   I believe in the previous version of AGS, display of the template.txt file was truncated so that the complete dialog box fit on screen.

As I said before, I don't consider this an issue. When a template author tests out their template, they will see this and correct it. The template.txt file is only supposed to be a brief intro to what the template is, not a manual full of instructions.

QuoteThe installer could ask for a location where new games are to be created.  MyDocuments could be the default so the uninitiated could just click through

This should be addressed by the new Preferences option in 3.0.1 beta 1.

QuoteModule Script Order - Currently when new modules/scripts are created or imported they are prepended to the script list so that the global script remains at the end of the list as it should be.  This however, makes it difficult to manage module dependencies.

As monkey says, why not just right-click Move Up or Move Down as appropriate to re-order things? Or are you just saying that by default new modules should appear at the bottom rather than the top?

QuoteScript Editor Search - When searching in the forward direction the found text is displayed in the last line in the window and searching in the reverse direction the found text is displayed in the first line of the window.   For me this seems backwards in that when searching forward I would prefer to have the found text displayed near the top of the window.

Hmm, I'm not sure about this one. To me, it seems more intuitive that when searching forwards, the text would display at the bottom of the screen, which also gives a better illusion of moving forwards whilst going through the find result matches...

Quote_blank.crm - This was really useful and is sorely missed.  However, I would be willing to wait if a NewRoom/NewModule templating system is on the books.

Yes, something like that is a good idea, thanks for reminding me.

QuoteTab Update Feature -  Someone mentioned in another thread that if a lot of changes have been made to a script file and the bookmark and auto complete features are a bit out of synch with the current file, they can be updated by switching to another tab and then back.  Perhaps the update could also be performed just by clicking on the currently open tab, eliminating the need to switch back and forth.  

Interesting idea -- but it seems like a bit of a hack. I really need to sort this out properly.

QuoteCombine "edit room"  with the node  so that clicking on the node text does the same thing that clicking on "edit room" does now.   The property grid is displayed and the room background is displayed and the area editor is active.  Clicking on the
[ + ] box would then reveal only the "room script" branch.

That's a possibility, but double-click having different behvaiour to clicking the + could start to get confusing. I'll have a think about it.

QuoteDialogue options on a GUI in a text-box, allowing for nicer customisation of topic selection without having to write an entire custom system.

Hehe yes, the whole dialog system needs a bit of TLC, I think. Can't promise it'll happen for 3.0.1 though.

Quotethe ability to place the main character on the screen like an object and the coordinates are automatically placed in the character section.It's complicated to get a xy position with the mouse and remember(or write it down on a piece of paper^^) it in the character section.

Well, you can right-click on the room background and do "Copy co-ordinates to clipboard" but some way of previewing them on the room background would be useful, I agree.

Quote*When you change the description of a room, it doesn't update the list

As I said in the other thread, I can't replicate this. Can you provide more details?

Quote*When you create new subfolder in sprites or views you can't move the existents views into the new folder, some kind of copy/cut/paste would be nice

Drag and drop is now in 3.0.1 beta 1.

Quote*When you are editing a room, and you change to do some walkeable areas or walk behinds all the objects hide and you can't see where they are, it'd be nice if there were a checkbox where you could hide or show them.
*Add 5 Ctrl+Z level (I made doble click and I lost all because I fill the screen twice) it should have a few more undo levels

These sound reasonable to me.

Quote*Add windowed mode the posibility of zoom like 1x, 2x or 3x I have a 1280 resolution and I work with windowed because it's easier but.. it's really small and I can hardly recognaize the things

Use the DX5 driver and enable a graphics filter in Setup, as I said in the other thread.

Quote* (I don't know if you are working on it but...) I don't know what is the use of the break point in AGS it should allow you to see a value when you stop the code at least that is what I do when I program in VB.NET and It helps a lot when you are looking for an error or just seeing what a function return in a easier way.

Ideally this is my goal, however it's not an easy task so it won't happen for 3.0.1.

Quote* "Assign to view..." doesn't remember previous view used. This means that if you for example want to add a couple of sprites to the down, left, right and up loop of some view (other than 1) you have to reenter the number between each assignment. And if you forget you might end up overwriting some of the loops of view 1. Very irritating and should be an easy fix!

Sounds easy enough to fix, I'll look into it.

Quote* When doing tiled import and selecting the area for import (right mousebutton) the selection  can go outside of the image. This makes the whole procedure more time consuming.
* Moreover, the import area is not remembered as it was in 2.72, so you have to define the area for each animation you import even if it quite often can be the same.

I'll look into this.

QuoteIt's great that all the tabs open at the top of your screen, but I keep trying to re-order them as I do all the time in my firefox, but doing that just opens a different tab. Being able to order them would be a lot handier. Just a simple drag and drop, like Firefox. Or an auto sort by alfabet (or type) if a new tab is opened, perhaps?

Is this something anyone else would find useful?

QuoteCan you put a File.Delete() function so that we can internally delete all types of files put on the game's folder?

Yeah sorry I keep meaning to do this, I'll look into it.

QuoteHowever, it seems that whenever I test the game after editing the script in the room, the room editor closes and leaves me at the script editor. It kind of annoying to have to open the editor again every time I test the game.

Thanks for this, it's fixed in 3.0.1 beta 1.

QuoteMyself, I would like it if you could make the room script split into its different parts, like you had in the previous version.   For organizational purposes really, so I don't have to scroll through lots of script to get to what you need.

I don't think this will be changing back -- but there is the drop-down list of functions at the top of the script editor that you can use now to quickly get to the right place.

QuoteAnd maybe Double-clicking on an Object in the room editor brings up the dialog to choose an image.

Sounds reasonable to me.

QuoteThe current TintScreen function does not allow for negative tints which makes it impossible to apply night time effects to a screen. It also appears to be buggy as I noticed it prevents screen transitions.

Tinting the whole screen is extremely slow in software mode, so I don't think it's worth expanding this feature. You can get good day/night effects by storing a secondary night background, and using SetAmbientTint to tint the characters and objects appropriately.


Thanks for all your suggestions, guys!  :)

QuoteThe thing is that there's no image layer there to draw onto. You've got the room background, then the objects/characters/etc, then overlays and then GUIs. The only way to draw something onto an upper layer is to draw onto an overlay or GUI.

Well fudge.  I'd ask you to redo how the drawing system works but that would be unfair, so I will simply have my rain module use both Drawline AND sprite overlays instead :) !  My plan of forcing people to upgrade their pc's to play my games is almost complete.  8)


Edit:  Thanks for adding moving views in folders.  Could you add the ability to move the folders themselves as well in the next release (even if it's a right-click menu with move up/move down/move to top/move to bottom)?  This would be especially helpful for me since I've got a ton of views to relocate and the folder creation places new folders at the bottom.  The ability to use the scroll-wheel while you're dragging an item to move up/down the pane would be helpful also, for the same reason.  Moving folders in-out of other folders and folder deletion would also be great.

Quote from: Pumaman on Wed 30/01/2008 22:15:03

Tinting the whole screen is extremely slow in software mode, so I don't think it's worth expanding this feature. You can get good day/night effects by storing a secondary night background, and using SetAmbientTint to tint the characters and objects appropriately.

Thats how the AGDs do it. I was hoping to avoid that due to the extra strain on the art team and the increased game size. That does suck that you don't think its worth it.

Quote from: Pumaman
This should be addressed by the new Preferences option in 3.0.1 beta 1.

;D

Quote from: Pumaman
I don't see the big deal here -- as monkey says, just use GUI.SetSize instead.

Using GUI.SetSize is an adequate solution for myself.   I don't mean to make a big deal of it an but the resulting error is confusing because the statement that causes it is perfectly valid.  IMHO, it's something that people will get hung up on in the future.  I suppose time will tell.

Quote from: Pumaman
As monkey says, why not just right-click Move Up or Move Down as appropriate to re-order things? Or are you just saying that by default new modules should appear at the bottom rather than the top?

Sorry, I wasn't aware of the Move Up/Dn functions already built in.   Changing the default to insert at end of list (just ahead of the global script) would satisfy the remainder of my request/comment.

Quote from: Pumaman
Hmm, I'm not sure about this one. To me, it seems more intuitive that when searching forwards, the text would display at the bottom of the screen, which also gives a better illusion of moving forwards whilst going through the find result matches...

IMHO, most people would like to see the context of each occurance of the found text (i.e. a few lines before and after).  That's why I suggested that the better solution would be to have a user settable preferences that specifies how many lines the found text should be above/below the bottom/top of the screen.   

Quote from: Pumaman
That's a possibility, but double-click having different behvaiour to clicking the + could start to get confusing. I'll have a think about it.

The current behavior is fine with me.  I would also like to remind you of previous semi-related comments about using single inistead of double clicks here.   With regard to the latter, perhaps single clicks could just select the corresponding tab and bring that page to the front, if the file has already been opened.  Double clicking would then just do what it does now open the file in a new tab and display it. 

Default GFX Driver DirectDraw/Direct3D
When I tried the demo that is part of the installation I got an error because my little computer does not have Direct 3d.  Ok, so I just went and ran winsetup easily enough but what about brand new users?   I don't know if this is just the demo game or it new game also creates a similar default setup.  It's kind of a trival point but something I thought that may be of some interest.

Font Identification
This may not make it in this edition but I would find it handy if the font name, font file, and point size were retained when fonts are imported.  For example if a particular true type font was imported at one point size and later there was a need to reimport it at a larger size, for some other usage, then it would be possible to know which file to import and the prevuious point size would be the basis for guessing what the new point size ought to be.  Perhaps this info could be displayed in the property grid.

Quote from: Pumaman
... thanks for reminding me...

CJ, thanks for all your hard work.   I'm sure you are well aware of this, but for those who haven't had the experience,  every software project of any size eventually gets to a point where it's more difficult to determine what's left to do than it is to do it.   Threads such as this one are very helpful in this respect, so even if a comment or suggestion isn't  adopted this time round doesn't mean that it wasn't helpful or that it lacked merit.   CJ is a very good listener and even though we don't always get what we want, we almost always get what we need.   

Hmmm, that last line is kind of catchy, maybe somebody will make it into a song one of these days ...  ;D 

Has anyone suggested native support for OGG Theora? That would be cool as the linux port can start to support video playback.

I apologize in advance if a function request is beyond the scope of this thread, but it seems to me the drawing functions could use a color getter.  Something like:
function DrawingSurface.GetColor(int x, int y)

Which would return the slot number of the color at (x, y) in a 256 color game or the AGS Colour Number, otherwise.  I know I personally would find it useful if it isn't too complicated to implement.

Quote from: Lyaer on Thu 07/02/2008 01:32:54
I apologize in advance if a function request is beyond the scope of this thread, but it seems to me the drawing functions could use a color getter.  Something like:

Code Select Expand

function DrawingSurface.GetColor(int x, int y)

Which would return the slot number of the color at (x, y) in a 256 color game or the AGS Colour Number, otherwise.  I know I personally would find it useful if it isn't too complicated to implement.

Hear hear, although also working in 16 and 32-bit, please... and a DrawingSurface.FloodFill(int x, int y, int colour), too!

Theora support has been suggested over the years, I think it's a good time to suggest it again though. Wintermute has it, and it's certainly a useful thing. Even if we ignore other platforms, it saves all the codec hassle you have if you want resonably compressed videos. Ideally it'd be able to play theora videos onto dynamic sprites or backgrounds, but fullscreen alone would be an improvement. Since I last saw it discussed the library came out of alpha testing and it has been stable for quite some time now, even if it's officially still beta. I will write a plugin for it for my game if it's not added any time soon, but I think it'd be best off as a core engine feature.

If its not too hard, OGG Speex might be handy for the music ...

Being able to right click on a frame (or a selection of frames) in the view editor and choose flip would be nice.  A keyboard shortcut like 'f' would be even faster!

Along with the suggestion to group the header and the script under a parent node on the 'Scripts' tab, I would find very useful to know which of the 'global' functions (i.e. game_start(), rep_ex(), on_event(), etc) are in use in each module.

Example:

...
[-] Fonts
[-] Scripts
   [-] ParticleEngine
      - repeatedly_execute
   [-] KeyboardMovement
      - repeatedly_execute
   [-] MyCoolModule
      - repeatedly_execute
      - on_mouse_click
      - on_event
   [] AnotherModule (closed node does not show children)
   [-] GlobalScript
      - game_start
      - on_mouse_click
      - repeatedly_execute
...

One click on each of the child nodes would take you right into the module, inside the function.

The motivation is that sometimes one has to open many scripts to see exactly what is being executed every game cycle (in rep_ex ou rep_ex_always, for instance), or to see how the mouse clicks and keypresses are being handled throughout the game.

Loving 3.0 so far!  Just made the switch.

I do miss being able to right-click on the room editor to copy x/y coordinates to the clipboard, so you can paste them into the code.  Is there a reason why that was removed?

-Dave

QuoteCould you add the ability to move the folders themselves as well in the next release

Sounds reasonable to me.

QuoteThats how the AGDs do it. I was hoping to avoid that due to the extra strain on the art team and the increased game size. That does suck that you don't think its worth it.

There's no point adding a feature that's so slow that nobody will use it. However, a potential improvement would be some sort of RawDrawImageTinted function to allow you to tint the room background. Rather than running every frame this could just be done once to avoid the slowness.

QuoteDefault GFX Driver DirectDraw/Direct3D
When I tried the demo that is part of the installation I got an error because my little computer does not have Direct 3d.  Ok, so I just went and ran winsetup easily enough but what about brand new users?   I don't know if this is just the demo game or it new game also creates a similar default setup.  It's kind of a trival point but something I thought that may be of some interest.

I agree that this shouldn't be the case, I'll change it to have DirectDraw as the default.

QuoteThis may not make it in this edition but I would find it handy if the font name, font file, and point size were retained when fonts are imported.

Sounds fair to me.

QuoteCJ, thanks for all your hard work

It's a pleasure  :=

QuoteHas anyone suggested native support for OGG Theora? That would be cool as the linux port can start to support video playback.

I looked into it a couple of years ago, and at the time Theora was still in a beta state so I didn't want to use it. Hopefully now it's been officially released, so it's probably time to look into it again.

QuoteI apologize in advance if a function request is beyond the scope of this thread, but it seems to me the drawing functions could use a color getter.

Quote
and a DrawingSurface.FloodFill(int x, int y, int colour), too

QuoteBeing able to right click on a frame (or a selection of frames) in the view editor and choose flip would be nice.  A keyboard shortcut like 'f' would be even faster

These sound reasonable to me.

QuoteAlong with the suggestion to group the header and the script under a parent node on the 'Scripts' tab, I would find very useful to know which of the 'global' functions (i.e. game_start(), rep_ex(), on_event(), etc) are in use in each module.

Interesting idea. I'll have a think about this one.

QuoteI do miss being able to right-click on the room editor to copy x/y coordinates to the clipboard, so you can paste them into the code.  Is there a reason why that was removed?

It's still there, but only works when the room editor is in "Nothing" mode -- if you're viewing walkable areas/objects/etc you can't do this. It's because in the drawing modes right-click is used to erase, therefore it would a conflict of the right mouse button.

Only thing I can think of since I'm new to 3.0 is the ability to sort sprites by number.
I am constantly adding sprites in different orders (depending on the order i make them) and changing the number so I don't get confused as to what group they belong to. eg: sprites for my ego are numbered 2000-2200 - also in a separate folder anyway).  Call me weird, but I like to be organized.

An option to select recently edited games from within the editor. Such as "File->Open Recent Games->Game 1, Game 2, Game 3" etc... I don't know if anyone else would find this useful, but I know I would.

Hi CJ! :) What would be incredibly handy for us would be an option in the editor to stop the generated .exe having exception handling around the plugin calls, as at the moment if there is a crash inside our AGX plugin the callstack is kicked out back into AGS (I assume into a catch that handles the error dialog) and this can add hours to debugging the plug-in as I need to step through the entire game hoping to find the line it crashed onin stead of it throwing an unhandled exception on the offending line.

Thanks!

lemmy

For managing views it would be nice for the scrollwheel to work without having to click on a frame first (for it to work when you open the tab).  Likewise, it would be useful if the scrollwheel worked when dragging folders or views from the property list.

hmm what about implementing a Frame Editor (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32057.msg413622#msg413622)?

I could imagine that it would be useful.

May I suggest a DrawingSurface.DrawStringWrapped function? Seeing as global and room messages are slipping out of use, DrawMessageWrapped seems a bit limiting (especially as Room.Messages is read-only, so there's no easy workaround). I tend to write my own linebreaking code for most RawDrawing of text, but for some purposes it would be quite helpful.

Quote from: GarageGothic on Tue 19/02/2008 23:40:37May I suggest a DrawingSurface.DrawStringWrapped function?

I've actually suggested this before...or something like it that resolved to the same suggestion. Still, it is something I would like to see.

Quote from: GarageGothic on Tue 19/02/2008 23:40:37May I suggest a DrawingSurface.DrawStringWrapped function?

I would find it very useful too.

I have a suggestion for on_event(). When event == eEventLeaveRoom, data carries the room number the player is leaving. Well, this is kind of pointless to me, because we already know this information, it's player.Room!

IMO, data would be more useful if it carried the room number the player is moving to.

I know it's not good to alter this behaviour, because it has a potential to break existing code, especially considering that many modules use this function. So, I suggest creating an #ifdef for testing at compile time, like this:


function on_event(EventType event, int data)
{
  if (event == eEventLeaveRoom) {
    #ifdef AGS_VERSION_301_beta3
    int room_number_the_player_is_going_to = data;
    #endif
    ...
  }
}


Well, maybe there is a better way to implement it, this is just an idea.

EDIT: On a second thought, one could watch eEventEnterRoomBeforeFadein, and fetch player.PreviousRoom and player.Room... this way he would get both room numbers, where the player WAS and where the player IS... Nevermind.

On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event...we can do this for individual rooms via their respective event handlers, but we don't have a way of doing this in a generic sort of way like we can with BeforeFadein. :=

But DOES player.room say the room the player is going to? At that point, HAS the player actually switched rooms? Maybe it hasn't, we need to take these things into consideration. eEventLeaveRoom is one of those actions that take place in that sort of limbo, isn't it?

IMO, your suggestion can be so specific that a simple variable, to be set at the leaving room and read back by the function, could work perfectly, and changing the current behaviour would bring few, if any, advantages.

Quote from: monkey_05_06 on Thu 21/02/2008 00:23:23
On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event...we can do this for individual rooms via their respective event handlers, but we don't have a way of doing this in a generic sort of way like we can with BeforeFadein. :=

in: on_event

if (before_fadein) { some_global=1; }

in: rep_ex

if (some_global) {some_global=0;
//after fadein stuff
}

Quote from: monkey_05_06 on Thu 21/02/2008 00:23:23
On that note however naltimari, it would be useful if we had an eEventEnterRoomAfterFadein event

Totally agree.

Quote from: Rui "Trovatore" Pires on Thu 21/02/2008 09:19:00
But DOES player.room say the room the player is going to? At that point, HAS the player actually switched rooms? Maybe it hasn't, we need to take these things into consideration. eEventLeaveRoom is one of those actions that take place in that sort of limbo, isn't it?

I thought about that. I think it is being called from the leaving room, but I cant say for sure, since I didnt perform many tests. I will do it, then I'll report here.

Quote from: Rui "Trovatore" Pires on Thu 21/02/2008 09:19:00IMO, your suggestion can be so specific that a simple variable, to be set at the leaving room and read back by the function...

Well, you're right, this could be done, but this is sort of a hack to me, and I try to avoid using globals whenever I can. To me, globals are only justifiable if they are used in many places. In this case, I think it's not justifiable, especially when there's an event where we could hook our code onto.

It would be really nice to have the option to have a 'sidebar' mode, like the letterbox mode, since I have a 16:10 screen (and i'm sure many others do), it is really ugly to have the pixels stretched horizontally when playing a game if you know what I mean.

What I would prefer is to have black bars down the sides of my screen as opposed to having the pixels stretched horizontally.

And there is that other thing... but you know, that can wait till 3.1... The thing that wintermute has that ags doesn't... (subtle hint)...

Great work, love your stuff...

Isn't that something you can set on your monitor/graphics card? How it deals with aspect ratios that don't match the native resolution? Usually you can at least choose between stretch-to-fit and center. You might have to run the 3x filter if you want a 320x200 game to be larger than a postage stamp, though.

The aspect ratio problem is something I've been considering a lot lately. I wanted to create a new thread about it, because I do think it's a big deal, but since it's already being discussed here, I might as well throw in my two cents.

After my beloved laptop with its nice 4:3 screen died miserably, I borrowed a 16:10 laptop and was instantly confronted with the horrors of the new format. Seeing as an increasing amount of users are replacing their desktop machines with llaptops and it's almost impossible to find a 4:3 laptop these days, this IS an issue that AGS must deal with eventually. It may be that some laptops support 'sidebars', but the one I had (a HP notebook with an onboard Intel video chipset) didn't allow any such choice.

In fact, AGS already DOES support resolutions with the 16:10 aspect ratio: 320x200 and 640x400. And it's perfectly possible to create a game that supported both 4:3 and 16:10 screens by creating your game in 320x200 or 640x400 and requiring 4:3 users to check the "Force alternate letterbox resolution" box in winsetup.exe. This would give nice, non-stretched images in either aspect ratio.
HOWEVER, as someone developing a game in 640x480 (albeit with black letterbox borders used for interface and text display) and loathing wasted screen space, I'd like to propose a new feature which at least I would love to use in my game: Optional cropping of a 640x480 viewport to 640x400.
By checking System.ScreenHeight in game_start, the game developer could then reposition GUIs, text displays and similar to custimize the game for the specific resolution. Of course this would require a bit of planning and extra implementation on the part of the developer, but I think it's worth it. Many games using the LucasArts interface could easily have an alternate GUI for 16:10 users, taking up less vertical space and still displaying the backgrounds without any cropping.

What I'm asking from CJ is this:

1) An offset value (Game.ScreenOffset or similar) ranging from 0-40 (in the engine's 320x200 grid), which would position the 240/480 pixels high image within the 200/400 pixel tall viewport of the screen. A 640x480 image with an offset of 15 would thus have 30 pixels cropped from the top of the screen and 50 from the bottom.

2) Winsetup support for the feature (possibly just having the "Force alternate letterbox" checkbox work in reverse if a game is 320x240 rather than 320x200).

The only possible problem I see is that a new resolution (800x500) would have to be implemented for the feature to fully support all existing resolutions. Thanks for reading my lengthy suggestion.

Edit: I actually discussed this issue two years ago (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24993.0), but nobody seemed to really get the point back then. I hope that the almost ubiquitousness of 16:10 laptops (and growing number of widescreen desktop displays) makes it a bit more relevant now.

Hmm, perhaps we need an opposite letterbox mode, whereby if the game is 320x200/640x400 it will run full screen, but if it's 320x240/640x480 it will get black borders at the side. The problem with this approach is that AGS would have to initialize a graphics mode like 384x240 and then paint black bars down the side, and I imagine that the graphics cards don't support any such resolution...

Is it possible to query which formats the graphics card support, choose the closest one to the game resolution and then use it with black bars as necessary and if it is possible to apply the 2x or 3x filter within the allowed resolutions, do so?

Actually, I did figure out that my video card does support such a feature, (intel intergrated graphics) but i don't think many of the less advanced users would figure it out. There is a little dropdown box that has full screen as default and fixed aspect ratio, which sorted out my problems.

It's just less advanced users wouldnt be able to play games in the intended graphical way.

Any chance of getting character avatars able to be placed in room edit for the next beta, CJ?  That would be a very useful little update indeed!

Quote from: Pumaman on Sun 24/02/2008 13:54:53
Hmm, perhaps we need an opposite letterbox mode, whereby if the game is 320x200/640x400 it will run full screen, but if it's 320x240/640x480 it will get black borders at the side. The problem with this approach is that AGS would have to initialize a graphics mode like 384x240 and then paint black bars down the side, and I imagine that the graphics cards don't support any such resolution...

But please, please, please, for those of us who'd like to make use of the full screen area in either resolution, wouldn't it be possible to force a vertical cropping of a 640x480 screen as I suggested above? The engine does seem to support this kind of thing already (though currently it's an error rather than a feature). This is what I got when running Blackwell Unbound windowed 1280x960 with the 2x filter on a 16:10 laptop:

Normal 4:3 resolution:
(http://www.2dadventure.com/ags/unbound_640x480_menu.png)

Windowed 2x resolution on 16:10 monitor:
(http://www.2dadventure.com/ags/unbound_1280x960_menu_2x.png)

As you can see, here the top op the screen has been cropped off by the engine and the GUI has moved down 40 pixels. If we as developers had control of this behaviour we could easily design our games to be compatible with either kind of screen.

I agree with GarageGothic entirely and believe it is a necessary step forward for AGS development. This whole force letterbox resolution thing has always felt a little loose and while it might be appropriate for older games which were developed for specific aspects I believe now is the time to support automatic aspect correction that is put in the designer's hands.

I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

It's quite easy to understand that this kind of developer control would offer uniformity and consistency to a game and its options rather than force the player to tinker with a completely separate application, when all he/she wants to do is play a game that works.

Cheers,
Paul.

Quote from: subspark on Thu 28/02/2008 20:15:42
I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

I would love to have the settings incoporated directly into the game, but if I remember correctly the reason for having a separate application for the game's setup was to allow people to change things if the game engine was unable to run.

There are possible workarounds, but it seems like a good idea to at least keep the current gamesetup around. :)

I agree however I feel my point still stands. I'll tell you why.

The only obvious reason why AGS games might not run correctly, or at all, is because the resolution of a game does not account for the different aspect formats or the color depth might not be supported. I you haven't noticed already, the few options in the game setup exe control the things in a game that a developer should account for when developing the game. If a developer chooses to make a 32 bit game, then the option to downgrade the game to 16 bit might not sit well with developers who intend their game to be enjoyed in its true glory. I think that option is by far obsolete. As for resolution, seeing there are only 2 mainstream display formats, 4:3 and 16:10, it is not difficult to imagine support for the developer to make their game adjust itself, automatically, for the monitor the game is being played on.

As for windowed support, this option could also be accessible in the game. Theres no reason why full screen gameplay couldn't switch to windowed gameplay on request rather than having to relaunch the entire game after tweaking settings in the game setup exe. As for sound, this is unlikely to be the cause of a game not running at all these days.

I feel that the game setup exe is a little hackish for todays times and lacks the professional polish that should be seen in a state of the art Adventure game. Having said that, the game setup exe does have its place. Older games not designed to work with both 4:3 and 16:10 screen formats automatically, will always come with an external setup exe, although most of the AGS games I have downloaded choose not to distribute their setup exe.

I think that a game developer should be able to choose whether to include an Editor GUI based game setup or a separate executable depending on what kind of polish the developer intends to give their game.

Cheers,
Paul.

To avoid confusion, I should say that I've never mentioned automatic  aspect ratio correction. I always imagined my suggestion of vertical resolution cropping being implemented as a reverse version of "Force alternate letterbox resolution".

In response to subspark, I think that an external setup program is stilll by far the simplest and techically safest way of controlling game settings - see the automatic detection in early Sierra games for Windows for examples of compatibility hell. There's way more to resolution support than simply aspect ratio. Your video card may support a certain resolution, but perhaps your display doesn't and all you see is a black screen. Or if you run your game windowed you might very well want to use the 2x or 3x filter to avoid straining your eyes. Distributing your game without a setup file is just asking for trouble.

I think the option should still be given to developers to control how their game should display these options.

In all honesty its time for AGS to move with the times and despite the obvious points you have expressed about keeping the game setup exe, my suggestion is simple: Allow the very same options to be incorporated as a GUI in the editor so that those who choose not to distribute the lackluster setup executable in their game installs can present those options without feeling tacky or out of date.

I say lackluster in the sense that it detracts from the game experience and is a token mark of the use of the AGS engine. Before anybody starts condemning me for AGS blaspheme I will say this: While some may argue that removing the need or providing an alternate method to the game setup exe is like choosing to leave CJ and AGS uncredited this is not true and is not the reason for leaving the setup exe out of a game. The whole point of an AGS game is the "game" itself and not what its built in.

Since the game engine is irrelevant to the player in the eyes of a developer, all of the game's settings and options should be accessible from within the game the way the developer wants to present it rather than be forced to present their players with a static and aging options program.

If a developer chooses to include the game setup exe instead of making his/her own GUI with custom graphics this should continue to be supported, however in this case, one method should not cancel the other out, but act as an alternative.

I imagine adding support for a GUI based options screen wouldn't be exceedingly arduous, would it Chris?
Can anyone else see the importance of housing in-game settings inside the game or are we all still stuck in the 90's?

My apologies for being so direct, guys, but I have to be the voice of truth once in a while.  :)

Cheers,
Paul.

Maybe you would make your argument more effectively if you didn't come off as an arrogant ass who preemptively belittles other points of view.

Apologies for being so "direct", but... *yawn*

Has anyone denied that the ability to set the config options from within the game would be nice? No. Then why the attitude? However, since save games aren't even compatible across config settings, perhaps changing settings mid-game isn't as easy as all that. (A few people recently asked whether it might be possible to remove this restriction, so stay posted.)

Meanwhile, there's nothing to stop you from writing your own setup app if you don't like the default one provided by AGS. The configuration is stored in a plain text file.

As Snarky mentioned, as long as savegames do not support changing resolutions, having the ability to change resolutions in game would be useless ;(.

I wasn't being benevolent to GarageGothic, Snarky. I agreed with his reccomendation that the setup exe has its place. I do tend to ramble on a bit sometimes so you'll have to forgive me for that.

Why don't you give me a break Snarky, please. Honestly mate, you seem to read into my text reply as if I am speaking it aloud in some smartass tone of voice.
I'm sorry but may I suggest you learn some restraint because your reaction here is clearly out of place.
I don't have an issue with you, why have you got it in for me?  ???

QuoteAs Snarky mentioned, as long as savegames do not support changing resolutions, having such a feature in game would be useless ;(.

If this is the case I guess it's not as straightforward a process as I imagined. As Snarky mentioned, however, there is scope to work toward removing this limitation. Cool.

Cheers,
Paul.

[EDITED by mod] Double posting.

There's no reason that the setup options couldn't be available for use in-game, but the main reason for having an external setup application has already been mentioned -- imagine this situation:

You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

Quote from: Pumaman on Fri 29/02/2008 21:12:56
There's no reason that the setup options couldn't be available for use in-game, but the main reason for having an external setup application has already been mentioned -- imagine this situation:

You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

yes but there could be an array (system.SupportedResolutions) or something else. Then check in-game what resolutions are available and just show these ones. And in case of emergency you could use the external setup.

This is just a curiosity on my part, CJ, but I'm wondering how challenging it would be for you to allow a toggle for dialogs that would allow (or not allow) action going on in the background while the dialog options are available?  I ask because, as it stands, environmental effects and background animations will just freeze-frame while you're selecting a dialog option and it looks a bit odd.  Would this be something overcomplicated to change, or to at least provide a setting to switch between the current method and a non-blocking one?

Quote from: ProgZmax on Fri 29/02/2008 22:03:05
This is just a curiosity on my part, CJ, but I'm wondering how challenging it would be for you to allow a toggle for dialogs that would allow (or not allow) action going on in the background while the dialog options are available?  I ask because, as it stands, environmental effects and background animations will just freeze-frame while you're selecting a dialog option and it looks a bit odd.  Would this be something overcomplicated to change, or to at least provide a setting to switch between the current method and a non-blocking one?

If animations could be played while the dialog options are up, that would be a HUGE boon.  It's always looked strange that everything on the screen freezes when the dialog options appear, especially during environmental effects like rain.

Yep, it's useful if you want to make M(ags)trix. Auto-bullet time effect on dialogs.

Yeah, there's no particularly good reason why the game is paused while the dialog options are displayed, it has just "always done it this way". I suppose it would make more sense for the game to be blocked but with rep_exec_always running (and thus animations, etc as well) like in most other blocking scenarios.

In that case, I think it would also be useful to have a variable to track whether a dialog is running or not!  Then you could do nifty things like make the person being talked to get bored if you wait too long to respond, or tweak idle animation times...lots of things, really!  8)

Quote from: ProgZmax on Fri 29/02/2008 22:19:56
In that case, I think it would also be useful to have a variable to track whether a dialog is running or not!  Then you could do nifty things like make the person being talked to get bored if you wait too long to respond, or tweak idle animation times...lots of things, really!  8)

I had to make my own dialog engine because of this... well, actually there are a couple of other issues, like the user does not have access to his inventory during a dialog, because every GUI is 'disabled'.

If only the dialog data structures were available through scripting... that would be great.

Quote from: subspark on Thu 28/02/2008 20:15:42
I would like my gamers to stay IN the game and out of the gamesetup execultable as much as can be managed. Having said that, perhaps it's time for the controls in the gamesetup to be incorporated as default GUI's in the game editor itself that can be turned off at will and customized to fit the game's appearance.

That's an interesting topic. I agree with subspark that we should have a way to change the resolution in-game, through scripting/custom GUIs. But resolution-independent savegames should be discussed first! Otherwise it would be somewhat useless, if you know what I mean...

Quote from: Pumaman on Fri 29/02/2008 21:12:56
You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

It would be up to the game designer to prevent this, confirming that the resolution actually works, just like Windows XP does, for example. If the user can't confirm, the game 'downgrades' to the old resolution.

And, regardless of where the display configuration is, the 'mrs. player problem' could happen anyway, not because she decided to change the resolution, but because the default resolution, chosen by the game designer, did not work, for whatever reason.

To prevent that, there should be a 'safe mode' shortcut to the game, in which the game would be invoked in windowed mode, and THEN the user could be led to the setup screen.

Couldn't the in-game setup and the regular WINSETUP.EXE work in tandem?

Quote from: naltimari on Fri 29/02/2008 22:35:56
I had to make my own dialog engine because of this... well, actually there are a couple of other issues, like the user does not have access to his inventory during a dialog, because every GUI is 'disabled'.

Me too!  I like my custom dialog system because I can use normal scripting for advanced things and not have to resort to run-script X.


My (completely unrelated) suggestion (I haven't tried 3.01 yet, so forgive me if any of this is already addressed):

I have lots of animations and I get really tired of
-click "new frame"
-double click blank frame
-click on sprite window
-use scroll wheel to scroll down
-double click appropriate sprite
-repeat

For one, I think that when you double click a blank frame to open the sprite window, I shouldn't have to click on it to scroll it.  Two, I think that the last frame used should be centered in the window instead of placed on the bottom or the previous scroll position should be retained.

[Next useless paragraph removed, because as nat points out.  I'm dumb!]

Quotend changes the resolution to 640x400 using your GUI

Not at all my good Chris. As I mentioned earlier it would be up to the game developer to enable what game modes to display to the player maximizing compatibility for the developer's intended audience. Just as Naltimari reinforced.

Ideally I imaged that the developer could choose to use either a fully customizable in-engine dialog based setup screen or the default basic dialog executable. Not in tandem, but rather an alternative to one another.

Paul.

Quote from: Vince Twelve on Sat 01/03/2008 00:00:23
And most importantly, since almost every animation I set up uses sequential sprites, it would really be useful to have a shortcut (either a button or a keystroke) to automatically make the next frame set as the next sprite.

At the sprite window, select multiple sprites and right-click, you should see an option 'assign to view' in the context menu. If this is what you're looking for, it's there since 2.72 I guess... :)

... wow.  I've wasted so much of my life.  :=  Thanks naltimari!

Quote... wow.  I've wasted so much of my life.

Ags 3.0 is full of handy little goodies now! :)

Cheers,
Paul.

Quote from: naltimari on Fri 29/02/2008 22:41:13

Quote from: Pumaman on Fri 29/02/2008 21:12:56
You create your fancy in-game setup options dialog. Mrs Player downloads your game, starts it up, and changes the resolution to 640x400 using your GUI. It turns out her monitor doesn't support that resolution, so now whenever she tries to start the game, she gets an error. She can't go into Setup to correct this error, because it's inside the game. End of story.

And, regardless of where the display configuration is, the 'mrs. player problem' could happen anyway, not because she decided to change the resolution, but because the default resolution, chosen by the game designer, did not work, for whatever reason.

But in that case, she could just run setup.exe and change it, no? With the configuration outside of the game, getting a setting wrong can never make it impossible to fix the configuration, like an in-game configuration system potentially could (especially if you leave it up to the game developers to put in safeguards).

QuoteBut in that case, she could just run setup.exe and change it, no?

Thats quite true, but should we not consider the possibility of building games with a higher minimal requirement or should all our games always be defaulted back the the minimal standard established last decade? I don't think this has changed since anyway, has it?

Cheers,
Paul. :)

Just a thought:

What would be ultra fabby, would be the ability to multi select a bunch of frames in the sprite manager, and then be able to import over them all a list of gif files in the order of the file select order -> sprite numbers. If less were selected in the file window, it would only replace as many frames as were selected, if more were selected, it would add the remainder as new frames after replacing the selected frames.

This means you'd no longer have to import the sprites as new sprites, reassign to the view/views, then delete the original.

No biggie at all, just when any slight sprite edits happen with long animations (walk cycles etc) it's quite a cumbersome process to replace them at the moment.

:)

Thanks!

lemmy

Well I was thinking that if AGS could store the filename and directory of a sprite on import, then you could right click a sprite folder in AGS Edit, and choose 'Update Sprites', or something?
Assuming of course that you saved over your original sprites in the directory from which you imported them from.

Cheers,
Paul.

If the savegame compatibility issue was solved, and RunAGSGame was made to re-initialize the engine, as monkey_05_06 suggested here (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33772.0), it would be possible to do exactly what subspark is asking. Assuming these two changes were made to the engine, you could let the player change the graphics settings from an in-game options menu, write them to acsetup.cfg using File functions, save the game in progress, then restart the entire game using RunAGSGame (whereby the engine would re-initialize using the settings from the .cfg file) and then restore the savegame to resume gameplay.

Brilliant, sir! Brilliant.
Would this be too hard, CJ?

Cheers,
Paul.

Adding the ability to set the Visible flag of a gui from the editor would be nice, since most people don't want all their guis visible by default and have to disable them in game_start.  Having the flag accessible in the editor would avoid this.

Thats an interesting idea and seems to fit with the 'user friendly' trend we have going here with AGS 3.0 system so I agree; it would be rather convenient and this is something I would also like.

Paul.

Scenario: I modify a script header.
I try to test the game, and the editor rebuilds all the rooms. Then, the parser spots an error in the script...

...would it be possibile/easy to check the script before the whole rebuild thing?

Bye ;)

Quote from: GarageGothic on Mon 25/02/2008 19:00:25
But please, please, please, for those of us who'd like to make use of the full screen area in either resolution, wouldn't it be possible to force a vertical cropping of a 640x480 screen as I suggested above?

I, myself, would prefer a horizontal cropping of the image on 4:3 monitors, with 16:10 monitors getting the full image.  In Garage's example, some nice touches, like a fire escape, the top of the paintings and the top of the kitchen archway, are cut off when vertically cropped.  Or, better yet, letterbox the 16:10 image in the 4:3 frame, as is already done.  This has worked for DVD's, so why not games?  The whole point of a widescreen monitor, in my mind, is to see more image, not less.

I should also point out that those of us with Nvidia graphics cards are unable to run our widescreen monitors in resolutions lower than 1024x768 without stretching, due to a bug that Nvidia refuses to fix.  Using the 2x and 3x filters sometimes gives me errors in games about using an invalid coordinate point or something.  Being able to play 4:3 AGS games without stretching would be a nice side effect of having higher max resolutions.

First post, anyway.  I love playing AGS games, and look forward to playing more in the future.

In response to InSPIREd (welcome to the forums, btw!), the screenshots I posted weren't examples of how I wanted the cropping function to work, they're actual in-game screenshots showing how AGS due to a bug sort-of already supports (albeit flawed) cropping and repositioning of the GUIs.

My point wasn't that 16:10 monitors should show less of the artwork - I doubt any background artist would like that - but that we should be able to use the full screen area in either resolution. Many games have large GUI/text displays that cover part of the screen. By allowing us to customize those to either resolution, we could make the best of both aspect ratios.
Your comparison to DVDs is pretty apt, but let me flip it around. When viewing a subtitled DVD on a 16:10 monitor, I'm fine with the subtitles covering part of the image, because there's no other place to put them. But if I watch a widescreen DVD on a 4:3 television with large letterbox borders, it'd better give me the option of displaying the subtitles in the huge black area underneath the image instead of covering the bottom third of the movie image. Unfortunately that's rarely the case.

Edit: Are you saying that Nvidia doesn't support 640x400 resolution? Or just that it doesn't add black bars on the side for 4:3 games running in resolutions lower than 1024x768?

QuoteBy allowing us to customize those to either resolution, we could make the best of both aspect ratios.

GarageGothic is right and as I have suggested a few times already I think we need to be able to control 'screen layout' in the editor along with the other features found in the default game setup exe.

And I'll say it again to be just to be super clear, I don't believe we need to break compatibility of older games or remove what has already been established by adding these new features.  :)

Cheers,
Paul.

QuoteI should also point out that those of us with Nvidia graphics cards are unable to run our widescreen monitors in resolutions lower than 1024x768 without stretching, due to a bug that Nvidia refuses to fix.

I have an NVIDIA Geforce 6600 gt.  I have a Samsung SyncMaster 22" widescreen monitor.  I do not have this problem.  Perhaps you need a different driver version for your video card, monitor, or to check some sites about this.

QuoteUsing the 2x and 3x filters sometimes gives me errors in games about using an invalid coordinate point or something.

This pretty much tells me you have an issue with your video card drivers, since I've never had any errors whatsoever when choosing filters (any filters).

I honestly think that some of you people with widescreen monitors should check and see if there are drivers you can get to correct your problems, since it doesn't seem to be a universal issue with widescreen monitors -- or maybe mine is just hyper fantastic, I don't know!  8)

I'm in love with my two 30" Apple Cinema Displays but agree entirely with ProgZmax in that support should continue for 4:3 in all areas of the computer software industry until 4:3 hardware is phased out. I don't think this will happen for a further half decade yet.

So...With a little hope, we beloved AGS developers may finally gain control over both 4:3 and 16:10 aspect ratios.
At the end of the day of course, this lies very much in CJ's capable hands.  ;)

Cheers!
Paul.

Quote from: ProgZmax on Mon 03/03/2008 01:15:26
I have an NVIDIA Geforce 6600 gt.  I have a Samsung SyncMaster 22" widescreen monitor.  I do not have this problem.  Perhaps you need a different driver version for your video card, monitor, or to check some sites about this.

I have a Geforce 7600 GT and a Samsung SyncMaster 19" widescreen monitor.  The "flat panel scaling" option in the Nvidia control panel did not work, no matter what settings I tweaked  So I updated my drivers, which made things worse.  Whereas before, my monitor's native resolution of 1440x900 worked perfectly, the updated drivers treated 1440x900 as a 4:3 resolution, stretching it off the sides of the monitor.  I was able to fix this and subsequently get windowboxed 4:3 resolutions as low as 1024x768 through some registry tweaks and an older version of the Nvidia control panel (but not older drivers).  However, this method does not work for resolutions lower than 1024x768.  Things below that res do run, but they are scaled and stretched into a very blurry result that is not pleasant to look at.  I have since checked the release notes of every single driver release since, but nothing about fixing it.

Quote from: ProgZmax on Mon 03/03/2008 01:15:26
This pretty much tells me you have an issue with your video card drivers, since I've never had any errors whatsoever when choosing filters (any filters).

It was an internal AGS error, actually.  Oh well, I can't seem to replicate it now!  :)  But now there's a new problem.  The game I was trying to run, La Croix Pan, will not run in a window for me.  I have it set to run at 1280x800 in a window with 2x scaling, but it instead forces my monitor to a letterboxed 640x480 fullscreen mode, even though I have "Force alternate letterbox resolution" turned off.

Quote from: ProgZmax on Mon 03/03/2008 01:15:26
I honestly think that some of you people with widescreen monitors should check and see if there are drivers you can get to correct your problems, since it doesn't seem to be a universal issue with widescreen monitors -- or maybe mine is just hyper fantastic, I don't know!  8)

Your monitor is hyper fantastic.  ;)  Googling "Nvidia Flat Panel Scaling" turns up a lot of people having my problem.  And even on Nvidia's own forums has it been brought up: http://forums.nvidia.com/index.php?showtopic=16588 (http://forums.nvidia.com/index.php?showtopic=16588).

I'm getting off topic.  In short, I'd still love to see higher resolutions and different (or better, as the case may be) aspect ratio support in AGS.

QuoteThings below that res do run, but they are scaled and stretched into a very blurry result that is not pleasant to look at.

I don't know about the stretching, but try using the Analog output from your monitor rather than DVI to get rid of the blur.  The blurring at low resolutions (for me only below 640x400) occurs due to refresh rate issues that widescreen monitors don't bother with.  When I switched from DVI to Analog the blurriness was completely gone.  It's worth a look if you haven't yet.

What do you mean by blurriness? The interpolation between scaled pixels or is it an artifact created through the a/d conversion? All graphics tech here in my studio is digital except for my third monitor which is a 4:3 Samsung SyncMaster 913v LCD but I don't know what I'm looking for so I can't hunt for a comparison.

Cheers,
Paul.

SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

Here are some suggestions I got using ags 3.0.1beta3:

- a sprite preview window
- proberty window: ability to change the sprite slot number
- import multiple sprites: ability to set transparency (like in "Import new sprite from file")
- export sprite to file: ability to choose bit-depth of the created file (gif, png,...)
- property window and work space should be updated when I single-click an entry in the project tree (ne need to double-click)
    In general I think there shouldn't always popup a new tab when click on smth in the prj tree. Maybe its more handy to make it more the Firefox-way.
- property window: width should be above height (no entries between - I know it is sorted alphabetical but that doesn't suit)
- ability to use normal scripting code in dialogs
- sound and music import
- ability to save rooms(-scripts) also when having compiling errors.
- ability to open translation-files within the editor. Just without syntax highlighting.
- and I think there are some options (property window) which are [outdated] because there is less use for them and they were for people who used the ie-editor. f.e. characters blinking view - I don't see the use for that. It just confuse people. You can easily create a view for a blinking char. Is there really need for an extra option?

Finally one question:  How do I import plugins?

I hope you can realise some of these suggestions

LtSm

EDIT:
- possibiliy to change transparent color of a sprite also when its already imported.
- ability to open more than one window (like having sprite manager and guis opened at once)

When I get more suggestions I will create a new post.

I would really love to see an enhanced file manager that enables the author to create custom data libraries instead of compiling most of the game data into the executable. I imagine the author creating a project tree in windows (a series of personally organized folders and files), and AGS would read the tree and draw game data directly from it using a file browser.

The author would choose a file extension for their data library or libraries and could enable encryption. When the project compiles, AGS copies the files in the windows project tree and bundles them up into a neat data package.

There are two distinct advantages to be had from this idea:

[1] The author could release their game on a digital distribution system like Steam and provide updates to their players that don't require them to redownload the entire game exe. You would essentially diff the data libraries.

[2] The author has more control over how their game data is distributed and can better manage projects where multiple people are involved. An SVN repository could be created, for example, and daily builds could be done with the latest file revisions that are checked in by fellow team members throughout the day.

Heres how I would set up my data package:
(http://www.shuugouteki.net/paul/Images/project_datatree.gif)

I'm not 100% sure that all this could be done with a plugin but I get the feeling that AGS already has the ability to use data from outside of the editor. That said, I would much rather see an official overhaul of the project data system.

Food for thought if nothing else.

Cheers,
Paul.

Quote from: subspark on Tue 04/03/2008 13:35:09
[2] The author has more control over how their game data is distributed and can better manage projects where multiple people are involved. An SVN repository could be created, for example, and daily builds could be done with the latest file revisions that are checked in by fellow team members throughout the day.

Hi, just a quick note about this: having problems with Perforce (natively supported by AGS), we SOTE-guys begun using SVN with our project.
I wasn't sure of how it would have been working with big binary files like acsprset.spr - about 180 Mb at the moment - but I decided to try and we're very satisfied: SVN uses binary diffing with non-text files, and performance is much better than expected.
We frequently commit/update using a linux home server on my ADSL connection (max upload 40 Kb) and we're very happy of how it's working.
We try to not mess-up with conflicting updates, but for now we didn't have any problem. And hey, if something will go really bad, we can revert to a previous version :)

So, while I think that it would be really cool if AGS could get resources directly from a file system directory tree (moving and updating stuff would be easier), I have to say that isn't a critical feature for using a SVN repository (as I was frighten of).

Baaad english today, greetings from Italy :)

Quote from: subspark on Tue 04/03/2008 13:35:09
I would really love to see an enhanced file manager that enables the author to create custom data libraries instead of compiling most of the game data into the executable.

Very interesting ideas, and it's very good to find these kind of concerns in the forum. They reflect the fact that (1) modern games should be (actually, must be) updated after their initial release and (2) games usually aren't made by a single person, at least not anymore.

I'm all for it.

Quote from: subspark on Tue 04/03/2008 13:35:09
[1] The author could release their game on a digital distribution system like Steam and provide updates to their players that don't require them to redownload the entire game exe. You would essentially diff the data libraries.

Or you would 'diff' the whole package, (game+data), and distribute only the 'patch' for winsetup.exe to 'apply' to the game. I dont know how Steam works, but I assume it's not free, so not everyone would be interested.

Quote from: subspark on Tue 04/03/2008 13:35:09
[2] The author has more control over how their game data is distributed and can better manage projects where multiple people are involved. An SVN repository could be created, for example, and daily builds could be done with the latest file revisions that are checked in by fellow team members throughout the day.

SVN integration could be implemented as an editor plugin, I guess. It's a very good idea. I was looking for a version control solution the other day, and SVN is coming out on top, along darcs (which I haven't evaluated thoroughly).

Daily builds would be very easy, I guess, since Game.agf is an XML file, and keeps the paths to every single resource in the game (sprites, sounds, fonts, etc). So, implementing daily builds would be a matter of (a) calling the editor with the 'compile' command switch, and (b) letting it update the resources to which Game.agf points to. (a) is already present in AGS, I dont know about (b).

Quotehaving problems with Perforce (natively supported by AGS),

CJ Fixed the Perforce BUG when I reported that AGS wouldnt launch. It was suggested by Chris that i rename a dll in the perforce directory to 'iforgethename.dll.no'. I can't remember if this workaround had been eliminated by now.

QuoteWe try to not mess-up with conflicting updates, but for now we didn't have any problem. And hey, if something will go really bad, we can revert to a previous version

I'm glad to hear you've found a system that works for you. I can't say that I would be satisfied with the same method because my artists would end up waiting around for one another to finish committing their changes to the ever evolving 'acsprset.spr' where as if the data was external to the editor, single sprites could be upgraded.
With a data management system like the one I have suggested, members could indeed better manage their files. Not to mention the would-be unnecessary trend of having only one guy use the engine and import all of the data.

I am a project lead and an artist so you can imagine the drama of having to essentially halt production for me to go in and make technical changes to the rooms, fonts, GUIs and oversee all the work that has been done. Eeaargh! :)

My idea of customizing your own data packages (tree/extension) is to make the game more your own and less 'everybody else's'.

Cheers,
Paul.

Edit: Oh and about Steam, I have long-time friends at Popcap Games who started out as a small games development studio much like my own here in Sydney. They chose to contact Valve software about securing the SteamSDK so that they could distribute their games to a larger audience. Adel was the project manager for one of their early games I forget which one now, loaded up their sales tracker each week for about 8 months to find that 'larger audience' was something around the 270,000 customer mark. In less than a year, they pulled in over a million in sales and something like 7 or 8 percent of their gross profit went to Valve for their service. From memory, it was unusually small being a single digit percentage. This is extremely lucrative to me and my team and if I am going to invest decent money into developing our games then this is an avenue I would like to explore. Company growth is a prime objective of Valve's, through their support of a 3rd party market. So again to sum up my suggestion, I would really love to see AGS become more compatible with 'diffing' and 'merging' data in a way that feels personal.

Quote from: subspark on Tue 04/03/2008 22:21:37
CJ Fixed the Perforce BUG when I reported that AGS wouldnt launch. It was suggested by Chris that i rename a dll in the perforce directory to 'iforgethename.dll.no'. I can't remember if this workaround had been eliminated by now.

Mmm if I remember I had problem with Perforce by itself.. I don't remember about AGS not starting. By the way, I'm not sure of the advantages/disadvanteges of using SVN against something "AGS supported". I mean, to sync binary files you had to do stuff out of AGS if I remember well my test... so, the generic and already experienced SVN/TortoiseSVN method shouldn't be worse that the other one? Or am I missing something BIG?  ???

Quote
I'm glad to hear you've found a system that works for you. I can't say that I would be satisfied with the same method because my artists would end up waiting around for one another to finish committing their changes to the ever evolving 'acsprset.spr' where as if the data was external to the editor, single sprites could be upgraded.

Sure, I can understand your frustration about this... I suppose our development is a bit more timely relaxed and, btw, usually only my pal BobaFonts works on the sprites, and 90% of the times I only mess with the scripts, so our collaboration is generally "easily split".

Quote
I am a project lead and an artist so you can imagine the drama of having to essentially halt production for me to go in and make technical changes to the rooms, fonts, GUIs and oversee all the work that has been done. Eeaargh! :)

Yes I sure imagine that :)
IMHO AGS 3 is by itself a step forward in the right direction (XML, separated script files for rooms...) and I'm sure that CJ will go on in improving the collaborative-work-friendness of AGS (while I can understand that it might not be high-priority).

Good luck with your projects, Paul!

D.

QuoteGood luck with your projects, Paul!

Thanks mate! And the same to you all :).

Initially, I imagined that all this could be done through a plugin, aside from the encryption of a personalized data library, but AGS can essentially draw things such a sprites from a working directory can it not? Isn't that one of the things raw draw is good for after all?
As for the custom library files, perhaps AGS can be scripted to read data from a zip archive with a renamed extension?

What is the scope of AGS and it's reading and writing of files on disk? Am I dreaming or can some of this stuff already be achieved without the official support of a new feature?

Cheers,
Paul.

Quote from: subspark on Mon 03/03/2008 05:14:01SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

I believe the reasoning behind this is that walkable areas/regions are governed by a 16-color bitmap, which is also the reason why we can't have overlapping areas. It's been suggested many times that this behavior be changed, but it's not something that would be a "quick 'n' easy 'fix'".

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- export sprite to file: ability to choose bit-depth of the created file (gif, png,...)

I'd actually like to voice my support for this suggestion because IIRC even if I'm running an 8-bit game, files exported are still at either 24- or 32-bit. Best-case scenario here (IMO) would be to allow exporting to 8-, 16-, or 32-bit with the default (selected) option being the current game color-depth.

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- property window and work space should be updated when I single-click an entry in the project tree (ne need to double-click)
    In general I think there shouldn't always popup a new tab when click on smth in the prj tree. Maybe its more handy to make it more the Firefox-way.

The decision to make everything open in new tabs was intentional and I've actually come to prefer it this way. One possibility might be an 'Open in current tab' option from the right-click menu to stop everything opening in new tabs?

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- property window: width should be above height (no entries between - I know it is sorted alphabetical but that doesn't suit)

As you've said, everything is sorted alphabetically. It's perhaps not the most logically intuitive ordering, but I'd say better for the editor to remain consistent in this behavior throughout. I'd much rather every property window be sorted alphabetically than each one being sorted by some other, altogether more arbitrary scheme.

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- ability to use normal scripting code in dialogs

I'm not sure CJ is planning on a dialog revamp for the 3.0.1 release, but he's been promising one for a while, so I imagine it won't be too much longer before this sees an update as well.

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- sound and music import

I can appreciate the desire to be able to "manage" your audio files from within the editor as we can with everything else, but I wouldn't say it's too high a priority. Especially with the extremely promising Audio Manager plugin (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32937.0) that smiley has so graciously provided us with.

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- ability to save rooms(-scripts) also when having compiling errors.

The 'Save room' option doesn't work if there are compile errors? AFAIK you should be able to save the game even in instances where it won't compile properly.

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- and I think there are some options (property window) which are [outdated] because there is less use for them and they were for people who used the ie-editor. f.e. characters blinking view - I don't see the use for that. It just confuse people. You can easily create a view for a blinking char. Is there really need for an extra option?

Making characters blink periodically is an extremely common option. Having the view automatically linked in and run is really just a nicety. I mean, do we really need an Idle view? :P

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- possibiliy to change transparent color of a sprite also when its already imported.

This would require the sprite to be reimported anyway, so I don't think there would be great benefit. Especially if the source file had moved, been renamed, deleted, etc. it could cause problems.

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- ability to open more than one window (like having sprite manager and guis opened at once)

Erm...isn't this the reason for tabs? :=

Cheers,

monkey

Thanks Monkey. I was hoping somebody could reply before I took over the thread with posts.
Lt. Smash, I agree with monkey in every case and I think its best that the program behavior your questioning remains untouched.
We like those features the way they are. Thats not to say however that other things can't be improved or redesigned. ;)

What does anyone else think?

Cheers,
Paul.

Quote from: subspark on Mon 03/03/2008 05:14:01
SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

I totally second that- I had quite a hard time of hit-and-miss sifting through colours now that pcx is no longer supported. A colour picker would greatly add to the comfort.

Quote from: monkey_05_06 on Wed 05/03/2008 01:14:39

Quote from: Lt. Smash on Mon 03/03/2008 22:19:11- ability to save rooms(-scripts) also when having compiling errors.

The 'Save room' option doesn't work if there are compile errors? AFAIK you should be able to save the game even in instances where it won't compile properly.

I can save the whole game. But when I create a new room and want to save it or when I try to compile the game the error message appears. It's the same as here (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33624.80) sadistyk and rui have.
I don't know what the problem is. Tell me please if you know.
I imported some guis and the global script from another game.
I think in the error message should be written where the problem is and how it can be solved.

Quote from: Ghost on Wed 05/03/2008 05:22:03

Quote from: subspark on Mon 03/03/2008 05:14:01
SUGGESTION: I think an 'Add Walkable Area/Region' function coupled with a color picker would be ideal for those of us who require a little more than 16 seperate areas. This of course would still be restrained by a hard coded limit but not that of 16.

I totally second that- I had quite a hard time of hit-and-miss sifting through colours now that pcx is no longer supported. A colour picker would greatly add to the comfort.

If walkable areas could be created from DrawingSurfaces/DynamicSprites by code, then the color-picker would already be implemented. That's what I think is the best way to do this, although it's not high-priority to me.

Are you suggesting we code in our walkable areas? I'm not a programmer and setting up rooms is usually, at least for our team, the artist's space. I wouldn't want the programmers treading on the artist's toes or vice versa. This is poor workflow and bad principle.

If we are to be awarded with additional walkable areas, then I believe the artists should also be able to create them. ;)

Cheers,
Paul.

Huh? What I'm saying is...

(1) Walkable areas (say, up to 32) can still be implemented the same way they are now...
(2) Programmers can access these areas in script (via accessing a DynamicSprite/DrawingSurface) and use that to change them in all ways...
(3) Programmers could also add new walkable areas, but they wouldn't have to use raw geometry functions (DrawLine, DrawRect or similar), they could load an image from the hard-drive or from the AGS sprite manager (via the sprite-slot) and use that one as a new area...

That's what I was thinking... ;) Anyways, I wouldn't need this stuff, three walkable-areas were always enough for everything I did.

Quote from: dkh on Wed 05/03/2008 19:38:36
(1) Walkable areas (say, up to 32) can still be implemented the same way they are now...
(2) Programmers can access these areas in script (via accessing a DynamicSprite/DrawingSurface) and use that to change them in all ways...
(3) Programmers could also add new walkable areas, but they wouldn't have to use raw geometry functions (DrawLine, DrawRect or similar), they could load an image from the hard-drive or from the AGS sprite manager (via the sprite-slot) and use that one as a new area...

I agree with these suggestions. I think programmers must always have 'backdoors' for anything that can be done 'interactively' in the editor. This way, missing functionality can always be implemented by someone as an editor plugin.

Additionally, I would like GetWalkableAreaAt() to use Room coordinates, not Screen coordinates, as it is right now. If someone can point me to a hack that shows if a point is inside an off-screen walkable area, I would like to know (right now I'm using regions).

Quote from: naltimari on Wed 05/03/2008 20:34:52Additionally, I would like GetWalkableAreaAt() to use Room coordinates, not Screen coordinates, as it is right now. If someone can point me to a hack that shows if a point is inside an off-screen walkable area, I would like to know (right now I'm using regions).

Can't you use GetViewportX() and GetViewportY() as offsets? If GetWalkableAreaAt() doesn''t work at all outside the displayed screen area, you could alternately SetViewport to the area in question, do your check and then ReleaseViewport, all within the same game loop so the player wouldn't see it.

Edit: And two three suggestion for CJ (sorry for being so demanding):

1) Any chance that the slight offset of labels using antialiased fonts as compared to non-antialiased fonts could be fixed now that DrawingSurface supports hi-res coordinates? I remember reading that anti-aliased fonts were rendered as DynamicSprites internally in the engine.

2) Using DrawingSurface, I developed my own method of rendering outlined TrueType fonts to display nicer looking text overlays. Basically I'm drawing the text 8 times non-antialiased at 1 pixel offsets for the outline and then drawing the interior text anti-aliased. Any chance that this could be implemented in the engine? While it's OK to do for speech, it's a bit of a pain to keep DynamicSprites for every single text item on a GUI. See screenshot below for comparison with AGS' own font rendering:


Above: Custom rendering of text as graphical overlay.
Below: Text on GUI label. Note especially the 'a' and the 's' as less readable.

3) Now that we have DrawingSurface.GetPixel, I would find it very useful to also have a reverse GetColorFromRGB function, such as Game.GetRFromColor, Game.GetGFromColor and Game.GetBFromColor. Edit: After posting this, I worked out how to calculate these values using the (2048, 64, 1) ratios, and after lots of testing I got it right. Still I wonder if an engine-internal function wouldn't be faster? If that's not the case, never mind me.

QuoteThat's what I was thinking...

Thanks for the clarification, Dkh. :) I couldn't really pinpoint what you were suggesting in your first post, sorry.

I openly agree with both of you by the way, as long as the artist has equal control over walkable areas and regions. After all, it is indeed the artist that designs the backgrounds in which these areas fit. I definitely think a more programmer-friendly way of creating walkable areas, other than drawing them, is a welcome idea.  8)

Cheers,
Paul.

Edit: I like the way that font is presented GarageGothic. The one at the top feels very nice!

I too would like to voice support for the ability to access walkableareas/regions/walkbehinds/etc. from the script.

If DrawingSurface controlled areas/regions, would we be able to create them from a predrawn sprite (similar to how masks work in the editor)?

Edit: How did I miss that?

Next to the SpeechColor property in the editor it would be nice to have a little filled square with the color represented by the speech color number so you can easily remember what color it is you selected.

Quote from: Lyaer on Thu 06/03/2008 06:07:03
I too would like to voice support for the ability to access walkableareas/regions/walkbehinds/etc. from the script.

If DrawingSurface controlled areas/regions, would we be able to create them from a predrawn sprite (similar to how masks work in the editor)?

Quote from: dkh(3) Programmers could also add new walkable areas, but they wouldn't have to use raw geometry functions (DrawLine, DrawRect or similar), they could load an image from the hard-drive or from the AGS sprite manager (via the sprite-slot) and use that one as a new area...

Suggestion:
Imagine you have a game with about 40 lines of old, not supported code. You want to compile it. It can't compile cause of compiling errors. It just shows the first one. You solve that-> compile the game->error: string no longer supported. etc.etc.

The suggestion is that all compiling errors are listed at once so you can solve them all and compile the game. At the moment you always have to compile to find out that the next line has wrong code.
This suggestion implemented would save lot of time, I think.

[edit]example: you have 25 StrCopy functions and enforce new-style strings. You compile-> 1st StrCopy error. You solve the problem and compile the game. -> 2nd StrCopy error. You solve.......etc. Errors that are caused by these errors can of course only be found after recompiling(after solving the errors).

Quote from: Lt. Smash on Thu 06/03/2008 13:37:58
The suggestion is that all compiling errors are listed at once so you can solve them all

Depending on the way the parser is implemented (e.g. top-down (http://en.wikipedia.org/wiki/Top-down_parser), bottom-up (http://en.wikipedia.org/wiki/Bottom-up_parsing), recursive (http://en.wikipedia.org/wiki/Recursive-descent_parser)), a single error 'cascades' into a lot of subsequent 'errors' which actually dont exist. This happens even in big mainstream compilers, like gcc or bcc (Borland), I mean, they may even report more than one error, but the only one you can 'trust' is the first. It's not that simple, I wrote a parser once... :)

While we're at it, I came across a parsing engine the other day which is very interesting, named Ch (http://www.softintegration.com/). ImageMagick (http://www.imagemagick.org) has a binding for it. The best part I guess is that Ch would be compatible with the current parser (thus not breaking current scripts), since the syntax is also based on C.

Maybe AGS 3.1 could substitute the current parser for Ch?

Hell thats interesting! ;D
Paul.

I haven't seen this mentioned elsewhere. Now that AGS stores the original path of sprites, would it be possible to reload multiple sprites/ sprite folders at the player's request?

This would be particularly useful to me because I am experimenting with pre-rendered 3D sprites and it is very time consuming to have to delete views, delete sprites then reimport sprites and rebuild views when the sprite files have the same names but updated content

I'm sorry if this has already been discussed, or is more complicated to implement than I imagine.

EDIT: Sorry Paul, I did a search but couldn't find it. Still, I'm glad I'm not the only person who would like such a feature.

QuoteI haven't seen this mentioned elsewhere.

Hehe. This is something I've already requested a couple of times not so long ago. It's in this thread somewhere I beleive.

Cheers,
Paul.

I believe that it was Chris's original intention to implement it this way, hence the tracking of the source-file now. It simply hasn't been implemented yet. ;)

Roger that! Good to know  :)

Paul.

Quote from: subspark on Tue 04/03/2008 22:21:37
I can't say that I would be satisfied with the same method because my artists would end up waiting around for one another to finish committing their changes to the ever evolving 'acprset.spr' where as if the data was external to the editor, single sprites could be upgraded.

I totally agree, acprset.spr being so 'monolithic' is not a very good thing. I dont know how other engines handle sprites, but I imagine there could be a more 'dynamic' way, like you suggested (grabbing sprites from the filesystem instead of stacking them all together in one single file). That would be the first step towards distributing work across many people.

Maybe CJ can add some event to the editor plugin API when AGS is about to save/read sprites, thus the 'sprite monolith' scheme can be customized in some way.

I also think that acprset.spr is quite big, obviously because it is using some 'lossless' method to store all the sprites, but there are situations when some of the sprites certainly can be compressed, especially in higher resolutions that depict 'real' scenes. Hmmm, another plugin idea comes to my mind... ;)

Quote from: subspark on Tue 04/03/2008 22:21:37
So again to sum up my suggestion, I would really love to see AGS become more compatible with 'diffing' and 'merging' data in a way that feels personal.

My hope is for AGS to have a (ever increasing) flexible API, so people [who are willing to spend the time/money/effort] can customize it to their specific needs, by means of runtime and/or editor 'plugins'.

QuoteMy hope is for AGS to have a (ever increasing) flexible API, so people [who are willing to spend the time/money/effort] can customize it to their specific needs, by means of runtime and/or editor 'plugins'.

I totally agree. I think this would open up a new class of design opportunities for a developer.

Paul.

Quotesome of the sprites certainly can be compressed

You mean like the "Compress the sprite file" option in General Settings?

Quote from: Rui 'Trovatore' Pires on Mon 10/03/2008 20:35:15
You mean like the "Compress the sprite file" option in General Settings?

Actually I meant 'lossy' compression, like in JPG. Some sprites can surely afford lossy compression, as long as the engine keeps the original 'non-compressed' file (to avoid 'compression-over-compression' artifacts). This suggestion builds up on the previous one, in which sprites are fetched directly as files from a directory tree.

OTOH, I dont know what type of 'compression' is applied when you choose that option you mentioned, but certainly it's not as good as the compression present in PNG or JPG files, because the sprite cache grows many times larger that the original files.

I think lossy compression is a debatable issue. Here is what I imagine being an optimal approach:

• Sprites are built by Artists and are saved out in an uncompressed or lossless format
  
• Sprites are imported into AGS unchanged
  
• Users control a compression slider for each sprite with an overall sprite index file size measure
  
• Users control an overall compression slider in order to tweak overall project size estimates
  
  I don't know how reasonable AGS would be with decent compression algorithms but I imagine this sort of thing is pretty standard across the board.
  
  Cheers,
  Paul.

Quote from: subspark on Mon 10/03/2008 21:46:47

• Users control an overall compression slider in order to tweak overall project size estimates
  

I dont know exactly what you mean, but if you want to use it as a 'target' filesize for the whole project, it would be a little hard to implement, so I would not ask for it... ;)

Also, I find that sliders would be a bit of an overkill, I guess a simple 'quality/compression' field would suffice. Any value other than 100 (for quality) or 0 (for compression) would trigger the compression of the sprite on the next game build.

QuoteAlso, I find that sliders would be a bit of an overkill

Why? Sliders are simply another way of displaying the measure of a value. It is notably a more user friendly method as well. Sliders don't have to be adjustable by the pixel. It can be adjusted in chunks of 5% and a label displaying the value below or above the slider would be present. Who in the world needs 42.7% compression for example?

Quotebut if you want to use it as a 'target' file size for the whole project

Not the whole 'project', but rather the entire sprite image index.
Let me clarify it's purpose:
A user might want to tweak each sprite's compression separately or might find that simply tweaking the overall compression for every sprite at once is more preferable. It depends on how much time the author wants to spend sifting through hundreds of sprites tweaking individual values. Another reason why a slider would be more appropriate than a text field in which the user is likely required to click on, in order to type in it, and then press enter to lock that value in. I've learned a valuable habit of thinking several steps ahead, particularly with engine design, which is why I chose to suggest it above :)

Paul.

Would it be possible to add the object method to the Room class?  I think this would greatly help organization when adjusting object information from the global script and would also make it possible to edit objects in other rooms from a room script. 

IE:

Room[4].object[3].X=5;
Room[2].object[3].SetView(1,2,eRepeat,eNoBlock);

Also, I think it would be great if the compiler would check to see if the object being adjusted exists (this should be possible with the above approach?).

Note:  I'm not saying we should remove the current way objects are used, this way would simply add some more possibilities and better readability since as it is now there's no way of knowing what object call in a globalscript references which room unless you're the person who put it there.

I support Prog's suggestion as long as it doesn't remove the ability to call them as we do now. In a global script, it would make things much easier, as well as stop our necessity to first check whether the player is in room X.

Coordinates:
- Could the division between x and y coordinates be a "," instead of a ";" when setting up the walk to points for hotspots. Coordinates are always typed  "x , y" anywhere and just here it is "x ; y" wich is quite confusing...

- Is it possible to add optional walk to points for objects? It has already been asked. But I ask again.

- Can there be a shortcut or something similar (maybe the middle mouse button) to copy the coordinates of the mouse to the clipboard? It doesn't seem to be possible via right click anymore when I'm editing a walkable area or hotspot.

Organizational:
- 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.
   
- I recognized that there is a folder option for views. Can there be one for characters and rooms as well.
Can there also be a drag and drop function to place existing views / characters / rooms into a folder.
It would make the organization of very large games much easier.

- When setting up the speech color for a character, can there be a pop-up to a color finder?

- When I import multiple sprites in the sprites folder, the imported sprites change their order.

- I still believe the limit of walkable areas walk behinds and regions should be altered to about 40 per room.
There is no reason for the 16 area limit. The argument that people will mess around with areas is not really understandable in my eyes.

- Can the view number be shown in a Tab, like with the rooms in this way: "View 32: Ego". It speeds up scripting.

Testing and previewing:
- It seems that the preview background option has been deleted. Could it be added again and include room objects and hotspots.

- The "jump to room" debug feature should automatically place the player character in a walkable area if there is one, so you can walk around and test the game faster.

- When a game is tested in full-screen mode the room tab gets automatically closed.
  Could it remain opened? It's annoying to reopen the room every time when a test run is done.

- When I preview an animation a large sprite or character gets cropped at a certain height so one can just view half of the animation. Can this be altered to a higher size?

Graphics:
- Alpha channels are shown as gray or white blocks in the sprite manager and preview window. Could their preview include the transparency shadings?

- Alpha channels don't seem to work with GUI buttons, can it be added.

-Whenever I import a singel PNG I get the "Appears to have an alpha channel" Question. You won't believe how often I already clicked "YES" but I never clicked "NO" in my life. Please remove that thing. Can't it be substituted via a tag in the import editor or something?

Sound:
- Is there a possibility to increase the number of channels?

Quote from: ProgZmax on Sun 16/03/2008 19:31:57Would it be possible to add the object method to the Room class?  I think this would greatly help organization when adjusting object information from the global script and would also make it possible to edit objects in other rooms from a room script. 

IE:

Room[4].object[3].X=5;
Room[2].object[3].SetView(1,2,eRepeat,eNoBlock);

Also, I think it would be great if the compiler would check to see if the object being adjusted exists (this should be possible with the above approach?).

Note:  I'm not saying we should remove the current way objects are used, this way would simply add some more possibilities and better readability since as it is now there's no way of knowing what object call in a globalscript references which room unless you're the person who put it there.

I think one of the biggest problems with this has always been the lack of any type of constant (macro or constant static variable) (i.e., AGS_MAX_ROOMS or Game.RoomCount) which would make the sizing of the array much more abstract. In approaching this it has been mentioned that rooms aren't required to be numbered numerically which could lead to lots of "empty" entries at valid array indices (due to the very nature of an array).

Another problem is of course that AGS has a limit of 300 state-saving rooms but then 1000 total rooms (I believe, IIRC you can't have rooms numbered 1000 or higher, but only 0-999 correct?). So in implementing this array should it only allow access to the state-saving rooms, or all the rooms? Making all 1000 rooms accessible from this array would make the overall array huge.

Also we must consider the fact that one of the benefits of AGS has always been that having objects stored within the rooms means the game doesn't have to track every object in every room throughout the whole game, but only has to keep up with the objects in the current room. On modern computers this might not even make a noticeable impact on gameplay; but it certainly would on older computers.

I'm not against the suggestion, but I think we must consider all the pros and cons and approach this one carefully so as to get the most benefit from it.

suggestion:
A nice feature would be to change the game language in-game. Maybe Game.Translation=String TranslationName;.
We would not need to use to the WinSetup.exe and it would look more professional to change the language from english to spain in the options menu of a game.

In the editor: Right click on a translation: Edit in default text editor. Or possibility to edit it in the editor itself.

What would also be nice: Game.Windowed=true/false; Game.GraphicsFilter=2xNN,3xNN,Hq2x,Hq3x; Game.ForceLetterboxRes=true/false;
These are things that are implemented in ScummVM and would be nice to have in AGS.

Lt. Smash, I suggested something (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33578.msg440685#msg440685) earlier in this thread, which would make your requests quite easy to implement through a module:

QuoteIf the savegame compatibility issue [between different graphics resolutions] was solved, and RunAGSGame was made to re-initialize the engine, as monkey_05_06 suggested [...] you could let the player change the graphics [and other] settings from an in-game options menu, write them to acsetup.cfg using File functions, save the game in progress, then restart the entire game using RunAGSGame (whereby the engine would re-initialize using the settings from the .cfg file) and then restore the savegame to resume gameplay.

A circle tool for rooms that tracks the mouse for both x and y diameter (so you can make ellipses) would be awesome.  Also, if the freehand/line tool would start drawing WHEN you pressed the button instead of after you started moving that would be more in-line with how conventional art programs work.  As it is, if you want to place a single pixel you have to click-and-drag to get it, which is difficult.

The compiler should barf if someone declares a variable or function in a script header as this is almost never what someone actually wants. It could also point them to the manual section on how to do it right, although this currently only refers to functions and not variables.

Quote from: ProgZmax on Wed 19/03/2008 15:05:14
A circle tool for rooms that tracks the mouse for both x and y diameter (so you can make ellipses) would be awesome.  Also, if the freehand/line tool would start drawing WHEN you pressed the button instead of after you started moving that would be more in-line with how conventional art programs work.  As it is, if you want to place a single pixel you have to click-and-drag to get it, which is difficult.

Also a zoom for the mask editing on the room editor would be fantoostic!

cheers,

lemmy

Quote from: Lt. Smash on Tue 18/03/2008 11:55:33
suggestion:
A nice feature would be to change the game language in-game. Maybe Game.Translation=String TranslationName;.
We would not need to use to the WinSetup.exe and it would look more professional to change the language from english to spain in the options menu of a game.

In the editor: Right click on a translation: Edit in default text editor. Or possibility to edit it in the editor itself.

What would also be nice: Game.Windowed=true/false; Game.GraphicsFilter=2xNN,3xNN,Hq2x,Hq3x; Game.ForceLetterboxRes=true/false;
These are things that are implemented in ScummVM and would be nice to have in AGS.

This is basically a small part of what I have already sugested, Smash. It has already been suggested by me that the options winsetup offers also be controlled via a scriptable GUI so that they can be changed in-game.

Edit:

QuoteThe compiler should barf if someone declares a variable or function in a script header as this is almost never what someone actually wants.

'Almost' isn't a very reliable statistic if functionality of the compiler is to be altered now is it.  ;)

Cheers,
Paul.

Quote from: Le Woltaire on Sun 16/03/2008 22:53:39
- Is it possible to add optional walk to points for objects? It has already been asked. But I ask again.

Well, you can certainly do it via Custom Properties. Just define two variables, 'WalkToX' and 'WalkToY', both with a default value of -1, and put the following on your GlobalScript.asc (or on a separate module):


function on_mouse_click(MouseButton button)
{
  Object* obj = Object.GetAtScreenXY(mouse.x, mouse.y);
  if (obj != null && obj.GetProperty("WalkToX") >= 0 && obj.GetProperty("WalkToY") >= 0)
    player.Walk(obj.GetProperty("WalkToX"), obj.GetProperty("WalkToY"));
}


Quote from: Le Woltaire on Sun 16/03/2008 22:53:39
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.

I support that. It's a good idea.

As if all those previous suggestions weren't enough, I have another one... ;) I think it would be very useful to draw directly on a sprite's alpha channel. If we could do it by 'fetching' a DrawingSurface out of a sprite's alpha channel, we could draw on it just like another surface. It would certainly be useful in situations where you must draw anti-aliased text.

My idea:


DynamicSprite* asprite = DynamicSprite.Create(320, 240, true);
DrawingSurface* alpha = aSprite.GetDrawingSurfaceForAlphaChannel();
alpha.DrawString(0,0,"Blablabla");
...


Another approach would be to copy a greyscale sprite directly onto another sprite's alpha channel, much like CopyTransparencyMask(), but instead of using the alpha channel of the source, it would use the rgb channels as alpha values on the destination. This way we could achieve the same effect, only requiring a temporary sprite.

Idea:


DynamicSprite* alpha_temp = DynamicSprite.Create(320, 240, false);
DrawingSurface* alpha_surf = alpha_temp.GetDrawingSurface();
alpha_surf.DrawString(10,10,"The quick brown fox jumped over the lazy dog");
alpha_surf.Release();

DynamicSprite* texture = DynamicSprite.CreateFromScreenshot();
texture.CopySpriteAsTransparencyMask(alpha_temp);


The above code takes a screenshot of the screen and applies a 'mask' to it, formed by the string 'The quick brown fox...'. The source and destination should be the same size, I guess.

I've started converting my RawDraw routines to DrawingSurface functions, and I find myself missing a DynamicSprite.CreateFromDrawingSurface(DrawingSurface*, int x, int y, int width, int height) function similar to DynamicSprite.CreateFromBackground.

Most of my distortion effects work by retrieving part of an image, distorting it and drawing it to either the original surface or a new one. Previously, I used the background as a buffer (which is no longer feasible due to slowdowns in Direct3D mode), and found DynamicSprite.CreateFromBackground very handy. But now my workflow looks like this:

1) Draw surface to a temporary DynamicSprite (sprite A)
2) Create an even more temporary copy of sprite A (sprite B)
3) Crop sprite B down to the actual area to deform (often a single row of pixels)
4) Deform cropped sprite B and draw it back to DrawingSurface
5) Repeat steps 2 through 4 until the whole sprite has been deformed

Without knowing exactly how AGS handles copies of sprites internally, I would guess that the repeated copying and cropping of the full sprite must be quite a bit slower than creating a new sprite consisting only of the needed area.

Did the Show and Say for the dialog script get moved somewhere wierd in 3.0? Because I can't see them...

If they did... could we have them back... I've got instances where I'm going to need to keep the player from seeing exactly what they're going to say...

Quote from: Recluse on Wed 19/03/2008 20:40:41Did the Show and Say for the dialog script get moved somewhere wierd in 3.0? Because I can't see them...

I don't know for sure about the stable 3.0 release, but at least the latest beta version has them right next to the dialog options as it used to be. Have you possibly moved the divider between the dialog options and the dialog script too far to the left so that they are hidden?

Why yes, that's exactly what happened  ::)

Thanks. *goes off into a corner and feels sheepish for a while*

EDIT: Oh, by the way. Is that divider movable for you? Because it's static over here... I can provide screens.

Quote from: Recluse on Wed 19/03/2008 20:47:02EDIT: Oh, by the way. Is that divider movable for you? Because it's static over here... I can provide screens.

It's definitely movable. You just have to find the right pixel since it's not marked (the divider isn't the same as the edge of the white script window). Try just left of the arrow at the bottom, where the slider to scroll the dialog script horizontally is located.

CJ, your post in SSH's blog thread prompted me to write this, hope it's helpful!

The Assign To View feature, while completely useful, may be overlooked because it violates some usability rules about context.  It's hidden at the bottom of a right-click menu containing a number of features used to bring in new sprites, in a section unrelated to views.  The view section has all the other functionality regarding setting up views, and is where I was always looking for such a feature (which I thought was sorely missing because it wasn't there until someone finally mentioned the Assign To View to me :P).

I think that a more intuitive way to implement this would be to add another button next to the "Create new frame" button that automatically creates a new frame and sets it to the frame numerically after the previous frame.  That way, for 80% of the animations in my game which are imported sequentially into the editor, I could just set the first frame and press "Add next frame" several times, which would be almost as fast as Assign To View if not faster.

Additionally or alternatively, a way to select multiple sprites in one trip to the sprite window rather than one at a time (a process that is much slower in 3.0 than it was in 2.7) and having them be added to the loop in the order that you clicked on them would be extremely intuitive and fast.

From a usability standpoint, the Assign to View seems to me to be working backwards.  I wouldn't eliminate it, but adding some alternatives is always nice!

Also, while I'm posting, I'd really like a full makeover for the sound and music system that:
-Has more than one channel for music to allow manual crossfading effects (I usually import my music as sound due to this)
-Doesn't make music skip or stutter when changing rooms or loading large animations/sprites
-Allows full control over music and sound channel volumes
-Has functions that return the volume of each channel
-Has functions that return the music or sound number currently playing in each channel
-Allows you to toggle looping for each individual channel (including sound channels)

QuoteI could just set the first frame and press "Add next frame" several times, which would be almost as fast as Assign To View if not faster.

This coupled with the ability to select a range of frames and re-import a gif over them (provided it has the same frame count) would greatly streamline the sprite importing/adding process!  I'd prefer a keyboard shortcut to a button that constantly moves, though.  That way I could just tap the '+' key 5 times and 5 frames would show up :D.

Another suggestion (see also http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19062.0 (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19062.0)).
I use custom shaped buttons, but when the gui is disabled, they have an ugly grey square.

So I would either suggest to allow a DisabledGraphic for buttons or do not grey out transparent areas.

cat, does that still happen when you do this?

(http://members.cox.net/progzmax/cathelp.gif)

Quote from: ProgZmax on Fri 21/03/2008 13:23:34
This coupled with the ability to select a range of frames and re-import a gif over them (provided it has the same frame count) would greatly streamline the sprite importing/adding process!  I'd prefer a keyboard shortcut to a button that constantly moves, though.  That way I could just tap the '+' key 5 times and 5 frames would show up :D.

Agreed and agreed!

@ProgZmax:

Thank you, you are right, it does not happen. I can do it this way. However, it would still be nice to show the gui disabled when the user cannot use it. (ok, there is still the wait cursor, so probably this feature is not really necessary)

Quote from: cat on Fri 21/03/2008 20:26:11
Another suggestion (see also http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19062.0 (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19062.0)).
I use custom shaped buttons, but when the gui is disabled, they have an ugly grey square.

So I would either suggest to allow a DisabledGraphic for buttons or do not grey out transparent areas.

I actually asked this before. Back in 2.8 I believe. It's one thing to hide the controls on a gui (including inventory) but its another thing to turn the gui completely off!
Paul.

One thing I've noticed is that when a 320 x 200/240 game is upscaled to 640 x 400/480 in DX 9 mode, the character scaling is done on the 640 x 400 screen, so you end up with characters that are higher resolution than the backgrounds which can look a bit odd. Is there (or would it be possible to have a way) to force characters to be drawn at the unscaled resolution as 320 x 200/240 is quickly becoming an unsupported screen resolution, but is needed for the retro look a lot of AGS games go for.

Thanks!

lemmy

Quote320 x 200/240 is quickly becoming an unsupported screen resolution

I doubt whether support for 320x200/240 will discontinue but I do believe that your issue with the mixed resolutions is a common one.

I noticed such an issue with The Infinity String actually. Notice the helicopter scene is in true 640x480 but the rest of the game is 320x240 scaled up. The characters, like you noted, were also displaying the same resolution mismatch symptoms.

Would it be time to overhaul the resolution system at this stage of AGS development yet, CJ?

Regards,
Paul.

Quote from: Pumaman on Sun 27/01/2008 00:59:41

These are some that have already been suggested and that I'd like to do:
* Bring back drag & dropping sprites around in the sprite manager
* Drag & drop views into different view folders
* Ability to delete views
...

I know that I am new here :) and that I am not a veteran like the most of you, but I have a suggestion too, which is minor and I think - useful. Can you add in your next version the ability to copy loops and insert them directly into the same or another view. This is mostly useful if you make a mistake for example and put the wrong loop in the wrong view. If you do that, you have to delete the loop and create a new one (exactly the same) but in a new view. That is a lot of clicking... :) Also very useful is to add an invert function for the loops.
For example we have a loop that shows our hero walking on the right. Then we use "Copy loop", we insert it as another one in the same view and with the same frames. We have now to "go-to-the-right"-views. But we want a "go-to-the-left"-view too. So we invert the new one and there we have now 2 opposite views.

Good Point! :D
I second that.

Cheers,
Paul.

Maybe it's just me, but I really miss a 'for()' construction. It's such commonplace...

Compare this:


int i = 0;
while (i < 10) {
  a[i] = i;
  i++;
}


To this!


for (int i = 0; i < 10; i++)
  a[i] = i;


UPDATE: Array initialization is such a pain... i guess i've been dealing a lot with them lately, so I'm a little pissed off with while's. If only array initialization would accept assignment... ;)


String s[4] = {"This", "is", "an", "array"};


PlayVideo() should return some status code to indicate if it was successful or not. Currently, if the video can't be played (due to a missing codec) or is not found, the user sees a rather nasty message box:

Quote
Video playing error: File not found or
format not supported: .\Compiled\clip1.avi

I'd rather 'code around' the error than to let that message pass through the player.

Yeah! Coincidentally this is something thats bothering me as of right now. I couldn't figure out why one machine would play the vid and the other wouldn't. It turned out to be a mismatch in codec versions. If we could write a handler for missing codecs with the PlayVideo() command then we could even recommend which codec the user should download.

Ultimately its more than reasonable to include the codec with the game's installer to save drama like this from being an issue in the first place. :P

Cheers,
Paul.

As previously suggested, I think the best solution to this problem is Ogg Theora support so that the codec is fixed and bundled into AGS. This would also mean it works on linux.

Could we have both? I mean, it PlayVideo, like a certaing SaveGame function whose name I can't recall, returned "0" or "-1" if the video couldn't be played, the programmer would have his control over the default error box (which is good, AGS already gives the scripter so much control, this is just the tidbits that are left over).

Is it possible to have AGS manage 3D characters directly?

The 3D character plugins is not maintened and giving AGS 2.5 D possibility will be very great.

Any other persons interested by that?

I think that support for models (3d characters etc.) is perfect for modules/plug-ins. It's not that hard to write your own 3D API for any experienced programmer. The main thing holding these kind of projects back is the lack of struct-in-struct-support, it's that way for me at least. Since no real 3D possibilities exist anymore (AGS3D, which I started, then gave to Steve McCrea to continue is long abandoned, he did some marvelous work there, though, and the Character3D thingie doesn't work in 3.0 either as far as I understand) I might just try to get something going, actually I already have some stuff. This time I know a little more about the math, too... :)

Quote
It's not that hard to write your own 3D API for any experienced programmer

I hope an experienced programmer will bring us soon a plugin or module to use 3D character with AGS.
2.5 D will extend AGS possibility a lot.
The possibiity to have different camera view will enhance,imho, the game design.

Surely the 3.02 suggestion thread now.. ;)

My favourite suggestions from this thread so far:

   * Ogg Theora video included
   * Widescreen support
   * Native Hi-res co-ordinate support (optional to maintain backward compatibility)
   * Game setup options configurable at runtime?
   * Non-blocking dialogs (toggle-able?)
   * PCX import
   * The compiler should barf if someone declares a variable or function in a script header as this is (I think) never what someone actually wants.
   * Group operations in view editor: copy, cut, paste, flip

And of course, the old biggies: functions being first class objects and pointers to structs being allowe dinside structs

I second the pcx-file import. I'm trying to make a RON game and all the backgrounds are in pcx-format. Sure I can convert them but If it isn't too much trouble I'd like AGS to have this feature.  :D

And a sound/music control overhaul!

Quote from: SSH on Thu 17/04/2008 10:59:18
And of course, the old biggies: functions being first class objects and pointers to structs being allowe dinside structs

And pointers being passed as parameters in functions, please... Well, I guess the two things are connected.

Quote from: Dixon on Thu 17/04/2008 11:27:41
I second the pcx-file import. I'm trying to make a RON game and all the backgrounds are in pcx-format. Sure I can convert them but If it isn't too much trouble I'd like AGS to have this feature.  :D

You can use ImageMagick (http://www.imagemagick.org) to convert them all at once, in a single line. ImageMagick is a command line application, multiplatform, very fast and powerful. Also, you can merge sprites together in a single image, apply alpha masking, and many other things.

Since there is such a tool, I don't think PCX suport in the engine is necessary. I would vote only for PNG and JPEG.

Here are some links for the PCX stuff: http://www.thefreecountry.com/sourcecode/graphics.shtml
http://libclaw.sourceforge.net/index-en.html
http://www.herdsoft.com/catalog/davinci.html
That last link is actually for windows C++ programming. But if AGS actually imports the file and converts it to its own format, then this might work. Also has some capabilities for image editing which could be useful for the AGS editor... But apparently, its not that easy to add PCX to AGS.

2.5d would be really hard to implement I would think. There are libraries that work with Windows that Chris could use. But, they would not work on the Linux or Mac versions.

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.

[gratuitous blog ad]
I've stuck a poll as to what features you prefer on my blog (link in sig)  :=
[/gratuitous blog ad]

SUGGESTION: When using the eraser tool for hotspots the tooltip balloon keeps popping up over my workspace. Due to this slight hindrance, I made a few mistakes but could not undo them all. Along with a less intruding balloon tip, I think AGS needs an edit menu with Undo and Redo commands that can be applied a finite number of times. The amount of Undo and Redos should also be modifiable under the preferences menu.

SUGGESTION: Now that the walk behinds, hotspots and regions can be made semi-transparent, I think the eraser ID should be replaced with a more intuitive eraser button on the top menu in the room editor and for the colors of the actual ID's to remain rather than go grey each time the eraser is used.

SUGGESTION:
Add a 'Close All' tabs option.

Cheers,
Paul.

Just something small that would be nice: New, open, and close options in the File menu (like in, say, visual studio)
New would close the current document (asking if the user wants it saved), and bring up the new game dialog.
Open would:
a) show a listing of already made games
b) let you browse for your game's project file
Close would close the current game (asking if the user wants it saved), and open the initial dialog

Just a few idea's I thought would be nice, instead of having to completely close out of AGS and re-open it. :)

I also would like this feature.
Good suggestion, Nightquest2. Forgot about that.

Paul.

I know the logistics of it have represented a sticky situation, but some way of retrieving the size of a dynamic array would be much appreciated.

One way that could avoid the problem of creating a function accepting a type-generic parameter would be to allow dynamic arrays within custom structs. We could then track the size of the array ourselves simply.

Some more suggestions I have:

1. Make areas editable directly through script

2. GetAtXY, colliding and/or overlapping (Edit: Animation-) functions for Overlays

3. Make the game pause during blocking scripts (e.g. save GUI can be called during cutscene, Sierra/Lucasarts)

In a similar fashion, if the game is run in windowed mode, it would be good if AGS could return "window focus lost" so that a GUI (game paused?) could pop up. Also Sierra/LucasArts

I would find the ability to write to ViewFrame.Flipped extremely useful.

What about new Character class function like this:


enum EDirection
{
 eDirLeft,
 eDirRight,
 eDirUp,
 eDirDown
};

function FaceDirection(this Character*, EDirection direction, BlockingStyle block);

Well you're halfway there already Crimson, why not just finish it off? :=

function FaceDirection(this Character*, EDirection direction, BlockingStyle block) {
  if (direction == eDirLeft) this.FaceLocation(this.x - 1000, this.y, block);
  else if (direction == eDirRight) this.FaceLocation(this.x + 1000, this.y, block);
  else if (direction == eDirUp) this.FaceLocation(this.x, this.y - 1000, block);
  else if (direction == eDirDown) this.FaceLocation(this.x, this.y + 1000, block);
}

Quote from: monkey_05_06 on Wed 21/10/2009 20:28:40
Well you're halfway there already Crimson, why not just finish it off? :=

*Sigh*
I did it, but decided to remove function body to save forum space ::)
Yeah, I have this as an extender function in the game I am currently working on. I simply thought it may be convenient to have it as built-in function. Simplier for newbies also.

please increase the ammount of possible walkable areas, hotspots, and regions.
I work on very large rooms and have to deal with the limits very often.

Could the view creation wizard that I suggested (or some variation of) be implemented?  ( http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37874.msg497684#msg497684 (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37874.msg497684#msg497684) )  Thanks.

J

I was wondering about something for a while.
Would it be possible to make the background animation have some more options?
Like-I always hate that you can enter only I think 5 different backgrounds for the animation.
If there was more of them(like-really more)there could be a possibility to make better background animation while
the character is doing something.
Let's say a character is walking over a meadow and in the background there is this cool animation of a big airplane
accident.
And if there were a lot of slots for the background animation-more could be done.
Just thought i could share my thoughts...  :-\

Quote from: lipaoklipa on Sun 25/10/2009 08:44:49
I was wondering about something for a while.
Would it be possible to make the background animation have some more options?
Like-I always hate that you can enter only I think 5 different backgrounds for the animation.
If there was more of them(like-really more)there could be a possibility to make better background animation while
the character is doing something.
Let's say a character is walking over a meadow and in the background there is this cool animation of a big airplane
accident.
And if there were a lot of slots for the background animation-more could be done.
Just thought i could share my thoughts...  :-\

People will simply tell you to use an object instead, which I would as well.

The only good reason to increase BG frames that I can think of, is for games with day/night systems, a la Quest for Glory. But even then you could use overlays and such.

Ooh ooh ooh, would it be possible to let us set the size of the automatic font outline? I'd really love to just bump the outline up to 2 pixels instead of sizing up my font to make it more legible.

[edit] Oh and another thing: when you compile a game, it automatically adds the dialog_request function to the global script - isn't that obsolete now that you can just run code from within the dialogs?

Here's one: Would it be possible to zoom in on guis while editing them? It would help for lining up buttons on the background (like you can in rooms with objects or drawing hotspots/walk-behinds).

Here are two minor improvements I'd like to see one day:

- anyclick event for inventory items
- placing event functions like cEgo_anyclick outside the globalscript without the need to create stubs
- variable    inspection inside the editor ;D

Just a couple of things I think would be most important:

- More customisable Dialog and Text Box behaviours - right now they automatically pause the game, but I think whether they're blocking/non blocking/pausing should be up to the designer. For example, the dialog is brought up in Simon the Sorcerer in the Tower section - you can click something, or a timer automatically turns it off after a certain time. Likewise, the Opera scene in FF6 is another example - you have to choose a certain song lyric, and after time runs out, the dialogue options end and a cutscene plays.

Perhaps adding a Dialog.Enabled tag, a Dialog.ChosenOption variable to return which dialogue option you're running, and a Dialog.RunOption (option, FollowDialogState) function just in case we want the dialog backend but not the frontend. (I know I do - I find it easier to write my dialogs inside the dialog editor than in scripts)

That way, we can have the dialog up but the freedom to let the player click anywhere on the screen, rather than waiting for them to pick a certain dialog option (this opens up the "click on anywhere but dialog" function in Scumm games that lets people automatically exit dialogs, and the ability to bring the player's inventory into it, simply by checking if the player has clicked on an option or an inventory item. I'm sure even more exotic things can be coded this way too.)

- Non blocking playing of Speech files. I'm sure this has been suggested before, but is there anything stopping this from happening?

And just something a little self-indulgant, since everyone seems to have abandoned 8bit mode:

- More intuitive GIF importing for 8bit games. I don't think you can set it to use Exact Palette yet. That would be really useful for me - I had some room specific GIFs that I needed to import, and it was a total pain doing it. It kept totally ruining it even when I had all the settings correct, too.

But these aren't the highest priority, naturally.

As far as your requests for the dialog you might want to check out the DialogOptionsRenderingInfo functions for custom dialog rendering and/or the CustomDialog module. Specifically regarding the blocking issue, there's a setting on the General Settings pane which allows you to run game loops while the dialog options are displayed, though only repeatedly_execute_always functions are run (so you can't of course call a blocking function; though it would be possible to queue and run any other functions).

I think the only real reason that the speech files can only be played in a blocking fashion is the fact that currently the only way to play a speech file is via the blocking Character.Say function. :P The current workaround (as applied in modules such as the queued background speech modules (by SSH and myself)) is to use sound files instead where you need to play the speech in a non-blocking fashion.

Quote from: monkey_05_06 on Wed 28/10/2009 05:32:17
As far as your requests for the dialog you might want to check out the DialogOptionsRenderingInfo functions for custom dialog rendering and/or the CustomDialog module. Specifically regarding the blocking issue, there's a setting on the General Settings pane which allows you to run game loops while the dialog options are displayed, though only repeatedly_execute_always functions are run (so you can't of course call a blocking function; though it would be possible to queue and run any other functions).

Thing is, I don't think you can control the dialog's presence while it's on screen - there's no opyion to turn it off. So even if you could, for instance, get REA to return an inentory item when you click, you couldn't then hide/turn off the dialog options and get on with the dialog. Nor is there any real easy way to run Dialog option scripts. It's all messy workarounds.

I personally would like to suggest Inventory Categories where you can assign an inventory item to a category such as Magic, erbs, weapons, etc...

Then you can choose what category the inventory window can display. This way the character can easily have multiple inventories rather than creating another character and displaying his inventory.

Post moved to: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=39210.0

I've noticed that quite a lot of games get released with Beta mode still activated when they compile their games.  I believe that most people must not know that there is a Debug mode, or it's just a matter of forgetting due to the excitement of releasing a game.

So I was thinking, perhaps when someone clicks the Build Game EXE button and when the "Your game has been compiled" message pops up, another message under that could say something along the lines of: "Remember, Debug mode is still on", if it was still on.

Or even the option of turning off the Debug mode for the EXE Build before it's built.  But turning off the Debug mode is already easy as it is, so perhaps a reminder is all that's needed. :P

Quote from: Ryan Timothy on Sat 14/11/2009 06:48:30
I've noticed that quite a lot of games get released with Beta mode still activated when they compile their games.  I believe that most people must not know that there is a Debug mode, or it's just a matter of forgetting due to the excitement of releasing a game.

So I was thinking, perhaps when someone clicks the Build Game EXE button and when the "Your game has been compiled" message pops up, another message under that could say something along the lines of: "Remember, Debug mode is still on", if it was still on.

Or even the option of turning off the Debug mode for the EXE Build before it's built.  But turning off the Debug mode is already easy as it is, so perhaps a reminder is all that's needed. :P

Or maybe a 'Publish' button, which will:
A. remove the debug option.
B. create an installer...

tzachs: That idea is a bit much, as there are free installers out there already. But I think Ryan is on the right track. There should be a way to let the user know that it's still in debug mode and to turn it off and re-compile if this wasn't what they wanted.

Perhaps along the same lines there could be an option in Preferences: "Generate a warning when compiling the game in Debug mode"? That way when you're building the EXE you could (optionally) generate a warning letting you know Debug mode is on. That would be the most obvious means to me.

As far as installers go, I think including one in AGS is a bit much. I absolutely would not want it to be required, and would probably rate it was one of the lowest priority suggestions for AGS. There are a ton of more useful ideas (i.e., getting the size of a dynamic array, pointers to custom types, dynamic arrays within structs, etc.).

tzachs: I think you made a good observation to point out a mistake that people often make, however, I don't agree with your proposed solution.  The editor allows you to turn off the message box, which I find deeply annoying.   Perhaps a better solution would be to display a message when a game is first open by the editor.

monkey: "There are a ton of more useful ideas (i.e., getting the size of a dynamic array, pointers to custom types, dynamic arrays within structs, etc.)." Yes, Yes Yes, and yes yes to your suggestions.  I would also add pointers to functions to your list.  I would love to be able to construct jump tables.

Quotetzachs: I think you made a good observation to point out a mistake that people often make, however, I don't agree with your proposed solution.

That was me actually who suggested that. :P

Anyway.. This morning would be the second or so time now that I've needed to check if an int is odd or even.  I haven't found anything in the manual, so I was mainly curious if it was possible to add.
I know there is a way to get past this, which would be to get the remainder of the int.  Eg:

if ((i%2 == 1) || (i == 1))  //the number is odd.

I blame Turbo Pascal.  I used to use  odd(int)  all the time with my old shooter games. :P

I think that having the 'for' and 'foreach' loops in AGS would help with scripting.

The 'for' loop is good for having a counter attached to a loop. In AGS, it would look like this:

int counter = 0;
while(counter <= 100)
{
  //do stuff
  .
  .
  .
  counter++;
}


Now, the same stuff, but in a 'for' loop instead:


for(int counter = 0; counter <= 100; counter++)
{
  //do stuff
  .
  .
  .
}


I find that much easier to deal with, rather than the while loop.

The 'foreach' loop is much like the 'for' loop, except that it iterates through all of the elements in an array (It would be a good way to find the size of your dynamic array, monkey)

As above, so below: here's the same thing in AGS (in AGS, this works only if you already know the length)

int counter = 0
while(counter <= 23)
{
  array[counter] += 5;
}


Now with 'foreach'


foreach int counter(array)
{
  counter += 5
}


the 'int counter' in the foreach loop is what the value of the current element of (array) is.

Thoughts? (I feel as if I wrote a tutorial...)

The foreach loop is something I've often wished for, but I've always found a way around.

Well, the 'for' thingie is an outstanding request, which I agree that it's useful, but due to the priority of stuff it's not quite possible to be re-implemented any time soon, and though using 'while' loops look less elegant, it does do anything you want already. (FYI, the AGS AC text scripting did have 'for' loops until V1.14, when the script engine was changed, and requests for bringing it back had been heard from time to time.)

Quote from: Ryan Timothy on Sun 15/11/2009 07:16:15
if ((i%2 == 1) || (i == 1))  //the number is odd.

if (i % 2 == 1)

would be sufficient, as 1/2 would be 0 with a remainder of 1, covering 1 as a possibility.

Hmm, didn't know that was possible.  Thanks Terran.

Also, I noticed something again this morning.  I'm not sure if it has been mentioned before (and I still haven't played with the AGS Beta yet), but if you make a large GUI (for example: 1024x768), the viewable editor doesn't have scrolling. :P

The thing that I was going to suggest is already in the tracker  := (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=172)

I don't really like the way how it has become really annoying for game creators to quickly run/preview their game in fullscreen in the last versions of AGS. I know some people like the windowed mode better for these things but I'm totally different there, it only takes my monitor a fraction of a second to go to fullscreen mode and then I get a feel for the immersion. Currently, I always have to hit F7 or click "Build game", then click "Run Setup", then hit "Ok".

dkh there's an option in Preferences regarding display mode when running the game without the debugger. You can set this to "Always run full screen" so that if you want to run the game full screen you can then just press Ctrl+F5 and it will run the game.

You can't use the script debugger when doing this. Any time you run the game with the script debugger it's always windowed. ;)

Ah, didn't know that. That fixes my issue ALMOST completely. One thing why I'd still prefer another system than that is for games where more than one people works on the project. Like in FoY, we work using SVN Turtoise and some people like the windowed mode, others like fullscreen, always having to change that flag in the settings is a pain- in the behind... :D

Thanks for letting me know that setting exists in the first place tho!

You shouldn't have to change it every time.
Just debug normally if you want windowed, and Ctrl+f5 for full-screen.

That does work indeed, thanks. So F5 does windowed mode and CTRL+F5 does fullscreen, pretty neat!

Yes, unless I'm mistaken the option is actually stored locally and will be applied to every project you work with in AGS (on that system). ;)

Ah that's even better! :D Sweet!

EDIT: Actually, that's pretty obviously a local setting since it's in the AGS preferences panel and not in the project somewhere... Dunno where my head is...

If it hasn't already been mentioned it'd be pretty neat if you could assign views to GUI buttons/labels/bg image etc.

Probably been mentioned before but how about overlays with an alpha channel?

also a transparency control on the text overlay would be nice. Specifically for fading text (i.e damage numbers :D)

Possibly an option to import or rather add to the list existing scripts as ash/asc files. Currently it is possible only by creating new script and copying contents from existing ones.

Actually, you can import and export scripts.

Yes, by using some *.scm format. That is you have to open your other project, export script to scm, open new project, import scm. Can it be quicker to import from existing ash/asc directly?

Try copying them over (the two files in the game dir), iirc that should work.

Quote from: Khris on Tue 24/11/2009 23:01:04
Try copying them over (the two files in the game dir), iirc that should work.

Unfortunately it didn't, that was the main reason I posted here ;)

You can do this manually by opening the Game.agf files in Notepad/Wordpad/(whatever other text editing program) which are written in plain XML. Modifying them directly is not recommended and could permanently corrupt your game, so if you do this back up your files FIRST.

Quote from: Every Game.agf file's XML<!--DO NOT EDIT THIS FILE. It is automatically generated by the AGS Editor, changing it manually could break your game-->

This is the section of the XML file you are looking for:

    <Scripts>
      <Script>
        <FileName>GlobalScript.ash</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>True</IsHeader>
      </Script>
      <Script>
        <FileName>GlobalScript.asc</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>False</IsHeader>
      </Script>
    </Scripts>

You should have more individual Scripts between the <Scripts> and </Scripts> tags than this, but I only have these two in the particular Game.agf file I opened. What you want to do is copy everything from the opening <Script> tag for your ASH file, all the way down to the closing tag for your ASC file, i.e. this portion:

      <Script>
        <FileName>GlobalScript.ash</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>True</IsHeader>
      </Script>
      <Script>
        <FileName>GlobalScript.asc</FileName>
        <Name />
        <Description />
        <Author />
        <Version />
        <Key>1953879197</Key>
        <IsHeader>False</IsHeader>
      </Script>

But not the <Scripts> or </Scripts> tags. You must make sure to copy this EXACTLY. Copy that section of the XML and paste it into the Game.agf file you are wanting to import the script(s) into (be sure to close the project in AGS first), and you must make sure you put the script above the GlobalScript. DO NOT COPY THE GLOBAL SCRIPT FILES FROM GAME TO GAME OR PASTE A SCRIPT BELOW THE GLOBAL SCRIPT DOING THIS. Save the modified Game.agf file, and load it back up in AGS.

Again, this process is NOT recommended to ANYONE doing so CAN BREAK YOUR GAME.

Sounds like too much work for what it's worth? It probably is. Just export/import the SCM files already. :=

I can appreciate that you might want to just import the raw files but is it really that difficult to use the SCM file? Most of the time when I'm wanting to move a script from project to project it's something I'm going to be releasing as a script module anyway, so I've already gone and exported it as SCM. Maybe that's just me though.

An old thread, I know, I just thought it would be better to use this instead of creating a new one.

I'd really appreciate if I could move the selected object in a room or button on a GUI with the keyboard (VS style). This is much more accurate than moving it with a mouse or tablet.

I think that the new version of AGS should have no limit cap on the number of objects allowed in a room  :P

A tiny qualm, but for consistency's sake, it would be nice if walkable areas could be "disabled" and "enabled", instead of "removed" and "restored".

Quote from: suicidal pencil on Wed 06/01/2010 21:36:55
I think that the new version of AGS should have no limit cap on the number of objects allowed in a room  :P

I think the cap is reasonable. At least for performance point of view..

How about a generic game object "Location" that can point to either a Character, Object or Hotspot?
If it implemented common members such as .GetAtScreenXY .Name or .GetProperty, this could save some scripting time.
It's easy to work around, I know, just a thought.

Quote from: Khris on Fri 08/01/2010 20:13:32
How about a generic game object "Location" that can point to either a Character, Object or Hotspot?
If it implemented common members such as .GetAtScreenXY .Name or .GetProperty, this could save some scripting time.
It's easy to work around, I know, just a thought.

Taking your idea one step further, maybe ags should have interfaces? IPositionable (or ILocation if you prefer), IResizable, IHasTransparency, etc. Then Character, Object and Hotspot can implement ILocation, and character and object will also implement IResizable, and this will simplify scripting for various scenario.
There are probably more urgent things than that on the list, though...

Instead of interfaces I'd much prefer to see class templates. Seriously. If you're trying to do anything to extend more than one type...it sucks. Code duplication...to the max.

For those who aren't familiar with code templates basically it would allow something like this:

struct MyTemplate<T> {
 T Data;
};

MyTemplate<int> myInt; // declares type T as int for this instance
myInt.Data = 5; // Data is an int

MyTemplate<String> myString; // declares type T as String for this instance
myString.Data = "This is some text."; // Data is a String

MyTemplate<Character*> myCharacter; // declares type T as a Character* for this instance
myCharacter.Data = cEgo; // Data is a Character*

Basically the T would be replaced with a class type, as defined at the time the instance gets defined. So when you put <int> then you are replacing every instance of T in the struct definition with int.

It makes coding much easier if you need to operate with multiple types. I wouldn't even mind if the template type had to be usable as a struct member type (AGS managed type or basic data type).

It would seriously save me a LOT of time. :=

When a character moves they effectively 'jump' across the room by however many pixels their movement speed is.

This causes backgrounds of scrolling rooms to stutter so perhaps it would be better if characters moved one pixel more often rather than 4 pixels less often.

Calin, I could be wrong, but wouldn't that cause the characters feet to slide?

hmm thats a good point.

I guess we need the viewport to scroll more smoothly then instead.

Quote from: Calin Leafshade on Sat 09/01/2010 22:22:48
hmm thats a good point.

I guess we need the viewport to scroll more smoothly then instead.

This is possible to do manually by writing an extension function for Walk, or just processing in rep_exec.

Ive tried.

I can make the viewport move slowly but that just causes the character to stutter instead for the same reason.

Unless you feel you can do a better job at scripting it, i cant see a solution..

Quote from: Calin Leafshade on Sat 09/01/2010 22:42:43
Ive tried.

I can make the viewport move slowly but that just causes the character to stutter instead for the same reason.

I am not sure what may happen there...
I used script-controlled viewport scrolling in my Shooting Gallery techical demo, and there were enemies wandering across the screen while viewport moved around. I don't remember they "stutter" or something.

Quote from: Crimson Wizard on Sat 09/01/2010 22:51:22
I am not sure what may happen there...
I used script-controlled viewport scrolling in my Shooting Gallery techical demo, and there were enemies wandering across the screen while viewport moved around. I don't remember they "stutter" or something.

Yes but keep in mind that the camera follows the player character, where as it was not following the npcs.

Quote from: Ben304 on Sat 09/01/2010 22:58:13
Yes but keep in mind that the camera follows the player character, where as it was not following the npcs.

If you control viewport explicitly, camera does not follow anyone.

I'm still not sure what stuttering was mentioned. I think I'll just check this out right now.

Yes but we are controlling the viewport TO follow the player. Just more smoothly.

Well, yes, now I see.

If I understand this correctly, the idea is to move camera 1 pixel per tick, yet it must keep character in focus (so it should be at same place relative to viewport).
To achive this character movement should be somehow synchronized with camera.

By the way, this reminds me... I saw some module:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33142.0
Does it make what needed or not? I'm gonna check it.


EDIT: I think it does... although it looks too fast in demo. Maybe some adjustments needed.
Anyway, I suppose that module may be a solution to your suggestion, Calin.

Runtime Error Reporting
Currently when a runtime error occurs, such as "array out of bounds", the cursor is positioned to the script line where the error occurred, a stack dump widow is displayed at the bottom of the screen and an error message pops up describing the nature of the error.   The popup window has an Ok/Dismiss button that closes the popup window and the stack dump window.  The popup window must be closed before doing any editor actions.  The problem with this is that in order to use the stack dump information one must record the information to paper before dismissing the popup window.   I have a couple of suggestions that would make it easier to debugging of these kinds of errors.

Leave Stack Dump Open
When the popup error message box is closed leave the stack dump window open.  This would eliminate the need to record the script file and line numbers of the stack dump.

Display Function Names in Stack Dump
The other thing that is routinely recorded on paper is the name of the functions that contain the script lines displayed in the stack dump.   It would be convenient and time saving if function names were included in the stack dump.   This would eliminate the need to inspect each and every script line in the stack dump to see it's context.

Goto Line on Click/DoubleClick of Stack Dump Line
It would be be really cool, slick, and all that stuff if one could click on a stack dump line to immediately to that line in the script editor.  This would allow one to quickly inspect the calling sequence that created the error.

Data Dump
It would be quite useful if one could inspect the values of dynamic variables defined in the function where the error occurred.   Presumably the data is readily available from the stack; I suppose the difficulty would be the availability of the variable names and stack location?  Anyway if this is practical it would be very useful.  

Thanks for the listen ;)

Isn't smooth scrolling what  this module (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33142) does?

No, that module sends me your credit card details.

But if you are using it for smooth scrolling it's pretty easy to change the speed.

Starting at line 764:

        float targetscrollspeedx = 35.0; // pixels per second
        float slowdownrangex = 100.0; // pixels
       
        float targetscrollspeedy = 35.0; // pixels per second
        float slowdownrangey = 100.0; // pixels


Just replace 35.0 with a lower value to achieve the effect you guys want. Unfortunately, slower movements are less perceptibly smooth at high-res because AGS moves the viewport in jumps of two pixels.

This is still for AGS 3.1.2 SP1, but it's a pretty interesting bug:

If you hide the player character in a room, SaveCursorUntilItLeaves doesn't work anymore.

It will change the cursor mode fine when you go over a hotspot, but when you move the cursor off the hotspot again, it doesn't change back anymore.

I think AGS should scrap all hard-coded cursormode functionality.
In order to be able to truly customize the way our games work we need to expand on the mode system rather than hold limits on it IMHO.

Cheers,
Sparky.

I agree, the hard-coded cursor mode functionality has been a thorn in my eye for a very long time. I appreciate it helps set up a very basic working interface for people who *just* started out using AGS but it really makes creating custom interfaces more of a cryptic hassle than it has to and can be a source for various incredibly hard to track bugs. I would propose a simple list of cursor modes without any meaning attached whatsoever and then in the Interaction panel for each hotspot/object/character and so on it would have a field for a handler for each of the modes.

Any other opinions?

I agree to the two above, I also hate Sierra controls anyway  :P

Maybe change it to a "Sierra cursor" module that comes as part of the default game, so it'll still be just as easy for newbies?

How about autocomplete to work with game start, repeatedly execute and the like? I'd really be useful for me!

I'm sure I've suggested this before but "winsetup.exe" isn't the greatest name for an options dialog anymore. Some of our users have already confused it with the actual game installer.
I propose the renaming of winsetup to "Config.exe". Simple, neat and clear. :=

Cheers,
Sparky.

Is it possible to add pixel-perfect click detection for GUIs? This may be useful in case you have non-rectangluar guis/buttons positioned so that their bounding rects overlap, and want them detect clicked ones correctly.
Otherwise this requires scripting detection.

I still think a full 8-bit alpha channel on drawing surfaces would be the most useful thing to add.... by far

Well you can draw 8-bit alpha channeled sprites onto a DrawingSurface...the problem comes in trying to merge alpha channels of two sprites which you can't do. IIRC you might actually have to use CopyTransparencyMask if the background is COLOR_TRANSPARENT, but it's still possible to do.

You just can't draw multiple alpha sprites onto the same surface without destroying all but one of the alpha channels.

Quote
I propose the renaming of winsetup to "Config.exe". Simple, neat and clear. Larry Values!!11

[
I agree but I would go a step further and suggest that it be included in the game executable and accessed like this:

    mygame.exe /setup 

I would also suggest that the setup program be script accessible  via built-in functions such as

     AgsSetup()   - open the winsetup.exe dialog and allow the user to edit the settings.

     AgsReboot() - use new settings saved in config file mygame.cfg (i.e. restart at current point in game)

I completely concur Rick. Thanks for elaborating.
Sparky.

Quote from: RickJ on Tue 26/01/2010 07:27:11
    mygame.exe /setup 

It already can! Nearly:

mygames.exe --setup is what works

Quote
I would also suggest that the setup program be script accessible  via built-in functions such as

     AgsSetup()   - open the winsetup.exe dialog and allow the user to edit the settings.

     AgsReboot() - use new settings saved in config file mygame.cfg (i.e. restart at current point in game)

In other words, a bit like this: http://ssh.me.uk/moddoc/GameSetup.zip

Quote from: RickJ on Tue 26/01/2010 07:27:11
    mygame.exe /setup 

But but but... don't you know what winsetup.exe does is only mygame --setup?

I understand the concern that some people may not be familiar with the '--' stuff though.

(Well, SSH beats me but I'd just post anyway.)

Hey man that was fast ... real fast!  ;)

Loved your module SSH. Very resourceful!

I still strongly suggest that AGS 3.3x come with an internal solution to changing all the game's config variables via script calls.

Cheers,
Sparky.

Quote from: subspark on Fri 29/01/2010 17:22:54
Loved your module SSH. Very resourceful!

I still strongly suggest that AGS 3.3x come with an internal solution to changing all the game's config variables via script calls.

Cheers,
Sparky.

Also the module causes some bugs. It's really good, but can end up teribly unstable at times. Perhaps it was me doing something wrong, but I wouldn't think so.

A way to adjust properties for multiple GUIs/GUI objects at once. If you need to make eg. a dozen buttons/labels with the same size, you need to adjust each one by hand.

You could do that from the script:

void SetSizeForGUIs(GUI *guis[], int guiCount, int width, int height) {
 if ((guis == null) || (guiCount <= 0)) return;
 int i = 0;
 while (i < guiCount) {
   guis[i].SetSize(width, height);
   i++;
 }
}

// meanwhile...
GUI *guis[] = new GUI[5];
int i = 0;
while (i < 5) {
 guis[i] = gui[i + 10];
 i++;
}
SetSizeForGUIs(guis, 5, System.ViewportWidth, 20);

It's a bit more round-about than your suggestion, but given the current method of resizing these items it would be very wonky to try and allow resizing multiple items at once anyway...

monkey, I believe Jim Reed means adjusting them in the GUI EDITOR.

BTW I remember suggesting adding COPY GUI OBJECT feature some time ago.

I know that CW, which is why I said:

Quote from: monkey_05_06 on Fri 29/01/2010 19:39:14It's a bit more round-about than your suggestion, but given the current method of resizing these items it would be very wonky to try and allow resizing multiple items at once anyway...