Two minor updates

1. Today I thought about how map creation could be made more convenient. In particular, I was unhappy with the fact that cube geometry is saved in .ogz files while entities are stored in the database, and so far in order to copy that entity data I've basically been doing SQLite dumps. Now, it does make sense to separate the two kinds of data (cube geometry is static, while entities are not, in particular, you might want to take 'snapshots' of entity activity for various reasons), but being forced to use database exporting is not good.
   
   So it seemed a reasonable idea to write dump_entities() / read_entities() functions, which would save all current entity data to a file and read such a file, respectively, in a portable manner (so it doesn't matter what database you're using, if at all).
   
   At first glance, it wasn't apparent how hard it would be to write such functions. But after a bit of thought, it became clear that my hard work from earlier in the project's history would pay off. For one thing, in the Intensity Engine we do entity lifecycle management is in a unified, high-level manner. For example, there is a single create_logic_entity() function, which encapsulates differences between Sauerbraten's dynents and extent data types. Another useful architectural feature is that we store all entity information in just one place: its StateData (well, to be accurate, two: there is also the Class field). Finally, the Intensity Engine has a clean separation of database operations from everything else, that is, creating entities and storing them in the database are conceptually and practically separate.
   
   As a result, dump_entities() and read_entities() take only about 10 lines of Python code each :) It's definitely a good sign when adding features is as easy as that.
   
   
2. A second issue I'd like to mention is that following a suggestion from SephoD on our forums, I looked into generating scenery from a heightmap. This differs from the procedural generation approach I did previously in that it uses a 2D heightmap instead of 3D full/empty information.
   
   This is a little trickier than 3D scenery as for heightmaps we want a finer resolution, which necessitates a lot of cube corner pushing, and there are issues with cube alignment boundaries (cubes can only be made at coordinates which are powers of 2). So far I have some partial results:
   
   
   
   (Click for a larger version.)
   
   Admittably this isn't terribly clear, but it shows a large 'valley'. Note that particularly near the center of the valley there are some artifacts, these are alignment issues that should be smoothed out in the future. They actually give an interesting effect, but that is completely non-intentional ;) In any case, the code is already useful for mappers that don't mind doing a little manual smoothing after the heightmap is generated.