UserTool - OpenSauce command line tool

Quote:

---

Originally Posted by Readme

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 :downs:.

>> 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!!

Update 27-01-10
New build available with some changes and some new commands :downs:
>>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.

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

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

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.

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 :-3

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

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.

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.

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*--//".

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.

Dees dreams have come true.

I redid a number of vertex shaders in hlsl. I have yet to figure out how pixel shaders will work (mainly because scythe didn't redo any one that takes more than 5 sasm lines :P) these may be all the ones that I rewrote however I don't think so.... Anyways; here:

convolution:

//--vs_2_0--//

float4 Unknown_c13 : register(c13);
float4 Unknown_c14 : register(c14);
float4 Unknown_c15 : register(c15);
float4 Unknown_c16 : register(c16);
float4 Unknown_c17 : register(c17);
float4 Unknown_c18 : register(c18);
float4 Unknown_c19 : register(c19);
float4 Unknown_c20 : register(c20);

struct vs_in
{
float4 Position : POSITION;
float4 texcoord : TEXCOORD0;
float4 color : COLOR;
};

struct vs_out
{
float4 Position : POSITION ;
float4 Tex0 : TEXCOORD0 ; // TILING, WOMAN.
float4 Tex1 : TEXCOORD1 ;
float4 Tex2 : TEXCOORD2 ;
float4 Tex3 : TEXCOORD3 ;
};


void main(in vs_in IN, out vs_out OUT)
{
OUT.Position = IN.Position; //^^^^^
OUT.Tex0.x = 2 * mul(IN.texcoord, Unknown_c13); //waves- shift makes it look like it's waving as in real water
OUT.Tex0.y = 4 * mul(IN.texcoord, Unknown_c14); //water
OUT.Tex1.x = 5 * mul(IN.texcoord, Unknown_c15); //water
OUT.Tex1.y = 5 *mul(IN.texcoord, Unknown_c16); //water
OUT.Tex2.x = 1.4 * mul(IN.texcoord, Unknown_c17); //not water?
OUT.Tex2.y = 2 * mul(IN.texcoord, Unknown_c18);
OUT.Tex3.x = 1.35 * mul(IN.texcoord, Unknown_c19);
OUT.Tex3.y = 1.25 * mul(IN.texcoord, Unknown_c20);
};


// vs_1_1
// dcl_position v0
// dcl_texcoord v4
// dcl_color v9
// mov oPos, v0 //^^^^^
// dp4 oT0.x, v4, c13
// dp4 oT0.y, v4, c14
// dp4 oT1.x, v4, c15
// dp4 oT1.y, v4, c16
// dp4 oT2.x, v4, c17
// dp4 oT2.y, v4, c18
// dp4 oT3.x, v4, c19
// dp4 oT3.y, v4, c20
// approximately 9 instruction slots used

My re-written one does some modifications to make water more visually pleasing. Try it out in Beavercreek.

decal.hlsl:

//--vs_2_0--//

float4x4 WorldViewProjection : register(c0);
float4 Unknown_c6 : register(c6);
float4 Unknown_c9 : register(c9);
float4 Unknown_c10 : register(c10);

struct vs_in
{
float4 Position : POSITION;
float4 color : COLOR;
};

struct vs_out
{
float4 Tex0 : TEXCOORD0;
float4 Dif0 : COLOR;
float4 Position : POSITION;
};

void main (in vs_in IN, out vs_out OUT)
{
OUT = (vs_out)0;
OUT.Position = mul(IN.Position, WorldViewProjection);
OUT.Tex0.xy = IN.color;
OUT.Dif0 = Unknown_c10;
float3 temp_r8;
temp_r8.z = mul(IN.Position, Unknown_c6);
temp_r8.z -= IN.color.w;
temp_r8.z *= Unknown_c9.x;
}


// vs_1_1
// dcl_position v0
// dcl_color v4
// dp4 oPos.x, v0, c0 //
// dp4 oPos.y, v0, c1 //
// dp4 oPos.z, v0, c2 //
// dp4 oPos.w, v0, c3 //
// mov oT0.xy, v4
// mov oD0, c10
// dp4 r8.z, v0, c6
// min r8.z, r8.z, v4.w
// mul r8.z, r8.z, c9.x
// approximately 10 instruction slots used

environment_fog.hlsl- I'm not 100% sure I rewrote this one. I think I did though. If not, scythe let me know lol!

float4x4 WorldViewProjection : register(c0);
float4 Unknown_c6 : register(c6);
float4 Unknown_c7 : register(c7);
float4 Unknown_c8 : register(c8);

struct vs_in
{
float4 position : POSITION;
float4 normal : NORMAL0;
float4 binormal : BINORMAL0;
float4 texcoord : TEXCOORD0;
float4 tangent : TANGENT0;

};

struct vs_out
{
float4 Position : POSITION;
float4 Tex0 : TEXCOORD0;
float4 Tex1 : TEXCOORD1;
};

void main(in vs_in IN, out vs_out OUT)
{
OUT.Position = mul(IN.position, WorldViewProjection);
OUT.Tex0.x = mul(IN.position, Unknown_c6);
OUT.Tex0.y = IN.texcoord.z;
OUT.Tex1.y = mul(IN.position, Unknown_c7);
OUT.Tex1.x = mul(IN.position, Unknown_c8);
}


// vs_1_1
// dcl_position v0
// dcl_normal v1
// dcl_binormal v2
// dcl_tangent v3
// dcl_texcoord v4
// dp4 oPos.x, v0, c0
// dp4 oPos.y, v0, c1
// dp4 oPos.z, v0, c2
// dp4 oPos.w, v0, c3
// dp4 oT0.x, v0, c6
// mov oT0.y, v4.z
// dp4 oT1.y, v0, c7
// dp4 oT1.x, v0, c8

// approximately 8 instruction slots used

lens_flare.hlsl

//--vs_2_0--//

float4x4 WorldViewProjection : register(c13);
float4 Unknown_c18 : register(c18);

struct vs_in
{
float4 Position : POSITION;
float2 texcoord : TEXCOORD0;
float4 color : COLOR;
};

struct vs_out
{
float4 Position : POSITION;
float4 Tex0 : TEXCOORD0;
float4 Diff : COLOR0;
float4 Spec : COLOR1;
};

void main(in vs_in IN, out vs_out OUT)
{
OUT = (vs_out)0;
OUT.Position = mul(IN.Position, WorldViewProjection);
OUT.Tex0.xy = IN.texcoord;
OUT.Diff = IN.color;
OUT.Spec.w = Unknown_c18.x;
}
// vs_1_1
// dcl_position v0
// dcl_texcoord v4
// dcl_color v9
// dp4 oPos.x, v0, c13
// dp4 oPos.y, v0, c14
// dp4 oPos.z, v0, c15
// dp4 oPos.w, v0, c16
// mov oT0.xy, v4
// mov oD0, v9
// mov oD1.w, c18.x

// approximately 7 instruction slots used

If someone figures out what those registers are holding, by all means, let us know as for now I'm just shooting in the dark trying to fish out what they do.


Add each one individually and compile with usertool.

Halo1 Mac and Stubbs the Zombie Mac/Xbox have the source shaders included in the install. Looking at Hal1 Mac's VSH sources would probably help. I'm not sure if I would be allowed to post them or not

Quote:

---

Originally Posted by Kornman00

Halo1 Mac and Stubbs the Zombie Mac/Xbox have the source shaders included in the install. Looking at Hal1 Mac's VSH sources would probably help. I'm not sure if I would be allowed to post them or not

---

I don't think that the devs would care... my main problem is figuring out what values are being held in the registers anyways.

Last night because I was bored doing homework I took turns doing the water reflection shader and Pre-Cal I did transparent_water_reflection. Gives the water a neat effect as-is however removing my modifications makes it look normal so dun u worry that hlsl screwed it up. :)

