Hey, I think we need the following:
1. A better global/room message editor.
First, I don't think there's any reason why the global message editor and the room message editor should work differently. It would be nice to set characters to say global messages, and have a display next message after this option. And no double clicky on the messages. how about a list at the bottom with all the messages, and a textbox on the top to write them? :)
Now, as for the rooms message editor, I think it should be a subtree in the room editor branch just like the global messages, and take up the whole screen so that you can easily edit the messages without going to a separate screen that blocks the dialog while you're scripting. Why? because sometimes I'm scripting and I type Display( and then I have to switch back to the general editor, click on the abc, then find the message, then close that window, and then switch back. If I don't close the window, then I think I can't switch to the script editor or something.
2. Enum support on dialog scripts
Man, it would be nice because now days instead of using numbers for global ints, I'm using enums... so I do things like SetGlobalInt(eBlah, eJunk), and it would be nice to do a set-globalint eBlah eJunk instead of doing a run-script and then doing it in code.
3. Block check
It would be nice to check if you're blocking somehow, because then I could do something like this on repeatedly_execute always:
if(!cutscene && Blocking()) {
StartCutscene(eSkip..);
cutscene = true;
}
else if(cutscene && !Blocking()) {
EndCutscene();
cutscene = false;
}
And bam! that takes care of skipping everything for good :P
What do you think? :)
I think an improved message editor is a good idea. And perhaps a display message XXX after this feature as well?
Quote from: netmonkey on Mon 20/06/2005 00:16:55
1. A better global/room message editor.
As a 100% scripter, I must say, who cares... ;) OTOH, this would be useful for the poor wee n00bs who use the interaction editor :=
2. Enum support on dialog scriptsLets face it, the dialog scripts coudl do with a whole bunch of stuff changing...
Quote
3. Block check
It would be nice to check if you're blocking somehow, because then I could do something like this on repeatedly_execute always:
if(!cutscene && Blocking()) {
StartCutscene(eSkip..);
cutscene = true;
}
else if(cutscene && !Blocking()) {
EndCutscene();
cutscene = false;
}
I think you can effectively check for blocking... with InterfaceDisabled or whatever its called now
Quote from: SSH on Mon 20/06/2005 09:43:47
As a 100% scripter, I must say, who cares...Ã, ;) OTOH, this would be useful for the poor wee n00bs who use the interaction editorÃ, :=
:= Actually it depends on one's scripting practice. For example, these messages are very useful for me 100% scripter. It actually doubles as string arrays which you can organise easily instead of using external data files or writing ugly codes like:
string str1, str2, str3,...;
...
StrCopy(str1, "HAHA!");
StrCopy(str2, "XAXA!");
StrCopy(str3, "Poobungies!");
...
(even if you use the GlobalString "array" or some kind of arrayed "strings" with struct you can't get away far from the above.)
Using those global/local messages I can actually just type in the messages within AGSedit and use them easily for something like (without bloating the scripts or having to load them from an external file):
function ErrorMessage(int msgnum){
Ã, string buffer;
Ã, GetMessageText (500+msgnum, buffer);
Ã, SetLabelText(ERRBOX, 1, buffer);
Ã, GUIOn(ERRBOX);
}
You can even make it room dependent string array when you use the room messages, it all depends on how to make good use to them.
I've seen two methods:
I put all my messages on the message editor, and then on the scripts I do cut-scenes this way:
Display(1);
/*move char, etc*/
Display(7);
... and so on.
But I've seen people who find the message editor inconvenient, so they do this:
cEgo.Say("msg1");
cEgo.Say("msg2");
cEgo.Say("msg3");
....
cEgo.Say("msg6");
/*move char, etc*/
cEgo.Say("msg7");
... and so on. That makes the script files very very big, and very messy. And although the way I use mine is cleaner, I keep forgetting which numbers do my messages stop, so I have to do all this clicking to get to the message editor and see what the number is. If it was like the global message editor, I can just leave it on the screen and switch back and forth between the script editor and the message editor.
The message editor could do with some sort of overhaul. The reason it's a pop-up dialog rather than an editor pane is so that it can pop up in front of the interaction editor.
I'm not so sure about global messages; really they're obsolete and should go, but they do have some specific uses so I'll leave them in.
As for checking for blocking, IsInterfaceEnabled should do the trick.
as a poor wee n00b, I would like to ask that the Global Variables in the interaction editor be the same as those used in Set/GetGlobalInt
Quote from: Pumaman on Mon 20/06/2005 22:48:16
As for checking for blocking, IsInterfaceEnabled should do the trick.
Thanks, I'll start jibbling with it.
Another Suggestion!
Multi-Platform Compile
I know that you can compile and distribute the game as an exe on windows or with acwin with the ac2game file, but what about a compilation that basically renames + adds an icon to acwin and makes setup so that it's compatible with the renamed acwin.
so the distro for, say ben jordan, would be:
bj.exe
setup.exe
ac2game.dat
bj.exe would have the custom icon, setup.exe could have a custom icon.
Why multi-platform? because you could a) include the linux and mac binary on the same zip file or b) not include those but it makes it easier for people to download those run times and play the game.
How many people would want to compile their game this way? The feedback I've seen generally is that people like keeping their game in one EXE file.
Quote from: Pumaman on Thu 30/06/2005 19:32:26
How many people would want to compile their game this way? The feedback I've seen generally is that people like keeping their game in one EXE file.
Yeah, I tend to like it in one EXE file. Basically the fewer files you need to distribute the better. I dunno, I'm fine with it the way it is, but if other people really want the milti-platform compile, ok...
Ah, well, personally I like to keep it as one exe file because I can't change the icon on acwin. Other than that, there could be 100 files in the folder for all I care. :P
I thought (I havent compiled a game in a while) that you can already change the icon of the EXE for acwin, and that you can use acgame.dat and have multiple files.
Personally, I would want an option for both. Makes it easier if we ever change our minds in the future.
Actually originally I'll say cross platform compile is a good thing, especially when you split the resources into fragments. Currently, the fragments created will be like:
Game.exe
Game.001
Game.002
...
The problem is, Game.exe already contains some of the game data in it (not only acwin.exe/acdos.exe), if you say, compile the game to a windows version, directly stuff acdos.exe into it won't work without renaming and such.
If the compile can be done into form like:
Game.exe (which is merely just acwin.exe renamed)
agsgame.dat (the other game data apart from rooms)
Game.001
Game.002
...
You can just stuff acdos.exe into the folder and launch the game immediately.
If it's not split it's not as important, since you can just do this trick:
1. Compile the game to a windows executable.
2. Open up a new folder, and throw in the following:
- agsgame.ags from teh game's folder (not the Compiled folder
- winsetup.exefrom teh Compiled folder
3. throw acwin.exe and acdos.exe into that folder and rename acwin.exe to Game.exe
However, since the DOS version is no longer valid, I don't care about it anymore, since I'm stuck to V2.62 now, and I won't use any new version anymore.
QuoteHowever, since the DOS version is no longer valid, I don't care about it anymore, since I'm stuck to V2.62 now, and I won't use any new version anymore.
On that note, the editor still has the "Windows EXE/DOS EXE" option. And it compiles. It just doesn't run. Shouldn't it have been removed?
Quote from: Joseph DiPerla on Fri 01/07/2005 20:05:36
Personally, I would want an option for both. Makes it easier if we ever change our minds in the future.
Yeah, I was thinking of it as an option.
I would like to be able to name dialog scripts, rather then them being called 'dialog 42' etc. It makes it so much easier to find things.
Tracker: Script names for dialogs (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=141)