Geography Tools

I just thought I would say that this tool would be very VERY useful to me, as I am now starting work on redesigning the cluster for Epic: Middle States. I am wondering if there is any eta on a semi-working version?

Update of great crapness: Sorry everyone, not giving this as much time as it deserves. There is no eta.

Image test:

Sorry SO BIG - just wanted to make sure that everybody could see it.

Ha! It's been a while... Just popping in, to keep some hope alive.

Hopefully, the screenshot makes it...

First, no ETA on the first public Beta (we're still implementing “proof-of-concept� code on some of the alpha stuff)... Ironing out our own and working around M$ library bugs.

Found the source code for an Lightwave Object viewer (we're modifying the code to import the games LWO models into the SDK)... That way we'll be able to see the same in-game models of each entity as opposed fabricating approximate models. The first public release will have the models, but NOT the textures.

We've set the freeze on features, for what we want the beta to do... Now we're in the process of implementing the 3D engine, testing the data entry forms, and expanding the options dialog.

As for the screenshot... the very much simplified interface of the SDK. The TreeView inside on the first tab. When the mouse is hovering over a node, a tooltip showing the highlights of the entity will appear – highlights include: faction, population, 3D coordinates, etc). Right clicking on a node will present a context menu to allow the insertion\removal\addition of entities. Double-clicking on a node, will activate the second (Entity) tab, where data entry takes place (names, etc). Single clicking on an entity, will zoom the 3D view to the selected entity. Ignore the checkboxes next to every entity... They're only going to be visible next to each system (So that the SDK knows to comment out\disable the system in the clusters.ini file). We're adding the code to hide the extra checkboxes, but that will come later.

Of course, the big black space on the right, is the 3D view... The visual playground. Right now it's just a blank canvas. In the initial beta, we'll have lighting\backgrounds and the ability to pan\zoom\rotate through the universe and each individual entity. Can also add\remove individual and grouped entities. This is also where positional tweaking can be performed\visualized. The second public beta WILL have texturing with full blending\effects. Ultimately, the groups final goal is to get the SDK as close to WYSIWYG as possible.

I keep pseudo-regular updates at: www-livejournal-com / ~tech2kjason (dots instead of dashes, and no spaces).

Also found a toy (not free, but cheap) “3D Object Converter� currently supports 410 3D model formats… It’s inexpensive in the sense that once you buy it, all future versions\upgrades are free, but it supports loading\converting of several formats that I have never heard of before: web.axelero.hu/karpo/

In any case, still alive over here, and figured I'd give this thread something to look at.

Oh! The SDK knows what maps are available by parsing the clusters.ini... FOR THE BETA, we need to establish\make certain that a standard is in place for the commenting of disabled/blocked systems (particular emphasis to the number of spaces between the semi-colon and the first character of the entry string). I think we've compensated for most of the possibilities, but if there are any "; system[4] = map:path/myname/etc this was hidden by me" type scenarios (that extra comment at the end), the SDK will currently strip the trailing comment (since it does not expect any spaces in the filename). It keeps the original comments of the clusters.ini (by keeping EVERYTHING above the "" line... Any examples\extra comments should be placed there (as every commented system, label, etc after the line, will at least be tried by the SDK. DO NOT MOVE COMMENTED SYSTEMS ABOVE THIS LINE UNLESS YOU DO NOT WANT THEM TO APPEAR IN THE SDK.

Also, incomplete maps... The SDK will reject an entire map, if there is an entity that does not have AT LEAST: an entity type, a name, or the map does not have the trailing L-Point table. It rejects the whole map, because without that information, it doesn't know anything about the entity, and breaks the dependencies of any children or following entities. It will allow an entity that only has a type and a name... It will focus on the entity, so that the position, and other data can be added (but if any 2 or more entities [L-Point inside a planet for example] overlap or occupy the same space - it will prompt for additional information or confirmation to seperate the entities)... If the SDK seperates the entities it will maintain the entity relations, and slowly move them apart until they are no longer overlapping.

Minimal map: System center, L-Point, and L-Point table.

The SDK will maintain rules of the original game (Parents of L-Points, etc). HOWEVER, if for some reason you want an L-Point to be parented by 2 stations - just be prepared to be reminded of this oddity every time the SDK updates the Work-in-Progress files.

There's more, but I just thought of an SDK correctable scenario... back to the coding.

Fantastic! I am really glad to see you guys alive and well.

Thanks for the update! I look forward to seeing it when you finish it.