I also tried the shader changes in Revelations, and the water looks p. cool, hope ya'll like:

shader_transparent_water_reflection.hlsl:

//--vs_2_0--//
float4x4 WorldViewProjection : register(c0);
float4 Unknown_c4 : register(c4);
float4 Unknown_c6 : register(c6);
float4 Unknown_c10 : register(c10);

struct vs_in
{
// dcl_position v0 //
float4 position : POSITION;
// dcl_normal v1 //
float4 normal : NORMAL0;
// dcl_binormal v2 //
float4 binormal : BINORMAL0;
// dcl_tangent v3 //
float4 tangent : TANGENT0;
// dcl_texcoord v4 //
float4 texcoord : TEXCOORD0;
};
struct vs_out
{
float4 position : POSITION;
float4 Tex0 : TEXCOORD0;
float4 Tex1 : TEXCOORD1;
float4 Tex2 : TEXCOORD2;
float4 Tex3 : TEXCOORD3;
float Fog : FOG;
};
void main(in vs_in IN, out vs_out OUT)
{
float3 temp_r5;
float3 temp_r8;
temp_r5.xyz = -IN.position + Unknown_c4;
OUT.position = mul(IN.position, WorldViewProjection);

OUT.Tex0 = IN.texcoord * Unknown_c10.xyyy + Unknown_c10.zwww;

OUT.Tex1.x = IN.tangent.x; //v3
OUT.Tex1.y = IN.binormal.x; //v2
OUT.Tex1.z = IN.normal.x; //v1

OUT.Tex2.x = IN.tangent.y; //v3
OUT.Tex2.y = IN.binormal.y; //v2
OUT.Tex2.z = IN.normal.y; //v1

OUT.Tex3.x = IN.tangent.z;
OUT.Tex3.y = IN.binormal.z;
OUT.Tex3.z = IN.normal.z;

OUT.Tex1.w = temp_r5.x;
OUT.Tex2.w = 0 * temp_r5.y; //Nulls effect to isolate what each does
OUT.Tex3.w = 0 * temp_r5.z; //If you want it to look normal, remove the multiplication

temp_r8.z = mul(IN.position, Unknown_c6);
OUT.Fog = IN.texcoord.w - temp_r8.z;
}


