Save Region

[greebo]

According to issue #178 the Save Region feature is crashing.

 

I could locate the crash in map.cpp:1595:

region_startpoint = &GlobalEntityCreator().createEntity(
	  GlobalEntityClassManager().findOrInsert(eClassPlayerStart, false));

The EClassManager is returning an empty IEntityClassPtr that is NULL, hence the boost::exception.

 

What I'm wondering is how useful this feature really is and what culprits it may provide when extracting parts of large maps (I could imagine that the entity numbering is screwed up and script targets may break).

 

Thoughts/comments?

[OrbWeaver]

As far as I know the findOrInsert() method should never return NULL, but should create the entity class if it does not exist in the cache. I can't say what the value of Save Region is as a feature though -- doesn't it basically do the same thing as Save Selected? I don't see why we need two features for this.

[greebo]

It should seal the selected "region" off with brushes and places an info_player_start to the current camera position. It's some kind of shortcut and thinking about it I'd vote for keeping it but move it to a different menu location.

 

Regarding the IEntityClassPtr: it was definitely NULL, but I haven't investigated the reason for it. The region code is a bit of a mess, so I'll refactor this whole thing into a proper class.

[greebo]

I've found the reason and it's actually my fault: I misspelled a registry key and the result was empty, which in turn caused the EClassMgr to return an empty IEntityClassPtr().

 

I'll fix it and upload it.

 

edit: Fixing it doesn't make it better, the func_statics are not handled correctly by the region save, so I'll have to fix that as well.

[greebo]

Ah, I just figured out how Regioning is meant to work: It's basically the same as Show/Hide, but stronger. You can define a region in your map and every scene::Node that is outside gets set to the state "excluded" (same as hidden, but stronger). You can continue working on the visible region and even use show/hide on the visible objects until you turn the Region off again.

 

And of course you're able to save the current region to a separate file where it's auto-sealed and an info_player_start is placed.

 

Overall, I think that's not a bad idea at all and it gives us another way of implementing a layer system basing on the scene::Nodes themselves.

 

I'll see to it that the current code is a bit more organised and is working ok, because it's a feature worth keeping.

[SneaksieDave]

What I'm wondering is how useful this feature really is...

Thoughts/comments?

I guess my opinion is already known as the tracker , but just to get it out there: beyond useful, I qualify it as essential. Compiling an entire map of the size of a Doom3 level and beyond, each time you need to verify that something works right, is really unfriendly. In DoomEd, you simply choose a region by one of the available methods, compile just that limited area, and launch. Seconds to compile and launch, as opposed to potentially many, many minutes (even hours in extremely large maps).

 

Most Favorite Feature! (...well, one of 'em)

[OrbWeaver]

Perhaps we could merge these two commands, so instead of two menu entries there would just be a single Save Selected item, with an extra checkbox in the Save As dialog to autoseal the region and place a player start.

[greebo]

Save Selected and Save Region is not quite the same, as "Save Region" does not depend on any selected items. It saves all the non-excluded nodes to the file, whereas the "Save Selection" command is independent on the current Region. I'd vote for keeping that separate.

 

However, as long as we can't compile any maps, this feature will remain half as useful, as Sneaksie mentioned.

 

I could look into creating a collision model (.cm) file for the map, which would of course be tricky, but my knowledge in regard to the .proc file is zero.

[OrbWeaver]

Surely you wouldn't need to compile the map yourself, you would just save the region to a new .map file and then compile inside Doom 3 in the usual way?

[greebo]

I must admit that I never used this feature and never did much mapping in DoomEdit, so I can't say for sure how this is intended to work in DoomEdit.

 

Isn't it desired that only the current region gets recompiled and not the whole map? Some kind of differential compile? SneaksieDave, is this possible in DoomEdit?

[OrbWeaver]

I was assuming that the region was saved to a separate file, with sealing walls and a player start location, and this separate map file was compiled by Doom as if it was just a normal map. Even if DoomEdit does provide a built-in "compile region only" option, the separate map file is as close as we can get without the map compiler.

[greebo]

I was assuming that the region was saved to a separate file, with sealing walls and a player start location, and this separate map file was compiled by Doom as if it was just a normal map.

This is true and is/was already functional and I agree that there probably is not much more we can do.

[SneaksieDave]

This is getting confusing. Even more confusing, is that it sounds like we're all saying the same thing but not realizing it.

 

In DoomEd, open a map, and zoom the view into the limited area you want to compile. Make sure it has light and a playerstart in it, as I'm currently not sure if DoomEd handles that for you if not. Then do Region | Set XY. Then BSP it. You can now enter that limited are in Doom3 by running "map whatever.reg" at the console.

 

I assume how it would work in DR would be to save that region out with:

-bounding walls to seal

-a player start

 

and then the user would "dmap whatever.reg" at the Doom3 console to compile it.

 

Edit: Oh, of course, since this is a separate application from Doom3, DR could just as well save out a .map instead of a .reg. Unless... maybe Doom3 uses .reg to ignore leaks? I'm not sure.

[greebo]

Ok, so it seems we're even with DoomEdit in that respect.

 

DarkRadiant can already save the map with automatically created wall/ceiling brushes including info_player_start entity. Of course the extension is .map.

[SneaksieDave]

DarkRadiant can already save the map with automatically created wall/ceiling brushes including info_player_start entity. Of course the extension is .map.

Awesome. In fact, it might be better, since DR treats it as an independant, sealed map (assuming .reg in Doom3 isn't in fact needed to ignore leaks, and DR's sealing is bullet-proof. Which it probably is - I imagine you can just get the largest bounds and then build a simple box around everything).

 

I just found some oddness (this is DoomEd). The warehouse.map is 426kb. I created a region to outline the steps above which is 123kb. It is saved out as warehouse.reg. However, when I re-open the map, it contains all of the original data.

 

Maybe the .reg is just a partner file to the .map. I dunno. Either way, it seems like DR might be handling it already in a more understandable and straightforward manner. :thumb: