Previous post:
[spoiler]I have a handful of ideas to put into code, but the interface is distracting me.
I am not sure how to move forward at this point so I'll ramble about it here. Jump right in if you think this is a good or bad direction.
I like using SchMEe from batch files and the commandline. I am definitely going to keep that ability.
But the GUI bothers me more and more every day. It is too simple and not complete enough.
It needs to give (relatively) easy access to all of the functions, and it doesn't. All the material editing features are locked into commandline mode.
It needs to be able to tell folks what is in the msh they are editing, and all I have is a basic segm list and uv saving.
And it needs a way to sequence edits, and repeat them. (scripting.)
I have found a very simple console for AutoIT that is really a regular cmd console with some sketchy cin and cout mimicking abilities.
Going this way instead of the GUI would be yet another abstraction onhow to edit these msh files, but it would also be interactive and I could provide info to the user in the form of text screens.
It would also provide a way to "record" a sequence of commands, that could be saved as a macro or exported as an editable text file. Frequently used macros could possibly be coded into their own function and optimized if needed.
The "type command" "do command" "provide feedback" "wait for next command" loop would also reduce the number of times a file would need to be loaded and saved.
Here is the console I plan on implementing... simple:
http://www.autoitscript.com/forum/topic/126569-consoleau3-udf/
And a ridiculously simple example (I forget if he has one in-thread.)
#include <Console.au3>
Main()
Func Main()
Local $Name
Local $Age
Local $Answer
Local $Continue = True
While $Continue
Cout("Enter your name: ")
Cin($Name)
Cout("Enter your age: ")
Cin($Age)
Cout("Do you want your answers printed in red? y/n: ")
Cin($Answer)
If StringInStr($Answer,"y") Then
Cout(@LF & "Your name is ")
Cout($Name & @LF,$FOREGROUND_RED)
Cout("You were born in ")
Cout(@Year - $Age & @LF,$FOREGROUND_RED)
Else
Cout(@LF & "Your name is ")
Cout($Name & @LF)
Cout("You were born in ")
Cout(@Year - $Age & @LF)
EndIf
$Answer = ""
Cout(@LF & "Do you want to try again? y/n: ")
Cin($Answer)
If StringInStr($Answer,"n") Then
$Continue = False
EndIf
WEnd
system("pause")
EndFunc
Typed commands would be interpreted with a switch/case.
A list of commands could be stored in an array and checked when enter is pressed to eliminate all the case comparisons for typos.
I tested it's ability to accept single-key-presses, so multiple choice menus are possible as well.
I will make a mock-up of it and post it here, probably tomorrow as I need to remove the chaos from my sleep patterns.
[/spoiler]
Ok, a very simplistic mock up.
I am thinking a series of menus to keep related commands close to each other.
********************************************************************************
* SchMEe console mockup 0.01 *
********************************************************************************
* No file loaded. Load a file for more options. *
********************************************************************************
* 1 - Load a file *
* 2 - quit *
********************************************************************************
Select an option
:
********************************************************************************
* SchMEe console mockup 0.01 *
********************************************************************************
* Loaded file: test.msh *
********************************************************************************
* 1 - edit options/commands *
* 2 - view msh reports *
* 3 - save and quit *
* 4 - quit without saving *
********************************************************************************
Select an option
:
********************************************************************************
* SchMEe console mockup 0.01 *
********************************************************************************
* Loaded file: test.msh *
********************************************************************************
* edit options/commands *
********************************************************************************
* 1 - List Materials *
* 2 - Edit Material *
* 3 - Delete Material *
* 4 - List MODLs *
* 5 - Edit MODL *
* 6 - Delete MODL *
* 7 - return to previous screen *
* 8 - save and quit *
* 9 - quit without saving *
********************************************************************************
Select an option
:
A nice ASCII chart would look a lot better than the stars, and of course there would be more options or screens.
The above would work by single key-presses and opportunities to fill in more data would be presented as needed.
From the menus, some GUI dialogs would be accessed (like the file and folder select dialogs), It doesn't make sense for me to try to rebuild MS's more than adequate built-in ones.
...
ugh.
There is so much I want to add to this program but managing all those nit-picky handles for the GUI is just annoying. Looking at the above makes me realize I'd still have to go throuh the "command" building process instead of making the GUI elements.
Ok.. scratch the console. (The menuing part of it at least.)
I'm going to continue the commandline part.
I like the idea of building alias commands to reference the functions directly or to access "macro" functions. But hooking it all into a menu seems like extra work for ever added option. While it may make using this beast easier, it will also make me less likely to work on it. (I already procrastinate due to the GUI work.)
Perhaps just a simple console with a prompt.
SchMEe console mockup 0.02
Type "help" for a list of commands and options.
:
Kinda old school, but a nice little document (forum post, txt file, ect..) with all the commands listed would be helpful.
I like the 0.02 mockup better. It still has the overhead of creating a command alias (and it's syntax), but the end result is a consistent design that doesn't have to be shifted or resized after every little edit and it can house a virtually limitless number of commands.
Creating commands would be similar to the commandline options.. I might even find a way to just copy paste some of it, which would speed up adding new features. And I already have to add those so it isn't a lot of extra work.
To get the console to work, I'll have to revamp the flow control parts of the program (#region ; SchMEe.au3 in the source.) but I could do away with Func _GUI_ShowOptionPanel() (400 lines of "I hate this"), and the flow needs to change anyway to accommodate possible scripting and multiple edits per file load.
Or, I guess I could read a book on interface design and commit to a GUI...
Yeah, stuck on the interface. Thanks for tolerating my crazy, guys.
Current events regarding the interface.
The GUI is taking the focus because of the new Wireframe display.
Still want to make some sort of interactive console mode, but that's being put aside for now. It will likely be made into a "mode" that will be activated by starting the program with a certain switch.
The switches used from the commandline will always be part of the program. The only changes I will make to them is internal and won't affect how it's used.
Progress on the GUI is slow and is being worked on independent of the code.
It's slow because I am not using a form designer and because I am unfamiliar with GUI elements in general. All the elements can have events paird with them in different ways and the only way to test it is to bolt it onto SchMEe, but I don't want to do that till I get a halfway decent mock up built so I can avoid needless code mess.
Because this is going to make it event based, I am worried about long-running functions not completing before another control is clicked (starting another function.) I solved this in the MSH_INFO program by temporarily disabling the mouse. I don't want to do that again. Still thinking about it.
Very basic screenshot of the GUI so far.
The left is going to be a tree view. It may have different display modes (tags in hierarchical order, or logical groupings of just the important stuff like materials and geometry, or a view of how the nulls are parented to reveal skeleton structure.)
The right is a tabbed display area where info about whatever is selected will go. Each tab will have diferent types of info. (Wireframe preview, full hex dump of the tag, raw translation of the data.) Still deciding what's important. Some controls for context specific commands may end up in a tab.
Very very basic so far.
So, why aren't you using a form designer?
It seems like a faster pace for progress.
Or do you like things written in your own pattern?
The form designer for AutoIT (called Koda) uses a weird naming scheme and includes has a bunch of irrelevant message loop stuff in it's generated code. It's good for laying out a basic form, but adding all the events in afterwards and renaming all the handles and ripping out the stuff I don't need is a supreme hassle.
I could get past it if I could import my own code into it and edit from there. Can't do it. It uses a proprietary format to save it's forms, and .. yeah... not gonna rant about it anymore. It's good for small forms with 2 or 3 controls.. maybe a set of menus. For SchMEe with a wireframe preview (that S3D library,) I need a treeview, graphic area, and a blank spot for context specific stuff. Koda makes it 100X harder to test.
It's not all Koda's fault.. I'm unfamiliar with events and windows message polling. One of the thing's I am doing is making a set of "add_command()" type functions to make adding new features to the commandline and the gui easier. There is no practical way for a form designer to do that.
Okay, gotcha.
I've recently started fooling around with AutoIt, I really like it. Even more so now that GameMaker recently goofed up my standard license, and cannot use it on my PC anymore...
I've been using AI to "adjust" some memory in the games I've made myself, but I was really impressed when I saw it was possible to load up 3D models, that was just cool.
--
Can't wait for this program to be finished! Great work.
Quote from: -RepublicCommando- on August 12, 2013, 10:20:54 PM
Okay, gotcha.
I've recently started fooling around with AutoIt, I really like it. Even more so now that GameMaker recently goofed up my standard license, and cannot use it on my PC anymore...
I've been using AI to "adjust" some memory in the games I've made myself, but I was really impressed when I saw it was possible to load up 3D models, that was just cool.
--
Can't wait for this program to be finished! Great work.
That's cool. Since AutoIT is an automation language, it has a lot of handy little capabilities built-in that more sophisticated languages lack.
This S3D UDF I'm using isn't really the best for doing 3d. (It's slow, hard coding of 3d to 2d calculations, really better for drawing wires only.) I use it because it doesn't require any DLLs. (and because it's syntax is easy enough for me to understand.)
However, the
Au3Irrlicht 2.0 (http://www.autoitscript.com/forum/topic/113881-au3irrlicht-20/) UDF looks very promising for real 3d work. It's an AutoIT wrapper for the Irrlicht engine. It's over my head, but looks good and all the examples he posted work great. A person could code an entire game with it. (though it would probably be better to come at Irrlicht from c++.)
I have a new layout (but no screenshot) for SchMEe.
Still have the tree view on the left, then a graphic area in the middle, then the whole right side will be scratch space for showing the data/info.
Might add a status bar at the bottom, but need to workout how to refresh the graphic area on resizing that doesn't grind the computer to a halt.