Removable.o - The future of stadium modding?

[MarlinsMY]

This is going to be a long and probably incoherent post, but bear with me, because this could improve stadium modding and open a bunch of new opportunities.

Awhile ago, I was trying to fix the disappearing graphic issues in my Hadlock Field, when suddenly a few topics from a few months ago re-entered my head:

1. I made a new “extra†external object from a blimp, and it acted like the Shea Stadium apple. I thought that using this file, extra polygons could be created and “added†to a stadium. Unfortunately, there were limitations to this method.

2. I remember a post by SeanO awhile ago talking about modding the create-a-stadium. He noticed that all of the optional objects were contained in the file “removable.oâ€. These parts could then be changed just like a normal mstadium.o file.

These ideas fused together all of a sudden, and I had an idea. I took the removable.o from the create-a-stadium and I replaced the empty files in Hadlock with them. When I saw it in the game, my suspicions were correct – there were all of the different walls, scoreboard additions, and other objects. Some of the parts were textured (rather strangely), and others had the “missing textureâ€. However, through FSHEd, I exported the missing images and their attachments into my cram32.fsh. It worked perfectly.

Because I was curious, I then took the Yankee Stadium mstadium.o file and renamed it to removable.o, and imported into Hadlock. It displayed the same way as the CAS. With Yankee Stadium’s tanim.csv also in place, the complete scoreboard, Yankee logo animation screen, and “EA Sports†side tickers all work correctly. I think this is huge, as now stadium modders can work with twice the polygons, or use another stadium for spare parts.

Advantages:

1. All polygons in the removable.o are “universal†polygons – they don’t disappear!

2. Additional polygons can be used for extra ads, walls, seats, etc…

3. Using a stadium and tanim.csv with an updating scoreboard as the removable.o will work in your stadium.

4. Any unused polygons and just be pushed beneath field level, and they don’t appear to seriously affect the render time.

Known Problems/Issues:

1. mstadium.o and removable.o cannot be “fused†together in OEdit, so it’s hard to visually edit without having two separate windows side by side.

2. Parts that share a common name (especially the “animated†scoreboard) will display, but in the scoreboard’s case, only the removable.o parts will update score, count, etc…

3. It’s annoying to add the missing texture files to the cram32.fsh

Anyway, it is somewhat of a tedious process, but I think this opens up a huge door for more flexibility for modders and complex stadiums. Here are a few screenshots which demonstrate what I was talking about.

[Yankee4Life]

So you found a way to take textures from one stadium and put them in another? That's great!!!! Imagine the possibilities that someone can do with this.

Good work MarlinsMY.

[Sean O]

Marlins-

You live in Maine, and my family is from Massachusetts. At most, that's like a 6 hour drive to Vermont.

I guess my question is, will you marry me?

[MarlinsMY]

So you found a way to take textures from one stadium and put them in another?

Not only the textures, but the vertices as well. In addition to the mstadium.o, you can use removable.o as effectively another stadium to edit.

Details on how to export/import textures:

A= cram32 of the actual mstadium

B= cram32 of the "donor" stadium

What you need to do is export pieces of B into A, as the final .big uses just one cram32 (both mstadium and removable know to look for textures there).

First, the images of B need to be able to be imported as pictures, so it should be run through fshtool or exported one by one in FSHEd (depending on how many images you want to import).

1. Open A & B in separate instances of FSHEd.

2. Select an image from B that is not in A... for instance, "wale".

3. Click the "+" next to the name, and there are two things: "metal bin" and "name". Export both of these one at a time (in order) by selecting Object -> Export. Save as "Binary Data Only". I don't think what you call it matters.

4. Switch to A.

5. Go to Object -> Add New -> Object.

6. Click "New" under Graphic Object and choose the image you are importing. Under the name, type exactly what is in B. (For instance, I would type "wale".) Click update.

7. With your new image selected, go to Object -> Add New -> Attachment. Import "metal bin" and "name" in that order. Make sure that it is designated as being a metal bin or name under the "label".

