Remnantmods

Here's the newest release of the MOPP disassembler (v1.2): http://www.remnantmods.com/archive/misc ... -Deasm.rar

*v1.2* Header now shows MOPP code size and unknown value is now listed as scale factor (value = 255^3 / scale)



Included in the rar file is a file called MOPPListing.txt
It should be fairly striaght forward for those who would like to help discover the OpCodes that are incorrect or whatever.
I know there are some missing and some I didn't encorporate correctly. I haven't began to try and decode the SHARED.MAP yet, just get this part done.
The triangle selection OpCodes are incorrect, but I will work on that soon hopefully.

For the <Auto> features to work, it will read the size from the header, but the Offset will only work if you have the .xml file that is generated when you save the meta. Otherwise, here's an easy method to get it (shown for sbsp):

So what does the MOPP Do?

Player collision on the bsp mesh. It doesn't effect grenades being thrown at the map or visual characteristics.

(From what I barely understand) The MOPP takes in a point on the map and returns either the triangle at that point or a list of triangles at that point (discussion seems to still be unsure of which it is). This way, instead of performing collision tests on all the sections of the map, you perform a raytrace through the MOPP and it will tell you which triangle(s) you intersect with and then I think they perform an intersection routine on the triangle/list to verify maybe?
Also, from what I've read because of the way it works, every bsp / phmo triangles are listed somewhere in the MOPP. I am going to replace some OpCodes in the shared with 0xCD (I am assuming NOP codes) and see if certain sections lose player collision. I know need to actually look at the codes to try & determine what they do (just been writing the program & re-reading the other forum up until now)

EDIT: Interesting link I just found:
http://transporter-game.googlecode.com/ ... lide/Mopp/

So you are trying to disassemble this MOPP code that is stored in its executable output format in each map? And the idea is that if you can crack the MOPP code generation, then we can generate it for BSPs of our own design, if even very simplified ones? Just trying to understand the bigger picture. I did not know each map contained another sub-language of executable code in it, but then there are many things I don't know.

You would do well to lure neodos out of retirement for help with this. He is the Michael Faraday of H2 modding.

Kinda like that. ATM this may be more for my own learning as it looks like "the others" have used ?Havok? code to create a 3dsmax/blender/etc plugin that will output the mopp code for you. We may be able to use this and just add the H2 header section to it.

However, knowing more about the way the collision & such works, makes me realize that more important than mopp is bsp visual mesh injection. It's useless trying to add mopp if you can't have a visual mesh.

So after looking through the codes some more, found a big issue. The triangles have an offset variable that would've had no way of being used, so I updated the code & the mopp listing to reflect the changes. Now Shared actually lists at least triangle 0 & 1 as collision points in the code. Also added a Cancel button (if you decide you don't wish to wait for some of the larger mopps to fully decode) as well as a more intuitive progress bar (yellow=working, green=finished okay, red=error). Also threw a cheapy icon on instead of the white box and added a more generic listing of the unknown (4 bytes) in the header.

Anyways, if someone actually looked at this before and it made no sense, this should clear things up a bit. Still need to work on the OpCodes though.

Havok has offered its Physics SDK (for PC) as a free download on their site for many years now. While diassembling the hkMoppMachine.obj file may provide insight, there's a chance that today's SDK doesn't use the same internal encoding as Havok 2.x, which is what H2 used.

To pick up the MOPP discussion from here: viewtopic.php?f=85&t=2303&p=37019#p36988 in a more appropriate thread, I just tested on midship. Moved all spawns onto the midship_platform_crate and set the MOPP reflexive count to 16 => still works fine. Nulled each of those 16 values (value 205 / 0xCD) and now the map loses all player collision (bullet & grenades still work). Gonna experiment with why it still had collision before. I am thinking that it ignores the MOPP size and just looks for a NOP (or series of NOP) code(s) to exit.

Also, I believe I originally took the known codes from the oblivion ones here:
http://niftools.sourceforge.net/wiki/Nif_Format/Mopp

*Updated MOPP disassembler to v1.2 (very minor update)

The MOPP info from the above listing seems to line up with Halo 2 MOPP data from what I've seen. I think H2 also uses some other codes that Oblivion doesn't use (or just never got decoded). Either way, I think that we could use NifTools MOPP generator to create unoptimized H2 MOPP data from what I've seen so far. Right now the biggest hurdle I think would be creating a BSP tree for the visual mesh so the map doesn't lag out.

Would the lag be due to the mathematical complexity of rendering a 3D surface at several distances and angles? Sorry, I'm a graphics noob. Where I'm going is that you could start with a simple plane and incrementally add topology to see where the tipping point is when there is no optimization. Or set the rendering radius fairly small and fill the map with fog or obstacles to compensate.
Foundation, Warlock, Beaver Creek, Desolation all seem like "simple" BSPs. Would they be too complex without optimization?