// add r5.xyz, -v0, c4
// dp4 oPos.x, v0, c0
// dp4 oPos.y, v0, c1
// dp4 oPos.z, v0, c2
// dp4 oPos.w, v0, c3
// mad oT0.xy, v4, c10.xyyy, c10.zwww
// mov oT1.x, v3.x
// mov oT1.y, v2.x
// mov oT1.z, v1.x
// mov oT2.x, v3.y
// mov oT2.y, v2.y
// mov oT2.z, v1.y
// mov oT3.x, v3.z
// mov oT3.y, v2.z
// mov oT3.z, v1.z
// mov oT1.w, r5.x
// mov oT2.w, r5.y
// mov oT3.w, r5.z
// dp4 r8.z, v0, c6
// add oFog, v4.w, -r8.z
// approximately 20 instruction slots used

I just ate a vanilla caramel drumstick

was orgasmic

Quote:

---

Originally Posted by Kornman00

I just ate a vanilla caramel drumstick

was orgasmic

---

I love you like a brother Kornman.

And I love you like a mother...


Dwood :allears:

Must spread rep. lol. Anyways I completely failed in my attempt to rewrite the active camo. Well it works, but it works a little... too well. The player is totally invisible.

Thanks kornman, those shaders should provide some good insight. Just to be sure poeple know, the shaders are written for OpenGL(?) so won't directly compile with usertool, some conversion is still necessary :).

Quote:

---

Originally Posted by Dwood

Anyways I completely failed in my attempt to rewrite the active camo. Well it works, but it works a little... too well. The player is totally invisible.

---

When rewriting rigged model vertex shaders i'd advise using a map that is basically a box at point 0,0,0 as thats where the verts end up (in object space) if the skinning code and/or WVP are incorrect.

np

There's also the Halo PC Beta vsh\fx shaders which I don't think changed until retail...but uhhhhh yeah. Not gonna post those ;x.

Quote:

---

Originally Posted by FireScythe

Update 25\02\10[*]

• 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.

---

Do the custom lightmaps still work if the d3d9.dll is not used? Similar to how the maximum BSP increase still works without the DLL? I ask because I'd love to have custom lightmaps for a map, but I don't really want to have every user install the d3d9.dll. And I also don't want to install Boost, open sauce, and the DirectX redist just to find out that I need the DLL to use custom lightmaps.

Yes. The lightmap UV replacement doesn't have anything to do with Open Sauce, it changes the lightmap UV's in the BSP tag itself so there is no dependence on extra files. You also don't need boost, DirectX SDK, etc. if your just using UserTool. You only need those if you are developing for it.

That's perfect! Thanks!

I'm making a lightmapping tut, permission to include this in the tutorial files?

You should link to this thread since usertool gets updated/changed on occasion.

ok.

usertool - version 00.01.03
Unable to locate HEK directory.

failed to find tags and/or data directories.

Could that be because it cannot find my registry for Halo CE?

It should be in your hce root directory.

It is. How else would I be running it lol

User tool uses the HEK registry entries so that's probably your issue. Add them or re-install

