Wow, long post. I'll go piece by piece. I think in most instances the underlying reason will be just that this is an early early build, and I released it as soon as it was usable at all.
A visual oddity in the gui the first time I started 0.70.0, but never after:
Weird. Never seen that, and if it only happened once I have no idea what could have happened.
Cancel doesn't do anything (at least, Windows 7).
Yeah, didn't get that far. Eventually upon startup users will be able to select their desired geometry generator and set options for it. Cancel will mean something then, so you can go back and change things. Right now it's the first thing that shows up, so there's really nothing to cancel. Also, I'm sure you noticed, there's an X in the upper right of the open dialog that similarly currently does nothing.
Is the user supposed to be able to resize and maybe even maximize the window? Because whenever it gets focus it locks the mouse in such that you can't access the sides/buttons, which makes them a tad tantalizing.
Not without breaking the mouse out of the window, at least yet.
Hitting alt-f4 instead of escape crashes it with no apparent error in the log that I noticed (although this should be easy for you to reproduce and figure out what's going on if it's not an oddity with only certain hardware or OS versions; but let me know if you want to drop in the logs from doing that anyway). Haven't tried changing focus and then hitting the red X button in the upper right of the window.
Thanks, probably forgot to properly destruct things in that instance. I'll make sure it does the same thing as Escape.
I commented out the line in plugins.cfg referring the DirectX, rather than dig out the official Microsoft install (of the whole thing or the particular dll). Obviously the program's interface has a certain level of capacity to handle exceptions and a certain level of ability (as its rendering subsystem has specific dlls for its use of DirectX and of OpenGL specified in plugins.cfg) to not bother loading dlls if it's not asked to (something I'd love to know how to do in c++, incidentally). Could it be made to simply check which libraries are useable rather than needing plugins.cfg and failing if it finds one of those specified in it isn't there or isn't useable?
If I'm not mistaken, on Windows OIS (the input system) requires DirectInput, so the presence of DirectX is required even when you're not using Direct3D for rendering. Outside of that -- this is an Ogre-level issue, and would require changing the Ogre library.
Could we get a button to skip to night or day, in the event we wanted to not have time pass while we're viewing but be able to view in night or day?
Yup, finer controls like this will all have a graphical interface eventually.
I assume fortifications and stairs are in the works, but could we also get floodgates, bridges and doors?
Yeah. Stairs are really tricky, and fortifications are even trickier with the current generator. It'll take a lot of thought to get those in and working. Bridges, floodgates, and doors are all easy though, and will all go in at the same time.
If we do, could there be (a) button(s) to toggle their state (open/closed, raised/lowered/flat-out-hidden, that sort of thing)?
Yup. I plan to make all non-world-geometry objects interactive, so if, for example, a staircase gets placed backwards, you could rotate it.
Could a box be put around the edge of the map below the ground level so that when viewing underground areas the sky doesn't shine through?
Yup, when I get around to it. That's a lower priority than improving the geometry generator and getting stairs and such in.
Is there a way to make trees smaller so that I needn't have especially tall z-levels to prevent trees that are floored over (to make ceilings outside) from sticking through the "ceiling"? I realize that changing this would make forests seem less dense; a user-configurable setting would probably be ideal, if it's possible. (I think I may have seen some discussion of this a while back, but I figure it can't hurt to ask -- it might even be in the settings and I just didn't notice skimming them.)
There's an all-vegetation scale value in overseer.ini, and you can control the sizes of individual species in xml/plants/*.xml.
There's a funny tendency for 1) trees to appear before Overseer has finished putting in all the map below them, and 2) trees occupying a rectangle within range of the camera to appear weird when the camera is a fair distance above the ground. Do I need to tweak the settings for tree distances, or are we waiting on more/better imposters for those distances that suddenly cut off to no trees, or what? (I'm pretty sure some combination of these should make it look... well, less funny than it looks to me using the default settings presently. But I'm no expert on what's going on and figured I'd ask first to get some pointers before trying to "fix" it myself, and then once I have a basic idea what to try start fiddling.)
They page separately from the world geometry. For world geometry I'm using a custom paging solution, and for plants I'm using
Ogre PagedGeometry. Honestly, I don't know a single thing about batching and impostors.... no clue how I would implement it myself if I had to. The trees show up first because PagedGeometry is able to get them onto the screen rather quickly, while PolyVox's SurfaceExtractor is crunching away on large chunks of voxel data that take much longer to prepare (PagedGeometry loads models directly -- PolyVox has to generate the 'models' manually).
For the distance thing, yeah, you'll need to modify visible tree distances. There'll be a GUI setting for that eventually as well, just like everything else.
You know how it pulls back a tiny bit when you stop moving? Sometimes that jerks me back farther than I'd moved in the first place. And sometimes after I've moved it leaves me in one spot but wiggles until I move again.
Yeah, and it's really damn annoying. I need to look back into that. It only happens for me when my framerate is low enough.
Could we have forward/backward never move up or down, and up/down move up and down only, regardless of camera up-down angle? It'd make floating around at odd angles so much easier.
I can make it an option. I know that this setting would bug the hell out of me.
And you're right about the ceilings, I hadn't considered that ceiling tiles weren't revealed, and all of my test maps were made with "mapexport all". I'll have to account for that.
Thanks for all the input! Sorry that it's so bare-bones right now, I just want to get everything working before I try to make it too fancy, and I only have limited time to actually work on it. Current priority for me is implementing dual contouring to replace PolyVox's marching cubes extractor. That'll let us set "hardness" of Voxels, and keep sharp edges on constructions while leaving natural terrain smooth. It'll also let me decrease the polygon count significantly (hopefully) and possibly significantly reduce the number of voxels required to store a tile (which, incidentally, will also make smoothing on terrain work a lot better). It'll also let me define visible boundaries between types of voxels -- which will let me implement voxel transparency for things like water and glass. Plus, if I make the voxels surrounding staircases harder than other voxels, I won't have to worry about the effects of smoothing making the staircases look terrible.
Or at least, that's the plan/hope. We'll see how it all turns out. And remember, even if it takes me a long time to get around to your suggestions -- they're not going unnoticed!