Community
AGI Programming => AGI Development Tools => Topic started by: ZvikaZ on February 12, 2021, 02:46:47 AM
-
(is it the correct place for feature requests? do you prefer single thread for each feature request?)
It'd be great if it was possible to run WinAGI in batch mode - i.e., from the command line, without GUI (like 'gcc', or other compilers).
Motivation:
I've started work on Hebrew translation for PQ1. My previous project was Hebrew translation for SQ3. In that project, I've exported all textual resources to an excel file, uploaded it to Google Drive, and then shared it with a team of volunteers. The translation, and discussions, were done on Google Drive. Then I had scripts that downloaded everything from the drive, made required changes, [compiled everything with SciCompanion (*)], and created zip file ready for distribution.
(*) I've written [compiled] in brackets, because that step couldn't be done automatically, as SciCompanion doesn't have batch mode. Thus, this step needed manual intervention.
I plan similar flow for PQ1, and it'd be great if WinAGI could be run from a script, without GUI.
I assume that for the current version, it'd be quite difficult to achieve, but please take this into account for your new C# version design.
-
This is probably the best place to make feature requests! Separate threads works for me, unless the requests are closely related.
Regarding batch mode, I can easily add command line switch options ( '/c' for a full compile; '/r' for rebuild VOL, '/d' for compile dirty logics) along with a wag file name that will run the compiler when WinAGI starts. Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions. But I could make the GUI disappear immediately after running.
Would that work for you? Are there any other switches/functions you think you might need?
-
Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions.
... suddenly I understand what's the big frikkin deal with recent, more "modern" UI development paradigms. I need a drink.
-
Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions.
... suddenly I understand what's the big frikkin deal with recent, more "modern" UI development paradigms. I need a drink.
I don't know how to read this. All I was saying is that the main functions for opening and compiling games currently provide feedback in the form of progress windows, status bars, and message boxes. I'd have to deal with all of these to go sans-GUI. It's not difficult, but it will take some time that I'd rather spend on something else.
Is that an example of a "modern" UI development paradigm? Why is that bad?
-
<lecture mode>
In classic Visual Basic and C# WinForms alike, you usually think in terms of "this is the user interface, when you click this button you run this event". "If the textbox has a selection, enable the Copy and Cut menu items". "Here's a window to create a new project, we actually do the creation thing when you click OK".
In the cut/copy example, imagine you have an Edit menu, toolbar, and a context menu. In your check to enable the cut/copy/paste commands you'd have to alter three separate controls for just the one operation. In the "new project" example, you can't run automated tests, or have a command line hook without either duplicating things or flashing the window on-screen.
With "modern" paradigms, the Cut menu item, toolbar button, and context item are each bound to the same single command, and you can just say "set the Cut command's availability to true if there's a selection". All three items automatically reflect that state, and they all execute the same code when clicked not because they have the same event handler, but because they have the same command. That's basically what WPF applications are like.
The "new project" thing could be done "better" in classic VB or WinForms by having a single "create new project" method/function that's not itself part of the "New Project" form but is called from that form. Or from the command line handler when it finds a "/new" argument. Or from an automated testing rig. Or gods forbid a Python binding. Either way there's a single piece of "create new project" code that all three entry points may use.
</lecture mode>
And I didn't understand the big frikkin deal until this week. Your comment on making it "completely GUI free" helped what I'd read before snap into place. So thank you for that.
-
This is probably the best place to make feature requests! Separate threads works for me, unless the requests are closely related.
Regarding batch mode, I can easily add command line switch options ( '/c' for a full compile; '/r' for rebuild VOL, '/d' for compile dirty logics) along with a wag file name that will run the compiler when WinAGI starts. Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions. But I could make the GUI disappear immediately after running.
Would that work for you? Are there any other switches/functions you think you might need?
Sounds great.
Maybe also an option to compile a single logic file?
On later phase, it might be nice to add also a possibility to "import Game" from command line.
Perhaps I will think of few more functions in the future...
-
<lecture mode>
In classic Visual Basic and C# WinForms alike, you usually think in terms of "this is the user interface, when you click this button you run this event". "If the textbox has a selection, enable the Copy and Cut menu items". "Here's a window to create a new project, we actually do the creation thing when you click OK".
In the cut/copy example, imagine you have an Edit menu, toolbar, and a context menu. In your check to enable the cut/copy/paste commands you'd have to alter three separate controls for just the one operation. In the "new project" example, you can't run automated tests, or have a command line hook without either duplicating things or flashing the window on-screen.
With "modern" paradigms, the Cut menu item, toolbar button, and context item are each bound to the same single command, and you can just say "set the Cut command's availability to true if there's a selection". All three items automatically reflect that state, and they all execute the same code when clicked not because they have the same event handler, but because they have the same command. That's basically what WPF applications are like.
The "new project" thing could be done "better" in classic VB or WinForms by having a single "create new project" method/function that's not itself part of the "New Project" form but is called from that form. Or from the command line handler when it finds a "/new" argument. Or from an automated testing rig. Or gods forbid a Python binding. Either way there's a single piece of "create new project" code that all three entry points may use.
</lecture mode>
And I didn't understand the big frikkin deal until this week. Your comment on making it "completely GUI free" helped what I'd read before snap into place. So thank you for that.
I read once someone (forgot who...) that said that Windows programmers first build a GUI, and then implement its functionality; while Linux programmers first implement the functionality, and then (perhaps) attach it to GUI.
@Kawa, the two paradigms that you wrote seems "Windows" to me, while I think in "Linux" terms...
-
I read once someone (forgot who...) that said that Windows programmers first build a GUI, and then implement its functionality; while Linux programmers first implement the functionality, and then (perhaps) attach it to GUI.
@Kawa, the two paradigms that you wrote seems "Windows" to me, while I think in "Linux" terms...
You're not wrong, I guess.
-
I read once someone (forgot who...) that said that Windows programmers first build a GUI, and then implement its functionality; while Linux programmers first implement the functionality, and then (perhaps) attach it to GUI.
@Kawa, the two paradigms that you wrote seems "Windows" to me, while I think in "Linux" terms...
You're not wrong, I guess.
And in DOS, both approaches are valid.
-
And in DOS, both approaches are valid.
To be fair, you don't generally have a GUI in DOS. Fun unrelated fact, QBASIC's user interface is written as if it runs on Windows, even though it's very much a DOS application. You figure out how that works... or how I know this.
-
The "new project" thing could be done "better" in classic VB or WinForms by having a single "create new project" method/function that's not itself part of the "New Project" form but is called from that form.
That is how I have tended to write my programs for the past several years. Makes it easier and faster to write it just once in a separate class or at least separate method that can be called from whatever button click, menu selection, command line argument, etc.
-
Right? The event model just seems to invite making the "actually create project" code a part of the form like goto allegedly invites spaghetti.
So hey, good on you. I ought to get over it and learn to do similar.
-
Thanks for the quick implementation of the new feature!
However, I'm not sure that I understand how to use it.
I've run
"C:\Program Files (x86)\WinAGI GDS\WinAGI.exe" /d "C:\Zvika\Games\Police Quest\AGI\PQ1.wag"
And WinAGI just opens, and closed, without anything happening.
How can I compile the dirty logic files?
(I have later opened the GUI, and compiled the dirty logic files from there, just to make sure that there were indeed file recognized as dirty)
Also, is it possible to write some log file, that I can check from the script what happened, what files compiled, which errors and warnings were issued?
Thanks
-
It only gives you a message if it encounters an error. if you don't get any error message, then you know it compiled correctly.
This was the easiest way to implement the feature. Adding a logging feature would require more work than I currently have time for. I might take a look at it later, but I can't make any promises as to when.
-
Possibly something to implement with your C# version, instead?
-
Yeah, probably a good idea.
-
Sorry, but the compile dirty logic files doesn't work for me from command line.
Maybe I'm not using it correctly...
Can you elaborate a little about it's usage?
Should it be simply:
"C:\Program Files (x86)\WinAGI GDS\WinAGI.exe" /d ?
Or:
"C:\Program Files (x86)\WinAGI GDS\WinAGI.exe" /d "C:\Zvika\Games\Police Quest\AGI\PQ1.wag"?
Should it be run from the game directory, or it doesn't matter?
Does it expect something to be run before it, or after it?
Or any other instructions?
-
Sorry - I didn't do a lot of testing, so there are a few 'glitches' you need to be aware of. I probably shouldn't have released this without doing extensive testing first. Oh well...
The second line is correct; you need to invoke WinAGI, then follow it with the switch '/d', and then your game file. It doesn't matter what directory you run it from, as long as the WinAGI executable is reachable (using the included directory information, or by using your DOS PATH environment variable). If the path to the executable includes spaces, the entire executable command needs to be included in quotes, as in your example.
BUT the game file argument MUST be quote-free. (The function that opens a game expects no quotes, and I forgot to make sure the argument passed from the command line was 'de-quoted' - :P)
Also, you must include the full path to your game file (again, I didn't do a lot of testing, and didn't consider how it would work if a path was not included in the argument value).
So this should work for you:
"C:\Program Files (x86)\WinAGI GDS\WinAGI.exe" /d C:\Zvika\Games\AGI\PQ1.wag
Also keep in mind that if you configure WinAGI to use the Splash Screen at start up, you will get the GUI to load even if you use command lines; I didn't want to screw with the program initialization too much to get this to work, so I chose to process the command line AFTER reading the configuration file, which means you will get a splash screen if that setting is active. It's not a big deal though - the GUI automatically closes after the compile is done, or more simply, just disable the splash screen and you should be GUI free. (mostly... ::) )
I also discovered that if you run a command prompt window that uses elevated privileges, WinAGI doesn't read the game configuration file correctly, so you get the splash screen even if you've disabled it. I have no idea what's going on there. Just be aware of it.
I tested these instructions again this morning on a clean install, and it worked for me. So hopefully, once you get the syntax correct, you should be able to successfully run the compiler in whichever mode you want (c/d/r). If it succeeds, then the program will just terminate, with no exit code, and no output at all. If the compile fails, you should get one message box popup that tells you that. But it won't give a lot of detail. You will need to run the GUI to get a detailed explanation of why it can't compile.
-
One more bug I noticed, when using the /r or /d options, you don't get an error message if the game file doesn't load. Using the /c option does give you an error message when the game file doesn't load.
So you just have to be a bit more careful with the /r and /d options.
-
Thanks, now it's working.
If you could print error messages for '/d' and '/r' as well, it'd be nice.
Also, it'd be helpful to have what you wrote here documented in the help file. It will save you questions in the future ;)