I really hate to break up Skyforgers systematic takeover of this forum, but I need a bit of clarification.

My last compile of my map has the size up to a whopping 9,235 KB! I'm about ready to throw it all into a zip file, and I noticed that it's freakin' twice the size of most other maps! (Only hera is bigger at 10,sumthin, and shiva is 100 KB behind me now) Daimos is the only co map that's close at 7megs. I've got a bunch of custom textures, but I can't have that many, in fact, my own two wads are barely 2 megs.

So what I'm thinking is that my use of wad Auto Detect in nems batch compiler is merging the textures I'm using in ns and ns2 wad into the map.

I have wadincluded my custom wads. This is simply so that I don't have to have a bunch of them floating around in cyberland, conflicting with each version of my map (since I keep adding, and replacing textures as I go along) So, I want those compiled in the map. But, I'm guessing I've got the ns/ns2 textures also being included in, though they aren't specified. I thought that by using auto detect, of the wads that are being included, only the ones being used would be compiled into the map.

So, if I disable autodetect for my next compile, would I get the desired effect then? Is -wadautodetect AND a -wadinclude redundant? Have I confused myself somewhere?

Its intended function seems to be to not mark .wads are required to play the map if they aren't in use by the map.

(A single bright dynamic light can add a over a megabyte to your light data. To reduce this you can selectively disable bounce for dynamic lights with nodynbounce)

That's what I thought. I remember now why I started using the wadautodetect oh so long ago.



Really? Well, then, some more investigation!

co_moirad20 (the last released version)

Texture usage is at 2.76 mb (of 4.00 mb MAX)

co_moirad3 (soon to be released version)

Texture usage is at 3.76 mb (of 4.00 mb MAX)

Huh... feature creep! My light data increased by around half a meg, and my texture data increased by about a meg. The fact that they are up doesn't surprise me (I've added more lights and textures) and fortunately, I've removed a "bright dynamic light" since last version. (nodynbounce isn't an option since my dynamic lights are fairly important to the areas they are in.)

The entirety of ns_machina can almost fit in my lightdata! I'm willing to guess that texture lights probably use more light data as well? Scratch that, I forget, I'm using -bounce 2... so there's a pile more data there alone in all likeliness.

Still... texture usage is over the size of my personal wads. Or is that number the amount that is expected to be accessed in game? If texdata, which now that I look at it, is my texture data in the map, perhaps it's less than my personal wads. Hmm....

Well, I won't worry too much about it then, if my light data alone is the biggest piece of the pie.

Lighting in HL is handled with light maps; this is like a tiny texture for each w_poly that stores the light that hits it from all light sources. If you use only static light sources you will never need more than one of these "light textures", but if you use dynamic lights you must use two or more lightmaps for the surfaces affected by them so that they can be independently toggled on and off.

Now that's FUNY

We are the borg. Your mapping knowledge and skillz will be added to our own. Resistance is futile; you will be assimilated.

Okay, yeah, yeah, this makes sense now. The texture lights take a few more calculations during rad (spread over an area instead of a point) but should use the same memory as a static point light, since the end effect is still one light map. Dynamic lights are simply as you say, more light maps. This is a tangent I've had to give a lot of thought to while making this map due to my use of dynamic lighting, which, is modeled after hera's use of dynamic lights... and it too uses a pile of memory as mentioned! It's all becoming more clear in my head now. Thanks!