How about:
Being able to have two tabs side-by side in the editor, in case you are referring back and forth between them
Having a context menu option in the editor to pick a Sprite (or View or Character) from that pane and insert its number into the script, kinda like when you select a s[prite in the view editor.
Quote from: SSH on Fri 14/12/2007 12:23:11
Being able to have two tabs side-by side in the editor, in case you are referring back and forth between them
You mean, having the option to split the screen, with the tabs in both parts?
What about
- 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]
???
Quote from: Rulaman on Fri 14/12/2007 19:06:46
- 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]
You can already do that, you just need to check which language is selected in the room script, and do SetObjectGraphic() based on that.
I agree, an easy option to change languages for sprites, and for voices (just like for text) would be sweet. But all of this can actually be done by some extra work and scripting. You can actually even have an option where it all changes in game if someone wanted to by scripting it. Use variables:
Speechlang(speechlangnumber)
TextLang(Textlangnumber)
SpriteLang(Spritelangnumber)
Then do if's for every piece of dialog, sign and voice file (Forgive me, I havent touched the scripting in AGS for a few months) that would look like this or somewhat similar:
if textlang = 1 'English then displaymessage ("I speak English!")
elseif textlang = 2 'Italian then displaymessage("Io parlo Italiano!")
end if
Catch what I am saying? It can be done, its just more tedious and annoying.
------
I have a wishlist of 1 item though... In addition to the templates included with AGS can each template, including the newgame template include certain AGSeditor plugins, such as the music one? And can it include certain modules such as the Flashlight module, Lake Module, Particle Engine Module, Panaroma Module, Character Control Module if they were updated to work with AGS 3.0? I think these functions and modules are a dream come true!!!!! Best idea AGS ever had implemented.
I agree. I think hot swapable vox files are a smart way to accomodate different launguages for Talkie games.
Would it be reasonable to suggest that the translations manager manage not only text but graphics and speech too?
Cheers,
Paul.
It's a piece of very cheap cake to translate sprites, as Radiant explained.
And what's the point of implementing multiple voice pack support in the engine? All you have to do as author/player is to offer multiple packs for download/put the correct speech.vox in the game's dir. I got bashed for it in the other thread, but I'll say it again: don't request features for the sake of requesting features.
Request stuff that isn't possible yet.
In AGS 3.01, I'd like to have a native, optimized pixel-perfect collision detection.
Maybe a built-in x-dimensional vector class.
I'd love to be able to use custom structs as members of custom structs. I've read about the difficulties concerning save-games, though.
I would love to see, somewhere in the future, an intuitive way to create branching dialogues. 3.0 is already superior to 2.72 because you can see your dialogue lines and the script at the same time; what I would like to have now is some sort of visual editor- dragging your dialogue options into a tree-view-like structure at will.
Wouldn't dream to request this for 3.1, though; I think it's a major implementation, and so far I'm getting accustomed to 3.0.
I'd like to see an abstraction of the entire dialogue GUI interface. To make it more manageable as far as the code is concerned, without hassling with creating your own GUI/dialogue engine.
That's even more than what Ghost wished for. But, hey, I like to think big. :D
I would also like to see some more OO paradigms make their way into the code. Namely, direct access to the standard AGS classes, as far as custom variables are concerned. And polymorphism. I've heard CJ mention that both would make it much more difficult to implement saved games. Perhaps if that was also abstracted out. Of course, it wouldn't be used much of the time, but it would be available.
Anyway, keep dreaming big, if we ask for big stuff, we're more likely to get something simpler, which is always a step in the right direction. :D
1. Drag-drop to move sprites and views from one folder to another.
2. New Room and New Script create from user selectable template files.
3. In the GUI editor, when editing properties have ability to move focus from field to field and from control to control using hot keys. Some functionality is already there but not quite enought to accomplish this.
4. In the GUI editor hav the ability to lock the position of the controls via a check box or other means.
=========
I think the ability to load alternative sprite and vox files at runtime is probably a good idea at some point. The method Joseph speaks of is not really scalable and is not realistic for games that are large or that are translated to many languages. I wouldn't reject it out of hand but rather just give it the appropriate priority. There are likely many other things that ought to come first, so let the cards fall where they may.
Quote from: Ghost on Sat 15/12/2007 00:35:45
I would love to see, somewhere in the future, an intuitive way to create branching dialogues. 3.0 is already superior to 2.72 because you can see your dialogue lines and the script at the same time; what I would like to have now is some sort of visual editor- dragging your dialogue options into a tree-view-like structure at will.
Wouldn't dream to request this for 3.1, though; I think it's a major implementation, and so far I'm getting accustomed to 3.0.
I wholeheartedly second this.
Wonder if CJ'll have a heart attack when he sees all this, with the new editor, remade from scratch, not even fully completed yet...
subspark, your on to something here with the vox file thing. Maybe you can put VOX files in the directory that the Language is spoken in. EG. Voice.vox in Italian directory for Italian...
Anyway, Since this is a wishlist, maybe this might be one of few times I wont be in trouble for saying something...
1) Higher resolutions
2) Use of 3d files, particularly halflife/quake 3d files for characters. Those things are a dream...
3) point plotting in the AGS room editor. The Gimp has an idea of what I am talking about.
Quote from: Rui "Trovatore" Pires on Sat 15/12/2007 09:55:15
Wonder if CJ'll have a heart attack when he sees all this, with the new editor, remade from scratch, not even fully completed yet...
Not untrue, but: Reach for the moon. Even if you miss, you'll land among the stars ;)
Then again, let's face it, 3.0 will be a pretty large step, if I read the signs right. People will love it it, hate it, and will say so. It's also been long in the making, and now that it is clear that there will be no new features taken abord, a new future wishlist has been started. It's just a collection of all the little wishes that *always* turn up here.
I hope CJ looks down to us with nothing but benevolent patience, as we toil around taking his toys apart.
Oh, I haven't said this in a while...
Dynamic TrueType Font support! :D
And, let's see...
Maybe an intergrated video playback...thingy. To negate the need for WMP, and such...
Y'know...using an open source codec, or something.
...
I'm no good with the technical stuff.
The other thing is that some of these things might actually be on the bug tracker: http://www.adventuregamestudio.co.uk/tracker.php
We ought to give Chris a lot of credit for the crap we asked him to implement... Each your heart out SCRAMM and GLUMOL!!!!
I am ready to SCRAMM as much as possible but refuse to GLUMOL because I do not know how to do that.
I also wish to have the Make My Game button back, but this time working.
Are we getting greedy? It's always easier to recieve than to give, sure, but I think that there is a sort of teamwork here. CJ provides an engine, and it is a skillfully put togehter program for sure, but I like to entertain the idea that the community provides the testing, the training wheels, and if there is, in a hundred reedy demands for Feature x, one that makes sense, real sense, that surely is a help.
It's all a matter of Sensillen, actually.
I don't know whether it's been added or not since I last used AGS, but:
- Better palette handling for sprites. Too many times I've lined up the colours in a sprite I want to use certain palette slots and AGS rearranges them, making my palette tweaking pointless.
OR
- Minipalettes, with 16 color palettes for sprites that we can edit, similar to OHRRPGCE, or even the SCUMM engine! It would make tinting a breeze. :)
Document Editor
Since the new editor can now supports multiple files via tabs and since SSH has asked for a future ability to have side by side panes, how about having the ability to edit text document files.
The document files could be kept in a "Document" sub-directory. In the project tree there could be a document node that when expanded would list all the document files in that directory. The same editor component used for the script editor could be used for this. I believe the ediitor component has the ability to highlight HTML and XML syntax. If so HTML files could also appear in the Document directory as an added bonus.
Paths Configuration
Currently there is only one import path. It doesn't matter what is being imported the same default path is used. This was also true in previous versions but they at least remembered from where the most recent import was made and use that as the default the next time. The new version just switches you back to the same directory no matter what.
I would like to have different default paths for different things; one for sprites, one for fonts, one for modules, etc. I would also like to have an option for each of these paths to use the most recently used path as the default which would override the one set by the user. It would also be nice if these could be set on a per game basis. I don't think there are many people left in the world who put every file they own in one big directory anymore. :
[edit]
corrected spelling
QuoteI would like to have different default paths for different things
This is something I have put forward to Chris before. I agree. It would unclutter the main directory and keep things organised within a team environment.
Quotedon't request features for the sake of requesting features
Your right Khris. Sorry; old habits in combination with overexcitement for this new editor.
I truly wish for a revised dialog editor with support for non-blocking functionality.
This is something I've requested for before in another thread but this thread sure seems appropriate.
Thanks, ;)
Paul.
Oops!!! The ultimate wish list... Err I mean tracker, is actually here: http://www.adventuregamestudio.co.uk/tracker.php
I should just say, I'm not a great fan of "wishlist" threads. They tend to grow and grow with increasingly wild suggestions that people think up, and end up being pretty much useless (which is what happened to the old AGS Suggestions thread a couple of years ago).
But if we keep it sensible I guess it can't do any harm.
QuoteBeing able to have two tabs side-by side in the editor, in case you are referring back and forth between them
I'm not sure how this could really work ... if you had two script editors open side by side for example, which one would the Edit menu apply to? Or the property grid?
Quote- multiple speech.vox (or music.vox)
i.e. speech.en, speech.de, speech.es (or german.spf english.spf, ...)
I do like this idea, because at the moment you can have multiple translations in the game directory but not a language pack for each one.
Quote- sprite-en.pack ( contains some sprites, shown in-game that was translated )
i.e. in-game a sign shows "Le Bakery" and in the translated version "Bäckerei"
I like this idea as well, but I haven't come up with a good way of implementing it yet.
Quote from: Pumaman on Sun 16/12/2007 20:59:35
I should just say, I'm not a great fan of "wishlist" threads. They tend to grow and grow with increasingly wild suggestions that people think up, and end up being pretty much useless (which is what happened to the old AGS Suggestions thread a couple of years ago).
But if we keep it sensible I guess it can't do any harm.
I am just glad I did not start the thread this time.... :-X
Quote
Quote- sprite-en.pack ( contains some sprites, shown in-game that was translated )
i.e. in-game a sign shows "Le Bakery" and in the translated version "Bäckerei"
I like this idea as well, but I haven't come up with a good way of implementing it yet.
What if after you load the translation files of each language, you can then edit in the properties pane which image to use for that particular language. Actually Chris, if there was some way of detecting which language is running within AGS, you would then just be able to script this somehow right??? EG: If Curr.Language == Italian, then object9.sprite = 30.
Forgive me, I havent touched the editor in a while so the scripting I just put there comes up like crap. Right now I have been trying to improve my Simpsons games graphics. They really need some work.
Oh and just for organizational reasons, I just added the two liked suggestions that Chris mentioned above to the feature/bug tracker. Dont know if you still use it Chris, but just in case...
Quote from: Joseph DiPerla on Sun 16/12/2007 21:37:17Actually Chris, if there was some way of detecting which language is running within AGS, you would then just be able to script this somehow right???
You mean such as checking Game.TranslationFilename ? ;)
I definitely support the localized speech files idea, since it seems to be quite a simple fix (just changing the filename that AGS reads voices from). I guess the only major programming task would be to implement winsetup support for it.
That's indeed possible (at least since 2.6, afaik):
if (IsTranslationAvailable ()) {
if (Game.TranslationFilename == "French") ...
...
Edit: Why would winsetup be involved? AGS would open "name.vox", according to the "name.tra" it's using.
The funny thing is, is there actually a game featuring more than one speech.vox file? Or rather: will there ever be one? ;)
Ah, very true. I hadn't thought of the .vox file sharing the name of the text translation :)
Edit: Actually, now that I think of it, it could be argued that some users might want to play the game with English audio but localized subtitles. But of course then they could just delete the localized .vox file.
Quote from: GarageGothic on Sun 16/12/2007 21:46:18
Quote from: Joseph DiPerla on Sun 16/12/2007 21:37:17Actually Chris, if there was some way of detecting which language is running within AGS, you would then just be able to script this somehow right???
You mean such as checking Game.TranslationFilename ? ;)
I definitely support the localized speech files idea, since it seems to be quite a simple fix (just changing the filename that AGS reads voices from). I guess the only major programming task would be to implement winsetup support for it.
HEHE. Told you I havent touched the scripting in a while... ;)
But yeah, if you have that, couldn't you just script the sprite thing?
And KhrisMUC brings out a very good point..
Quote from: Joseph DiPerla on Sun 16/12/2007 21:58:52But yeah, if you have that, couldn't you just script the sprite thing?
Sure, that's exactly what I did in two Maniac Mansion Mania episodes so far.
Actually, the starter pack we're using (which is based on Maniac Mansion Deluxe) uses this method to translate the 9 verb GUI. The images and positions of the buttons are mapped using strings, allowing the translator to use their own images by using lines like "A_GIVE 7 804 805" in the translation source. Very handy.
Implementing this technique is as easy as putting this in before_fadein:
String s=GetTranslation("48");
oSign.Graphic=s.AsInt;"48" will now end up in the translation source.
Was 2D arrays ever added? Thats on my wish list.
Would be cool if you could store struct references within structs if you can't yet in AGS 3.0
I think there were a couple of modules that dealt with that, Delta.
Quote from: deltamatrix on Tue 18/12/2007 00:45:04Was 2D arrays ever added? Thats on my wish list.
AGS 3.0 now supports
dynamic arrays (http://americangirlscouts.org/agswiki/Dynamic_Arrays) which makes building multidimensional arrays somewhat easier (as you can use "non-constant" values such as "eEnum1 * eEnum2"). The MultiArray (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=32147.0) module that I wrote specifically for AGS 3.0 allows for arrays of any number of dimensions of any size provided that the total product of all dimension sizes is less than 1000000 (one million). You may find it of some interest.
Quote from: deltamatrix on Tue 18/12/2007 00:45:04Would be cool if you could store struct references within structs if you can't yet in AGS 3.0
That's not yet possible unfortunately.
I'd like to see an option to clear the Recent Games list, since it can easily add up over-time.
I just 'd like to see a File.Delete() function added..
Moving sprites into/out of folders, moving views into/out of folders. I realize you said deleting the views could cause problems, so how about a right click 'clear' option that safely resets a view? The new Dialog concept you suggested with just activating it in the main script through Dialog.Start() with the topics and other stuff handled between it and something like Dialog.End() would work great as well, and would make it function similarly to StartCutscene/EndCutscene, which is always a plus design wise.
This has been discussed once before, but I think the AGS directory should now be cleaner with sub directories for plugins, templates and modules.
Cheers,
Paul.
Yes, it should. In fact, that's exactly how mine is arranged, and everyone can arrange it howsoever they like. :P
Quote from: Pumaman on Sun 16/12/2007 20:59:35
I'm not sure how this could really work ... if you had two script editors open side by side for example, which one would the Edit menu apply to? Or the property grid?
It would have to be possible to select one, to which the edit menu and property grid would apply to. Opera does this, you can 'tile horizontally', and whichever specific window (within the main window) is selected gets to be controlled by the menu items.
It is indeed a very good option to have, though fairly hard. It'd require a true MDI (or a very well-hacked SDI) to work well.
QuoteYes, it should. In fact, that's exactly how mine is arranged, and everyone can arrange it howsoever they like.
Thats not quite what I was getting at. Let me rephrase:
I think AGS should read plugins, templates and modules from directories rather than the root folder exlusively. If one is using several templates, several plugins and several modules things can become rather confusing and untidy. I think it is time to reinforce tidyness or at the least, support those of us who keep tidy.
Paul.
Like allowing the user to set a series of default directories per type?
Quickbasic 4.5 allowed that, you just set the directories to where you wanted them to be and that's what it'd look in. Worked like a charm.
Precisley. I'm leaning more towards letting the user specify a set of directories rather than having a predefined search path. :)
Cheers,
Paul.
I wish:
- x,y,z coordinates system like OpenGL.
- Advanced shading
- Unlimited dialogs, unlimited rooms
- Better font outline controls. E.g. change of size-color of outline
- import 3d objects
- import 3d scenes
- Up to 1600*1200 resolutions
- Support for surround sound
- Full support for alpha channel images
I think my 3d wishes is later maybe in AGS 4.0
It would be wonderful if the room's repeatedly execute function (Room Events pane) could default to the function: repeatedly_execute. This just caused me a good bit of frustration trying to figure out why it wasn't running until I realized, d'oh! it's a room script!
Another thing I would like is for the 'Find and Replace' dialog to work a bit more like it does in Firefox. I'm referring specifically to two points: a) it could appear as a static pane at the bottom of the window such as the 'Output Window' pane does, which would allow us to navigate the scripts while the dialog was open, and b) a 'match case' option for finding case-sensitive items (which ordinarily might not be a problem, but since AGS is case-sensitive, could be relevant; for example, searching for 'string' vs. 'String'). This is a much more minor request than my first (about the room's rep_ex), though I would find it quite beneficial.
What AGS needs to become a better engine, in my humble opinion, without massive code changes:
- better support for the higher resolutions (640x480, 800x600)
Right now, all room coördinates are scaled down to 320x240 (or 320x200)
=> prevents me from placing alpha-transparent objects on the EXACT pixel position I want.
=> imported masks always need to be at this lower level resolution, so I can't have exact walkbehinds and regions
- a better/quicker way to load sprites into loops.
=> I want to be able to select a whole series of sprites and go "import into loop x", rather then having to enter the sprite number for each frame seperatly. This is a time-killer if you got a rather large animation.
=> I want to be able to drag and drop frames once loaded in the view, so I can rearrange them easily (or a "move" button when right-clicking, that would help too.
- drag and drop of views into folders, the ability to easily rearrange views into logic groups
- dialogs:
=> add a "set-speech-loop NAME X" function. This is for fixed-position characters which have different expressions in different loops. (I don't want to have to create a new view for each single facial expression)
=> the character reverts to his normal view when other characters are talking. I would like to have the option to make him stay in his current view. (otherwise the character would change facial expressions suddenly when another character speaks. In order to prevent this I have to do a run-script and change his normal view every time. Rather annoying.)
/* Note: all of these problems can be 'bypassed' but it takes a LOT of time that I don't believe is needed to spend on this. If these issues are adressed a lot less time is needed for the game programmer on 'cosmetics', and there's more time to go into the actual coding. */
Quote from: Electroshokker on Sat 19/01/2008 13:47:13
- a better/quicker way to load sprites into loops.
=> I want to be able to select a whole series of sprites and go "import into loop x", rather then having to enter the sprite number for each frame seperatly. This is a time-killer if you got a rather large animation.
This already exists. Select more than one sprite in the editor and right click. In the context menu there should be an "Assign to View" item. Click on that and you can choose which view to stick the selected sprites in. :)
Quote from: VK Dan on Sat 19/01/2008 13:51:08
Quote from: Electroshokker on Sat 19/01/2008 13:47:13
- a better/quicker way to load sprites into loops.
=> I want to be able to select a whole series of sprites and go "import into loop x", rather then having to enter the sprite number for each frame seperatly. This is a time-killer if you got a rather large animation.
This already exists. Select more than one sprite in the editor and right click. In the context menu there should be an "Assign to View" item. Click on that and you can choose which view to stick the selected sprites in. :)
Allright! :D
How 'bout having a button in the views panel which enables you to do the same? I think it would be a logical place, and makes it harder to overlook this feature.
I posted it twice because it'd be nice if the staff read it.
*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.
Well that's all for now. If I figure out something else I will tell you.
Thanks for the great new version! :)
Quote from: proximity on Sat 29/12/2007 03:55:25
- Better font outline controls. E.g. change of size-color of outline
- Support for surround sound
- Full support for alpha channel images
Removed absolutely stupid suggestions.
This is more geared towards a 4.0.1 release, but hey, suggestions are always good!
-SVG support for Vector sprites. Then the images wouldn't lose quality when resized.
-Possibly use the Qt 4.4 toolkit? It supports complete cross-platform, and the underlying technologies (Plasma, Solid, Decibel, Phonon, Oxygen) would make some excellent solutions for frustrated game developers. I'll go into this later on in the post.
-Ports to Linux and Mac OSX? I always push for this. Hey, at least we get a runtime, which runs most games pretty well.
-OpenGL acceleration/rendering.
-Backends allowing for Blender imports?
-Compatibility for reading older game templates (mainly so developers can upconvert their games to a latest release, thus making a packaged runtime for crossplatform support)
-Plasma technologies use widgets as parts of a window, the desktop, whatever you want. So, lets say the editor could be rearranged by simply clicking, dragging, and dropping? That way, a user who doesn't like everything about the layout can rearrange it to resemble whatever works for them.
-Phonon is an open-source media framework that allows for a simple, streamlined media runtime. Using only 4 lines of code, one could build a simple music player. So, utilizing this would allow for media tricks in AGS. Ever had a problem playing an MP3 in-game? Ever wanted it to give a certain feedback when that MP3 is played? With Phonon, this is possible.
-Decibel is built on the Telepathy framework, which calls forth technologies allowing the user to simply set up a multiplayer/internet script. Theoretically, it could be used to solve the "AGS Multiplayer" option.
-Solid is a hardware API. It interacts with Decibel and Phonon to tell the game about the system it's being played on. What graphics card is running? What network card? Sound card? Is it multithreaded?
-Oxygen is not a technology per se. It's a standard for artwork.. Not game artwork, but the editor interface. Using Oxygen artwork, AGS could change from looking just functional to amazingly beautiful.
And how many redistribution packages, runtimes, plugins, extra .dlls or other junk would the end user have to install to play a game or use the editor with all that in it?
Quote from: Ishmael on Tue 22/01/2008 21:28:41
And how many redistribution packages, runtimes, plugins, extra .dlls or other junk would the end user have to install to play a game or use the editor with all that in it?
Very little, surprisingly. It ports extremely well between platforms.
As far as I'm aware, to port the editor (if it were theoretically using this technology)
-Write it in a common language, such as C++, Java, Python, or pretty much any other language, using the Qt toolkit as a guide.
-Correct a few errors here and there for cross-compatibility.
-Add in a few OS-dependent features, such as the universal menu and Cocoa/Carbon for Mac OSX, CMake for Linux, and whatever the hell Windows uses for Windows.
As for redistribution packages, there could be a lot, judging by how many Linux OS'es there are. Luckily, the easy way is to just release a tarball for Linux users to compile, and somebody will package it for their particular OS. Oh, and there'd be one for Windows, and one for Mac.
As for .dlls, I don't know. However, I've seen a lot of KDE (K Desktop Environment) apps being ported to Windows and OSX, and they seem to develop easily enough. It takes time, and effort, but interoperability is a fantastic feature, and Qt 4.4 (soon to be officially released, currently it's on 4.3) is capable of easily porting. Don't ask me the specifics on how, I'm not quite entirely sure. However, I can pull up a bunch of Wikipedia articles that give some insight, and so I will at the end of this post.
That said, it could all be packaged together with the editor, the runtime, everything. Meaning all one would have to do to use the editor is to install it. As for an individual game, perhaps it could ship with a runtime specifically for that game. Like I said, not entirely sure how Windows programs compare to Mac or Linux ones.
As promised, here are some articles on everything I've talked about.
http://en.wikipedia.org/wiki/Qt_%28toolkit%29
http://en.wikipedia.org/wiki/Cmake
http://en.wikipedia.org/wiki/Decibel_%28KDE%29
http://en.wikipedia.org/wiki/Kross_%28KDE%29
http://en.wikipedia.org/wiki/Oxygen_Project
http://en.wikipedia.org/wiki/Phonon_%28KDE%29
http://en.wikipedia.org/wiki/Plasma_%28KDE%29
http://en.wikipedia.org/wiki/Solid_%28KDE%29
(http://i208.photobucket.com/albums/bb259/khrismuc/Bender.jpg)
Would be nice if you could change dialog option texts in-game.
Something like Dialog.SetOptionText
I'm not sure when you'd need something like that. The dialog script is set in stone, so changing just the options doesn't make sense (unless you're talking about slight variations in phrasing or handle everything using dialog_script).
As a workaround, put the different lines directly after one another (say options 3-5), uncheck say of 4&5 and turn them on/off one after another.
- Double-clicking on an event editbox doing the same thing as the "..." button (it's just faster :P)
- Properties panel not getting reset whenever you edit an event
Quote from: KhrisMUC on Wed 23/01/2008 20:52:37
unless you're talking about slight variations in phrasing
Yes, slight variations would be easier to do by scripting, but it would also make possible to add things like player's name, or something player has written to a textbox, into dialog option texts.
Hi, if it's not too late I'd like to see higher resolutions supported (more than 800x600) : ALL monitors support at least 1024x768 nowadays, and the use of hardware acceleration in the new version could improve the rendering speed.
I have a project and consider WinterMute a serious challenger, even if it's not adventure-game oriented. A friend is doing a comparison between WM and AGS. Resolution is a big point for me.
Since there already is a game.speech_music_drop, why not something like game.sound_music_drop which lowers the volume of background music whenever you use playsound?
That doesn't make much sense, though, does it? The purpose of lowering speech volume is to hear it better. A sound effect needs to be integrated within the game's music/sound system/settings/whatever.
(Sorry about the late reply.)
Hm, you got a point there.
However, in my game I'd like to emphasize the scoresound and lowering the background volume really gives you the feeling something special happens.
It's not difficult to code, so it really isn't necessary, I just thought it would be easy to implement.
I don't care as much about larger resolutions, but how about being able to specify window size up to the resolution size... like if I want to make a game in widescreen, say to match the PSP 480x272, or smaller like the DS 256x192...
or even if I want a game window that's vertical.
Quote from: alisa_tana on Sun 10/02/2008 00:05:43
I don't care as much about larger resolutions, but how about being able to specify window size up to the resolution size... like if I want to make a game in widescreen, say to match the PSP 480x272, or smaller like the DS 256x192...
or even if I want a game window that's vertical.
You can already script that, can't you? Well not window size, but playable area size. Using mouse bounds (they still are in, right?) and a 320x200/240 GUI with the game area size hole in it to hide any extra stuff easily...
The ability to set the Loop number and Frame of an object as you can for characters would be nice and consistent, since I often want to update the frame of an object manually but cannot right now.
As mentioned before, it would be nice to be able to access things like the stack trace in the scripts, like you can in some languages like python. It would allow functional as well as debug stuff, too.
I wish for the ability to tell AGS to ignore unhelpful warnings like "Character (Narrator): normal view 4 has no left/right frames and could crash the game."
In my case the narrator is invisible and need not carry any frames.
Cheers,
Paul.
So why not use the special default narrator character?
game.narrator_speech
Which character ID to use for voice speech within Display() command. Default initial player character. You can also use NARRATOR which uses 'NARR' prefix - special narrator character.
;)
Whoops ;D Perhaps I should do some reading! :-[
Cheers,
Paul.
Erm... maybe i'm being a zealot, but shouldn't this other thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33578.0) be used instead of the current one, as CJ asked (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33624.0)?
I've being following the other one, but it seems that this one is getting all the attention.
Only for practical, immediate sorts of suggestions, I think.
Anyway!
Item #1. Tentative suggestion: Would it make any sense to have pointers to functions?
Item #2. And another odd one: What about something like function String.AsScript(String code) which would read the String (as it would be displayed on the screen, in the case of characters like % and ") as if it were a line in the script. Coupled with an input box you could do all sorts of Debug type functions really easily (like getting/setting variables, for instance.) I'm sure it would also be useful in a ton of work-arounds, though no specific examples come to mind, immediately.
A function that checks whether a given String will crash the game (or whether it would have compiled as a normal, preexisting line of code) would probably also be a handy accompaniment, if not strictly required.
I have no idea if such a function is technically possible or not, but I thought I'd throw it out there.
Function pointers would be quite useful in some circumstances, yes. I'm not sure most people would have a use for them, though.
How about multiple hotspots on characters?
QuoteHow about multiple hotspots on characters?
Do you mean if the player is clickable you could for instance move the mouse over the character's arm or face and the text name updates based on those regions?
I'm no programmer but I imagine this is a pretty specialized feature that I'm guessing could be coded in per user rather than be added to AGS for all. However saying that, this is an interesting idea and 'Character Regions' could well be something everybody wants!?
Cheers,
Paul.
From the manual:
QuoteBecause there is no new keyword, you cannot create object instances.
Well, this certainly isn't true anymore, as we now do have a 'new' keyword, hehehe.... Seriously, creating Objects and Characters dynamically would be a big feature for me.
Another need, especially for module writers, is the ability to use struct pointers inside other structs (allowing complex data structures, or 'object-oriented-ness') and to return custom struct pointers from functions.
I realize this is more likely to be in AGS 3.1 than 3.0.1, but somebody has to ask for it... :)
One of the biggest problems with dynamically-created Objects/Characters/Hotspots/Regions...etc...is that they all have interaction events. If they were created dynamically, how would these be handled?
One solution would be using function pointers. Then we could have something like this:
// internal
managed struct DynamicCharacter {
// constructors
import static DynamicCharacter* Create();
import static DynamicCharacter* CreateFromCharacter(Character*);
import static DynamicCharacter* CreateCopy();
// destructor
import void Delete();
// set interaction functions
import bool SetInteractionEvent(CursorMode, (*evtFunc)());
// etc.
};
// user-code
DynamicCharacter* egoCopy = DynamicCharacter.CreateFromCharacter(cEgo); // create a copy of EGO
function egoCopy_UseInv() {
if (player.ActiveInventory == iRottenfish) {
egoCopy.Tint(0, 250, 0, 30, 100); // used rotten fish on copy of EGO
}
}
egoCopy.SetInteractionEvent(eModeUseInv, egoCopy_UseInv);
Of course this would become very cumbersome in practice because you would first have to define the DynamicCharacter globally (to that particular script) then inside some function set it, then define the interaction function outside of all other functions, and then finally inside a different function set the interaction function.
Struct-within-struct support as well as pointer-to-struct support have both been discussed several times before, but AFAIK haven't really been feasible due to internal limitations. Hopefully this new version of the editor will have cleared some of that up.
Clearly pointer-to-struct support (with pointers-to-structs being allowed within custom structs of course ;)) would be the most flexible and powerful solution in this case. Perhaps now that CJ has finished his revamp of the editor he could take another look at the current status of this request.
Quote from: monkey_05_06 on Sun 17/02/2008 17:26:09
Struct-within-struct support as well as pointer-to-struct support have both been discussed several times before, but AFAIK haven't really been feasible due to internal limitations. Hopefully this new version of the editor will have cleared some of that up.
Clearly pointer-to-struct support (with pointers-to-structs being allowed within custom structs of course ;)) would be the most flexible and powerful solution in this case. Perhaps now that CJ has finished his revamp of the editor he could take another look at the current status of this request.
I know, offtopic (mentioned before), but I just HAVE to throw this in once again: that above would be the only left part of functionality that I miss in AGS... big, big time. Although it clearly isn't necessary for most simple adventure games, especially the new OO-aproach to modules/scripts etc. would hugely benefit.
Anyways, coming back to the topic, I have two small additional ideas/suggestions:
#1: would allowing the user to overload functions like in C++ be possible? This would mean the coder can define functions with the same name where the parameters are different? This can always be worked-around etc. but it'd be nice to have. Example:
// in "Renderer.asc"
function CRenderer::DrawPixel ( int x, int y )
// draws a pixel
{
// draw pixel using int-type coordinates
}
function CRenderer::DrawPixel ( float x, float y )
// draws a pixel
{
// draw pixel using float-type coordinates
}
Again, I know this can always be worked around, but I'm just pointing out the elegance of such an approach, I realize this might be low-priority though...
#2: People have discussed different ways of structuring the Script-tree in the side-window thingie, my suggestion here would be to sort by type like this:
- Scripts
- Script Files
Renderer.asc
Tile.asc
Sprite.asc
Particle.asc
GlobalScript.asc
- Script Headers
Renderer.ash
/* etc. */
This is how it's handled in MSVC 6.0 and it seems like a very clean and usable solution.
A simpler approach would be to just add Script Folders so everyone can organize their scripts however they wish.
Though at this rate we're gonna end up with folders for everything! :P
Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?
Not continuiing this conversation...
I was thinking of a way to add a certain feature for a game I am helping to program. Regarding dialogues, can there be an option when you add a dialog option that says "show on all dialogs"? In other words, we have a "say" option and a "show" option in the editor. But this option would allow that line to be displayed on all dialogs at the bottom. Is that possible?
Another script function I was hoping to get... Actually a few... Are:
AddDialog(DialogName)
AddDialogOption(DialogNameToAddTo, Dialog String, ScriptToRun)
And is there a way to check what the current dialog option is?
These are some crucial items for this particular project I am working on. And it SEEMS (But I know its not as easy as it sounds) that this is not too difficult to add, I hope. The first option is really for convenience, but this can be done, with a lot of coding by just using the script functions I Requested. But at least it would be possible, unless this is possible already.
Thanks for listening.
Any chance of bringing back support for PCX files?
Only, DPaint Animation only supports PCX and LBM formats, so ditching support for PCX files means an extra conversion stage for every single sprite :(
Cheers,
CapnBinky
Quote from: Pumaman on Mon 18/02/2008 19:25:23
Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?
I like the current layout. There is a purpose for every element of an adventure game production and it's immediately obvious and accessible. I don't imagine collapsing everything up into another folder would aid accessibility no matter how convenient it sounds.
Thats simply my opinion however. :)
Paul.
Quote from: Pumaman on Mon 18/02/2008 19:25:23
Actually, that does beg the question ... should the editor folders be arranged like they are at the moment, or should there simply be one root "Game" folder, and then you can just right-click and "Add character", "Add view", "Add font" or whatever else to have everything arranged wherever you feel like it?
I think that, as long as we can delete any item (characters, views, fonts, guis, rooms, etc), i'm happy with the current layout.
In AGS 3.0.1 b2, pratically all items can be deleted (if not all), as opposed to AGS 2.72, in which we could only delete GUIs, if I recall correctly.
Besides that, the current folders act as a cue to newcomers that all those elements are part of a 'normal' AGS game, and the designer can, if he chooses to do so, include items under them.