Tool # 0.2 Beta RELEASED!!

About a week and a half ago, [PMMF]Rambo and I ({HV}Chaos) started messing around with a new GUI shell for Tool. We knew about Tool ++, but realized there were a few features missing inside of it that we thought would be extremely helpful to any map makers, including ourselves.

The coding process has taken quite a bit of debugging, and many builds just to get it as stable as it is, but Tool # is here, and ready to rock!

Installing Tool # is relatively simple, just place Tool #.exe inside your Halo Custom Edition directory.

Current List of Features (Probably incomplete because of all the features):
1. Detection of Haloce.exe to make sure it is installed correctly.
2. Automatic detection of 3 variations of Tool: Tool.exe, Toolpro.exe, and Toolio.exe. It uses hash based detection, so any filenames will work!
3. Guerilla-styled layout.
4. Batch Processing Work
5. Multi-threading of windows allowing you to run (for example) Bitmaps on one thread, and turn around to run Lightmaps for a different project.
6. Built-In Help file that is written to the disk for ease of access.
7. Detection along the filepaths to turn Red/Black based on the validity of the paths. (Just like Guerilla does)
And many more!

Here's the readme:

Quote:

---

Tool # is a Tool Frontend that is designed to complement the other tools' use, as in Guerilla and Sapien. While this tool is based heavily on the Guerilla shell design, it is not Guerilla and therefore should not be treated as such. Written in Visual Basic .Net, Tool # is a powerful and robust application that takes care of every function Tool and other Tool variants perform.

NOTE: Tool # is currently in Beta stage. As such, only the following functions are supported.

-Bitmaps
-Structure
-Lightmaps
-Build Map (build-cache-file)

Do know that these functions are 100% working and completed, though bugs still may arise. Also know that all of these functions support batch mode, as in you may consecutively perform functions on a unattended basis, simply by queueing up the functions the same way you would add blocks to a guerilla tag.

We hope you enjoy this production of Tool #. Any suggestions, comments, or constructive criticism is welcome. To contact us, please contact the developer at ccchaos on Xfire.

Programmed by: {HV}Chaos
Beta Testing & Ideas: [PMMF]Rambo
Special Thanks to Bungie for inspiring us to use the Guerilla design.

---

Preview: http://i222.photobucket.com/albums/d...MainWindow.png
You may download Tool # here!

Edit (10/18/2009 - 11:44PM): Build 121 Released, link updated to show.
Edit (10/22/2009 - 11:22PM): Build 161 Released, link updated to show.

You should also post a sample screen shot for people to gander at before downloading

Right, sorry. I'll tell Chaos.

Quote:

---

Originally Posted by Kornman00

You should also post a sample screen shot for people to gander at before downloading

---

For a second there I thought this thread was you updating OS_Tool. :(

my sensors are picking up a trojan banker when building a cache file

Quote:

---

Originally Posted by shadowslayer123

my sensors are picking up a trojan banker when building a cache file

---

What do you mean by that?
And Kornman, I'll update the main post with a screenshot of the program.

Try looking into loading\saving the batch jobs too. Maybe even as .bat files? That way when larger mod projects are under going tweaks of many data files (bitmaps, sounds, etc) they can easily just load up those batch jobs.

With that said, looks pretty cool :)

Thanks for the feedback Kornman00! That feature is actually very possible and would take a bit of tweaking in a few things here and there, but I can see it being accomplished given enough time.

Hopefully the next release will include this and more!

No problem :). Nice to see others taking interest in (tool) development for the game

Looking amazing, hope you make good progress for the rest of the stuff

Tool++ doesn't want to work for me at the moment so this would be p coo.

Thanks guys. I suggested the Guerilla layout because I figured it would be a familiar environment to work within for the end-user. Now, all we need are decent suggestions. Anyone have any ideas?

I thought this would be another Tool++ but this is quite unique. Good job :P

at first malwarbytes' anti malware said it had a trojan banker in it, but now it just says this: http://i37.tinypic.com/n2ltub.jpg bug perhaps?

Malware Anti-Bytes could have been referring to the program Tool # was trying to initialize. There are no viruses in Tool #, and for all I know, the only thing that could have triggered it would have been that I embedded the help file and it writes it as bytes to the hard drive, or the detection of the Tool files.

