UserTool - OpenSauce command line tool

[FireScythe]

UserTool: Open Sauce multifunctional command line tool
By TheFieryScythe
Usertool is a command line program that Open Sauce developers can use to provide a familar tool-like way to manipulate tags, or for any other purpose they may need.

Using UserTool:
If you know tool then you already know how to use it. Open up a command prompt and navigate to wherever usertool is located. Type 'usertool' and hit enter to list all of the commands that are available. If you are unsure as to what a particular command will do, type 'usertool *the command*' and it will print the command with a short description about what it does. Once you know what command you want to use type 'usertool *the command* *arguments*' and the command will do its stuff.

Developing for UserTool

Prerequisites:

1. Boost C++ library - http://www.boost.org/
2. Open Sauce V2 - http://www.modacity.net/forums/showthread.php?t=17758
3. Latest DirectX redist - http://www.microsoft.com/downloads/d...displaylang=en

Obviously you will need to change the include directories to match your file setup.

I've tried to keep the coding for usertool as similar to OS code as I can so its simpler to switch between the two. To add a command to usertool you simply add your own namespace and then put the function that your command will call inside it. You then add a COMPONENT macro to the components array in Main.cpp and fill in the function, name, description, etc. sections.

There are a few namespaces included that handle some things for you:

• ErrorPool - holds a list of error strings that you add to when your code has a problem, which then get output to the console and saved to debug.txt before the program closes.
• DebugOutput - Use this to output messages to the console and to manually add messages to debug.txt.
• Direct3D - Use this namespace to create and destroy a Direct3D device should you need it.

As this is mainly intended for manipulating custom tags, i've put together a basic tag interface namespace that you used to build, load and save your tags. An example of which can be found in the shader_post_process tag included. There may be circumstances where it might not work with more complex tags but those bridges will be crossed when we jump off them.

Readme says it all really, its a tool-like command line tool for OS developers to add commands to. If your not developing anything for OS and not putting any post processing effects into your maps then this isn't going to be of any interest to you .

>> Download <<

Current commands:

• test-post-process - Takes a shader_post_process tag as its argument and check it to see if it's HLSL is valid and compiles correctly. Does not change the tag.
• compile-post-process - Takes a shader_post_process tag as its argument and if the HLSL is valid, it will compile it to a binary format and save that to the tag. This WILL remove the HLSL code from the tag, so use it at your own risk!!

[FireScythe]

Update 27-01-10
New build available with some changes and some new commands
>>Download<<

Changes:

• Replaced ErrorPool and DebugOutput with a single Console namespace which records all text put to the console and writes it to debug.txt if a function fails.
• Removed handle checking from test\compile-post-process functions as it was causing a crash.

Added:

• New function "os-bitmaps". os_bitmap is a new tag i've made to provide an easy way of getting bitmaps from the map cache, and this function creates either one bitmap from one image, many bitmaps from a directory of images, or a single bitmap from a directory of images.
• New functions "compile-custom-ps" and "compile-custom-vs". I have decompiled and saved all of halo's vertex and pixel shaders to a number of text files. These functions allow you to edit those shaders and compile them into two files, "vs_replacements.vsr" and "ps_replacements.psr", which when used in conjunction with the current post processing build will replace Halo's shaders with your edited ones. The decompiled shaders can be found >>here<<. Extract the folders to your shaders directory.
• Added a console command "-listfull" which will list all commands and their descriptions.

[Kornman00]

In PostProcess.cpp, I think the CheckHandles error may stem from the tag_string pointer. Verify that pointer magic you use for the pName parameter. Since tag_string is really just a "char value[31+1];" type you should just be able to pass as is (except with just a single dereference since it is a tag_string* in your CheckHandles code).

Also, you may want to verify your tag_string TagInterface code. Make sure that it properly terminates the string data (ie, some_tag_string[32] = '\0') after loading and before saving. I think I may have originally annotated that tag_string was 32 characters but later updated code to treat it as 31 characters (thats the true count, it uses a zero-terminator). I failed to go back and update the documentation though.

