Having admitted to being unable to use modern IDEs, along with all your other examples of being rather inexperienced, do you honestly think you are the right one for the job of writing yet another How To Code book?
However, for now, I'll just reach out to that developer of "block puzzle" and ask him directly what's going on there...
IANAL and all that, but don't do this. Every contact with this guy should be through your lawyer, for your own protection. Clearly "what's going on there" is that he hopes to intimidate you, extort you for a little bit of cash, and remove a competitor. Contacting him won't solve anything, and could in fact cause potential complications if/when it does go to court.
I like Blender, though I haven't really been using it for all that long. A couple years, maybe. I've dabbled with 3D Studio and (briefly) Maya, but neither really gelled with me. (Price might have something to do with that.) Blender is nice, and I really don't see why everyone bitches about the interface. Pre-2.5 and above, yeah, it was kind of a mess, but lately it's pretty nice.
Create a number of different variations that tile together, and select randomly. If you wanted to get more complex, you could use a Wang tiling scheme ( http://en.wikipedia.org/wiki/Wang_tile ) but doing so would complicate both your tile generation and your auto-tiling filler routine.
You know that you can use full 3D and get the exact same effect as 2D, only without the stupid pain in the ass ordering problems, right? For example, see http://www.gamedev.net/topic/629496-dynamic-objects-in-isometric-map-drawing-algorythms/#entry4968844 Old isometric was pretty much intended to get around the limitation of having old cruddy hardware that couldn't do real 3D. As soon as real 3D capabilities came around, it just wasn't necessary anymore. You can the exact same look by plastering your pre-rendered stuff on some quads.
dejaime Thanks, I understand what you are talking about, and indeed my interest is "doing it my self" rather than "doing it asap".
AgentC You are correct. This is the reason that after two pages and (my assumption) at least 14 different engines suggested in the topic, I still can't find the right one for me. One reason is because I'm having other things right now and didn't check the engines too deeply, but mainly because from what I checked, none of them matches the need of being more than raw OpenGL but still allows me to enjoy programming and reinventing the wheel. But that's me..
A huge part of modern development is learning to be flexible enough to make do with what is available. If you haven't found what you need yet among these suggestions, it is highly likely that what you are looking for doesn't exist. Your choices in that case are 1) Make one of these options work or 2) Build it yourself, and prepare for a long development cycle, since you have a fairly hefty feature list, and building such a beast is not a trivial task.
To drop in my own particular 2 bits: I second the Urho3D nomination. JT turned me onto it awhile back, and it is a pretty neat little engine. Of all of the mentioned options that I have personal experience with, it seems to be the closest to your original requirement list.
I recommend you read this blog post (it's part of a series which is itself pretty interesting) talking about one developer's experience with trying to use Qt for his main game UI, and the performance problems that it caused him. Qt is pretty heavy-weight. It's useful as hell, but that usefulness comes at a pretty significant performance cost. It really isn't designed for game UI. Game UI tends to be more highly specialized, since it needs but a fraction of the features something like Qt provides, and as a result tends to be more highly performant. CEGUI was built more with games in mind than Qt, but it also offers a measure of flexibility (and the attendant complexity).
Depends on how mature it was before it was abandoned. If it was fairly mature (ie, no game-breaking bugs) then no biggie. Additionally, it depends upon your ability and willingness to fix for yourself any bugs that do occur. If it's so complex that a bug would stymie you, then maybe don't use it. Finally, it might also depend on the availability of other, more active, libraries that can fill the same need.
One quick and hacky way to do it is to advance along the curve using very tiny increments of the curve parameter, s, accumulating distance as you go until you reach the distance you want to move. It's not as elegant as a numerical solution, but it's easy to do and should probably be fast enough for most applications.