An attempt at a new tool++ - but I don't know much VB

Before I start, for those who actually follow who's posting what, I know I said I haven't really being doing anything HEK related recently but what I meant was I haven't really been using the HEK. I have however been playing with Visual Basic in Visual Studio 2008 without really knowing what I'm doing, attempting to create a new tool++.

The reason I'm doing this is the old tool++ screws up whenever you try to compile a model (including bsps) that doesn't have all it's shaders already created in you tags folder. I've dug around on the internet for a few days and managed to find enough code to get the tool command to run but I'm having a similar issue to the one I set out to avoid, plus an issue exclusive to my app. This second issue is that the program only works at all if it is in the HALO Custom Edition folder with tool, otherwise tool looks for whatever you're compiling in a sub-folder of the location of my program, not tool itself. The debug.txt is also created in the same folder as my app, not tool. This second issue is especially anoying as I spent some time (before getting the run tool bit to work) working on a settings menu complete with code to check the halo custom edition directory entered by the user actually exsists and contains tool.exe and haloce.exe.

You'll probablly need more information to be able to help, if so and you're willing to help just ask and I'll see if I can provide the info.

Quote:

---

Originally Posted by Rhydgaled

I have however been playing with Visual Basic in Visual Studio 2008 without really knowing what I'm doing, attempting to create a new tool++.

---

If you don't know what you are doing, and you are just copying and pasting code that you find on the Internet, you should not be attempting this. Instead, do some actual research about how to go about doing something like this, as well as actually learning the language.

I don't see the point of using a GUI for Tool. It's not hard to use Tool in it's current state, but that's just my opinion. Also, other people are working on a Tool GUI already, in case you didn't know.

Quote:

---

Originally Posted by ShadowSpartan

I don't see the point of using a GUI for Tool. It's not hard to use Tool in it's current state, but that's just my opinion. Also, other people are working on a Tool GUI already, in case you didn't know.

---

I don't see the point either, tool really isn't all that hard to use.

On the topic at hand, you would be better off learning more of VB first rather than trying to learn it while you program.

Quote:

---

Originally Posted by Con

On the topic at hand, you would be better off learning more of VB first rather than trying to learn it while you program.

---

I should have mentioned that I can speak from experience on this matter. This is where I made a mistake when I first started programming Halo related projects. I dived right into the script extractor as my first project, and while I did get it to work properly, the code is such an eyesore to look at. I have since rewrote it about two times.

Another thing you don't want to do is just jump right into writing code, it causes you to create not well thought out, and thus sloppy code. I've moved onto C#, and have been writing an app for a couple months now, and I can't tell you how much planning it out and not jumping right into coding has helped me. While your project is rather "small" in comparison, the same principles still apply.

Quote:

---

Originally Posted by ShadowSpartan

If you don't know what you are doing, and you are just copying and pasting code that you find on the Internet, you should not be attempting this. Instead, do some actual research about how to go about doing something like this, as well as actually learning the language.

---

Quote:

---

Originally Posted by Con

On the topic at hand, you would be better off learning more of VB first rather than trying to learn it while you program.

---

Your point makes perfect sence, I would probablly think the same thing if I was a well practiced programer and somebody in a similar siutuation to mine right now asked me for help.

Although I don't really know much VB I'm not as far out of my depth as I may appear, as I have studied programing (Java (only command line though) and Delphi) before, just not to this kind of level. I chose to use VB for this as it is what we're using in the programing module of HND Computing this year so I thought this tool++ project might be a good bit of practice.

Quote:

---

Originally Posted by ShadowSpartan

I should have mentioned that I can speak from experience on this matter. This is where I made a mistake when I first started programming Halo related projects. I dived right into the script extractor as my first project, and while I did get it to work properly, the code is such an eyesore to look at. I have since rewrote it about two times.

Another thing you don't want to do is just jump right into writing code, it causes you to create not well thought out, and thus sloppy code. I've moved onto C#, and have been writing an app for a couple months now, and I can't tell you how much planning it out and not jumping right into coding has helped me. While your project is rather "small" in comparison, the same principles still apply.

---

