Jump to content

Removable.o - The future of stadium modding?


MarlinsMY

Recommended Posts

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?

The removable.ord and .orl are dummy files in all the stadium mods, but they allows any part contained within them to have universal vertices, meaning they can be rendered at all times. I wonder though if this will tax the heck out of the graphics card and system seeing as though the .bmps will have to be rendered constantly.

Expanding on this there are a whole other bunch of .ord and orl files that are empty as far as I know. I wonder if one could use these to add additional 2d and 3d crowds to fill parts of the stadiums. If there's one thing this game is lacking is 3d animated fans. I'll have to test this at some point...

Link to comment
Share on other sites

  • Replies 53
  • Created
  • Last Reply

Any chance something like modifying the create-a-stadium to make it look like its not generic?

Maybe take the apartment building from Petco and put it in left and the train from the Spring Traning Stadium in the backround somewhere. Then the Jumbotron from Turner put in somwhere.

Any chance something like this can happen? I've seen what you stadium modders do. I think you guys can take the challenge.

Link to comment
Share on other sites

That is wht OEdit is for. In Oedit you can move things all over with no worry as to where you place them. Especially now. You can take this removable or mstadium file and with a little tinkering and a lot of patience make just about anything. You should play around with it.

Link to comment
Share on other sites

  • 2 weeks later...

So, working on something, I found this definitely works for alphablend.o. This is really exciting, because it means we can have full blended alpha files now, with shading for any grey colors. I've always had trouble with this, but by doing the steps Marlins laid out, it works like a charm.

I'm also finding out that you can use remcrowd0.ord/orl, but remcrowd1.ord/orl doesn't seem to work. good to know.

Link to comment
Share on other sites

So, working on something, I found this definitely works for alphablend.o. This is really exciting, because it means we can have full blended alpha files now, with shading for any grey colors. I've always had trouble with this, but by doing the steps Marlins laid out, it works like a charm.

I'm also finding out that you can use remcrowd0.ord/orl, but remcrowd1.ord/orl doesn't seem to work. good to know.

Awesome. I'm gonna need that for the RF corner in Oakland. :)

Link to comment
Share on other sites

Actually, I shoud amend that, in that only crowd.o works, not the remcrowds. But alphablend definitely does work, and I suppose there's no reason you couldn't replace any of the other .ord/orl files not in service with an mstadium file, guess it's worth a shot.

pirate-

Take a look at classic fenway, the netting above the left field wall, right in front of the crowd in play. unlike the regular cram32, these files fully blend the shades of grey in an alpha file, so you can get partially transparent pieces. It looks really great. That's alphablend.

Link to comment
Share on other sites

Actually, I shoud amend that, in that only crowd.o works, not the remcrowds. But alphablend definitely does work, and I suppose there's no reason you couldn't replace any of the other .ord/orl files not in service with an mstadium file, guess it's worth a shot.

Damn. You got my hopes up.

But would it be possible to replace another .ord.orl with a crowd file? Like maybe one of the extra background files? I just need a way to bring the mstadium AND crowd files from another park into new Oakland. I'll have to try it after work.

Link to comment
Share on other sites

Ok, so I'm importing to the new cram32 from the donor and it's wierd. Sometimes I get an error when I click on Graphic Object : New when I am adding an object, yet some of them work fine, I'm going to try to find out a pattern of which ones are working and which ones arn't.

Link to comment
Share on other sites

i have a question, In my custom stadium I am taking the john hancock sign from fenway, and putting it somewhere in SBC. I also will change the font to say Marlins. My question is how do i appoint where it will go? Also do I nedd to copy over the graphics files also.

Link to comment
Share on other sites

I think this method has made stadium modding for the beginer to difficult. This is a method to be used when you run out of verts in a stadium. You can still do things like the John Hancock sign in the traditional manner. You do not need to import it into your stock stadium. Just clear up a vert and add it in.

Link to comment
Share on other sites

  • 3 months later...

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.

Link to comment
Share on other sites

  • 4 weeks later...

I know this question was already asked, but I'm not sure if it was really answered here or anywhere else.

Is it possible to redirect the "parts" of an Oedit file (and ultimately the ord/orl files) to look at images in a different .fsh file? Or, is it possible to have them look at different images within the cram32.fsh file?

For example, in aa03nite.big, "part 149" (of the mstadium.o file) is the right outfield ads section, and thus, wherever I put that part in the stadium, it will always reference "ads0" for its images. Is it possible to make it reference "stcs" (for example) instread?

Also, I think this is talked about in this post, but is it possible to add files to the cram32.fsh file and make them usable by the mstadium files?

Thanks for your help.

Link to comment
Share on other sites

Is it possible to redirect the "parts" of an Oedit file (and ultimately the ord/orl files) to look at images in a different .fsh file? Or, is it possible to have them look at different images within the cram32.fsh file?

Unfortunately, no. The ord/l files have a listing of what I believe is the cram32.fsh file list, but I can't figure out where it says which parts map to a particular image.

Also, I think this is talked about in this post, but is it possible to add files to the cram32.fsh file and make them usable by the mstadium files?