Try changing the selected Tool from the menu list at the top, and see what happens.

EDIT: Here's a Jotti scan of Tool #:
http://virusscan.jotti.org/en/scanre...5dc9da532e23bd

And here's a virus-scan of the toolpro.exe I'm testing for Tool #, which as you can see has been picked up by one AV to contain Trojan.Crypt.Gen, it is possible that we have the same version of Toolpro and your AV picked it up.
http://virusscan.jotti.org/en/scanre...377b77b1ec1bc7

The AV is alerting because of Process.Start()

now that i look at it, it said tool pro is the virus. i might have downloaded a bad version of it. can you upload yours for me so i can see if thats the problem?

oh and one more note, i see that normal tool is greyed out in the menu, but its right there in my halo ce folder

nice stuff

Quote:

---

Originally Posted by CrAsHOvErRide

The AV is alerting because of Process.Start()

---

If that was the case, Rambo's AV would have gone off like crazy when we were testing it and so would have mine.

As for my version of Toolpro, as you can see the AV says it has a Trojan as well, but I can upload it later on when the next release comes.

And the final bug of Tool not being enabled has to do with detection. Make sure it's an unmodified Tool.exe that has an MD5 hash of: 1f18ecb6f0acdcd0b0455aa4f7e06b73. The Filename won't matter because I don't do a check based on the filename (avoids major bugs that way)

You can easily check the hash of your tool.exe right here and make sure it matches with the one that I have. My tool.exe is the one installed with HEK, and that's how I base my detection function inside Tool #

Sure I can upload Toolpro for you. My build is clean. I used AVG to scan it and Chaos used Jotti to scan it. Virusbuster did find a Trojan Crypt in it but ignore it because it's proven harmless on our computers. It probably has to do with Kornman00's old hacks to the tool itself. We've never noticed any problems with our computers as a direct or indirect result of toolpro.

awesome thanks. but do you know why normal tool wont let you click on it in the menu?

I too have ran into Malwarebytes Anti-Malware detecting it as a Trojan.Banker, its the way Kornman packed the EXE's so that people wouldnt play around with them. (km00 note: and to require less files, ie dlls, to be tracked by end users)

It is not this, but I still recommend you checking, http://www.bitdefender.com/VIRUS-100...anker.LCG.html

I spoke to Kornman about this, its not really an issue, its definitely clean.

Looks like a Tool + Guerilla blend. Neat.

Thanks for all the replies guys. I just read what you (Limited) said about Toolpro. I'll place a warning message inside Tool # about it that certain Anti-Viruses might tag it and remove it, which will cause Tool # to error right now. As for the suggestion Kornman00 suggested (saving/loading of batch work), I have the class implemented and working for the bitmaps and structure dialogs, while lightmaps and the build-cache-file dialogs are recently being started.

I'm also adding models/collision forms, and implementation of the classes will come in there too. I'm hoping to have this done by Mid-November, but no promises since school and other things demand attention (You guys know how that works).

Please keep the feedback/suggestions coming!

Excuse the double post.
Just updated the main post to show that Build 121 has been released. With this build comes the feature that Kornman00 suggested: Saving/Loading of Batch Jobs.

On top of this new feature, there are several bug fixes that were scattered throughout the program, some minor, some that could cause the program to come crashing down (quite literally), and some just misc. fixes.

Any suggestions, feedback, bug reports, etc., are all welcome here and we hope you enjoy Tool #.

I didnt actually read original post, Kornman linked me to the error post I assumed it was OS stuff.

Great work on the tool :) I personally dont do much Halo mapping, but I love any new tools to help people out, I'll have a tinker and try to think of some new features :D

You should do this with OSTool some time. :D

Well guys, I have a lengthy post for you to read, so hope you got plenty of time :P

The next Tool # release will be in the Build 140's somewhere, not exactly sure at this point because we've done so many changes and builds to the program that it's insane.

The biggest feature is actually a dual combo feature:
1. Virtually instantaneous scan of your tags\ folder
2. The detection of shaders when compiling structure

Let me explain in details:
You know that when you compile a structure and you forget a shader, tool will ask you to make one directly inside it. Well, Tool # lacks the means to know when this happens and actually allow you to do so. To divert this kind of a lockup/error, We're taking matters into our own hands so Tool won't need to.

