I'm not sure if I'm using the right terms to describe it and if it is feasable and if it has been asked before.
But I think it would be very useful to be able to always have access to all AGS Windows. Maybe you call this multi-tasking or modular program structure or so.
Then, when I you are scripting you don't need to remember which room number corresponds to which room and the same for objects, walkable areas etc.
You could just look it up, since the scripting window would not stay on top.
Yeah, I know I could use an external editor or the AGS ressource manager, but the first means less comfort, the latter means considerable extra-work.
(If there's a trick to access the inactive windows while i.e. the scripting window is open, tell me :) )
It's not currently possible to edit multiple rooms at the same time. What I do is keep a copy of notepad (the windows tool) open that has a list of relevant rooms and such. What could also help is putting the following in your global script header:
#define R_HOUSE_OUTSIDE 1
#define R_HOUSE_INSIDE 2
#define R_HOUSE_CELLAR 3
#define R_PATHWAY 4
etc...
This allows you to call rooms by name rather than by number, just like you do with loops and characters.
I can access the AGS editor itself when a script window is open. I use this a lot, especially when playing around with coordinates in rooms.
I also use #define's for room names, and I have the defined names in the room descriptions in the room editor. Helps things out a lot for me.
While editing the room script or the global script, it's no problem. If you go through the intarction buttons, and then "Run script", the "interaction editor" will block the access to the rest of AGS. A workaround is to jump back out when you've added "Run script", then enter room script (or global script) and you'll find the new interaction added at the bottom here. You now have access all areas (not multiple scripts though, but I believe you weren't asking for that...?).
Quote#define R_HOUSE_OUTSIDE 1
#define R_HOUSE_INSIDE 2
#define R_HOUSE_CELLAR 3
#define R_PATHWAY 4
etc...
This allows you to call rooms by name rather than by number, just like you do with loops and characters.
I like thatÃ, :) ... now let's see if I get it right:
if I type NewRoom(R_PATHWAY) in any script (global or room) it is replaced byÃ, NewRoom(4) ... is that correct?
That's really a good idea!
In the latest Beta version, you can make a Room enumeration and the editor will auotcomplete for you after you've typed 3 characters... even better than #defines
Quote from: Iago on Wed 09/02/2005 00:05:10
Then, when I you are scripting you don't need to remember which room number corresponds to which room and the same for objects, walkable areas etc.
You could just look it up, since the scripting window would not stay on top.
As Neil says, this already works except when the interaction editor is open. If you use the Edit Global SCript or Edit Room Script options, you can alt+tab back to the editor and look stuff up.
What about when the help file is open?
I suspect this is more of a behaviour determined by the Windows OS, but when i have the helpfile open i can't set focus to the AGS window.
Only when i minimise the helpfile i can reach the AGS window again.
This is quite tedious when you're intensively making use of the manual (like my momma tought me so no one would yell at me to RTFM)
Sorry for kind of hijacking your thread Iago, but i thought this was very related and might be answered aswell here instead of in a different thread.
Quote from: SSH
In the latest Beta version, you can make a Room enumeration and the editor will auotcomplete for you after you've typed 3 characters... even better than #defines
I get that same autocomplete behaviour with v2.6x with this ugliness in the script header:
#define ROOM_LIBRARY_PRESENT 1
#define ROOM_LINGUIST_TENT 2
#define ROOM_STONETABLE 3
#define ROOM_WORMHOLE 4
/*
import int ROOM_LIBRARY_PRESENT;
import int ROOM_LINGUIST_TENT;
import int ROOM_STONETABLE;
import int ROOM_WORMHOLE;
*/
I think it was Scorpiorus who showed me that trick.
Quote from: Oneway
I suspect this is more of a behaviour determined by the Windows OS, but when i have the helpfile open i can't set focus to the AGS window.
The solution there is to start up the help as a separate application, by double clicking on "ags.chm" in the AGS folder.
I'd love to be able to have multiple scripts (and dialogs) open at the same time and switch between them M$ Visual Studio style, with Ctrl-F6 or by clicking on the room/character/inventory/dialog name. And have a search function that could search in all scripts, rather than export the text and search in that. But I appreciate that it's a paradigm shift. (Sorry - just wanted to say paradigm shift.)
Steve
Or if there were tabs like Firefox or Opera at the top of the editor and you could use those to switch between files. OK, there might be problems administering this between room/global files, but at you could open the editor with global/header and module files in tabs. SciTE has tabs like that, so it should be feasible in Scintilla.
While we're on editor suggestions, SciTE has the ability to print and export to HTML, etc from the editor. This might be a nice way to print AGS scripts with all the nice syntax highlighting, etc included...
Quote from: SteveMcCrea on Thu 10/02/2005 02:12:54
Quote from: SSH
In the latest Beta version, you can make a Room enumeration and the editor will auotcomplete for you after you've typed 3 characters... even better than #defines
I get that same autocomplete behaviour with v2.6x with this ugliness in the script header:
#define ROOM_LIBRARY_PRESENT 1
#define ROOM_LINGUIST_TENT 2
#define ROOM_STONETABLE 3
#define ROOM_WORMHOLE 4
/*
import int ROOM_LIBRARY_PRESENT;
import int ROOM_LINGUIST_TENT;
import int ROOM_STONETABLE;
import int ROOM_WORMHOLE;
*/
I think it was Scorpiorus who showed me that trick.
Yeah, I remember that, but using an enum now saves the hackiness and has a lot less typing as well, because you dont always have to specify the number if you're using contiguous room numbers
enum Rooms {
eRoomIntro=0,
eRoomMenu,
eRoomCutscene1,
eRoomEntrance,
...
eRoomCredits=99
}
As Steve suggested earlier, the help file is a standard windows help file (.CHM or something) and you can open it in a separate process by double-clicking it from your AGS folder, rather than pressing F1 within AGS. That way you can alt-tab to both.
Radiant, Steve mentioned that already (though I had a hard time re-finding the line :P)
I used to have a shortcut to the AGS Manual file in my start menu, right in the root of it, on my old laptop. That was damn handy if I was lazy (too lazy to press ctrl-alt-m), just two clicks and the manual is open. I hardly ever open it though the editor. It's all just a matter of getting used to doing something...
Me, I always call the help file with F1. The context-sensitive help is a precious feature which I love.
QuoteThe solution there is to start up the help as a separate application, by double clicking on "ags.chm" in the AGS folder.
As Rui says, the problem with this is that you lose the context-sensitive help in the script editor, so you have to manually find the function definition in the help.
QuoteI'd love to be able to have multiple scripts (and dialogs) open at the same time and switch between them M$ Visual Studio style, with Ctrl-F6 or by clicking on the room/character/inventory/dialog name.
Looking back, this would have been a better way to design the editor. The main problem is the way that interactions work with script snippets, which causes various issues when trying to multi-task while editing a script.
If I were to start AGS over again, I'd probably not bother with the interaction editor at all but rather have a few more tutorials on object-based scripting. After all, it's not like you can write a serious game using just the Interaction Editor anyway.
Quote from: Pumaman on Fri 11/02/2005 19:06:47If I were to start AGS over again, I'd probably not bother with the interaction editor at all but rather have a few more tutorials on object-based scripting. After all, it's not like you can write a serious game using just the Interaction Editor anyway.
I agree the interaction editor won't get you anywhere near a completed decent game, but it DOES have its advantages. I use it a lot when assigning dialog to look and use interactions, it's a lot quicker than doing it manually.
I don't know if this is a possibillity, but couldn't the interaction editor, when assigning a 'run script' to an interaction:
1) Check if a script for the current room is already opened.
2) Open the script for current room if not already opened.
3) Append the new interaction function to the opened script (as it essentially already does)
If this is possible then i think a lot of peoples 'complaints' would be solved.
/me begins the open-source AGS reverse-engineering project ;)
The text editor already behaves differently when opening from the interaction editor, as it is more blocking, so why not have a different editor for those (less features) and have a separate better one that can be opened from the menus that allows multi-editing? Would that work. Or you could make the scripts available through the AGS COM plugin thingy and then we could do what we like with them.,.. ;)
Quote
If I were to start AGS over again, I'd probably not bother with the interaction editor at all but rather have a few more tutorials on object-based scripting. After all, it's not like you can write a serious game using just the Interaction Editor anyway.
Here are some of my thoughts on the subject for whatever they are worth. First of all the interaction editor is great for beginners because they can get started and not be intimidated by the scripting aspects of AGS. I believe that is is also true that most experienced folks use it as little as possible. This and some of the prior comments lead me to think about some possibilies.
CJ, if you were to dispense with the interaction editor, as you lament, what form would interaction events take in the script? I suppose the programmer would enter keywords or predefined function names to identify interaction events. If this were so, would it not be a possibility to execute interactions defined in both the script and in the interaction editor? I guess what I am suggesting is cutting the tight intergration of the interaction editor and the script. Essentially allow the interaction editor to do what it now does except for the script. Add to the script language what you alluded to in your comments. The programmer would have a choice to use the interaction editor or to do script programming (or possibly some combination of the two).
I fully appreciate there are numerous difficulties and that a huge amount of effort would be involved so I am not expecting this to happen in the near future but I am curious about how it might be done (technically speaking) and how people would react.
=====
Now on a slightly samller scale ;), when doing "edit script" from the interaction editor, why not open the entire script file and then position the editor window to the interaction function from which the edit was called, instead of restricting the edit to that window? Would this alleviate some of the difficulties regarding having mulitple edit buffers simultaneously open?
For me I would be happy to have the header and script opened in seperate tabs whenever I edit a script.
CJ, Hope I haven't unied your day by asking all these weird questions ;)
Cheers
Rick
Quote from: RickJ on Sat 12/02/2005 19:37:46
CJ, if you were to dispense with the interaction editor, as you lament, what form would interaction events take in the script? I suppose the programmer would enter keywords or predefined function names to identify interaction events. If this were so, would it not be a possibility to execute interactions defined in both the script and in the interaction editor?
Those are good questions. I don't have the answers, because I haven't really thought about it seriously yet, it's just something I've been musing about. Not likely to happen for a long time, anyhow.
Quote
Now on a slightly samller scale ;), when doing "edit script" from the interaction editor, why not open the entire script file and then position the editor window to the interaction function from which the edit was called, instead of restricting the edit to that window? Would this alleviate some of the difficulties regarding having mulitple edit buffers simultaneously open?
Yes, that would be the easiest solution. The way it works at the moment was designed to make it easier for beginners, but in reality it can be confusing since people don't necessary realise the connection between the interaction scripts and the room script.
Quote from: RickJ on Sat 12/02/2005 19:37:46
CJ, if you were to dispense with the interaction editor, as you lament, what form would interaction events take in the script? I suppose the programmer would enter keywords or predefined function names to identify interaction events. If this were so, would it not be a possibility to execute interactions defined in both the script and in the interaction editor? I guess what I am suggesting is cutting the tight intergration of the interaction editor and the script. Essentially allow the interaction editor to do what it now does except for the script. Add to the script language what you alluded to in your comments. The programmer would have a choice to use the interaction editor or to do script programming (or possibly some combination of the two).
This is already possible, thanks to an abuse of AGS's text parser. You can call a room script from a global scipt by one method and one alone, but it is enough: CallRoomScript and on_call. OK, it only allows one function in the room's script to be called, and you have to use global variables to pass in info, but it is entirely possible to use this mechnism to entirely bypass the interaction editor in AGS. In fact, thanks to Radiant's template, we do this in the upcoming FoY demo, and I'm thinking of putting out a game template to demonstrate the method. There's also no reason why this can't be extended to check for interactions and use them instead if they exist.
In fact, CJ, while I'm on the subject, please dont chnage the way CallRoomScript works, because according to the manual, it shouldn't quite work how it does. You can actually set it up to run as interactions with objects, hotspots, regions, rep_ex, enter room, leave room, etc. All I'd ever want to change is a way to call different functions, and you can always work around that.
Slightly off-subject but not an awful lot, related to interaction editor. If this were to disappear overnight, I'd only miss the "If Player has been in room X" interaction, because - correct me if I'm wrong - there's no script counterpart. How come?
Quote from: Rui "Erik" Pires on Sun 13/02/2005 01:49:36
Slightly off-subject but not an awful lot, related to interaction editor. If this were to disappear overnight, I'd only miss the "If Player has been in room X" interaction, because - correct me if I'm wrong - there's no script counterpart. How come?
You mean HasPlayerBeenInRoom ... ? ;)
That function exists? Damn.
<runs away as fast as he can, trying with all his might to outrun his shame and his lazyness and his inability to fully RTFM>
<stumbles and falls>