Gamecube Battle Zone (updated)

[Shuffle]

I've been working on a Deathmatch map and its.. a giant Gamecube! ^^;

Here ya go!: http://home.comcast.net/~mlmars/gcbz3.zip

 

[Walan]

I got a error that there were not enough starts in the map. Did you remember to add start locations?

 

[Shuffle]

It's a DM map, you gotta start a deathmatch game.

 

[Walan]

*falls over, anime style*


I really should play a multiplayer game one of these days...

 

[Mystic]

Shafluigi, you should ALWAYS place a Player 1 Start on any map, whether it is DM or otherwise.

The Player 1 Start is what SRB2 uses if it has trouble for whatever reason placing the player, hence, you should always put one in.

 

[SSG]

not a bad wad at all Shaflugi. :D

 

[Digiku]

I'll say this:
Very interesting concept, yet bad use of textures/flats

It's the wall textures, really. The GFZROCKness of it all basically dirties the GCN. Some of the flats (Namely the ones to to the edge of the indent to the CD tray) also don't do justice

I like the laser :D, though I wonder if they fixed that damned laser bug yet :/

 

[Shuffle]

Wheres the GFZROCK? Do you mean the sides of the tray?

 

[a441]

Since I haven't played this in an actual netgame yet, I can't judge it for sure, but I already have a few suggestions. First, get rid of the GFZROCK way up in the sky. It looks like you've used Main textures there. The only time you should ever use Main textures in SRB2 is when you're making sector borders (GFZGRASS) or control sectors (off the map).

About the level itself, it might make sense to put a weapon ring or randomly respawning monitor or something up on the top of the lid, so people have a reason to go up there. I would also recommend spreading out the rings some more, so it's not as easy for one player to take nearly all of them.

Finally, I agree with the suggestions that you add a Player 1 Start and replace the GFZROCK with more appropriate textures.

 

[Shuffle]

I would also recommend spreading out the rings some more, so it's not as easy for one player to take nearly all of them.

Well I would, but for some reason I cant build nodes anymore, if I do, everything will mess up badly.

 

[Mystic]

Try using Zennode. It is your god.

 

[a441]

Close the wad in WadAuthor before you run ZenNode. If you keep it open, everything will get badly messed up, because WadAuthor doesn't like other programs modifying the wad files while you have them open.

 

[Mystic]

I haven't noticed WA has that problem. DoomBuilder outright doesn't LET me do it, however.

 

[Shuffle]

I know, I use ZenNode and I'm not making the same mistake I did before with leaving Wadauthor open to use Zennode..

The problem is, I think, there are 2 linedefs that are attached that shouldnt be..

 

[a441]

Maybe you have two linedefs overlapping each other, where there should only be one? If you suspect this has happened, you can test by selecting the linedef and pressing Delete, exposing any linedef hidden underneath. (Ctrl+Z if there isn't one.)

 

[BlazeHedgehog]

Close the wad in WadAuthor before you run ZenNode. If you keep it open, everything will get badly messed up, because WadAuthor doesn't like other programs modifying the wad files while you have them open.

It's not that. WadAuthor loads the WAD up into it's cache. It works like this:

- You save your map in WadAuthor, and it builds it's own nodes. You don't close this, so WadAuthor leaves the map and data in memory.

- You run Zennode on the map. Zennode rearranges everything and builds it's own (superior) nodes.

- If you save your WadAuthor map again, this trips WA's "not modified" defense, so it simply rebuilds the nodes under the premise of the old data. Because of how Doom handles data (incremental lumps and all), this throws everything completely off, and any data after the map itself becomes misaligned and corrupted.

 

[a441]

I wrote a program to modify lumps in wad files, and I didn't understand any of that. What do you mean, incremental lumps?

I have WadAuthor's node builder turned off and it still gives me trouble if I do that. So it has nothing to do with WadAuthor's nodes.

 

[BlazeHedgehog]

Like, from what AJ once said, Doom's textures are all 64x64, 128x128, etc for a reason -- it's how Doom indexes the WAD and reads the data. Rebuilding WadAuthor's nodes over Zennode's nodes messes up, because WadAuthor is storing the entire map in system memory and uses that to base it's study off of. When you save your map in this state, it overwrites data it didn't know existed, and thus screws up the index offset.

Then again, I'm hardly the techno geek you or AJ are, so I'm undoubtedly talking out of my ass.

 

[a441]

Nope, the way it works is there's a directory somewhere in the file (typically at the end, but according to the spec it can be anywhere... I wonder if I'd screw some programs up by putting it at the beginning) that lists all the lumps and has pointers to where in the file they begin, as well as their sizes.

So as long as the offsets in the wadfile directory are correct, there won't be problems. Texture sizes wouldn't make a difference there because textures themselves aren't even lumps, and if you meant patches, they're stored the same way all lumps are stored, so they could be any size.

The reason flats are 64x64 and 128x128 and so on? I don't know exactly, it probably has to do with how they're drawn, or maybe the size. Flats are stored as bmps without headers, so they don't have any size information. If you keep them square, you can take the square root of the lump length to find the dimensions.

Textures have to have widths that are powers of 2 because of how the TEXTURE1 entries are stored. The heights don't have to be powers of 2. There are a few SRB2 textures with weird heights, I think.

 

[SSNTails]

Yup, you used to have the texture height at a power of 2 also, but I fixed that.