It occurs to me that with the release of the source code everyone may be experimenting and doing new stuff, which is cool.
However that means we might all be doing the same thing which would be totally stupid.
So it might be a good idea for ideas to be in the open a little so that people aren't doing something that someone else is doing.
It also might be nice if we had some kind of list of things that people think the editor is missing.
So in that vein I thought I would declare that I'm working on updating the gui editor. If anyone else is working on the same thing then feel free to PM me and discuss it.. or just do what youre doing anyway just for gigglez.
I've already implemented a few things like control locks and control snapping but is there anything else that people think the gui editor (or indeed any part of the AGS editor) is missing?
Well, I will not be doing any editor extensions myself but I have a few wishes:
- A way to refresh the auto-completion database for instance with a key shortcut.
- If someone could hook up the editor with ASpell that would be really swell :D (Dialog editor and strings used in Say and Display functions, etc.)
I'll edit this post if more come to my mind.
I haven't had time to look at the source yet (have to reinstall Visual Studio first), but I think the room editor in particular needs careful coordination. Someone (ProgZ?) mentioned a wysiwyg'ish approach to see the effects of scaling and light settings on a character directly in the editor, which is a great idea. But it's also a good example of something that would have to be modularized enough that other engine plug-in coders could substitute their own room renderer, for instance to display 3D characters in the editor preview.
Most of my own ideas for the editor relate to engine plug-in functionality rather than enhancing the usability, but I'd be very happy to see the dialog editor redone to actually be helpful - I think there's was a plug-in or external dialog editor at some point, but I don't know what the status is on that.
I'm still familiarizing myself with vs 10 but I intend to give room edit a well-deserved upgrade. A few things I've been itching to implement:
1. New drawing modes (ellipses, selecting a painted region/hotspot/walkable area and be able to reposition it).
2. Zoom within the default dimensions of the area rather than resizing the form.
3. Visible characters in rooms. If they have a non-negative room listed, characters will appear in room edit at the coordinates specified with their base sprite (walking view, loop 0, frame 0). No more guesswork with precision placement of npcs by tables or doors, etc.
4. (Optional) A checkmark option by each mode so you can view objects, regions, walkable areas simultaneously if you want. This will be especially helpful for getting accurate region placement.
All of these seem possible from looking at the project so it's just a matter of having the time to do it. At some point I'll likely set up some polls at my website for recommended features to implement, that way the most desirable ones can be tackled first.
In terms of GUIS, these are some improvements I've had in mind for awhile, though at least two of them seem unlikely right now:
1. I suspect it's impossible without access to the engine to, for example, increase the maximum number of buttons available on a gui, or, indeed, to increase the maximum number of animating buttons beyond 10 (setting this to the number of available buttons just makes sense to me for some reason).
2. More user-friendly options including, eventually, a 'dialog' listbox you could drop into a gui to completely design and customize a dialog list gui from within the editor. This would include the option of auto-resizing itself to fit the text (or not) and support for scroll buttons, a parser, and so on.
Something else I might tackle later on is to add folder support to the Characters pane.
At this point, it might be a good idea to open a new forum section for the editor and its source code.
Ok, I won't deny that at the moment this is selfishly motivated, but I think in the end posterity will benefit. I pushed this in the previous suggestions' thread so here it is copy and pasted:
Could the parser word list be [optionally] organised into folders, in a way identical to the current sprite folders? That is, users can create their own sub folders for nouns, verbs, commands, adjectives, etc - or for whatever they want (words relating to cake!). Is this complex to do? I haven't got a clue.
It would bring custom organisation to the text parser, which can quickly turn into a jumble, with verbs, nouns, and adjectives mixed in together as they are added. It's a nightmare to keep track of them or weed out words you no longer have a use for. The way IDs work does not need to change - new words would still take the next free number. Something like this should be of lowest priority (clearly, there are so many options open now!), but it would be a lifesaver.
PS. I have full faith and admiration for everybody that will be working on stuff that's over my head.
I totally second all of ProgZs suggestions. They would make everything much easier.
Oh, and as for the GUIs: Aside from locking, snapping etc. it would be cool if one could zoom in like in the room editor.
Quote from: ProgZmax on Wed 27/10/2010 03:37:47
I'm still familiarizing myself with vs 10 but I intend to give room edit a well-deserved upgrade.
You might have problems with updating the room editor without a significant recode of the drawing mechanism.
Currently the editor delegates all drawing functions to the Native DLL, which is not open.
You can't edit the drawing functions in any sense or add anything to be drawn, only the positioning of the entities currently recognised by the editor.
So perhaps a good start would be to rewrite these drawing functions into the main source.
EDIT: Although actually now i think about you could always draw
on top of what has already been drawn.
Here's a simple thing I'd like..
Event triggering:
eEventAfterFadeIn()
data= room that just faded
Yeah, I can code it as a module, but it'd be a nice addition. And I suck at C. Like a lot. It's a simple thing, but that doesn't mean it's not a useful thing.
-I'd like to also draw hotspots in-game
-And a good thing would be to allow hotspots to have their name change in-game
Thats all engine stuff Duals.
This is for *editor* changes
Oh, well the editor is great as an IDE. I'd like a button supported by all AGS engines saying "Calin loves you"
Bottom right corner. With a japanese animation smile preferably. Something cute and adorable.
On a serious note:
NOTEPAD INTEGRITY.please! A man has to be able to do that. Nottttttteeeeeepppppppaaaaaaaddddd!
Thank you.
Aww... and I have to learn java :'( But it's already very cool to see some C# knowledge around and I keep my fingers crossed, that Calin doesn't burn out (too quickly).
What I like to see in the editor is folders for modules
The next cool thing would be bringing the "Edit Functionality from module editing to the dialog editor. Since dialogs can contain script, I'm desperately missing bracket matching, search & replace and so on.
These would be awesome.
Btw. I bet organizing this inside a tracker would be much easier ;)
Once I've got my new lappy, and a few life things sorted, I'll have a look at this.
Although, for the moment I'll have to be using the express edition, any news as to whether it works?
I'm using MS Visual C# Express 2010 and works great.
CD-Key in case someone needs it (if it's against the rules I can remove)
Spoiler
PQT8W-68YB2-MPY6C-9JV9X-42WJV
the program is free, it just needs a free registration. It's no biggie. Then just load the project and do a simple conversion (it asks for conversion) no biggie there either. Really simple steps.
A lot of these suggestions are really cool. I can't wait to see what's gonna come out of this!
Personally, I would like to see:
- An improved palette editor, maybe room specific. I'd like to be able to view my palette from within AGS.
- More elegant sprite importing for 8-bit sprites. GIF animations never have a "don't remap colours" option, so importing a massive amount of sprites is arduous, especially if they're room specific.
And that's all I can think of for now. AGS is pretty elegant otherwise for me.
- Drag'n'drop for sprite folders!
- A checkmark option "ALWAYS USE ALPHA-CHANNELS" for importing sprites
- Auto-selection of the delay-panel when selecting a frame, so that you can immediately type in the delay
I'll extend this list if I come across other issues.
It would be cool if Roomedit could load alpha channels from pngs as masks (walkbehind etc..) It wouldn't need to actually use them in game (which would be cool too) but just not having to deal with those 8 bit BMPs would really help a lot.
Calin how about adding the ability to copy/clone or "cut and paste" controls? For example one would create a control such as a button and edit it's properties in the normal way.
The copy function could be activated by right clicking the control and selecting copy from a context menu. This would save the control's properties in a clipboard/buffer. The GUI editor's cursor would be loaded with the copied control so that a left click would instantiate a new control at the click location with the same property values as the original. The X,Y position would be changed to the current cursor position. If the user drags a rectangle then the x,Y position as well as the height and width properties could be changed.
The copy function would also need to create a unique name. Perhaps there could be an option to popup a text input box that would allow the user to enter the control name or press enter or OK to accept the auto-generated default.
Hmm, Copying a control does sound like an excellent suggestion.
However GUIControl is an abstract class so I guess I'd have to implement the ICloneable interface for each inherited class separately.. which sounds boring ^_^
I'll look into it.
For GUIs:
-Moving Gui elements with the keyboard when selected
-Selecting multiple Gui elements at once
-Gui alignment tools like in VS could be useful too
This probably won't be too difficult, I might have a look at the source code when I have more time.
Maybe we should build some kind of taskgroups where people focus on one part of the IDE like Gui-Designer, Roomeditor, Dialogeditor. Maybe even with separate sourcecontrol for each group?
+1 for copying GUI controls. It'd be a big time saver when trying to make a GUI with many identically sized elements.
All these other suggestions sound great too, though the main thing I'd like to see would be a better zoom and pan for the room editor like ProgZ said, as long as it wouldn't require a huge overhaul and buttloads of work.
Can't wait to see what the future holds!
For GUIs:
-Moving Gui elements with the keyboard when selected -
done!-Selecting multiple Gui elements at once -
nearly done!-Gui alignment tools like in VS could be useful too -
done!Quote from: cat on Wed 27/10/2010 20:12:55
Maybe we should build some kind of taskgroups where people focus on one part of the IDE like Gui-Designer, Roomeditor, Dialogeditor. Maybe even with separate sourcecontrol for each group?
Actually most of the things like the room editor and gui editor don't need a massive amount of work so a full task force might be overkill.
I've already implemented most of the things requested for guis in about 2 hours of coding time (without the rigorous testing required obviously).
Most of the things people want done to the editor are the fixing of annoyances like being able to flip a group of view frames and things like that.
We can't make many huge changes to the way AGS works because the engine still needs to understand all the conventions so these changes are more about making the editing experience even less painless than it already is.
I'm not sure if this can be done with the *editor* side of things, but I suggested on this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=41732.0) that whenever you add/edit/delete a global variable every room should be changed to an updated status so that they are forced to recompile on next build. It prevents issues if you create or change a variable to the same name as a room variable that's already existing, which causes unexpected errors. Or if a room is using a global variable and you delete it, it will crash the game when you go to run it.
Also a trivial one I suggested a while ago was having the X and Y input boxes and such for the positions for Objects, GUI controls, characters to support simple math. Such as: 150-10. Unless obviously it proves to be harder than it should be to do this. It was just something I figured the editor should support anyway, whether it recalculates it once you input it, or just keeps it stored as 150-10 would do.
The only reason I wanted it to support simple math is if I went to move every GUI element over 10 pixels or whatever, I can just subtract it without doing math. But if Calin is going to support selecting of multiple elements, this may not be needed anymore.
Some great great stuff there (and Calin, you're a machine!)
I haven't looked at the source code yet, so I don't know what's doable, but here are the things I intend to tackle (some are easier than others):
* Context menu for the loops in the view editor, with: copy, cut, paste, flip all, create from folder.
* Docking abilities to the forms (visual studio style) and being able to have more than one form open at a time.
* Enhancing the text editor with: Find all references, find/replace all in all projects/open documents.
* Having writable custom properties (not too optimistic about that one, though)
* Be able to name (x,y) locations in the room editor and use them in-game.
Some good suggestions coming in!
One thing though, if this is a wishlist, could it be possible to have a complete list of approved changes/additions in the first post, Calin?
It would make it easier when the time comes to assign jobs.
EDIT: I wouldn't mind sprucing up the IntelliSense stuff a little, as it seems a little glitchy atm...
Quote from: Calin Leafshade on Wed 27/10/2010 18:13:37However GUIControl is an abstract class so I guess I'd have to implement the ICloneable interface for each inherited class separately.. which sounds boring ^_^
I'll look into it.
As I've noted my knowledge of C# is limited, but from what I've read, and from looking at the implementation of the GUIControl class itself, I don't see why this would be necessary. Abstract classes can have non-abstract methods defined (the GUIControl class is already doing this). So then wouldn't it simply be sufficient to do:
namespace AGS.Types
{
public abstract class GUIControl : ICloneable
{
public object Clone()
{
// NOTE: the GUIControl class has no non-value members, so a shallow copy is fine
return this.MemberwiseClone();
}
// ...the rest of the GUIControl class...
}
}..or am I overlooking something?
thats true actually. A memberwiseclone of the object would be fine.
and then if necessary the object could be cast to any of the derivatives of the GUIControl class.
I think your C# is likely much better than mine :p
We had a similar problem at work.
A memberwise clone would work in most cases, but if one of GUIControl's children has non-value members, then they will not be cloned.
I would write:
public object Clone()
{
Object clone = this.MemberwiseClone();
NonValueClone(clone);
return clone;
}
//Override this method to add specific non value members to the clone
protected virtual void NonValueClone(Object clone)
{}
And then go over all of the children, and if one of them has a non value member, override the method:
class MyGui : GuiControl
{
private MySpecialData _mySpecialData;
override void NonValueClone(object clone)
{
//Calling base, since maybe in the future GuiControl will have non value members of
//its own
base.NonValueClone(clone);
//Unfortunately, I didn't see a way to avoid casting here
MyGui myClone = clone as MyGui;
if (myClone != null)
{
myClone._mySpecialData = _mySpecialData.Clone();
}
}
}
Maybe even NonValueClone should be made abstract, so that every new control that's added will force the developer to think about the non value clone, and possibly avoid future bugs...
Based on what is currently defined as far as GUIControl and its derived types, a MemberwiseClone should be fine since each of them use only value types (bool, int, string, and enums). Seeing as we can't implement any new GUIControl types for run-time as yet there'd be no real point in implementing new types right now that would fail to conform to this.
You make a valid point about non-value types, but for now it's not really a concern.
Copying the gui's + controls is an excellent idea! I would suggest perhaps giving more control on the folders, like being able to drag folders over each other to change their order, or class them alphabetically, etc...more like in windows.
Here are some more suggestions if you think some of them are good ideas:
-Being able to create or class dialogs + inventory items + gui's + characters into folders
-Having a prompt pop-up when deleting a loop inside a view to ask the user if they are sure they want to delete the last loop...right now if you click on the button by accident, you`re screwed...!
-Adding "undo" to certain actions like deleting controls, gui's, etc...I think Undo is missing in AGS, if Im not mistaken (?)
-Adding bookmarks to sprite folders (with keyboard shortcuts for quick access), and bookmarks to the script editor (like in UltraEdit).
-Keyboard shortcuts feature (that can be modified by the user)
Ill think of more when Im actually working in AGS and post here frequently if you dont mind... ;D
copy/paste with a memberwise clone works fine.
I'll implement using the windows clipboard tomorrow instead of a buffer var so that copy/paste can be across editor instances. Done!
Undo is something I've wanted to add for a while but the implementation of that should really be editor wide so it needs a little more planning I think.
EDIT: I really think a new subforum for this might be a good idea. Otherwise these conversations are going to get ridiculous.
Yeah we need a subsection for 3rd party editor development. I suggest a generic title that can eventually be applied also to a forum for engine development also.
Would anyone like to test my editor 'adjustments' thus far?
not ready for public consumption but i'd like some feedback on the changes ive made
Quote from: Calin Leafshade on Fri 29/10/2010 23:35:13
Would anyone like to test my editor 'adjustments' thus far?
not ready for public consumption but i'd like some feedback on the changes ive made
I'd be interested in taking a look. Linux (Mono), Win2K and WinXP (.NET) here to try it on. Also got Mono via WINE too.
One thing my wife reeeallly wanted when working on Puzzle Bots was the ability to get the value of variables when the game pauses at break points.
I'm fairly sure that would require engine adjustment and would be non-trivial to implement.. although it would be *awesome* if that could happen.
you could do that with just the editor, then you need to include a API call (and hide this in the editor view) that transfers the new value and variable name to a dataset every time a variable is changed, and somehow make this data set visible to the user. Ok, that is a lot of work :D
Sounds like you have it well under control.. I'll leave you to do that ;D
I'm not sure I got you there, Wyz. How will you make the engine send a message each time a variable is changed if you don't have the code for the engine?
Can you do that with the API? How?
Well it's a bit of trickery but it boils done to this:
Say you have this code:
some_var = SomeFunction(some_parameter);
SomeRoutine();
some_var++;
Then you would make the editor change it to this:
some_var = SomeFunction(some_parameter);
DebugScope("some_var", some_var);
SomeRoutine();
some_var++;
DebugScope("some_var", some_var);
DebugScope would be implemented with the plugin API to do something useful with the values. Now the trickery: you need to hide the newly added lines to the user. Also, it must only be generated when the user uses the scope.
Ah, I see, yes, that is a lot of work, thank you for agreeing to do this ;D
Hey wait a minute! :D
LA LA LA CAN'T HEAR YOU OVER THE SOUND OF YOUR VIGOROUS CODING
How about someone fixes this little inconvenience (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37668.msg538358#msg538358)? You know you want to! :P
Also, Calin, did you happen add scroll bars to the GUI editor if it was too big to fit the work area?
Yes! This happens to me plenty of times too, I'll look into it...
Do you think this can be added?
Have a feature that saves your editor layout so you can load it later...right now if I resize panels (like the width of the folder display list for the sprites, for example)...it doesnt save the resize when I restart the AGS editor...pretty annoying to have to resize this all the time!
It should already be saving layout changes..I thought..
Quote from: Ryan Timothy on Tue 02/11/2010 15:25:31
How about someone fixes this little inconvenience (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37668.msg538358#msg538358)? You know you want to! :P
Hmmm, is it possible CJ already fixed it?
I tried to reproduce it (with the scenario you described) but it worked fine.
Quote from: tzachs on Tue 02/11/2010 23:38:30
Hmmm, is it possible CJ already fixed it?
I tried to reproduce it (with the scenario you described) but it worked fine.
Nope. I'm using 3.2.0.103 now and I can still flawlessly recreate this issue each time.
Best way to do it is to hover the mouse over something that has the popup thing.
(http://www.bryvis.com/entertainment/other/agsf/box_glitch1.png)
Then, at any time while the popup is visible, move your mouse up to the top tab. Actually, whether you click on the tab or not, the popup thing will show up there. You just have to pass over the drop down box before the popup timer cycles again.
Quote from: tzachs on Tue 02/11/2010 23:38:30
Quote from: Ryan Timothy on Tue 02/11/2010 15:25:31
How about someone fixes this little inconvenience (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=37668.msg538358#msg538358)? You know you want to! :P
Hmmm, is it possible CJ already fixed it?
I tried to reproduce it (with the scenario you described) but it worked fine.
I get to reproduce it so many times, I think I even forgot its a bug anymore.
Quote from: monkey_05_06 on Tue 02/11/2010 17:22:02
It should already be saving layout changes..I thought..
Well so far, doesnt seem like it for me! Everytime I reload AGS, I have to manually resize my panels how I like them (you know, the little arrow that pops up when you are over panel "seams")...
Here are an assortment editor tweaks that would be handy: ;)
GUIS
----
-Not sure if this one's possible, but a way to drag the "Text" field on a button/label more precisely into place (or type in coordinates to position it) rather than relying on TextAlingment being TopMiddle, Middleleft etc. which isn't always accurate.
-Would be useful if you could specify what double clicking a GUI control does. It's easy to accidentally double-click on GUI buttons (which you don't want to run a script), and this auto-creates a new event in the global script for that button/control, which you may then need to manually delete if you didn't intend for it to be created. Personally, I'd find it more intuitive if double-clicking a GUI control opened up its Normal Image in the Sprite Manager.
ROOMEDIT
---------
-If you have "Use low-resolution co-ordinates in script" set to True in the General Settings>Backwards Compatibility section of the editor, AGS should always display 320x200/320x240 coordinates next to "Mouse Position:" when you move your pointer across the background to see the current mouse x/y pos. This would be useful when hi-res games (made with AGS 2.x) are converted over to AGS 3.x but the scripts still maintain their old 320x200/320x240 positioning coordinates for backwards compatibility.
-Currently you can only right-click to bring up the "Copy coordinates to clipboard" menu when the "Show this room's: Nothing" panel is displayed. It's a tad inconvenient having to change back to that specific panel just to copy the room coordinates to the clipboard. Would be nice to have this ability when objects/hotspots/regions etc. panels are active too. (On the Objects panel, a new entry could be placed under the "New object here" item on the menu).
-When working on a walkable or walkbehind area, the Eraser tool notification message keeps popping up in the text bubble every time you click it. It gets quite annoying. I guess this notification message should only appear the first time you erase something. Otherwise, just have the notification message appear in a stationary position below the background image (in the grey area of the editor) so that it can't interfere or visually block the area that you're drawing.
-When moving room objects around, providing an option to temporarily hide all other objects (except the one that's currently selected). If you have a large or full-screen-sized object, it obscures everything behind it, making it quite cumbersome to click on or move any smaller objects in the room.
SPRITE MANAGER
----------------
-Bug fix: if you right-click in the sprite manager to find a specific sprite by typing the sprite number, but you have 2 sprite folders, or a sub-folder, with exactly the same name (not case-sensitive) the editor will jump to, and open, the first sprite folder found with that name, even if that's not the folder where the sprite that you searched for resides.
Oh right... This is the thread that the requests should be in then. :P I'm deleting my post in the other thread and putting it here.
As it stands right now, AGS doesn't have an export/import feature for dialogs. It would be a very nice feature. Especially if AJA modified his dialog designer to match the output file you guys end up making for the export of dialogs from within AGS.
I think it would be a great feature.
This whole thing would be easier if everyone collaborated on ONE editor. Go here: adventurestockpile.com and then go here and create a project:
http://adventurestockpile.com/index.php?option=com_projectforkmpl=component&Itemid=58
Everything anyone would need to work on an open source project.
Actually, here you go. I have already created a project base for you. All you have to do is upload and edit the code.
Yeah I was going along that direction myself. I think we really could use a collective shot in the arm like this. :)
Someone's got to do it right?!
Im not sure if this has already been requested, but it would be great t0 be able to "Delete N frames", where N is the number of frames you want to delete on a selected loop (so you enter, say 2, in the text field, press "delete N frames" button, and every 2nd frame gets deleted from that loop).
I think that can be useful when trimming down long loops.
What would make me very happy is being able to reorder the file/folder structure for sprites, dialogs, characters and views. For the rooms you can already sort by room number, but it would be great to have alphabetical sort or drag-n-drop for all the above tabs. That would save me a lot of headaches and searching around :)
Other than that I'm aching for an update to the dialog system. I suppose most of that is engine stuff, but having a dialog editor somewhat more similar to this (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=39568.0) would be tremendous.
The dialog system is certainly on my todo list.
I have coded a new lexer for the dialog script editor so that the script highlights in a way that makes sense for scripts but I'd certainly like to improve upon that if i can figure out a way to make the workflow a little more simple.
A dialog search/replace feature would go down well too, I think.
Cheers,
Sparky.
already implemented
Brilliant! ;)
Very cool. I wouldn't mind kicking around a few ideas sometime, I'm trying to build a Bioware style dialog module right now and I'd love to see how far we can take it with the engine code, even if just for structure and stuff. There has to be a better way for keeping track of dialog trees..
Oh and one more thing: a thicker automatic font outline. On light backgrounds that 1 pixel outline is barely enough to make a custom font readable. Being able to adjust the thickness of it would be super.
Not sure if this has been requested but being able to add bookmarks in the script editor would be really great (like in ultra-edit)
http://www.ultraedit.com/products/ultraedit/ultraedit_feature_map/technical_writer.html
(http://www.ultraedit.com/products/ultraedit/ultraedit_feature_map/technical_writer.html)
I noticed that edited sprites flip back to 640x480.
It would be nice to have a check box to keep it at 320.
I was thinking today and I thought of a great idea! maybe for rooms in the drop down menu there should be "Layers". With this you are able to spit the room in 3 or 2 layers, when changing to layer 2 the normal layer will become darker shade until you switch back.
Also the point of this for me right now is that I may want to make a flying game were you can equip a jet pack that let's you fly of the ground.
To do this the easy way.
- 1. Just go to layer 2 and a walking area for the flying.
function region1_WalksOnto()
{
if(cego.View == 16){
cego.CHangeView(17);
room.SetLayer(2, eNoeffect);
}
}
- 2.This is the code for when the player walks on region 2 in layer2
function region2_WalksOnto()
{
if(cego.View == 17){
cego.CHangeView(16);
room.SetLayer(1, eNoeffect);
}
}
That's really all I can think of for my needs but I am pretty sure other people will find other ways to use it.
I was wondering if anyone else here thinks this could be a good idea:
When we create custom properties, if you want to access them, you need to click on the "..." button at the bottom then a window pops up showing you the custom properties. If you have to manage lots of objects with properties, its kinda annoying having to click there, do your stuff, close it, reselect a new object, reclick the "..." button, etc...
How about if the AGS editor detects what's in the custom properies list and adds them into the column...that way, the only time you need to click on the "..." button is when you want to modify a property's definition or add a new one/delete one.
BEFORE:
(http://s1.postimage.org/5byba50ym/this.gif)
AFTER:
(http://s1.postimage.org/5byrtihwe/THIS2.png)
I've been thinking about that for a long time, and it might be too soon, too big.
But I think AGS should start embedding some sort of versioning system, in order to open the production pipeline (writers working while artists work while scripters work).
I don't know how to put that in action. But at the moment the monolithic agf file is too central. There have been great improvements with the room import/character import/etc.
Maybe one could start with externalizing the strings (a bit the same mechanism as translation files, except it would also be for the original strings). Or the dialogs. I don't know. Break it into bits. And keep tracks of the versions. No need to do something fancy with conflicts resolution/merging.
Ouxxey, it sounds like what you're describing there is a source-control program, in which case I would actually disagree that AGS needs this built-in. AGS already has support for interoperation with source control programs. For example, you say the "monolithic agf file is too central", but why? The AGF file is placed under source-control if a supported program is detected, so you would then be able to handle versioning a lot simpler, which seems to be what you're trying to describe.
It would be great if the Edit Custom Properties window could be resizeable...right now you cant modify its size so you are forced to scroll up or down when the window is too small for all the items.
Why do you care, traitor?
http://forum.dead-code.org/index.php?topic=3734.0 :P
Quote from: Calin Elephantsittingonface on Tue 22/02/2011 14:23:06
Why do you care, traitor?
http://forum.dead-code.org/index.php?topic=3734.0 :P
"on: July 26, 2009, 02:33:45 AM" - or is this just a poor attempt at a joke?
Quote from: Sslaxx on Tue 22/02/2011 14:35:40
or is this just a poor attempt at a joke?
Alright, simmer down. I was only kidding.
I, myself, have a post or two on that forum asking about WME.
haha! Wow I forgot about that, 2 years ago when I was just starting out...man Im glad I stuck with AGS!
Well atleast we're 2:
http://forum.dead-code.org/index.php?topic=4353.0 (http://forum.dead-code.org/index.php?topic=4353.0) ;)
Calin: Thank you for asking, miss. :=
Awe... Such a polite young man! ^_~
I don't know if this has been posted before or if there is actually a solution to this problem.
Anyway, here's my wish:
- There should be a way to quickly create new characters in the editor or at runtime.
I need a lot of characters (most of them are dummies for spells or particles) in my game and the only way i saw to get that done, was creating a new character, exporting it and mindlessly importing it a hundred times in a row.
With these dummies, i use a "select first free dummy"-script when i need a new character ingame for the visuals of a spell or something.
There must be a faster way.
Greetings, D
Quote from: deee on Sat 26/02/2011 12:45:20
I don't know if this has been posted before or if there is actually a solution to this problem.
Anyway, here's my wish:
- There should be a way to quickly create new characters in the editor or at runtime.
I need a lot of characters (most of them are dummies for spells or particles) in my game and the only way i saw to get that done, was creating a new character, exporting it and mindlessly importing it a hundred times in a row.
With these dummies, i use a "select first free dummy"-script when i need a new character ingame for the visuals of a spell or something.
There must be a faster way.
Greetings, D
There is... I also use dummies but I just run a piece of code on game_start to assign their properties. Like view, position, room ecc.
Dynamic object creation would be lovely. AGS *can* create managed objects at runtime so I see no reason why the code can't be tweaked to allow characters to be created.. Of course this is all *engine* stuff not *editor* stuff.
Quote from: Dualnames on Sat 26/02/2011 14:40:23
There is... I also use dummies but I just run a piece of code on game_start to assign their properties. Like view, position, room ecc.
That is just what i do. I have a procedure for resetting a character before it is used for a new purpose and a procedure to select a character that is currently not in use.
The problem is just getting a lot of characters into the editor, for there is just the possibility to add/import 1(!) new character at a time. We need a button in the editor, allowing the import x instances of the exported character y.
Quote from: deee on Sat 26/02/2011 17:18:38
The problem is just getting a lot of characters into the editor, for there is just the possibility to add/import 1(!) new character at a time. We need a button in the editor, allowing the import x instances of the exported character y.
Yeah, I second that request, it would save me some time too.
Quote from: deee on Sat 26/02/2011 17:18:38
Quote from: Dualnames on Sat 26/02/2011 14:40:23
There is... I also use dummies but I just run a piece of code on game_start to assign their properties. Like view, position, room ecc.
That is just what i do. I have a procedure for resetting a character before it is used for a new purpose and a procedure to select a character that is currently not in use.
The problem is just getting a lot of characters into the editor, for there is just the possibility to add/import 1(!) new character at a time. We need a button in the editor, allowing the import x instances of the exported character y.
Oh, nvm me, I misunderstood. I second that then. I have to say today I was playing with the new editor. As much as I like those + - thingies for collapsing functions/ifs/anything bracketed/sections of the code in general, they somehow removed the most awesome thing. Which is to move over the mouse to the right and select a whole line by left clicking. I mean, yeah, collapsing is cool, but seriously? I lived without collapsing for the past 4 years and I coped quite easily. I know you can still select the line, but it's too god-damn pixel perfect. Imagine people using a mouse-pad. Just move over that + to the left would be awesome.
Quote from: Dualnames on Sat 26/02/2011 19:46:20
I know you can still select the line, but it's too god-damn pixel perfect.
I just click the line, hit End (or click off to the right side to begin with, to start the parser at the end of the line), hold shift, then press Home.
It's something that just became natural for me and unbelievably efficient.
I put the cursor at the start of the line, then press shift & arrow down. Does the same thing but copies the next line code at the end, too. That way one can easily move around lines without having to clear space first or remove it after cutting the line.
(http://www.bryvis.com/entertainment/other/agsf/ags_recent_list.png)
I have AGS pinned to my taskbar in Win7. I would love that when I right click on it, the recent list is actually populated with the correct name of the game instead of Game.agf. Is there a reason AGS is creating a Game.agf file instead of: Journy Of Iesir.agf?
I tested it by renaming a blank game's file and it didn't appear to run into any issues with loading, compiling or running the game.
Edit: Never mind about that last line. It appears that AGS will create a Game.agf file if the other is renamed. Obviously this would have to be changed if there aren't any issues with having a game file not named Game.agf.
I don't know how difficult it would be but I would like to see a seek bar for audio and have the milseconds displayed so you can find exact milseconds in a specific ogg or mp3
Ryan, (I thought I already replied to this, but anyway) I think that the name of the "Game.agf" file is somewhat based on what is now an antiquated way of thinking about the naming convention for the files (like the old "ac2game.ags" files).
Part of the reason ac2game.ags files were so named, AFAIK, is simply to ensure that the filename would always be less than 8 characters (not counting the file extension), in compliance with the DOS portion of the engine (particularly when using RunAGSGame).
However, seeing as the DOS engine has been dropped entirely, I would venture to say that there's no longer a "technical" reason for these files to be named like this. I mean, the Game.agf files can't even be used with RunAGSGame anyway. I'd actually like to take a look and see what can be done about the naming of the AGF file.
Yeah I figured it was the 8 character limitations of dos that made it Game.agf in the first place, and that it's within its own folder making it impossible to confuse one project from another.
The only issues I can see now are perhaps the accented characters and such. I can't remember the technical term for them.
It's definitely not a huge hassle. I do open multiple projects up at once all the time and I mostly figured it was a quick fix with the editor.
Also, since I'm posting in here again. You know what feature I really like with XNA. I like the ability to press the back button on your mouse to return to where you previously were in a script. Whether you moved away from your current location by jumping to a function or simply scrolled away from where you were previously editing the script, it will return you to where you were.
It's definitely a very speedy feature, I would love to see that with AGS.
Well, I'll have to consult with the C# gurus to see if there's any hidden complications with the changes I've made, but I've actually compiled a build of the editor that uses the project's folder name as the name of the AGF file. AFAIK you can't have accented characters in an AGS folder name anyway, can you?
In any case, there's a couple more things I need to check on (like ensuring that the AGF name is persisted when you load and then recompile the game)..but so far I don't see any reason why this shouldn't be a viable request.
I'm back so I may as well make my usual wishes for next version:
-Support for pointers to custom struct.
-Thread API wrappers.
-Animated CJ on the sidebar spreading useful tips!
Thanks in advance :=
Something that occured to me yesterday is that it would be cool if the shakescreenbackground command could be expanded on a little bit. Right now it only goes up and down, and it doesn't exactly interpolate between those two (aka the movement is not smooth at all if you set the speed very low). I've no idea how it does what it does exactly or what the limitations are, but taking a cue from the Tween module, it would be nice if we could smooth out the movement, and also shake left and right, perhaps even introduce a random into it. Putting those ingredients together you could create a pretty nice shakycam effect.
It would be nice to have a cooperative editor so that two people can use the editor at one time.
How do the teams of game makers on AGS games handle using the editor. Let's say one person is scripting and another working on a character.
Can't this already be done if you share a folder somewhere and both your editor's file paths go to the same place?
@hedgefield
Very good idea...I would also love to have a smoother shake screen + randomness.
I noticed there is a game.inventory_greys_out variable, but not one for ALL GUI controls. So during the game you cannot toggle the setting where it greys out inactive controls for anything other than the default inventory. Not a huge deal but it's a bit of an annoyance in some cases.
hedgefield, use the SetGameOption (http://americangirlscouts.org/agswiki/Game_/_Global_functions#SetGameOption) function:
SetGameOption(OPT_WHENGUIDISABLED, 2); // controls unchanged
I would find it very usefull to move objects and characters (and even hotspots, walkable areas, regions..) pixelwise with the arrow cursors,
for easier adjustment in the right spot.
The second thing im praying to heaven every day, ;) is the way to low limit for walkable areas and regions.
It would highly recommend to raise the limit to at least 50 like the hotspots,
but i guess this doesnt belong to the editor and can only be done by CJ in the core Program, which wont happen in the near Future. :-\
I think someone should rewrite my crappy walkcycle generator in .NET and include it in AGS.
Quote from: SSH on Tue 26/04/2011 07:22:47
I think someone should rewrite my crappy walkcycle generator in .NET and include it in AGS.
Not promising anything here, but it might help if you'll release the source code (same goes for SteveMcrea's version).
Quote from: Rocco on Mon 25/04/2011 11:01:47
I would find it very usefull to move objects and characters (and even hotspots, walkable areas, regions..) pixelwise with the arrow cursors,
for easier adjustment in the right spot.
I remember craving it myself, and it seems simple enough to do, I'll look into it.
Edit: Done in 3.2.2 for objects, characters and edges. I'm not sure how to approach the rest of the areas since it's using native methods to draw onto the mask, so I didn't touch it.
Quote from: hedgefield on Tue 05/04/2011 12:43:22
Something that occured to me yesterday is that it would be cool if the shakescreenbackground command could be expanded on a little bit. Right now it only goes up and down, and it doesn't exactly interpolate between those two (aka the movement is not smooth at all if you set the speed very low). I've no idea how it does what it does exactly or what the limitations are, but taking a cue from the Tween module, it would be nice if we could smooth out the movement, and also shake left and right, perhaps even introduce a random into it. Putting those ingredients together you could create a pretty nice shakycam effect.
This could be scripted in module form pretty easily, if rooms were designed with a bit of extra space around the edges. If I remember correctly, shakescreenbackground affects the entire screen including GUIs, so I don't think it's very well suited to a shakycam effect.
Quote from: tzachs on Tue 26/04/2011 23:18:16
Quote from: SSH on Tue 26/04/2011 07:22:47
I think someone should rewrite my crappy walkcycle generator in .NET and include it in AGS.
Not promising anything here, but it might help if you'll release the source code (same goes for SteveMcrea's version).
I'll leave Steve to release his own stuff, but here's the latest code I've got knocking around (including some code from Steve):
As suggested, I'm releasing the source code (http://ssh.me.uk/dev/walkcyclist.zip) for this, so that anyone can take it and make something better. Please give Steve McRea and myself some acknowledgment if you re-use any parts!
I haven't looked at this for nigh on 3 years, so apologies if its broken or rubbish!
A few more Room transitions.
It would be nice to have a random field for view frame delays...as in, instead of putting a fixed number, the user can type in "1-3" or "33-55" and AGS will choose randomly a delay number from what is typed in (we can do this manually but it would be cool to have it in the editor already).
Also, I is it possible to have a checkbox for buttons that says "Always resize to new Sprite"...that way, if you have a button that is 30x30, and you change it's graphic to a 45x45 sprite, the values for the H+W will update to 45x45...right now you have to manually change those values after changing the sprite.
For buttons if ClipImage is false, doesn't it already resize if the graphic is changed, at least changed to a larger graphic? It..used to..I thought.
Yes, it does resize automatically.
Well when you set the sprite number the 1st time it does resize automatically, the 2nd + times, in my case (just retested), it doesnt resize automatically if the next sprite is smaller than the 1st :(
That's something that could probably be fixed in the editor, but for now if you're using a smaller sprite you could set it to sprite 0 first.
My suggestion: auto-scale characters when they are positioned in scaled walkableares in room editor
Quote from: Joe on Mon 02/05/2011 11:46:31
My suggestion: auto-scale characters when they are positioned in scaled walkableares in room editor
I've looked into that some time ago.
It seems that we need to wait for open sourcing the native, since it requires changing the API to allow scaling to non-whole numbers.
What the editor really needs is a way to test a room without having to go through every room.
For a long game it is a real pain testing.
"Testing a room" is not an editor process at all, it's a run-time process. Anything you do while your game is running (during run-time) is part of the engine, not the editor. The editor only deals with design-time and compile-time.
Also, I just answered this in the thread you created. I didn't look at the timestamps, and I'm on my phone so I won't right now, but this essentially constitutes posting the same thing twice. Either post by itself would have been sufficient, there was no need to do both without a response.
Okay..I looked and you posted here six minutes after creating the thread. Why would you assume that just because an answer wasn't provided within six minutes that the feature must not exist at all?
I made a quick assumption and turned out correct. I searched everywhere and didn't find a function for running just one room.
I thought it would be a good thing for the editor to be able to do.
What do you mean you turned out correct? What you want to do is going to require work on your part, period.
I don't see why you think the editor having the capability to compile a single room, but compile it in such a way that it is based entirely on the game logic of the rest of the game is something that "would be a good thing". That's absurd.
If you need to simulate having played through the game in the script, then script it, but expecting AGS to do that for you is ridiculous.
Oh, and unless you're talking about compiling the room to a separate executable, this would still be an engine request more than an editor request.
All I was talking about is just testing one room to save the time of having to go through every room.
The debugger already lets you jump to any room, so you don't have to go through all of them, if that's all you want to do. The problem is that usually there's some setup that needs to be done so the game is in the right state, and that's not something the editor can telepathically deduce, it's embedded in the game logic.
Yes, and by "test one room" you mean play. The editor is for designing and compiling only. Not playing.
I know what you meant, and I'm saying that there's not really a lot that can be done to simplify the process. The Debug function allows you to teleport to any room by typing it in so you don't have to manually script it. Anything beyond that (such as simulating a certain game script state) would have to be manually script anyway. So this doesn't even make sense as an engine request either, because the Debug function already supports this (in so far as it is possible).
Edit: Snarky posted before me, and maybe he worded it a bit better than I have. To elaborate on what he said, your game logic is entirely customized, and controls the game script state. The script state is entirely dependent on the global and room variables that have been set as the user plays through the game. If you want to simulate the script state of a given point in the game, then you're going to have to script that manually because it is based entirely on custom code.
Quote from: monkey_05_06 on Fri 06/05/2011 23:43:41
Yes, and by "test one room" you mean play. The editor is for designing and compiling only. Not playing.
I know what you meant, and I'm saying that there's not really a lot that can be done to simplify the process.
Well, not necessarily.
Adding a button to the room editor "Test Room" can be a useful shortcut to the "teleport" debug function, which makes this a combined engine&editor feature.
I'm too lazy to press a button on every iteration! Wise up and just put a change room debug statement in Room0 like everyone else.
Being even more clever why not add a test function to each room that would execute every time the player entered the room. If a global variable called "Test" is set true then if would continue to execute and exit if "Test" is false. What would it execute? "Whatever is necessary" to test the room such as giving inventory articles or setting other variable states.
Why doesn't it make sense to make this a feature of the editor? As everyone explained above the essential part is the "Whatever is necessary to test the room" bit that can only be determined by the programmer and is likely to change quite often and on programmer whim.
IMHO what is being proposed is in the same class of feature as the "Make my game" button.
tzachs, a special request for you: Would it be possible to make the search result/usages window resizeable like the projecttree/properites window on the right side? (btw, thanks a lot for these two features!)
@RickJ: Let me ask you this:
* Wouldn't you say it's more intuitive for newcomers to have this button in the room editor, than having to use the debug function?
* Isn't it more convenient? If the button was there, wouldn't you use it?
I know I would use it on a daily basis.
And while it's true that some rooms will not work out of the box without some work on your part, a lot of times it would be perfectly suitable. If I just want to test walkable areas and scaling issues, then this for me is a productivity enhancer, and really not at all comparable to "Make my game" button.
Also, unlike the "Make my game" button, this feature is actually doable (while obviously not the most important feature on the list)...
@cat: Thanks, and it's possible. The reason I didn't do it in the first place was because I'm planning on adding docking capabilities to all windows which will also make them resizable. If I'll see that it's too complicated for me, then I'll do this as plan B.
tzachs, you actually make a reasonable argument for the "Test Room" button, but I think my points from before remain valid. I think that a "Test Room" feature would not be absurd as a debug-only feature (no standalone EXE). It essentially would compile the entire game, minus all other rooms except this one, and would automatically set the player to start in this room.
All sprites, global variables, scripts, dialogs, etc. would be available just like normal, you just wouldn't be able to use ChangeRoom for example.
I'd actually like to propose that in addition to this Test Room feature that rooms have a "roomX_debug.asc" or "roomX_test.asc" (or something along the same lines) that would only be compiled in the event of using the Test Room. It would have available any of the linked room functions, standard functions like on_event, and custom functions. Any functions in both the debug and normal room scripts would be merged with the debug script code on top.
Given this setup I'd say this could be a very useful feature. However, it's pretty drastically different from the situation that was previously described (at least insofar as I understood it).
@tzachs: If I understand correctly, the button we are talking about here would compile the game and transport the player to some specified room. How would AGS know in which room and at which coordinates to place the character, if he should be visible or not, and what inventory items he should have? It would be necessary to pop-up a dialog box to allow the user to enter the above information. In the very least it would be necessary to enter the room number to be tested. So - honestly - no, I doubt I would find much utility in such a button.
@monkey: I don't see any advantage of compiling only one room. Currently only the rooms that have changed are compiled and so if one is working on one room at a time then AGS currently produces the same result. On the other if changes are made in multiple rooms isn't it better to compile everything that has changed; the programmer would get immediate feedback would likely know where to fix any errors that occurred?
=============
I think time would be better spent improving the GUI import/export mechanism to include code/module and other resources and so that it could easily be "unimported" when no longer needed. This would make it a little easier to create and use reusable debugers.
Really, the most important thing is to design code in manner that makes it easily testable. There is no magic button that will do it for you.
I think that for the purposes of testing things like scaling, walkable areas, and room events that it would be reasonable to support the compilation of a single room for debugging and testing purposes, with no availability to go to other rooms. This would not simulate the actual in-game values of global variables, player inventory, etc., it would just let you see that room in action. The reason I suggested an alternate and additional script would be so that you could more easily simulate that when testing the room.
The reason for my suggestions in addition to the layout that tzachs provided is that it would avoid the need for the pop-up dialog that you're talking about. Compiling only this room would avoid a lot of the issues you perceive in this suggestion. I'm not saying that when building the actual game EXE that other rooms shouldn't be compiled, I'm talking only about testing a single room.
Rick, I think this suggestion has the most potential benefit for those that have extremely long games. This isn't so much about testing the in-game code (as far as I'm concerned) as it is more about testing the design and layout of the things within the room itself. That would require a fair bit less "magic" than what you're thinking of (which is closer to the original idea, which tzachs' is rather different from).
As far as GUI import/export including the GUI code, I think that would be great, and should probably be given a fairly high priority. I also would like to see the option of having standard event handlers appear in other scripts than just the global script. That would make it possible for GUIs to be able to import their own code much easier.
@monkey: My hangup was having a button that doesn't do anything useful unless custom script is attached. However now that I think about it I'm intrigued.
What if the TestRoom button compiled and executed as is done now except that the PC starts in the current room and places the PC on a walkable area. This part is uninteresting, unnecessary, and not worth much consideration from my point of view.
However, suppose that in addition and event handler called something like RoomTest(...) was also executed before any of the other event handlers? There could also be an #iftest macro as well. Now this would be interesting because people could leave test code in their source permanently. If debug mode is not set in game settings then the test code would be omitted from the exe and would have no affect on release versions.
Yes, I would find use for something like this and it would not be complicated to implement (probably a bit of work though since both editor and runtime would need to be changed. I'm persuaded...
@tzachs: I figured you would most probably be the one deciding if this is doable:
Do you think we can make the "edit custom properties" window resizable? Right now (for me anyways, windows 7 x64), it isnt resizable...since I currently have many custom properties, its a biatch having to scroll through a very small window!
ps: Do you think there will be future possibilities to have a whole menu section for "saving/loading user layouts"...so you can save a layout as a .agsUI file (or something) + load it in other copies of AGS on different computers (it would save window sizes, locations, font, template colors, preferences, etc).
@monkey_05_06 & RickJ: I'm glad we've come to an agreement (well, sort of)!
I agree that the "TestRoom" event handler would make it even more useful.
I'm also very much for the export GUI as a whole with its code and for separating event handlers linking to other files (I wonder if the linking is done in the editor source code or in the native though).
@General_Knox: Yes, both of these are doable. As I told cat just a few posts above, I plan to integrate a docking windows library, which will make all windows being able to switch between docking to a certain area of the screen (which is resizable), or a floating window (which is also resizable). Plus, this library also comes with support for loading/saving the layout, so it will at least help incorporating some of your suggestions.
@tzachs: Nice! Do you think that it's also possible to drag tabs to change their order so a tab that's last can be grabbed, and dropped into the first position?
I think that the library I was talking about have this functionality in it.
If not, then it is still probably possible, but might be complicated since I'm not sure if the default dot net tab control supports this out of the box.
Hi
I think the idea of room test/debug is rather a must have.. Like if you make a new lable, gui etc then you should be able to test it without having to play through lots of other rooms first or restarting player in that room... Definitely a must..
Possibly an updated cursor when adding/taking away walkable/region/hotspot as it's sometimes almost impossible to see cursor (crosshair) without zooming right in..
:=
barefoot
I'm not sure if this is both an editor feature and engine feature, or solely editor.
How possible would it be to have the function pointer for something like "Any click on character" to allow to pass variables? So you can have it point to: whatever(1, 2, 3) instead of just: whatever
I think it would be very handy. Now get to work on it! :P
Edit: I realize that a small request like this requires tons of work. Or it may be possible to already use the script error checking that AGS already has built in. Otherwise you'd have to manually check if it's a string, integer, enum, global variable, etc, etc. Also checking if the variables in the function are asking for the same type, and if there isn't too many variables being sent or too little.
Erm, what are these variables that you want it to pass?
Why not just use globals instead?
I guess he means function pointers like c has them. This can be useful for callback functions, lets you do stuff like this:
int CompareInt(int a, int b) { return (a-b); }
int array[];
// ...
Sort(array, CompareInt);
But again, you could just make a function SortInt.
I've wanted to have function pointers forever as they can be very useful especially in the context of modules. Currently there is no mechanism for a pre-written module to call user written functions. Pointer to function would allow user defined functions to be assigned module events or to over-ride generic or virtual module functions. It would also make jump tables, case functions etc possible.
Currently AGS mechanisms do not provide for indirection or dynamic assignments of function calls making the above very difficult or impossible.
My question was not "durr, what is be function pointer?", but rather what would the parameters passed to the "Any click on character" callback be? The engine calls the callback, so the parameters have to be defined by the engine. You can't just add random parameters.
I'd certainly find a use for general function pointers.
My apologies. I thought it would have been understood quite well.
I didn't actually mean for it to be on "Any click on character" only, it was only used as an example. I meant for it to work for all buttons, objects, characters, etc.
One quick example I can think of, you have a 10 GUI buttons and you wanted them all to point to a single function with variables (I honestly don't know the correct terminology for this) you'd have to manually script them yourself.
function bButton4(GUIControl *control, MouseButton button)
{
Whatever(1);
}
function bButton10(GUIControl *control, MouseButton button)
{
Whatever(2);
}
function bButton17(GUIControl *control, MouseButton button)
{
Whatever(3);
}
Instead you could just simply point the button OnClick to: Whatever(x)
x being whatever you want. Whether it's a constant int, or a variable that changes within the game, like (a completely random example) Player.Y
It basically saves you from having to create possibly dozens of identical function which just points you to the same function anyway. It's not an incredibly important addition. You can argue it if you want, it's only a suggestion, what do I care. :P
You could simply link all the functions to the same click event handler (copy+paste or type in the name manually), and then do this:
function btnWhatever_OnClick(GUIControl *control, MouseButton button)
{
Whatever(((((control.ID / 10) - 5) * 12) / 32) + 8);
}
You can point it to the moon and back, it still isn't as efficient as just placing: Whatever("Hello", 10, 84, player.x, player.y, eBlock) right inside the editor pane instead of actually creating a master function that points to another function. When instead you could manually change each item right inside the editor pane for that object, character, button, etc and in most circumstances they wouldn't be identical.
But even with your solution, you still need:
if (control.ID == 5) Whatever(16);
else if (control.ID == 12) Whatever(11);
else if (control.ID == 1) Whatever(27);
You'd still have to look up which ID that is revering to afterwards if you wanted to change something in the script. Of course you could just simply comment them, or you could just create multiple hundred functions if needed as I showed above to have it ultimately organized but very redundant in function count.
Or instead of referencing the ID you could treat the pointers as pointers and reference them as pointers:
if (control == btnWhatever1) Whatever(1);
else if (control == btnWhatever2) Whatever(2);
else if (control == btnWhatever3) Whatever(3);
Which makes the code significantly more readable.
What I'm trying to understand, which is also what Steve was asking about, is what additional data is it that you're realistically wanting to pass through to these handlers?
Short of doing something with a variable argument list, I don't see how you would expect to be able to pass random data like that into the event handler. Seeing as AGS doesn't allow direct memory modification (like C++), and doesn't have a foreach keyword (like C#), and doesn't have a way of generically checking the size of an array (dynamic or otherwise) then I don't see how you would be able to fetch the data back. So not only would the engine have to be modified to include "..." as the final parameter of every event callback, we'd also need further modification to actually be able to make use of that data, and all of it for what?
That's what we're getting at, is what is it that you're wanting to pass through to these event handlers??
I'm still believing that you're confusing what I'm saying with something much more grande. You're making it sound like you could pass a gigantic list of random parameters into a fake function or something. But I'm speaking of passing variables into a function that has parameters that are already defined with an already existing function created within the global script or imported to the header script of a module.
Global script:
function Whatever(int A, int B) { }
Then while typing in the editor pane for the OnClick function, as you type: Whatever AGS pops up the: function Whatever(int A, int B)
and you can pass whatever variable or value into those fields. Having the same error checking as AGS has with scripting, it warns you if the function has too little or too many parameters or the data types are incorrect as you compile the game.
I don't have a very good example off hand at the moment for where this is ultimately handy, other than just avoiding function after function. And depending on how AGS stores the data in how it points to these functions that are entered into the event handler, that's where it's a fine line between difficult to add or nearly impossible. Sounds like fun doesn't it? :P
While I understand the request I, too, don't see the benefit, especially if weighed against rewriting that part of the editor.
And I, too, am having a hard time of thinking about an example where this would be useful.
All I can think of is for instance a keypad consisting of 11 or 12 GUI buttons, but if you create the buttons so that the ID reflects the label, you won't need 10 else ifs. One function is going to handle all the button clicks, and all it needs is the control pointer.
And what parameter would you like to include in a character's interact function or the like? Even if you came up with a situation where each of those needed some arbitrary parameter(s), why not put them in Custom properties?
Or if you wanted to really cut down the number of functions and coded your game so that a single function is going to handle all NPC interaction, again, what would you put in there? You can find out the character and mouse.Mode etc. perfectly fine using existing commands, what else do you need?
Basically, this discussion is entirely moot until you provide us with an actual situation where this would come in handy, IMO.
@Steve: Didn't intend to imply anything at all about your comments. I just wanted to express my interest in having function pointers. I agree that function pointers could be put to good use.
@Ryan Timothy: What you describe would be very useful in creating modules that call user functions that are not known or knowable when the module is created. Consider a module that generates or manages events or states. When an event occurs or a new state becomes active then the module is to perform some action (presumably by calling one or more functions). The problem is that these functions are unknown when the module is written and would be different for every use of the module. Module pointers would allow the user to tell the module which functions to execute when specific module events occur and which parameters arfe to be passed.
Personally I would like to have function pointers to recreate the Thread module I wrote a couple of years ago and lost to a HD crash. This module allows one to create and execute concurrent threads in an AGS script. To do this a byte code interpreter is required to execute AGS builtin functions so as to manage/emulate script blocking. Function pointers would make the byte code interpreter much cleaner and efficient.
@Monkey: A better example of what Ryan Timothy is talking about would be something like the following. He defines some arbitrary function with some arbitrary parameters. The function knows what what the parameters and what they are used for but not the actual variable references.
He wants to use a module that manages some kind of events. He defines an event named "SomeEvent", assigns a callback function, and specifies the conditions under which the event is triggered.
// Global or Room Script
// Some function for my current game
function SomeAction(int x, int x) {
// Do something
cEgo.Walk(x,y);
cNonPlayer.Walk(x+10. y-10);
}
// Use a cool event module written by monkey years before
CoolEvent SomeModule;
SomeModule.Event("SomeEvent", SomeAction(160, 100), ...);
Quote from: Ryan Timothy on Thu 14/07/2011 01:46:25Global script:
function Whatever(int A, int B) { }
Then while typing in the editor pane for the OnClick function, as you type: Whatever AGS pops up the: function Whatever(int A, int B)
and you can pass whatever variable or value into those fields.
In addition to what Khris said, which I absolutely agree with, part of the problem is where you say "
you can pass whatever variable...". Unless you're just explicitly calling the function for some
other reason than what the event handler itself has been created for,
you don't pass
anything into the event handler, so how would
you specify what those values were? Any values being passed in would have to be either static or linked directly to a global variable, and in the latter case the entire feature has just negated its own purpose.
So in the case of static values, I don't see any difference between setting up in the editor, Button 1 Properties, OnClick Handler Parameter 1: 10, versus:
function btnWhatever(GUIControl *control, MouseButton button)
{
int param;
if (control == btnWhatever1) param = 10;
}So no matter how you look at it in this case, I don't see how you're accomplishing anything you couldn't already do. One extra function call that establishes the values as opposed to entirely rewriting the way AGS handles event handlers...doesn't seem worth the cost to effect the change to me.
Edit: Rick posted before me.
Rick, don't get me wrong, I understand why function pointers are useful, and particularly if we could utilize them in a fashion similar to C#'s delegates and events that that would be great for module writers. However, that's not what Ryan's asking about. Ryan is specifically referring to the linkage of the built-in events.
@monkey: "Ryan is specifically referring to the linkage of the built-in events." Perhaps I'm reading more into his comments that I should. I was thinking he was just using built-in events to illustrate his idea, so I thought I'd help the discussion along. If we are only talking about built-in events I agree with you.
Btw, is it possible for built-in event handlers to reside inside modules?
I understand your argument and I also agree with it not being overly useful considering the time it would take to get it to work. I just had always felt it was something that AGS was lacking; especially when I first started using it. It was just a suggestion no more than that.
In the beginning of my AGS 'learnings', I had twenty-something GUI buttons that all did their own thing. But using the same function to process the action, just like Khris' example of the keypad. I tried to pass the OnEvent to the single global function with the required parameters to find out AGS doesn't support the passing of variables/static values.
Then I had to change all my existing buttons to be in numerical order, since I hadn't created the GUI fully knowing how many buttons I was going to need. Either that or create the 20 default OnClick functions for the buttons having them point to the single function, or just pointing the OnClick directly to the single function with Else If's checking which button it is.
Like I said, it was just a suggestion and I agree with your argument. I didn't mean for this to take an entire page to get my point across, so we can just leave this suggestion as is. I was basically just hoping "If it was possible to do easily, then why not?", but I doubt that is the case.
Well it's not just a matter of "is it possible", it's a matter of the reasonability of the suggestion.
For what you're wanting to do, the editor would have to be modified to allow event handlers to specify how many and what type the parameters should be, in addition to the actual values, which as I said would have to be either static or linked to global variables. So now we need some huge schema editor similar to the (Custom) Properties Schema Editor so that you can define how you would like AGS to handle each and every (type of) event handler. Even if undefined values could revert to the AGS default parameter list, this would still be a rather large feat in and of itself. From there the editor would have to read said schema every time the events pane is drawn so that it can create a subsection for every event handler in the events pane to allow you to specify the values.
The engine would have to be modified to allow the event handlers to have a variable argument list at run-time, otherwise you'd have to build a custom engine every time you compiled the game. In addition to that, the actual run-time calls to the event handlers would have to extrapolate the parameters that had been passed through the variable argument list, based on the data entered in the editor at design-time. Once the parameters had been extracted, then AGS would be able to actually place the call to the event handler itself.
These are not insignificant changes, and your suggestion was to make these changes so that you could avoid having to include a few if-else if statements in your code. I honestly don't understand the aversion to having to type out these if-blocks. If you did it properly you wouldn't have to duplicate any code, would have only one event handler for each of the controls (or other items) that needed the additional parsing, and quite realistically it would probably take less time to type out the if-block than it would to go through every one of these controls and specifying the static values in each control's respective Properties pane. I honestly believe that your design-time work flow would be more efficient with the event handling the way it already is, and an understanding of such, than the scenario you've described.
I'm not trying to be rude or bash your suggestion. As you said, it was just a suggestion. All I'm trying to do is explain why, in my opinion, your suggestion is not only worthwhile for implementation (due to the sheer amount of changes that would have to be made when weighed against the "benefit"), but would actually have the reverse effect of the intended one.
I would like to request a type of point plotting in the room editor. I know I can draw free-hand or use lines. But point plotting takes away the stress of trying to connect the lines or by have to hold a steady line. Basically, you click on one area of the screen and then on another and a line is drawn from point a to b and you can keep connecting the dots until you press Escape or some other release key.
I could actually see the usefulness of that, but I'd prefer it more like in Photoshop, where you can use the "pencil" tool normally to draw individual points or freehand, but if you draw a single point, then hold down shift and the select another point, it will draw a straight line between those two points.
That works too as long as I can continuously connect points by holding shift.
That's how it works in Photoshop! :D And I actually find it more useful than the line tool unless I don't know where I need the end-point to be (for the reasons you mentioned).
I'd love to have current tiled sprite import removed entirely -
because it's basically useless, the time you pixel hunt to get everything right takes actually more time than saving frames separately and -- it would be time better spent! -
and replaced with something much easier to use, like the one Game Maker uses (perfect, high level of customization) or a simply smart one like filmstrip import in Gif Movie Gear -- you only tell how much frames strip has and it chops them down automatically evenly to get required number of frames
Tilesheets - while rarely used by AGSers - are very powerful way to manage sprite graphics and the unpopularity is very clearly tied to the fact that AGS isn't making it's usage any easier.
Would you like 800 files for 100 animations or only one? What if you decide to add a detail onto characters clothing?
While this can be reworked right now using GIF importing and other tricks, AGS should be self-sufficient.
I imagine it's an eveningful of coding for a good coder. If I had skills, I'd implement it myself.
Second what InCreator says. I gave up on tiled sprites a long time ago.
Spritesheets are only really useful for memory conservation in-engine. Since AGS splits them up anyway they lose all their benefit. individual images or gifs are a far better way of importing.
On engine level, yes.
But for actual image editing, sprite sheets give a good overview, organization and ability to adjust (such as copypaste a detail, make slight change in sprite so all animations get it instantly (say, you want to color red shirt green. Have fun with going over every file!), etc etc) on the fly, and that's very much overlooked. If you find no use to sheets, try first and thank me later.
Also, I fail to see how importing file by file or GIFs is any way better than importing areas of same sheet? With as shitty tiled import is right now, true. But with any other software that does this right, it's way another ballgame.
Also there's quite a difference between 10 characters and few opening doors for MAGS game and full featured project with enormous amount of animations and sprites to manage. This is where TSI is required.
Room folders. Please. Room folders.
Quote from: LUniqueDan on Sun 17/07/2011 10:06:21
Room folders. Please. Room folders.
Seconded!! I've never been lucky enough to make a game that didn't kind of need this. It's really nice to have it for views and sprites, and I believe it would be useful for rooms too.
If I had some time I'd like to eliminate objects from rooms and just turn characters into an entity class that serves both needs. This would mean adding another tier to the treeview on the right (below characters) for the 'object' store, as well as adding folder support to both. That way, if you still wanted to recognize objects by the room they initially appear in you could place them in a folder called 'Room 1'. For players, folders would be a good way of organizing by type to reduce clutter.
Unfortunately, I'm busy with so much stuff right now... But maybe someone else might want to take on unifying objects and characters into one class so objects no longer have the silly limitations imposed on them (inability to set frame, limited number of objects per room, objects can't transition rooms, etc). There's no reason why they shouldn't just share one class and all the benefits thereof, and many people circumvent objects entirely now with characters, making the logical step just to strip them from being tied to rooms and allow the user to make as many as they want, wherever they want.
Quote from: Joseph DiPerla on Fri 15/07/2011 17:23:48
I would like to request a type of point plotting in the room editor. I know I can draw free-hand or use lines. But point plotting takes away the stress of trying to connect the lines or by have to hold a steady line. Basically, you click on one area of the screen and then on another and a line is drawn from point a to b and you can keep connecting the dots until you press Escape or some other release key.
I haven't looked at the editor source and I still need some more practice with my C#, but for my suggestion, I figured I would point out this code I found at these sites which might do what I want. Of course, a little tweaking will be necessary. But if someone has the time to include this feature into the AGS Editor, you would be making me very happy:
http://www.java2s.com/Code/CSharp/2D-Graphics/Drawpath.htm
http://msdn.microsoft.com/en-us/library/system.drawing.graphics.drawpath.aspx
http://msdn.microsoft.com/en-us/library/system.drawing.graphics.drawpath(v=vs.71).aspx