The rendering of a 3D surface is fairly straight forward, the lag comes from trying to render to much at once.

The BSP tree is used for Occlusion Culling, which means it is used to find which parts of the BSP are visible and render them, thus ignoring the parts that are not visible, so there is less to render.

Fog doesn't reduce what needs to be rendered, it just hides things so that they too can be ignored, but simply adding fog doesn't achieve this (at least as far as I know, its possible the engine takes account of this, but I highly doubt it)

It might not be to difficult to create a BSP tree which contained a single node with all the mesh data in it, this would of course limit the number of triangles but it would be a good start.

troymac1ure wrote:To pick up the MOPP discussion in a more appropriate thread, I just tested on midship. Moved all spawns onto the midship_platform_crate and set the MOPP reflexive count to 16 => still works fine. Nulled each of those 16 values (value 205 / 0xCD) and now the map loses all player collision (bullet & grenades still work). Gonna experiment with why it still had collision before. I am thinking that it ignores the MOPP size and just looks for a NOP (or series of NOP) code(s) to exit.

Also, I believe I originally took the known codes from the oblivion ones here:
http://niftools.sourceforge.net/wiki/Nif_Format/Mopp

Hmm interesting, are you messing with the MOPP Code tag_block at offset 496? My tests on zanzibar show that this tag_block was not even used, setting the block count and address to 0 did not affect player or bullet collision at all. I then started messing with the MOPP Code tag_block in the Instanced Geometries Definitions tag_block at offset 328. My tests with this block showed that setting the block count and address to 0 for all instances of the tag_block caused the map to crash when loading. Looking in VS it seems the game relies on this tag_block and can't run without it. I will try to set all the MOPP code to 0xCD and see what happens.

Grimdoomer wrote:

troymac1ure wrote:To pick up the MOPP discussion in a more appropriate thread, I just tested on midship. Moved all spawns onto the midship_platform_crate and set the MOPP reflexive count to 16 => still works fine. Nulled each of those 16 values (value 205 / 0xCD) and now the map loses all player collision (bullet & grenades still work). Gonna experiment with why it still had collision before. I am thinking that it ignores the MOPP size and just looks for a NOP (or series of NOP) code(s) to exit.

Also, I believe I originally took the known codes from the oblivion ones here:
http://niftools.sourceforge.net/wiki/Nif_Format/Mopp

Hmm interesting, are you messing with the MOPP Code tag_block at offset 496? My tests on zanzibar show that this tag_block was not even used, setting the block count and address to 0 did not affect player or bullet collision at all. I then started messing with the MOPP Code tag_block in the Instanced Geometries Definitions tag_block at offset 328. My tests with this block showed that setting the block count and address to 0 for all instances of the tag_block caused the map to crash when loading. Looking in VS it seems the game relies on this tag_block and can't run without it. I will try to set all the MOPP code to 0xCD and see what happens.

Yeah, the MOPP code in the SBSP @ 496. The first 0x30 bytes are a header listing (as can be seen in the picture at the top) are X,Y,Z offset, scale factor and MOPP code length as well as some data that seems consistent through all maps. After that the first section always checks the X,Y,Z bounds and exits if the point is not within them, otherwise it starts the journey through the rest of the code. The values are scaled so the maximum value lies within 0-255 (hence why bounds checking is 00-FF, 00-FF, 00-33 (25 x 25 x 5).

I think it partially ignores the MOPP code reflexive length and just uses the MOPP header for the true code length. If you remove the header (0xCD) it loads without BSP collision.

On a side note that would help alot, can someone post a playable shared.map or a step-by-step instruction to do it. My attempts all seem to fail and a playable "box" would be great for testing things.

I have made a few maps this way, I nulled shaders from sbsp, purposfully broke the bsp collision of the map, then spawned several Itmc with just large models, no coll or phmo tags, these worked better then scen tags for being the visual models, and spawned for everyone.
I then used Box Blocs, for coll and phmo, and nulled the mode once i was done placing them.
A few simple edits to make the visuals stay visable always were done but, I dont think it was needed when spawned thru Itmc tag. I also linked all my blocs to Itmcs, just so they worked for non modders. (Altho i never tested it for non modders).

If they all spawned thru Itmc you are very limited.

I tried linking several boxs in one bloc, thru cloning but i had mixed results and gave up.
I hope this helps, good luck.

in the butt?

Awesome.

But where the fuck did you get that from?

Also, it seems to be missing a few header files...

My...butt? what what.

Also, I double checked h2tool and they still used Havok 2.3, just like H2X (makes sense, they wouldn't want to upgrade to a new SDK version willy nilly). I'm not sure who started the chatter about the MOPP codes being different (the docs even say they're platform independent)