Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Much belatedly
UPDATE
A replacement application is being developed by Tycho, tentatively named EVNMap. If you are looking for a graphical map editor, then try that application.
------------
A few people have opened topics or emailed me about EVN Cartographer; Specifically, looking for support or bug fixes.
I posted a reply in one of those topics that EVN Cartographer is no longer being developed, maintained, or supported, and have replied to the emails with similar news. Just want to put this in it's own topic so everyone can see it.
I should have done this five years ago or so, but here it is: The application EVN Cartographer is dead. I am not working on it at all and have no plans to do so in the future. I will not provide support for it aside from recommending the application be used as little as possible if at all. If you recommend EVN Cartographer to another, please inform them of this status (topic link code at bottom of post).
I am happy that so many found this application useful, but this is greatly outweighed by the sadness caused by the apparent lack of a replacement in all these years.
I'm sure the source code is still out there somewhere, as I distinctly recall distributing the code with the application. If anyone decides to make a replacement application feel free to use that code as a reference if you so desire*. If by some chance a replacement application is written using PHP or Python and is open source I may participate, but I will likely not start** such a project myself.
** I still like the application concept, but I refuse to work with the either of the Nova datafile formats either natively or through EVNEW. If EV4 is ever announced all bets are off. I have dreams of EV4 using something sane (possibly SQLite3) for its data files.
CODE
(topic="128362")EV:N Cartographer is no longer being developed or maintained, nor is it supported by its author.(/topic)
This post has been edited by Artanis : 18 June 2010 - 02:50 AM
QUOTE (Artanis @ Apr 21 2010, 06:39 PM) <{POST_SNAPBACK}>
I have dreams of EV4 using something sane (possibly SQLite3) for its data files.
The resource fork is old, but don't confuse that with bad. When Matt designed the engine circa 1995, it was by far the best choice he could have made. The operating system provided all the necessary routines, and best of all, everyone already knew how it worked and had the relevant tools.
If I were designing a new format from the ground up, though, it would probably involve bundles of property lists, PNGs, and the like — which are really the modern equivalent of the resource fork.
I wish I had the coding knowledge to update EVNEW with the graphical system placement from Cartographer, but unfortunately, my programming skills are pretty limited.
QUOTE (David Arthur @ Apr 22 2010, 07:57 AM) <{POST_SNAPBACK}>
Yes, I agree that the format was likely the best choice at the time. However that was 15 years ago, when the engine was Mac-only.
If I were designing a new format, it'd probably be similar to your idea, and go something like this:
plugin(.tar(.gz)) /plugin.db (SQLite3) /images /sounds /descriptions (other binary resources that don't work well in databases--this is an incomplete spec)
All the tabular data (numbers, short text, etc.,) ends up in the database. Images, sounds, descriptions (long text,) etc. go in the folders and are referenced from the db.
You can work on the data directly with whatever program you use to interact with those files (SQLite is a little more complicated, but it's well understood and easy to find something that'll let you directly edit it).
And distribution is a simple tar and gzip away. Write the programs that access the data to do so with it in folder form, tape archive form, and gzip form install is as simple as dropping the archive into the plugins folder.
Naturally there are disadvantages to this idea I haven't thought of.
QUOTE (krugeruwsp @ Apr 22 2010, 09:08 AM) <{POST_SNAPBACK}>
That was my first desire. Take EVNEW and add the feature. Well, back then I was young and new to application programming. EVNEW was opaque to me. Took 3 days to track down the functions that read and write .rez, and even then I could not makes heads or tails of it.
My programming knowledge is limited pretty much to Applesoft BASIC from my youthful days with an Apple IIC+ and enough UNIX to run the computers out at Kitt Peak National Observatory. In the silly astronomy world, everything is still command-line interfaces that haven't been updated since the early 90's. The .9m WYNN was just finally updated a few years ago to be able to burn data to CDs instead of just tape drives. Alas, however, that only gets me as far as moving files and working IRAF. I have thought about sitting down at some point and trying to work my way through something like Python, though, if for no other reason than to write scripts for Blender.
Hi guys, i find this discussion very interesting.
First off, if there's a need for this app, I wouldn't mind starting off a realBasic version. realBasic is like visualBasic. I believe it's what David Arthur uses for Mission Computer. It can compile for mac/windows and linux.
I figure this sort of thing would be best kept as open source, so that the community can continue to develop it. Who would like an app like cartographer and would be willing to work on it? Minimal programming knowledge required.
Secondly, Artanis and David, can you talk a bit more about a theorised plugin format? I have been working on one similar to what David mentions, with plists. plists are just xml and can be edited easily with a text editor and no real technical knowledge is required to (kind of)understand the content.
Thanks guys, tycho
QUOTE (Tycho @ May 3 2010, 02:15 PM) <{POST_SNAPBACK}>
First off, if there's a need for this app, I wouldn't mind starting off a realBasic version. ... I believe it's what David Arthur uses for Mission Computer.
Correct. I once started to rebuild it in Cocoa, and produced the best resource browser I've ever seen, but it was clear that rebuilding all the editors would take more trouble than it was worth.
I figure this sort of thing would be best kept as open source, so that the community can continue to develop it.
I'm not so sure about this: in the past, various people have released their partially complete editors as open source, expecting the community to embrace them, and instead they've vanished. (NovaBurst, anyone?) Open source only seems to work for things that very large numbers of people care about.
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?
I haven't thought it through in a great deal of detail. Presumably it would be a package containing property lists representing all of the systems, ships, and things, along with loose PNG images — and, potentially, 3D models if we're following through Matt's musings about using 3D rendering while keeping the current 2D field of play. This way, dedicated editors would be possible and helpful, but not required, just as the original format was open to everyone who had a copy of ResEdit.
Thanks for the reply David.
I'm impressed by your resfork browser. I pondered with the idea of making a macFUSE file system for doing the same thing, 'Mounting' a resource fork like a disk image. This would allow the user to use whatever editor they chose for a particular resource. Would you be interested in writing plug editors in cocoa? plists are a world easier to code with.
I'm not sure about Cartographer. I assumed it had a feature set, not present in other editors. Sometimes I read a post from a plugin maker where they are wanting to do something clever, but there is too much work involved or just not practical. I can't think of any real examples at the moment though.
Say the maker wants to have a spiral galaxy. Each system sits within the 'arms' of th galaxy. The closer a system is to the centre of the spiral, changes a variable of the spobs/ships/etc in the system. Perhaps the mining resources are more abundant. On the outer rim of the spiral would be hardly any resources.
If the maker had access to the source of an editor which could read/write plugs, with a bit a know-how or a good friend, they could autogenerate the data based on certain inputs relevant to the project.
If I were to work on a directory structure and xml/plist convention for a plug, could I get you to comment on it? I have been toying with core animation and have an initial format. Models in the plug is a good idea too. Do you know if Matt was thinking the models would be rendered as a standard EV sprite map or the models would be used in game alongside sprites?
Thanks a lot.
QUOTE (Tycho @ May 4 2010, 10:36 AM) <{POST_SNAPBACK}>
Would you be interested in writing plug editors in cocoa? plists are a world easier to code with.
The principal disincentive to writing new editors is actually not the difficulty, but the tediousness. Basically, the two challenges to implementing a new editor in MissionComputer are cramming all the fields into a single window while keeping it vaguely organised, and then staying interested long enough to get them all rigged to the underlying resource. This is why recent versions of MissionComputer have tended to focus on underlying technology rather than new resources, and why I stopped work on the ‘Beiderbecke’ project after I'd completed that resource browser.
Say the maker wants to have a spiral galaxy. Each system sits within the 'arms' of th galaxy. ... If the maker had access to the source of an editor which could read/write plugs, with a bit a know-how or a good friend, they could autogenerate the data based on certain inputs relevant to the project.
At one point TomWoozle was actually working on a programme called Systematic, which would procedurally generate star maps based on criteria like this. He showed screenshots which suggested it was fairly far along, but I don't think anything was ever released to the public.
If I were to work on a directory structure and xml/plist convention for a plug, could I get you to comment on it? I have been toying with core animation and have an initial format.
By all means, although I don't know how much useful input I could actually give. Really the structure should be whatever works for your engine, although the standard Mac OS X package format seems a good place to start.
Do you know if Matt was thinking the models would be rendered as a standard EV sprite map or the models would be used in game alongside sprites?
At one point, when Matt was tempted into musing about what shape a hypothetical EV4 might take, he suggested that sprites could be replaced with live rendering of 3D models, producing the same ultimate gameplay, but with more advanced visual effects. Presumably, you could have rotating turrets, fighters emerging from a visible bay, smooth banking, Ares -style zooming, and other such things.
Of course all of this is contingent on finding someone to write the thing who doesn't have Matt's memory of how much work EV Nova turned out to be.
I know of a reason as to why a new program similar to EVN Cartographer would be a good idea: Windows users. There are plenty of plug-in makers out there who don't have the option of using a Mac and thus can't use Mission Computer, our own StarSword is one of them. From what I've heard, EVNEW doesn't do what Cartographer does.
I support Tycho's willingness to make a new program. I can't help in any way (no programming skills) unless plug-in making counts as enough skill for something like this.
QUOTE (darthkev @ May 4 2010, 04:16 PM) <{POST_SNAPBACK}>
I know of a reason as to why a new program similar to EVN Cartographer would be a good idea: Windows users. ... From what I've heard, EVNEW doesn't do what Cartographer does.
And I would, for reasons that are at most mildly cryptic, be interested in knowing exactly what functionality Windows users are lacking with the loss of this programme.
If I understand StarSword correctly, EVNEW has little in the way of star map editing. Having never used the program, I can't say for sure, but this is my understanding.
is anyone able to write a bit of a design for a replacement to cartographer?
what functionality is required? -as far as i can tell, a graphical editor for the placement of systems
what would be good to add as extras? -syst/spob editing -graph/formula based placing of systems -auto populatesysts with spobs
what's a good UI?
This post has been edited by Tycho : 05 May 2010 - 09:19 AM
QUOTE (David Arthur @ May 4 2010, 05:35 PM) <{POST_SNAPBACK}>
QUOTE (darthkev @ May 4 2010, 08:30 PM) <{POST_SNAPBACK}>
This is correct. The most recent construction problem I faced in EVN:UGF (apart from choosing which ship-change operator to use for upgrade OUTFs) was that EVNEW's interface, while effective for most purposes, is purely textual (except for graphic resources). I needed EVN Cartographer, a separate program, to be able to see what I was doing when I was building the starmap. Without Cartographer, when I placed new systems I would've essentially been guessing what the result would actually look like.
QUOTE (StarSword @ May 5 2010, 10:32 AM) <{POST_SNAPBACK}>
Without Cartographer, when I placed new systems I would've essentially been guessing what the result would actually look like.
So we're talking about a programme that allows you to place systems and planets on a map resembling the in-game one?
QUOTE (David Arthur @ May 5 2010, 11:12 AM) <{POST_SNAPBACK}>
Yes, exactly. I've attached a screenshot. EVN_Cartographer_screen.GIF (68.15K) Number of downloads: 29 (In case you're wondering, the map in the screen is from EVN:UGF: the bottom half is the Milky Way, the upper half is the Andromeda Galaxy.)
This post has been edited by StarSword : 05 May 2010 - 10:39 AM
More or less. There's quite a few things that it would be quite nice to get EVNEW to do. Map functions would be outstanding. EVNEW, as previously mentioned, works fine. You can edit everything that needs editing.
My EVNEW wish list would be something like this:
1. Cartographer/Mission Computer style GUI placement of systs and spobs. Currently, what I do is use a sheet of graph paper where I graph out all of my system placements and hyperlinks. I then have additional sheets of graph paper for each system for all the spobs. I have a 3" binder stuffed pretty full from a TC idea that I started a few years back and later abandoned.
2. Ship resources would link directly into appropriate desc, rleD, shan, and pict resources, combining these all into one nice dialog box or tabbed box.
3. In fact, linked resources in general could be placed together, i.e. spobs would link to the rleD and descs for planet landing, bar, or landing pict resources, and outfits could link directly to desc and pict resources. Weapons would show the weapon rleD, perhaps a range-finder (I'm thinking a simple red circle?) associated outfit, or whatever else needs to be in there.
4. This would be an insane amount of work and probably really unnecessary, but a Nova emulator that would test resource functionality. In truth, this is probably not needed, as the debuglog and pilotlog can be used perfectly effectively for this function. If there would even be a way to launch Nova directly from EVNEW, that might serve effectively, but again, this is simply a convenient shortcut that any taskbar can do perfectly. Or, if there would be a script that would essentially load Nova and output the debuglog.
Lately, since I've gotten my hands on a G5 Mac, I've been enjoying working with Mission Computer. I have simply been doing everything with .rez files and testing everything on my Windows machine. For some reason, the plugs I've been working on work perfectly on Windows, but choke on Mac if I save the resource file from a .rez to a Mac plug-in file. Debuglogs haven't been particularly helpful. I greatly enjoy the Mission Computer interface. It would simply be nice to be able to have that same functionality on Windows.
By the by, what ever happened to RezEditor? I think that was supposed to do some of these things, right?
StarSword: What exactly do the 'External', 'Internal', and 'Display' tabs do? Does the programme also place spöbs within the system?
QUOTE (krugeruwsp @ May 5 2010, 12:22 PM) <{POST_SNAPBACK}>
Currently, what I do is use a sheet of graph paper where I graph out all of my system placements and hyperlinks.
This is apparently how ATMOS did it too.
Ship resources would link directly into appropriate desc, rleD, shan, and pict resources, combining these all into one nice dialog box or tabbed box.
My experience is that unless it's absolutely necessary (e.g. in the star map editor), you want to avoid having any one editor handling multiple resources at the same time. Otherwise, the potential for conflicts increases exponentially.
For some reason, the plugs I've been working on work perfectly on Windows, but choke on Mac if I save the resource file from a .rez to a Mac plug-in file.
What sort of choking, exactly?
By the by, what ever happened to RezEditor?
I suspect it's joined EV-Edit, Schmelta-V, EEEV/Override Override, NovaBurst, EVONE, and all the other such utilities in the great add-ons directory in the sky.
For some strange reason, the if I open a .rez in Mission Computer, change it, and save it as .rez, it works great on my HP Notebook. If I open a .rez in Mission Computer, change it, and save it as a Mac plug-in, Nova doesn't seem to actually load it. The odd thing is that according to the debuglog, it does, but none of the changes show up in-game. I've tried starting new pilots with the plugs loaded, all sorts of things. It just doesn't want to cooperate for some reason. If I take the exact same plug in .rez format, it works flawlessly on my PC.
Makes sense on editors handling multiple resources at once. In truth, the way EVNEW handles it isn't terrible, just a bit tedious. I just keep a notebook next to me and write down all the associated ID's and such. Lately, I've been using Microsoft OneNote instead of a paper notebook for everything but graph paper, more to save space than anything else. It would be nice to implement a slightly more elegant or convenient solution, but certainly unnecessary. The graphical star map editor would be the nicest thing, and probably the only wish list item of any real importance.
Of course, a Windows build of Mission Computer would also do the trick... (I know, I know... not likely...)
This post has been edited by krugeruwsp : 05 May 2010 - 02:46 PM
krug, what happens if you open a .rez plug-in Mission Computer and then save it in Mac format without changing anything? Does it still choke or does it work then?