8. Save A. (It's important to do this and make a backup for every few images imported. If one thing goes wrong, the file corrupts and you have to do everything over. Trust me on this one! )

(9.) If you're adding another new image, you only need to export the "name" each time. The "metal bin" is the same for each picture and the same one can be imported each time.

(10.) Add A into your stadium file, along with the removable.ord and .orl files. You should see the "missing texture" replaced with the actual images.

Something to keep in mind: Somehow, the game files still know what aspect ratios the images are, so if you're making something bigger, make sure to keep the same ratio (in other words, something originally 64x64 has to be 256x256, no 256x512).

[awesome]

i'm no doctor, but this seems like a huge deal. great work, guy.

[aaronuconn]

Ya, thats awesome. And cool, someone else from Maine.

[Pirate]

I knew there was a trick to Hadlock.

While it is incredibly tedious it is amazingly helpful.

I may just use this on my Anaheim mod. I just don't know if I have the patience.

Just unbelievable. I cannot express my impression. I am blown away what a tool. WOW!

[Pirate]

Yeah, I don't have the patience for that. Amazing find. i hope somebody can add some great things using that method, but I don't have the time or patience.

[The Big O]

Ya, thats awesome. And cool, someone else from Maine.

There's a few of us here...

Great find MarlinsMY! Unfortunately Oriole Park and Fenway are at their limits as far as the cram32.fsh is concerned so any additional textures would cause the mod to crash the game. I might play around with this a little in some future mods though....

[HardcoreLegend]

Unfortunately Oriole Park and Fenway are at their limits as far as the cram32.fsh is concerned so any additional textures would cause the mod to crash the game. I might play around with this a little in some future mods though....

Even if the vertices pointed to some other graphic file? Would you not be able to increase the size of the image, and merely 'move' the framing for the original over the original graphic and use all the rest of the space for the other vertices?

Something like this below, using the wall graphics.

[The Big O]

Even if the vertices pointed to some other graphic file? Would you not be able to increase the size of the image, and merely 'move' the framing for the original over the original graphic and use all the rest of the space for the other vertices?

Something like this below, using the wall graphics.

All the images are at their dimension limit in both mods. If I add anymore .bmps or increase their size the game will crash due to the increase in size of the cram32.fsh. Trust me I had a heck of a time remapping things and decreasing the resolution on certain unimportant .bmps so I could get the cram32.fshs under the limit. Hi-res is great but it does limit what you can do. Nevertheless I plan on looking into the new possiblities of this recent discovery by MarlinsMY...

[HardcoreLegend]

Ah, gotcha. I didn't pick up on that the first time.

[krawhitham]

dumb guy here, so do not kill me

Is it possible to map it to a different FSH file. say like notcram32.fsh

[MarlinsMY]

Is it possible to map it to a different FSH file. say like notcram32.fsh

Unfortunately not at this time. There has to be something that tells the files to look there though. I know if you open a stadium in a hex editor, you can see the names of some of the images in cram32, but I don't know if they mention the file name itself.

[five]

Great find, I remember this crossing my mind one night when I was doing a mindnumbing search during my outfield grass saga, but then I forgot about it.

[MarlinsMS_35]

Ya, thats awesome. And cool, someone else from Maine.

While we're on the Maine topic http://www.doubleminor.net/forums/showthread.php?t=22393

[Jdurg]

So this means that things like a Yankee Stadium with the proper transparent sections of the Left Field Wall and a fully functional scoreboard(s) is possible? Good god I can't wait for someone to get around to an up to date Yankee Stadium mod. :D

[The Big O]

I’ve discovered a few things when building my Fort Lauderdale Stadium mod with the removable.o file. The first thing is that when you are exporting the image from one cram32 to the other you need to first export the actual .bmp. before the metal.bin and name files. Export it as the filename of the .bmp you are trying to export for example “ads0.bmp†and choose to save the image as a 32 bit bitmap. Now you can go ahead and export the metal.bin and the name files as binary data like MarlinsMY described. The key with this export is you have to name each file something different otherwise they will overwrite each other when you go to export them.

Once you have done this you can now import the .bmp into the host stadium cram32.fsh file. The key here is that you have to make the properties of the imported .bmp the exact same as the one that you chose to export. The two fields that you need to pay particular attention two are the Image Type and the Mipmap. The Image Type determines whether or not the image has transparency or not and the mipmap field determines how many frames will be assigned to that image for mapping purposes. Mipmapping is the mapping of .bmps depending on the perspective. For example one .bmp is mapped to display sharply from a far away perspective so it might have 4 mipmaps while another may only have 2 because it doesn’t have to display so crisply. I have illustrated this process in the linked screens below:

Image Type

Mipmap

Once you have changed the Object Properties you can then assign the image its proper name (ex: ads0) and then click Update. You can then attach the metal.bin and name files that you exported as MarlinsMY described. Once this is done you then save the cram32.fsh. For you nfshtool users you will notice that once you extract the cram32.fsh, the bmps that you added will appear at the end of the series of .bmps for that cram32 as shown in the link below:

cram32 .bmps

Repack the cram32 and you will see that the textures that were once “missing†are now present in the game as depicted below:

Merged stadium before

Merged stadium after

That's all for now but I intend to play with this some more... 8)

[Sean O]

Two comments.

1). So, with this, is it possible to just switch the mstadium.ord/orl files with the removable.ord/orl files within a single stadium, and eliminate the disappearing vertex problem? Theoretically everything would still point to the same files in the cram32 file.

2). I'm thrilled that we now have enough vertices to create all of the parks that used to be impossible, such as big Anaheim, Candlestick, old Oakland, etc.

This is huge, I'm working on it with Baker right now.

[MarlinsMY]

Two comments.

1). So, with this, is it possible to just switch the mstadium.ord/orl files with the removable.ord/orl files within a single stadium, and eliminate the disappearing vertex problem? Theoretically everything would still point to the same files in the cram32 file.

In theory, yes. Why didn't I try that? :lol:

[NYM]

Some one should make a insane Create a Stadium. With the removable o files I'm sure someone can make something cool. Maybe something orginal.

Maybe an apartment building in left field, a huge jumbotron in left center,

In right center a restaurant with the bullpens with one on top of the other, under the restaurant.

Maybe with this we can create a sick stadium so the CAS, isnt just some boring generic stadium anymore.

Maybe a contest too see who has the most resonable, doable stadium.

Any thoughts?

[Sean O]

My suspicions were correct; the disappearing vertex problem is officially a thing of the past. By switching removable.o and mstadium.o around, vertices become universal as MarlinsMY mentioned, and virtually anything is possible.

I'm working on it in Baker right now, and I can't believe it was that easy. This is a dream for modding, and the sky really is the limit.

Thanks a ton to MarlinsMY for figuring this out. We've finally got it!

[NYM]

Now all we need is to find a way to add extra stadium slots so that we dont have to keep overwrighting minor league stadiums.

[Pirate]

So confused.

How do switch the removable and mstadium o files?

How will the removable file reflect PNC Park.

Or is this for creating new stadiums all together?

[Sean O]

Pirate-

It is so surprisingly easy, you'll kick yourself. All you have to do is rename mstadium.ord/orl (or .o) to removable.ord/orl (or .0), and removable to mstadium.o, and no vertices will ever disappear again. Then, just treat the removable.o file as mstadium.o file.

So, essentially nothing changes except the name.