Okay, so I'm running into the same problem CodeBrain had. He theorized that the tool was looking at the x64 path, not the x86 path. Both of us are running 64 bit systems, so that would make sense. However, I have no clue how to fix this issue. Any ideas? Would be really nice to be able to import custom uvs.

Code:

---

0041E0F9  LEA ECX,[LOCAL.70]
0041E0FD  PUSH ECX
0041E0FE  PUSH 20019
0041E103  PUSH 0
0041E105  PUSH OFFSET 004253A4                                  ; ASCII "SOFTWARE\Microsoft\Microsoft Games\Halo HEK"
0041E10A  PUSH 80000002
0041E10F  CALL DWORD PTR DS:[<&ADVAPI32.RegOpenKeyExA>]

---

My registry path was default: "SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft Games\\Halo HEK". I am running Windows 7. Regardless of where your Halo Custom Edition directory is installed or whether it's x86 or x64, the registry entry it opens may be incorrect. Since UserTool must be placed in the Halo CE directory anyway, may I suggest using GetCurrentDirectory or GetModuleFileName to obtain the path? Otherwise you may need to check multiple registry paths.

Quote:

---

Originally Posted by Skarma

Code:

---

0041E0F9  LEA ECX,[LOCAL.70]
0041E0FD  PUSH ECX
0041E0FE  PUSH 20019
0041E103  PUSH 0
0041E105  PUSH OFFSET 004253A4                                  ; ASCII "SOFTWARE\Microsoft\Microsoft Games\Halo HEK"
0041E10A  PUSH 80000002
0041E10F  CALL DWORD PTR DS:[<&ADVAPI32.RegOpenKeyExA>]

---

My registry path was default: "SOFTWARE\\Wow6432Node\\Microsoft\\Microsoft Games\\Halo HEK". I am running Windows 7. Regardless of where your Halo Custom Edition directory is installed or whether it's x86 or x64, the registry entry it opens may be incorrect. Since UserTool must be placed in the Halo CE directory anyway, may I suggest using GetCurrentDirectory or GetModuleFileName to obtain the path? Otherwise you may need to check multiple registry paths.

---

This is actually quite simple to fix, however the fix I am about to give really only changes the registry usertool tries to find: the x32 Halo HEK registry, and instead makes it look for the x64 directory.

