cordon bounds

I know what the general purpose of "cordon bounds" are. You turn it on, drag over a small portion of a map that you wanna compile, place a player start, and compile.

This is kind of a silly question, but when do you turn them off? I'm nervous to use them because I left them on, exited world craft, and when I came back, everything outside the cordon bounds had been deleted. What is the procedure for "turning them off" so the rest of my map is not deleted?

-Thanks

Yippie Ki Yay!

You should be able to toggle the cordon bounds easily using the two buttons in the toolbar, the same way you turned them on.

Do you just use .map files instead of .rmf files? That's the only explanation I can think of as to why you'd have areas of things deleted.

Cordons work by exporting only the included architecture into the .map file. Make sure you're opening (and saving to) an .rmf file, which will store all the information of the entire level. The .map file loses much of the information stored in the .rmf, and if you open a .map file after a cordoned compile, you'll probably run into this problem.

Okie doke. I've been using just .map files, since I tend to consider them more versatile and more stable. I only made .rmf files when I first started with mapping. >.O



I think that answers my question -- you say if were to turn them on, on an rmf file, none of the "outside" would be deleted, yet on a .map file, everything would?

Just double checking. :smile:

I think that the .rmf files are more stabel than the .map files.

.map = win

the 'normal' compile in hammer has the option to 'save visible objects only', where the expert compile has the option to 'run with visible objects only'. in the 'normal' compile, when the option is selected, everything that is hidden is lost when hammer re-writes your rmf/rmx/map/max files without it. (as it compiles)

i've never used the cordon tool, so i dont know if it's the same as hiding objects, but if it is, and you used hammers 'normal' compile with the option selected, then that would explain the loss of your work.

Alien_Sniper said:
.map = win

Yes, if you like parts of your map missing sometimes for no reason. :smile:

Gorbachev said:

Alien_Sniper said:
.map = win

Yes, if you like parts of your map missing sometimes for no reason. :smile:

gorby, i cannot believe you just said that..

the only thing the .map file does, is force a mapper to map error free.. if it was removed, it was defective, plain and simple.

.map = win.... always.

I've seen otherwise...same with .rmf files. I've heard and witnessed them opening to nothing. dod_belfort opens empty as a .map but compiles off of one just fine.

I hope you guys are joking. Working and saving your map in the .map format can delete portions of the map and send complex vertex manipulation to hell.

Saving as .map makes you lose all your visgroup information, therefore .rmf = win

:razz:

Bearing in mind that that complex vertex manipulation gets converted into .MAP format before you compile anyway, then you're probably better off working with .MAP if you vertex manipulate a lot and don't use visgroups...

cass, i never joke about this particular subject.. why do you think i promote frontends so strongly (whever one you chose).. its because the .map is 99% reliable.. the .rmf is far,far less so.

i am far from "seen it all" but of the 1000's or 10's of 1000's of maps i have viewed in WC/Hammer, only maps with defects ever cause errors by removing pieces.

you do however have occasions where a person has a defective editor, and never actually realized it till a portion of the map goes missing.

i have seen several occasions where the author claimed missing pieces, but my editor saw them just fine...

keep your PC clear of bugs, and clashing programs... keep the registry clean and run spybot and hope.

acquire a fresh version of the editor and run regclean after un-installing the ruined editor.

the only positive benefit to the .rmf is the retention of the visgrouping.

i keep both saved files, but if you intend on using a front end, you most likely will be forced to use the .map

i say this again without malice, the .map file forces a mapper to map error free, if it removed something it is a very high probability it was defective in some way.

do what you guys feel is best, but i assure you i am not trying to pass on bad info.

bottom-line guys, i only use the .map to compile with, and if you have problems with it, at the very least exhaust all other causes, cause i can assure you the likelihood of the .map being your problem is negligible at most.

/ 2 cents

Actually, everyone uses only .map files to compile with. It's just that some of them don't know it :biggrin:

The .rmf format cannot be processed by the compile tools.

/me gets a mental image of mike sifting through reams of text to acquire that info.

.RMF also saves your camera information, if you like to use more than
one, and it tends to load faster. If you don't care about these or the
visgrouping, then using .MAP is probably advisable, as it will let you
know if you've caused little vertex manipulation errors that the "check
for problems" tool doesn't spot.

i use visgroups extensively, but since 3.3 came out, i have placed not one camera since..

pressing the space bar with either or both mouse buttons simulates camera use without the need to place any.

I used to place lots around the map, way way back when I made Elixir,
but lately I don't bother. I use an odd and sporadic combination of
WASD and mouse controls for the camera, its kinda subconcious which I
use at any time, just whatever comes naturally!

Orpheus said:
/me gets a mental image of mike sifting through reams of text to acquire that info.

Heh - I'm not quite as persistently bookish as you might imagine (though I take it as a compliment :smile: )

well, i use both, just incase, one for saving the map in rmf for the hell in case my vhe is stupid and hides stuff for no reason and the .map to compile with using batch compiler.

batch compiler is immensly useful for compiling steam maps, as to normal vhe compiler which sucks anyway as the frontend is lame and wont copy to a directory higher than 8 dirs high.

batch compiler also has a huge range of clickable options that explain what they do to your map when you click on them then compile your map.