To answer your questions, in brief (I could go on and on, I've been waiting for this to become possible for a very long time now):
1. If you want a tree at a very certain position, you'd just script it. Easy enough to do, and I'll include example code. This isn't about single trees, though.
The random stuff is basically there to save you a lot of time, and to make your maps more interesting. Static maps just aren't very interesting, compared to stuff that's more dynamic. And the randomness adds a lot of replay value.
For example, you can put minefields into a map, that won't be at the same positions every time. Players know there will be mines, but will not just be able to go to a given spot and get rid of them.
As another example, say you want to do a dense jungle terrain on a map. Before, this was practically impossible to get good gameplay on, and required enormous time investment by a mapper. When this is done, you'll just be able to set up a LUA Gadget that will auto-populate the map with stuff- and it'll look different and new every time.
Moreover, each object can do different stuff. In fact, they can do anything a Unit can do- which is, well, basically anything, given what can be done with LUA. For example, you could have a randomly-generated forest, with a scripted, non-random object in the middle, that, if captured, allowed units to be teleported elsewhere.
Or you could script in a custom Ancient Mecha, that waits to be captured by a player, and then is controlled by that player (I have an example object like this, that goes from Neutral to able to fight other players, already working).
And, when I get to it, you'll also be able to add mobile actors- Units, basically. Some could be hostile to players, some could be helpful, and most neutral- things like animated animals, for example.
Lastly, by combining LUA with COB, I've already built some fairly sophisticated procedural-content stuff. That's what that cluster of "trees" demonstrates- each "tree" is part of a single object, manipulated via COB to go random places, be at the right height relative to the map, and when the cluster of "trees" is dead, they have death animations!
I have one more demo object I want to try and build today, after I've slept- a fully procedural building. It'll have elements that look vaguely like a ruined temple, but each version will be a bit different, because different parts will be moved around, hidden, and so on. I've gotten quite good at building models with a lot of clone parts, and so forth, due to work elsewhere, so I'm thinking that I can probably pull this off. If you see the rocks and various other flora in those shots, especially that hillside one- that's
one object you're looking at! Pretty major COB required, and a very interesting .S3O, but not rocket science!
So, basically, I do *not* want to take away control from mappers. In fact, I want to make it possible for mappers to build much more interesting content, and lower the amount of time it takes them to build great maps.
Random placement of objects will help a lot, because instead of a static work of art, you can have non-static elements, mixed with static ones, to make player experiences never quite the same way each time, and if I get my wishlist items (that blocking-map thing is one of them), you'll be able to make very sophisticated stuff, but with much higher performance than with static Features, and much easier to work with.
But you do not have to go the random route. You could use this stuff to build totally static maps, but with much more interesting content. At first, this is going to be in the control of game designers (i.e., me, P.U.R.E.'s next version, as a showcase), but I'd like control to revert to mappers, where it belongs. Gadgets can be run map-side, and this is probably the place to do this.
Ooh, and I should note, also... that this
finally provides a very, very concrete reason to pool stuff together, and build "feature packs", like the olden days.
2. Units are absolutely reclaimable, if they are set to be (there is a reclaimable=0 tag for Units, IIRC, if not you can just make it take pretty much forever). The only major problem with reclaiming is that area-reclaim commands don't work on Units. That's not as big of a deal as it sounds, though, because with this stuff, you're generally going to use far fewer procedural objects than you'd use Trees, for example.
Trust me, I've been testing everything