That sounds like sound advice. I shouldn't really be rushing in like this, but I can't resist playing around with programing. I've actually understood most of what I'm doing (and grabbing off the internet) in this tool++ project, just not the more hardcore stuff that actually interfaces with the command line app. Here's the function (from the internet) that does the interfacing (probbablly over 90% of the stuff I don't understand well.) Despite not understanding it at all well, I still managed (with a little more hunting on the internet) to make a few modifications (mostly to get it to compile in the version of VB I'm using).

Code:

---

PrivateFunction GetDosOutput(ByVal strCMD AsString) AsString'Function from the internet (http://www.vbcity.com/forums/topic.asp?tid=36383&#RID108842) to allow command line interaction
GetDosOutput = ""
Dim objShell As IWshRuntimeLibrary.WshShell
Dim objExec As IWshRuntimeLibrary.WshExec
Dim strLine AsString
Dim strPrompt AsString
'set the prompt to look for
strPrompt = "choice (1-9):"
'instatiate Shell object
objShell = CreateObject("WScript.Shell")
'Execute the dos command
objExec = objShell.Exec(strCMD)
'wait for execution to finish
DoWhile objExec.Status = IWshRuntimeLibrary.WshExecStatus.WshRunning
Application.DoEvents()


'get respone 1 char at a time
strLine = objExec.StdOut.Read(1)
If strLine <> ""Then
'append the char to the output
GetDosOutput = GetDosOutput & strLine
'my next modification
If GetDosOutput.IndexOf(strPrompt) <> -1 Then
MessageBox.Show("choose a type for the shader") 'temporay modification to show me if it's found the line, which at the moment it doesn't seem to be doing
'objExec.StdIn.Write("1")
EndIf
'if the last part of the output is the prompt, write something to stdIn (input)
If Microsoft.VisualBasic.Right(GetDosOutput, Len(strPrompt)) = strPrompt Then
MessageBox.Show("Toolbeta") 'temporary message, so I can see if the IF statment has been entered
objExec.StdIn.Write("1")
EndIf
EndIf
If objExec.StdOut.AtEndOfStream Then
ExitDo
EndIf
Loop
'get the rest of the standard out
GetDosOutput = GetDosOutput & objExec.StdOut.ReadAll
'get any standard err. output
GetDosOutput = GetDosOutput & objExec.StdErr.ReadAll
'clean up
objShell = Nothing
objExec = Nothing
EndFunction


---

I'm not expecting to recive any help, but I put this up just in case.

Quote:

---

Originally Posted by ShadowSpartan

I don't see the point of using a GUI for Tool. It's not hard to use Tool in it's current state, but that's just my opinion.

---

Quote:

---

Originally Posted by Con

I don't see the point either, tool really isn't all that hard to use.

---

I think I can see what you mean here as well, when the tool++ shader choice issue comes up I switch to normal command line tool myself and once you've found out you have to copy cmd.exe to the halo ce folder it's not too hard. I just find tool++ faster scine I'm not very good at remembering the tool commands for the original command line version so it takes me two or three guesses before I get it to compile my stuff.

Rhydgaled, all you need to do is list the command options in Tool, make a new VB.net project (I wouldn't recommend any version of C, C#, or C++. VB.net is more user-friendly) standard windows forms application. Add fields for each option, include the tool.exe in your project and make a reference to it.

E.G,
You make a textbox under "build-cache-file," call it "cachenametxt". You then make a button "Compile scenario." Call it buildcachebutton. Now into scripting, add a form handling buildcachebutton.click (just double click the button in the visual window) and under it add something like this:

Code:

---

Dim p AsNew Process
p.StartInfo.FileName = "./tool.exe"
p.StartInfo.Arguments = "build-cache-file " & cachenametxt.Text
p.Start()

---

But that's only good for build-cache-file, you would have to do that same thing for every command line argument that is possible to pass to tool.exe.

-Arightwizard

Quote:

---

Originally Posted by Arightwizard

(I wouldn't recommend any version of C, C#, or C++. VB.net is more user-friendly)

---

I don't necessarily agree with that. VB was a good beginning language for me, but I will never touch it again after making the switch to C#. I wouldn't really call VB a more user-friendly language, since what makes it so easy to use is the .NET framework which C# also uses, it just seems to be a good language for beginners.

Quote:

---

Originally Posted by Arightwizard

Rhydgaled, all you need to do is list the command options in Tool

---

I was under the impression that he had this part working already, hence why he has it checking for the "choose a type for the shader" prompt. Also, that isn't "all he needs to do". He wants to make it better than Tool++ by, for example, including the ability to create shaders when they do not exist in the tag set. It's not as simple as the code you have in your post.

okay ummmmmmmmm i know the makers of tool++. They knew they be bugs the have to fix it. Dont steal their idea okay

ShadowSpartan, I figure he's new to .NET and so I recommended VB.net to him because, as you said, it is a great beginning language. (I still use it a lot :P)

Also, that was my bad for saying that incorrectly. No it is not "all he needs to do," it was the basics of what he needs to do. The other features would require much more coding as well as a concept of C++, to compile the shader tags in. (Like making a script to write to a .cpp file, then compile that with existing files into a tag).

I was telling him an alternative way to do this, rather than creating a console prompt. Console scripting in VB.net is, dare I say, "Harder" than standard forms applications.

Quote:

---

Originally Posted by skywalker71291

okay ummmmmmmmm i know the makers of tool++. They knew they be bugs the have to fix it. Dont steal their idea okay

---

Tool++ was created by Kornman, you are thinking of Tool #. It is hardly an original idea to create a GUI wrapper for Tool, and I find it rather annoying that you believe Rhydgaled is "stealing their idea". A little competition is good for the community, and it doesn't hurt anything by him trying to do this.

Quote:

---

Originally Posted by Arightwizard

The other features would require much more coding as well as a concept of C++, to compile the shader tags in. (Like making a script to write to a .cpp file, then compile that with existing files into a tag).

---

I think you are over analyzing the situation. Why would he need to go through C++ to have Tool generate a shader file, which it does already? All tool does is create a blank shader tag, based on whatever type you choose when prompted.