Sort of, yes. Additional images can be created in the cram32.fsh most of the time (some .fsh files won't work with this for some reason). If a removable.o file finds a needed texture in the cram32, it will use it, even if that image was not in the original. That process of adding images is in my second post on page 1.

Link to comment
Share on other sites

The parts in each .o file are mapped to a specific .fsh file so those cannot be changed. Also each part is mapped to a specific .bmp in the .fsh as well. This is why when you first combine the stadiums, you will get missing textures for certain pieces because the removable.o is looking for those specific .bmps in the .fsh. To answer your last question, the only way to add a file to the cram32.fsh and make it useable is to have the part in the removable.o file map to it. I hope this answers your questions.

Link to comment
Share on other sites

Ok, so let me make sure I got this straight...

First, MarlinsMY, thanks SO much for figuring this all out. I know you first posted this like 6 months ago, but I just found it yesterday, so, it's new to me!

Second, and I think Big O kinda answered this for me, let me make sure I got this straight: Suppose I combine two stadiums (let's just say busch stadium and yankee stadium). The mstadium ord/orl files are form busch and the removable ord/orl files are the renamed yankee stadium mstadium files. Both the mstadium and the removable mstadium ord/orl files look at the same cram32.fsh file. However, if I am using the busch stadium cram32.fsh file, there may be some htings missing that the yankee stadium cram32.fsh file had. Is that wat you're all saying?

Ok, and lastly, I'm not sure that this neccesarily helps or is useful, but I was experimenting with stuff today, and I found a way to make all "parts" of a mstadium that pointed to the "ads0" file (just using ads0 as my test) point to the "stcs" file instead. So, wherever there were ads, there was now random parts of the stadium. Then, I merged the ads0 picture and the stcs picture completely into the stcs picture. Then, because the scales were off, I moved and rescaled some of the vertices that were redirected towards the "stcs" file so that the ads would show again. Basically, what I did was make the ads0 file completely useless. It could be removed form the cram 32.fsh file and the stadium would never know the difference at it looked the same.

Did that make sense?

Link to comment
Share on other sites

Second, and I think Big O kinda answered this for me, let me make sure I got this straight: Suppose I combine two stadiums (let's just say busch stadium and yankee stadium). The mstadium ord/orl files are form busch and the removable ord/orl files are the renamed yankee stadium mstadium files. Both the mstadium and the removable mstadium ord/orl files look at the same cram32.fsh file. However, if I am using the busch stadium cram32.fsh file, there may be some htings missing that the yankee stadium cram32.fsh file had. Is that wat you're all saying?

Yes, that's it.

Ok, and lastly, I'm not sure that this neccesarily helps or is useful, but I was experimenting with stuff today, and I found a way to make all "parts" of a mstadium that pointed to the "ads0" file (just using ads0 as my test) point to the "stcs" file instead. So, wherever there were ads, there was now random parts of the stadium. Then, I merged the ads0 picture and the stcs picture completely into the stcs picture. Then, because the scales were off, I moved and rescaled some of the vertices that were redirected towards the "stcs" file so that the ads would show again. Basically, what I did was make the ads0 file completely useless. It could be removed form the cram 32.fsh file and the stadium would never know the difference at it looked the same.

Did that make sense?

I followed it. :lol: That's really interesting. Was this through hex-editing the file(s)? If you wanted, could you have changed the "ads0" to a made up texture, say "myt0"? If that was added to the cram32, it should have worked. I think this could be useful, especially if it can be found out how to change individual parts.

Link to comment
Share on other sites

Yes, this was through hex-editing. Just on a minor league stadium, so it may be more complex on an actual stadium.

But, I found that in the original mstadium ord/orl files the list of graphics used (ads0, blpe, stcs, etc...) are listed. And, they are each listed only once in each file. Just changing the "ads0" to "stcs" and saving did the trick.

The thing is that right now, I don't really find an advantage because I still can't add new files in the ord/orl files. For example, I think the stadium I was using was looking at about 36 files from cram32.fsh. By changing the ads0 to stcs, I didn't open a new slot or anything, just change the route.

I guess one advantage might be that after you get rid of ads0 in the ord/orl files, you could technically delete it from cram32.fsh which might be useful when combining stadiums to free up slots. If you have a stadium that uses a TON of cram32.fsh files and combining it with a stadium that doesnt use many, this could be helpful.

If you wanted, could you have changed the "ads0" to a made up texture, say "myt0"? If that was added to the cram32, it should have worked. I think this could be useful, especially if it can be found out how to change individual parts.

I'm still working on this. It should work, since my first test was to change the name of ads0 to ads1 in cram32.fsh, then change it from ads0 to ads1 in the ord/orl files. It redirected flawlessly. So, I would assume that if I imported a texture "myt0" and then redirected to myt0, it should work. I'll test it out, and let you know.

EDIT: The simple answer to this is yes. I just added a texture called "test" to my stadium. I redirected the walls (wale) of my stadium to the "test" texture and it worked fine.

I still think there are limitations to this. But, it has some potential to be helpful. If you have another test for me ot run, let me know. For now, I'm going to try and work on making the seperate parts redirect as opposed to all the parts.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...