I was going to make a small tutorial on how to do this yourself, but because of how FireSythe has his project folders and directories set up (He has the directories/folders on another hard drive of some kind, I had to use my flash drive to make it look there. I even placed all the files exactly the way he had it, and Visual C++ still told me it couldnt find the files, even though it was sitting in front of it's stupid face.) I cannot accomplish that. I did however make a successful exe a while ago, and I have no idea what caused it to not work anymore.

Anyway, enough rambling, here is the exe I promised.

http://www.codebrainshideout.net/files/usertool_x64.exe

The odd thing is it was developed and tested on x64 since that's what I use. When I get the chance i'll change it to use the current working directory rather than the registry path.

Yeah, the usertool_x64.exe gets the same error for me, thanks though CodeBrain. Guess I'll have to wait for Firescythe's fix.

Add some more error checking so the app can spit out the exact error codes from failed functions, might help work out the kinks

Oh derp I forgot to give you guys the .reg file as well. <_>

http://codebrainshideout.net/files/Halo_HEK_x64.reg

If you install the Halo Editing Kit on a x64 bit machine, I think usertool tries to look in the x32 registry instead of the x64 registry. Therefore, the solution is to copy what the x64 registry for "Halo HEK" has and import it into the x32 bit. The file above is the solution. (I think)

Drat. Still gives that error. Does it work on your end?

And I'm testing it by typing in usertool_x64.exe, then seeing if it gives a list of commands, like tool does. Instead, it gives back that error. If I need to type an actual command, let me know. I couldn't figure out what exactly that command was, honestly.

@Siliconmaster: Try this fix I cooked up, works great for me now. It uses a different method other than the registry to get your Halo CE working directories. Just don't forget to put it in your Halo CE folder before running it. You may need to run as admin, but it worked without that for me.

usertool with fixed paths problem:
http://www.mediafire.com/?9yjwp1i4vqqt3rc

Changed:

Code:

---

004376CF  LEA ECX,[ESP+14]
004376D3  PUSH ECX
004376D4  PUSH 20019
004376D9  PUSH EBX
004376DA  PUSH OFFSET 00449CD0                              ; ASCII "SOFTWARE\Microsoft\Microsoft Games\Halo HEK"
004376DF  PUSH 80000002
004376E4  CALL DWORD PTR DS:[<&ADVAPI32.RegOpenKeyExA>]
004376EA  TEST EAX,EAX
004376EC  JNE 0043796B
004376F2  LEA EDX,[ESP+18]
004376F6  PUSH EDX
004376F7  MOV EDX,DWORD PTR SS:[ESP+18]
004376FB  LEA EAX,[ESP+78]
004376FF  PUSH EAX
00437700  LEA ECX,[ESP+24]
00437704  PUSH ECX
00437705  PUSH EBX
00437706  PUSH OFFSET 00449CFC                              ; ASCII "EXE Path"
0043770B  PUSH EDX
0043770C  MOV DWORD PTR SS:[ESP+34],1
00437714  MOV DWORD PTR SS:[ESP+30],104
0043771C  CALL DWORD PTR DS:[<&ADVAPI32.RegQueryValueExA>]
00437722  MOV EAX,DWORD PTR SS:[ESP+14]
00437726  PUSH EAX
00437727  CALL DWORD PTR DS:[<&ADVAPI32.RegCloseKey>]

---

To:

Code:

---

004376CF  PUSH EAX
004376D0  PUSH 104
004376D5  MOV ECX,DWORD PTR DS:[<&KERNEL32.GetCurrentDirectoryA>]
004376DB  CALL ECX
004376DD  TEST EAX,EAX
004376DF  JE 0043796B
004376E5  JMP SHORT 0043772D
004376E7  NOP
004376E8  NOP
004376E9  NOP
004376EA  NOP
004376EB  NOP
004376EC  NOP
004376ED  NOP
004376EE  NOP
004376EF  NOP
004376F0  NOP
004376F1  NOP
004376F2  NOP
004376F3  NOP
004376F4  NOP
004376F5  NOP
004376F6  NOP
004376F7  NOP
004376F8  NOP
004376F9  NOP
004376FA  NOP
004376FB  NOP
004376FC  NOP
004376FD  NOP
004376FE  NOP
004376FF  NOP
00437700  NOP
00437701  NOP
00437702  NOP
00437703  NOP
00437704  NOP
00437705  NOP
00437706  NOP
00437707  NOP
00437708  NOP
00437709  NOP
0043770A  NOP
0043770B  NOP
0043770C  NOP
0043770D  NOP
0043770E  NOP
0043770F  NOP
00437710  NOP
00437711  NOP
00437712  NOP
00437713  NOP
00437714  NOP
00437715  NOP
00437716  NOP
00437717  NOP
00437718  NOP
00437719  NOP
0043771A  NOP
0043771B  NOP
0043771C  NOP
0043771D  NOP
0043771E  NOP
0043771F  NOP
00437720  NOP
00437721  NOP
00437722  NOP
00437723  NOP
00437724  NOP
00437725  NOP
00437726  NOP
00437727  NOP
00437728  NOP
00437729  NOP
0043772A  NOP
0043772B  NOP
0043772C  NOP

---

and not only that, the app is also 20 bytes faster congratz :allears:

All right, Skarma fixed the issue for me, though he initially fixed the earlier version of usertool, not the most updated one. However, now the app itself is giving me crap lol. Max exports the 22 lightmaps as a single .obj file. But when the app tries to import the uvs, it says that the bsp has 295 objects. Wat. How do I fix this?

This line of code is just backwards.
obj group count = 295
lightmap count = 22

Code:

---

Console::AddFormattedText("obj group count (%i) does not match bsp lightmap count (%i)", bsp.lightmaps.element_count - 1, obj_file.groups.Count);

---

I think your obj format is not compatible with UserTool.

Yeah, turns out max was exporting everything, not just the lightmaps. This time I used the "export selected" option. :downs: Imported the uvs fine, just need to make sure they match the lightmaps ingame.

And they do. Yay. Pics in a bit.

Doublepost for importance, also posted this in the Precipice thread.:

Thanks to Skarma, usertool now works on my computer. The first import tests have been very successful, but I've been seeing a few very odd glitches. I think the importer may be modifying the level uvs as well, resulting in bizarre uv errors that were NOT there before. I managed to recover it from the ingame build, but just barely.

Edit: Confirmed. Prior to the import, the uv error was not there.