QUOTE (David Arthur @ May 5 2010, 01:53 PM) <{POST_SNAPBACK}>

StarSword: What exactly do the 'External', 'Internal', and 'Display' tabs do? Does the programme also place spöbs within the system?

Simple first: the Display tab is just display preferences for the interface ("what colors should Cartographer use" and so on)

The External tab (shown in the previous screenshot) lets you name the SYST, numerically adjust its position (In one case, I ringed a capital system with outer defense SYSTs at equidistant locations), and determine which SYSTs it links to.

The Internal tab lets you determine background color, murk, interference, average number of AI ships, which SPOBs are in the SYST (though not their positions), and which DUDEs to use and how often.

QUOTE (Tycho @ May 5 2010, 10:09 AM) <{POST_SNAPBACK}>

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?

• -basically the EVN map, but resizable
• -floating palette of tools
• --stamp
• ---library/templates of systs
• --clone
• --join
• --cut
• ---hyperspace route
• -floating inspector window
• --inspect/edit syst details

I also encountered a couple of bugs that I detailed on the EVN:UGF thread. Number one, Cartographer can't seem to place SYSTs past (I think) 1126 (no idea why). I had to go back into EVNEW, create a crapload of blank dummy systems and reposition them individually to get to the current total. Number two, since EVN:UGF uses the original EVN map as a starting point, I had to delete a bunch of duplicate SYSTs (ones that were involved in bitwise SYST changes), and then add new ones in the middle of a big gap (the Polaris have left the building, as it were). When I did that, Cartographer started adding SYSTs in the wrong order, which screwed up EVNEW's conversion function (EVNEW can convert files from REZ to TXT and vice versa, which can help in batch editing); I had to go into Notepad and reorder them manually. (See the EVN:UGF thread for the details.)

This post has been edited by StarSword : 05 May 2010 - 09:11 PM

QUOTE (krugeruwsp @ May 5 2010, 05:22 PM) <{POST_SNAPBACK}>

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.

Almost, at least. What were those resources that determine the location of buttons called? From what I can see, they do exist for .rez files, but EVNEW can not edit them.

They're the DITL and DLOG resources. And actually, even Mission Computer doesn't strictly have editors for them. They're there, but in my experience are iffy in terms of functionality.

QUOTE (krugeruwsp @ May 5 2010, 03:45 PM) <{POST_SNAPBACK}>

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

Now that's odd indeed. I assume you've tested to make sure that plug-ins from other sources do work when installed in the same manner?

QUOTE (krugeruwsp @ May 5 2010, 03:45 PM) <{POST_SNAPBACK}>

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.

My compromise is usually to provide a hotlink to the editor for each associated resource, rather than trying to handle it in-editor.

QUOTE (krugeruwsp @ May 5 2010, 03:45 PM) <{POST_SNAPBACK}>

I know, I know... not likely...

Not a full-featured one, anyway.

QUOTE (darthkev @ May 6 2010, 05:31 AM) <{POST_SNAPBACK}>

They're the DITL and DLOG resources. And actually, even Mission Computer doesn't strictly have editors for them. They're there, but in my experience are iffy in terms of functionality.

What specific problems do you have with the DITL/DLOG editors? They've had various problems over the years, especially with the odd conversions the system performs on Intel-based computers, but as far as I can tell the current versions seem fairly consistent.

Yep, I've tested other people's work and my own, both changing things and just converting through MC. Now, I don't know if the problem is that I'm running 1.1.0 on a G5 iMac? Nova just doesn't seem to like the converted .rez files. They run perfectly on my HP notebook, though. Basically what I've been doing is just using MC to do all my resource editing, and my notebook to do all of my testing. It works for my purposes. I haven't tried using the standalone Mac converter, however.

krugeruwsp: This is odd indeed — there shouldn't be any way in which 'converted' plug-ins could be different from any other kind. Has anyone else noticed anything like this?

In other news:
http://davidarthur.evula.net/beta/duessa/rled_6may.png
http://davidarthur.evula.net/beta/duessa/starmap_6may.png
Not everything works, it's a bit crashy, and so far I've only tested it under WINE for want of an actual Windows machine in the immediate neighbourhood, but the main thing is that something I nearly posted as an April Fool's Day joke a month ago now exists for real.

Regarding problems with the DITL and DLOG editors, I was referring more to the fact it's a bit odd-looking and not very clear on what does what. I haven't tried doing very much with them in MC simply because those, when opened in MC, look like the kind of thing one shouldn't mess with unless they absolutely know what they're doing.

So yeah, it's messy.

krug, I ask again, what happens if you simply convert a .rez plug-in without changing anything?

QUOTE (darthkev @ May 6 2010, 01:44 PM) <{POST_SNAPBACK}>

Regarding problems with the DITL and DLOG editors, I was referring more to the fact it's a bit odd-looking and not very clear on what does what.

Oh, that's just because the game uses its own custom controls rather than standard ones. All of the in-game dialogue boxes are therefore full of user controls — empty boxes that get filled at run-time — rather than real buttons and things, so you have to guess by position what each one does. This isn't something that an editor can ‘fix’.