Basically, here's what happens.
Step 1: Tool # will open your JMS file and find the Materials List (This part has already been tried and succeeded without any errors)
Step 2: Tool # will then very quickly (Based on a benchmark, we found every shader in Rambo's tags\ in less than 3 seconds and he has over 1.8GB of files in his tags folder) find every possible shader that halo supports in your tags folder.
Step 3: Using the material name that Tool # gets from the JMS file, Tool # will loop through each possible extension, searching for a matching shader. If it doesn't find it for ANY at all, then we'll ask you to create one from a dropdown list of what the shader is supposed to be, and then place it in the appropriate shaders folder. Once done, it will loop for all materials found until it is done.
Step 4: Once done with all of this (this process cannot be stopped because you'll end up messing up the entire thing), we will then run Tool for you, with all the appropriate shaders in place for you!

That is the entire process summarized into extremely simple steps. The pragmatical logic behind it is extremely difficult, but we're getting there, closer after every test build.

The other feature is a work in progress, and is actually a program that's Internal to Tool #. It's a JMS Material Viewer (Soon to be Editor). What the program actually can do right now is just show you the Material Name, and the path to the original bitmap. What it will be able to do soon will be able to change these Material Names and path, set flags (such as is this a sky, portal, walkable, etc) via checkboxes, allow you to resave it back to the JMS so you don't ever need to reopen the model in 3DSMax/GMAX to fix a small error. The reason this is possible is because of how the JMS format is, which is quite literally plain text. Because of this, we can load portions of the code for reading purposes, store the rest in memory, and then resave it, inserting the new code where we need to. This will allow for editing of JMS files on the fly, solving so many problems that map makers can have with the JMS exporting.

We plan on releasing a stable build later on tonight if we can get the Structure-Shader handlers coded and working properly, but no promises!

Chaos and I have finalized the shader detection problem. It will not work on multiple JMS files though, but we will be fixing that later. For now, don't try and compile permutations using Tool #.

We are making a few fixes and tweaks to stuff we currently have implemented and then we will release a bug fix / upgrade release to the program. Expect it within the next few days or by the week-end.

We finished up Build 161 of Tool # just a few minutes ago (probably more like seconds, because it's uploading as I type this.)

There have been several feature changes, one of them has already been mentioned, which is the ability to detect your Materials List inside your JMS file, read them, then scan your tags directory for each material. In laymen terms, it prevents you from compiling a structure without creating the appropriate shaders.

Another feature is the ability to open your saved batch files without using the import option. This allows you to quickly reload your work and get back going.

Our last two features that I remember right now is the ability to cascade the windows, organize them horizontally, and then vertically via shortcut keys or the MenuStrip along the top. The other part is that the program will automatically remember your forms when you close the program, and reopen them automatically for you so if you accidentally closed the program while working, it will have them reappear for you.

The main post will be updated in a few seconds with the new link and an updated screenshot of the Main Window.

We would like some feedback on this build from you guys!

I don't know how hard this is but can you make it easy to edit string lists and ui hud messages?

Quote:

---

Originally Posted by Dwood

I don't know how hard this is but can you make it easy to edit string lists and ui hud messages?

---

Just use these:

http://hce.halomaps.org/index.cfm?fid=1049
http://hce.halomaps.org/index.cfm?fid=2874

I have a small update available for you guys...it's right here in this picture.

See that window? It's the latest feature available in Tool #. If you can't guess what it is, it will make any map maker's job easier. It took me quite some time, but I managed to not only be able to read a JMS file, but now I can recreate one with edited material names.

This will make life easier for mappers because you can now change properties of each material in the list using the available check boxes. Obviously, there will be built in limitations because you can't have a collision model and a render only one at the same time (that just defies physics!).

The program has proven to be extremely fast at reading a JMS file, reading nearly 100 different material names and their appropriate paths in less than one second, and writing them all in roughly 2 seconds (because I have to rewrite the original file around it).

You'll have to wait till we release the next build of Tool #, which will also include some new dialogs as well.

PS: For those of you who noticed, the window is different. It says "Debug Window" along the top, and for those that can find it, there's a debug form in your version too. However, it's hidden pretty well :), and includes a beta of the JMS reader.

