EVN Cartographer is dead.

I apologize for dredging older posts to reply to. My topic subscription seems to have broken, so I'm refreshing it with this post.

QUOTE (David Arthur @ May 4 2010, 06:46 AM) <{POST_SNAPBACK}>

Come to think of it, what exactly are the functions of EVN Cartographer? From the name I've always assumed it to be on the same level as Pontus's old EV Developer's Map, or MissionComputer's map editors (which were themselves originally called Cartographer). Is it just for graphical placements of systems and planets, or are there other abilities that need to be replaced?

Between the screen shot you've already seen, and what StarSword's explanation of the UI comes close to the entire feature set.

IIRC, you could place systems by clicking on the map (is there dragging?), link (jump, hypergate, and wormhole) and populate systems (stellars, ships, etc.), adjust system environment settings, and import from and export to EVNEW's text format. The import/export functions handled the entire EVNEW csv file, storing the other resources and writing them back to the file properly.

There were a few things I was doing before the code became unmanageable. I don't believe they ever got released, though. I had a pretty decent method of generating a random map from a gray scale image (brightness as system density), and a series of auto-linking algorithms (nearest-n in min/max range, web, and one or two others) based on the linking types found in the Nova universe.

I wouldn't be kidding when I say you could draw a shape in Photoshop with a large, fuzzy brush and have Cartographer make a nearly-ready-to-fly galaxy with little-to-no interaction.

QUOTE (Thom @ Jun 11 2010, 01:45 PM) <{POST_SNAPBACK}>

I'd go a step further and use human-readable data files, such as YAML. In the first place, this would obviate the need for special software to write plug-ins; you could use any text editor on any platform. If desired or necessary for performance, the game engine could keep a cache of the scanned and processed data as a database or even simply as a blob and simply scan all plug-ins' metadata on startup to determine whether each one needs reprocessing.

YAML looks interesting. Wikipedia assures me it has some relational capabilities (I especially like the auto-expanding of referenced data). If those references can work across multiple files--if everything is in one file you'd be looking at multi-megabyte files in notepad/textedit; Definitely bad news for notepad, and I think even gEdit would struggle with it--then I think that would be better than my SQLite idea. (edit: anchors/aliases are within document only, doesn't looks like you can reference an anchor in another document, much less another file.)

I'm going to look into that some more, I may be able to solve a similar problem in one of my current projects with it.

This post has been edited by Artanis : 14 June 2010 - 04:08 PM

QUOTE (Thom @ Jun 13 2010, 05:53 PM) <{POST_SNAPBACK}>

I guess that "special software" is a relative term, but I think we can agree that a resource editor is more special than a text editor. The fact that only two products were even available is evidence toward that

Oh, there were plenty of others, but the main two covered everything that anyone could want. Given that ResEdit was great and free, I'm surprised even Resorceror survived so long. Resource editor may be more special than text editors, but they were many times more common in 1996 than the 3D modelling software needed to create proper graphics for Escape Velocity plug-ins.

What it comes down to is that, yes, the resource fork would be a downright bizarre choice for a new game being made today, but if Matt had done Escape Velocity any other way, I doubt anyone would still be talking about it now.