Thought I mentioned that... oh well. If I just convert a .rez without changing anything, I still get the same thing: nothing happens, but the plugs show that they have loaded in the debuglog. If I create a file entirely in MC starting with Mac plugin format, it works fine with exactly the same numbers and images and everything. NDAT does the same. Converting files from .rez seems to be the issue. I don't recall exactly off the top of my head which Mac OS I'm running, but it's on a G5 iMac.

DA: The resource browser looks good. If you'd like, I would be absolutely enthralled to test it for you. Shoot me a PM and I'll send you a wave with my e-mail if you want.

This Windows version is still very experimental — I just took the requisite technology live on the Macintosh yesterday, and on WINE today, as you can see from the clock in the screenshots. (Essentially, it's a small-scale Resource Manager clone that I originally started in March 2007 as part of 4.0 that got pushed back. Using it, MissionComputer is able to read, edit, and write .rez files without depending on Mac OS technology, though I haven't yet found a way for it to read PICTs or snds.) Not all of the editors are even adapted to function under these conditions.

I've made no secret of the fact that I've had MissionComputer running on Windows for years in some form or another, but this is the first time it's actually been able to open a file and display resources. If it does develop into something useable, I'll probably post public preview releases like I did for 4.0, but that's still some distance away. The relevance to this thread is that I'm thinking there may be some middle ground in terms of getting a version that's good enough to fill the role played by EVN Cartographer, but doesn't port over all of the Macintosh version's functionality.

QUOTE (krugeruwsp @ May 6 2010, 03:13 PM) <{POST_SNAPBACK}>

If I create a file entirely in MC starting with Mac plugin format, it works fine with exactly the same numbers and images and everything.

Now that's strange indeed. Could you post a copy of a small, non-working plug-in?

I'm curious. You wouldn't happen to be running Snow Leopard, would you krug? If so, I'm fairly sure that could be part of the problem. It seems to have been causing problems for many lately, problems I haven't experienced while also not using Snow Leopard.

It's possible, though I don't think I am. I'll check the version as soon as I remember to do it. However, I don't think that a G5 iMac could run Snow Leopard, could it? My Mac knowledge has gotten quite rusty over the years. I grew up with System 7, but have had nothing but Windows since going to college until picking up this secondhand Mac more or less for the express purpose for Nova and a few UNIX based astronomy utilities like IRAF. Still do a bit of research with the university for funsies.

DA: Would you like me to post it as a .rez or as a Mac plug-in? Or would you like me to post both for comparison?

Post the Mac plug-in, so I can see if there's anything strange about it.

No, 10.6 is Intel-only, so your iMac G5 couldn't be running it.

Quick note that I am having no problems running MC on 10.6 (4.0.8). I am having some problems with Nova itself, but nothing with editing so-far (which I have only re-begun recently).

this is what i've been working on, so far
http://www.ambrosiasw.com/forums/index.php?showtopic=128516

i hope you guys can test for me. thanks

QUOTE (Artanis @ Apr 22 2010, 06:38 PM) <{POST_SNAPBACK}>

If I were designing a new format, it'd probably be similar to your idea, and go something like this:

CODE

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.

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.

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

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.

This was the rationale behind using resources in the first place, but with any format this complex, doing it in a text editor is going to be a substantial amount of work, just as there was an instant demand for purpose-built EV resource editors. That said, I do support a human-readable format, probably an XML property list one that fits into Cocoa structures easily.

Resources, while efficient, were hardly flexible. You needed special software (a resource editor) and special templates for that software (Nova tools). What those tools got you was more or less the ability to type in the values manually. With a decent data format, that comes for free.

Also, I know this is a bit of a divisive issue, but XML isn't really the best format for representing data; it was never intended to be. XML requires tremendous line noise to accommodate anonymous text nodes, which are a necessity for document markup and of little use for data storage.

QUOTE (Thom @ Jun 12 2010, 10:39 PM) <{POST_SNAPBACK}>

You needed special software (a resource editor) and special templates for that software (Nova tools).

In 1996, a resource editor was in no sense 'special software'. Anyone who was remotely qualified to write a plug-in could be counted on to understand resources and have ResEdit (or its leading competitor, Resorcerer): they were fundamental parts of understanding development, or even customisation, on the Macintosh System Software of the day.

The NovaTools editors came much later, as the format became more complex. All the original game required was a simple collection of templates, which were nothing more than a list of fields and their types; these were included with the EV Bible package, in both ResEdit and Resorcerer formats.

The format is definitely showing its age, and wouldn't be a reasonable choice now, but don't underestimate how simply and elegantly it worked back when Matt made the decision. It allowed the game to rely entirely on the system to handle its data, in a format which third parties could understand without special knowledge or tools; the entirety of the game's data could be split among a few files, which meant a lot more in the days of 120 MB hard drives; and the Resource Manager's patching system was what made plug-ins possible in the first place.

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. I do remember the original ResEdit templates; true, they were simple, but they were still special software from Ambrosia that was necessary to edit the data files.

I'm not saying that resources were a bad choice at the time – the extra storage and parsing overhead for a text-based format is insignificant today, but was a real concern fifteen years ago.