The documentation says that the GetParam function is suppose to return NULL if the shit is invalid, but that's probably under the assumption that pName is a proper string pointer :P

Still looking at the rest of the code

[FireScythe]

The GetParameter function exceptions no matter what gets passed to it, even plain old "foobar". So i'm not sure whats wrong there .

Fair point on the tag_string IO, code now forces the null terminator when saving and loading.

On an unrelated note, i've made a change to the custom shader compiler that will allow replacement shaders to be written in HLSL rather than just shader assembly. So that will be coming soon.

[Kornman00]

Have you tried setting your DX setup to debug and see if it provides any extra information? That sounds really odd.

I'm currently scheduling the next 4 to 5 months in terms of Kornner Software developments. Depending on how that goes, how far you're able to get with this, and when I'll get a decent test computer again, maybe I'll get to finalize OpenSauce 2 and include this. Since this is adding to the engine, be sure to plan your designs accordingly for any possible future endeavors as this entire (OpenSauce) setup is far from version friendly. Personally, I'd try to keep most things tag and cache based, but when it comes to user configuration, it's kind of hard to ignore letting the user define their own skeeters and tweeters

[FireScythe]

Turns out that crash only occurs when linking to the d3dx9d.lib, so it would have been fine in release .

Which project are you looking to include? Whichever one (or both), i'm not looking to add much more functionality at the moment, just trying fo fix bugs and polish things up, although I haven't planned anything so far so i'll have to see how it goes.

[Kornman00]

Any and all of your code if possible. I'll contact you a month before things are bolted down on my end to leave room for integration.

[FireScythe]

Update 06\02\10
>>Download<<

Changes:

• Tag field values are now references, not pointers. So dereferencing is no longer required when using the values.
• Post process component has been updated to account for changes to the shader_post_process tag definition.
• Shader replacement component can now compile shaders that are in either assembly format or HLSL.
• D3DX errors are now parsed better.
• Boost::filesystem::path is now used whenever file paths are used because its cool shit.
• Component descriptions have been moved to the component cpp files since Main was getting a bit crowded.

The shader replacement component no longer uses the .txt extension. For assembly shaders the file extension is .sasm and HLSL file use .hlsl. All exported shaders are now included in the post processing build >>here<<, with an example shader thats been converted to HLSL included. Because of the HLSL inclusion the compile-custom-** commands now require a default shader profile which can be found in the command descriptions, however to define a different shader profile for each shader you can put a comment at the top of the shader to define which shader profile you want to use, "//--*shader profile*--//".

[FireScythe]

Update 25\02\10
>>Download<<

Changes:

• Tag structs now require a char string id so that should an error occur the block type can be printed to the console/debug for easier debugging.
• TagBase now requires a tag version;
• No longer necessary to declare pads in the struct, they are now added in the constructor.

Added:

• DynamicArray's and tag block elements can now be accessed with [index]'s.
• Fully mapped out scenario_structure_bsp definition.
• PackedFile object to create a data file with a generic struture that can be easily read by OS.

Fixed:

• Data fields were being loaded incorrectly when in nested blocks. Data is now loaded correctly.

Two new commands have been added this build:

• pack-files - Takes a directory of files and packs them into one file that OS can use.
• import-lightmap-uv - Replaces the lightmap UV's of a single bsp with those read from a matching obj file.

For the lightmap UV replacement you should wait until you have completely finished your BSP as tool can create different lightmap surface arrangements each time you run lightmaps so an obj created with an older bsp might not match a newer one, and you don't want to re-uv the bsp everytime you make a change. Also, you should ONLY change the UV's as changing the mesh can break the surface ordering and will cause problems. The workflow for using this with Aether would be:

1. Finish the BSP completely.
2. Export lightmaps with Aether.
3. Re-UV the lightmaps and import.
4. Recreate your Aether project and export everything again.
5. Do your Max/Maya lighting as normal.

I can't guarantee every obj file format will work so if you have problems let me know.

[Dwood]

Dees dreams have come true.