Just to let you know, we are still working on this diligently, cleaning up code and adding new stuff in (such as this!). There will also be a dll of the JMS Reader/Writer so you can design your own GUI's around the dll in the framework.

Any questions, lemme know here!

Most impressive.

For shader symbols, consider adding an additonal combolist field called "Collision Attributes", where you have "None", "Render Only", "Collision" and then "Large Collidable". Since the user isn't suppose to check them at the same time, it would appear more natural in a single selection box (especially since they're all collision related anyway)

The same should go for the shader flags field, it should just be just like an enumeration field since you can only have one of them.

Also, consider moving the explanation detail text as a second text box in the explanation name pane (ie, "$$$ SHADER SYMBOLS $$$"). That's how the explanation fields work in the toolkit; they have a "title" (large font text) and a "description" (regular font text at the bottom)

All that considered, it should shorten up the editor form a good deal so you don't need as much consumable view space to view it all.

Ok, here's a new update to the look of the Material Editor:
http://i35.tinypic.com/33kyd1x_th.png

It fully works as well, able to save and load the entire list really fast. We did a count on Blood Creek and it loaded over 100+ Materials in less than a second, and resaving it was really fast too.

Any suggestions are welcome.

Unearthing an old topic to bring some news.
Tool # is still being developed for those that use it. I've been taking my time, making sure everything inside it works perfectly.
The next release I'll hand you will not add new task abilities, but it does add a new GUI entirely: The Simple Interface. It looks nothing like Guerilla does, going for a more simplistic approach:
http://i47.tinypic.com/2ugjae8_th.png

Most people would probably use just two or three of those buttons.

On top of this, I've been doing several bugfixes for the Guerilla Theme. Can't really say bugfixes because I've rewritten them entirely (well one at this point) and even added a new feature to the bitmaps: Detecting each bitmap and making sure they're valid textures. How so? Most of you know this, but for those that don't, halo's engine takes textures that has dimensions from a power of 2. Basically, the number, when divided by 2 enough times will result in 2. If any bitmaps fail, the path will stay red, and you can view these error messages by right clicking the box and hitting "Error Details". Things like this to enhance the ease of using Tool # and making map making easier to do overall.

I hope to have this done tonight, but if not, I'll probably make a release before the end of February if I'm happy with how things look.

It's been a long time since I posted and I apologize. If anyone is still interested in this program being complete, I'd like to know. School work caught up to me and lack of motivation kind of killed out any progress that was made, not to mention I have to restart on it (the last source code I've been able to find is pretty old and buggy). The Simple Interface needs to be restarted, same with the Guerilla Interface. I wish I didn't have to restart, but it's unavoidable. For those who are interested, bear with me, I'll get a solid release out there sometime soon.

I'm ready to give you guys a beta release of Tool #. It had to (unfortunately) be restarted since all the good code I had was lost :saddowns:

Here's what's wrong:

• Lightmaps & Build Maps are broken
• Batch Classes are not working either (Can't save/load/import stuff)
• Only supports Tool.exe and Toolpro.exe (theoretically Toolpro, haven't tested)

Here's the good stuff:

• Forms have individual handles now, rather than relying on global variables
• Individual windows have their own menu bars for controlling options on that window.
• Tool output is a bit more reliable now
• Shader detection is properly fixed and will prompt you if you're missing shaders.
• Bitmaps are checked for valid image dimensions (slightly buggy still). You can also view your bitmaps by clicking the "View" button on the Bitmaps form.
• The tag folder is scanned at runtime and can be refreshed by either going to Options -> Refresh Tags, or Ctrl + F5. Also, when a tag is manually placed/created by Tool #, it is added to the internal shader list (to save time from rescanning).
• Got a fancy facelift.

I probably missed a few things, but whatever. If you want to try it out, just place the EXE and DLL in the root Halo Directory.

Download it here

How did I miss this :o

very nifty, tho when you go to view your bitmaps, the displayed image is full size, when you preview an image, it shows all of it, a shrunk image. you might want to fix that. Also, load button don't do anything

I always wondered how ppl do the Guerilla UI...did I miss something?

@Killa, I said that the batch class is broken and saving and loading won't work. So that's why they do nothing, sorry.

@Crash: It takes a lot of work :|