PICT and snd are two of the biggest unanswered questions — in both cases MissionComputer normally relies on standard Macintosh routines, as the resources aren‘t particularly suited to manual interpretation. Even EVNEW relies on QuickTime, doesn’t it?

I'm not actually sure. I would guess so.

A lot of the old formats aren’t particularly congenial, having been designed in the 1980s with their primary goal being efficient decoding on slow hardware, rather than portability and simplicity. It took ages to write my own cicn decoder, and the encoder still isn’t done — and PICT is far worse. I’ll explore the possibilities for calling in QuickTime for Windows the way that EV Nova itself and presumably EVNEW do, but for the moment my focus is on more basic functionality.

And if anyone is still having trouble telling what was and was not an April Fool’s joke, the Windows 3.1 version has been delayed until 1994.

Dang it... I can't seem to find a viable link to the EVNEW source code anymore. I don't suppose anybody still has it?

@david-arthur, on 09 April 2011 - 01:18 PM, said in MissionComputer: The Saga Continues:

PICT and snd are two of the biggest unanswered questions — in both cases MissionComputer normally relies on standard Macintosh routines, as the resources aren‘t particularly suited to manual interpretation. Even EVNEW relies on QuickTime, doesn’t it?

Yes, it does.

@krugeruwsp, on 09 April 2011 - 03:06 PM, said in MissionComputer: The Saga Continues:

Dang it... I can't seem to find a viable link to the EVNEW source code anymore. I don't suppose anybody still has it?

Try contacting Aprosenf by email. No idea if that address is still valid, though.

This post has been edited by StarSword : 09 April 2011 - 03:12 PM

I think I actually still have a copy somewhere. I looked at it a few times when I was implementing .rez, although the internal structure of the two programmes is so different that typically I looked at it, said ‘Yes, that’s a sensible way to do this’, and then did something completely different.

I know the various holes are frustrating, but I’ll try to plug them whenever I’m able to. For the moment let’s focus on the functionality and usability (and/or lack thereof) of the features which are present in the current alpha.

I surprised I didn't notice this earlier, but there is no shän editor.

So far, everything else seems to be working within all specified parameters. I did have one crash, but it was my fault, not MC's. I've rebuilt two small plugs from scratch in MC using the EVNEW file as a template, and so far, everything has worked just fine. The ship editor is so, so much more easy to use than EVNEW's, and I'm glad that I can now monkey with stuff on my laptop instead of having to try to trick this iMac I have at home into doing what I want. (I'm not opposed to Macs, but the one I have is in need of some serious OS overhaul and I don't have the time or patience to wipe it down and reinstall everything.)

The opening new windows does not bother me in the slightest. You could probably get rid of Mac-specific things such as the DITL and DLOG, and vers resources, or perhaps just gray them out in the Windows version? It's a pretty minor issue. I haven't had a lot of time to test things, but so far, I've been greatly enjoying what I have played with, and have not found anything that would qualify as a bug. The star map editor is greatly appreciated. Is it supposed to just show a big pink square for nebulae? I can't recall off the top of my head if Mac MC calls up the PICT for the nebula. No big deal if so or not. Still works great.

This post has been edited by krugeruwsp : 11 April 2011 - 08:29 AM

@krugeruwsp, on 11 April 2011 - 08:28 AM, said in MissionComputer: The Saga Continues:

Is it supposed to just show a big pink square for nebulae? I can't recall off the top of my head if Mac MC calls up the PICT for the nebula. No big deal if so or not. Still works great.

It does pull the appropriate PICT, but only if it's in the same file as the corresponding nëbu resource. Otherwise, it's a pink parallelogram.

Glad it’s working out!

@krugeruwsp, on 11 April 2011 - 08:28 AM, said in MissionComputer: The Saga Continues:

I surprised I didn't notice this earlier, but there is no shän editor.

Yes, shän is the most prominent EV Nova resource type for which I don’t currently have a graphical editor. I’ll need to do it at some point, but the calculations aren’t precisely documented, and an incorrect preview would be worse than none.

The Macintosh version fills this hole with a template script, but I haven't yet tested the template engine on Windows. There will probably be text-encoding issues, and I’ll have to find some alternative to including the template within the application bundle.

@krugeruwsp, on 11 April 2011 - 08:28 AM, said in MissionComputer: The Saga Continues:

You could probably get rid of Mac-specific things such as the DITL and DLOG, and vers resources, or perhaps just gray them out in the Windows version?

'vers' is pretty useless on Windows, I agree (and not even particularly valuable on the Macintosh these days). But is the same true of DITL and DLOG, or does the Windows version of EV Nova still use them to construct its dialogue boxes?

@krugeruwsp, on 11 April 2011 - 08:28 AM, said in MissionComputer: The Saga Continues:

The star map editor . . . Is it supposed to just show a big pink square for nebulae?

The pink block (a rough approximation of Escape Velocity ’s Serpens Nebula) is what it shows when the relevant PICT resources are missing. Since PICT support isn’t available on Windows yet, they’re always missing as far as the star map can tell.

If the Windows version of Nova does require vers, DLOG, or DITL resources, I'm not sure. EVNEW does not include an editor for any of them, so I'm guessing probably not, but perhaps they are just handled uniformly by the Windows engine, rather as a specific resource type.

'vers' isn't really required by anything; it just tells the Finder what version number to display in the Get Info window. It used to sometimes be used by installer/updater programmes to tell whether a file needed to be updated, but such things have mostly gone out of style.

DITL/DLOG, on the other hand, is what configures the layout of a dialogue box — where the various buttons and text fields can go. If the Windows version of the game doesn’t use them, it must have adopted some other way of handling the same information and converted all the data, which seems to go against the general philosophy of this particular porting job.

@david-arthur, on 11 April 2011 - 12:13 PM, said in MissionComputer: The Saga Continues:

DITL/DLOG, on the other hand, is what configures the layout of a dialogue box — where the various buttons and text fields can go. If the Windows version of the game doesn’t use them, it must have adopted some other way of handling the same information and converted all the data, which seems to go against the general philosophy of this particular porting job.

From what I can remember from the Empire port, DITL/DLOG appears to be used by the Windows version. EVNEW just doesn't have editors for them.

The DITL and DLOG resources are definitely used by the Windows version of EV: Nova. That’s how the Fullscreen Map plug-in works, and it works on Windows last I checked.

@david-arthur, on 11 April 2011 - 10:25 AM, said in MissionComputer: The Saga Continues:

Yes, shän is the most prominent EV Nova resource type for which I don’t currently have a graphical editor. I’ll need to do it at some point, but the calculations aren’t precisely documented, and an incorrect preview would be worse than none.

For prioritization purposes, I’d say the most important thing to preview correctly is weapon exit points. If the preview could do that, but could only display one RLE/PICT animation at a time (so the user could manually toggle between Base, Alt, Glow, Light, and Shield with no blending or overlay), that would be a huge boon.

Edit: As far as I can tell (looking at NovaTools in ResEdit) this is how exit points locations work:

For convenience, let us call the center of the ship’s base sprite (0, 0). If the sprite has an even number of pixels, say p = 2m, in some dimension, the center will be (m+1) pixels from the top left corner of the sprite in that dimension. For example, if a ship’s sprite is 2×2 pixels, the center of the ship will be the bottom right corner pixel.

For a given exit point, let x, y, and z be its offsets as specified in the shän. Let ux, uy, dx, and dy be the up and down compress values for x and y respectively. If any the compress value is less than 1 (so 0 or negative), it is treated as 100. Let the ship currently be on frame n of f total frames, so its heading (measured in radians clockwise from north) is 2π(n-1)/f, which we will call θ.

The first thing to know is that, when values are rounded to integers, they are rounded toward zero if the fractional part is less than 0.5 in magnitude, and away from zero if the fractional part is at least 0.5 in magnitude. So 1.3 becomes 1, 14.5 becomes 15, -4.4 becomes -4, and -8.5 becomes -9.

The z-offset serves only to shift the center about which the exit points rotate by z pixels along the y-axis (north if z>0, south if z<0). This amount is not affected by any compression factors. We may think of this as being applied “last”, after everything else is calculated.

Now we have a ship heading at angle θ with exit point offsets x, y, and z. Let k be the unit vector pointing in the direction of the ship (forward), and let j be the unit vector pointing to the right of the ship (starboard). By formula, these are k = (sinθ, cosθ) and j = (cosθ, -sinθ).

Let a1 = jx + ky be the uncompressed (and unrounded) position of the exit point. Call its coordinates a1x and a1y. If a1y < 0 then it is considered “down” for compress purposes, otherwise (if a1y ≥ 0) then it is considered “up”. Let cx and cy be the proper compress values based on this. By formula, cx = a1y<0 ? dx : ux, and cy = a1y<0 ? dy : uy.

Let a2 = (round(a1xcx/100), z + round(a1ycy/100)). This is the final pixel coordinate of the exit point relative to the center of the ship sprite, measured in standard cartesian coordinates where the first entry counts horizontally to the right (east) and the second entry counts vertically up (north).

This post has been edited by Qaanol : 12 April 2011 - 07:21 PM

I don’t recall if this has been suggested previously, but it would be nice if the resource selector panes (from clicking a magnifying glass button) would remember whether they were last sorted by ID or Name.

This post has been edited by Qaanol : 21 April 2011 - 08:12 PM

Would it be possible to add new röids to systems without overriding old ones?

röid resources are limited to just sixteen (IDs 128 through 143). Not only is this a lower limit than for just about any other resource type, but the game already uses all sixteen slots.

So no, there’s no way to add a new röid that without replacing one of the existing resources.

Feature request: would it be possible to allow Mission Computer to have a spellcheck? Or am I stuck having to check manually when I think I've spelled a word wrong?

@darthkev, on 10 May 2011 - 09:30 PM, said in MissionComputer: The Saga Continues:

Feature request: would it be possible to allow Mission Computer to have a spellcheck? Or am I stuck having to check manually when I think I've spelled a word wrong?

Type in a text editor, copy and paste.

Well yeah, I can do that, but it would be much easier to have a spellcheck right in Mission Computer.

Quote

Well yeah, I can do that, but it would be much easier to have a spellcheck right in Mission Computer.

I asked the same question several pages back. David's answer:

Quote

I could, I suppose, call in the system spell-checker, but again that’s substantially more complicated than it would be in Cocoa, and it’s never really seemed worth the trouble. I tend to assume that anyone who is writing a substantial amount of text will be pasting it in from a real word processor anyway.

Oh well. Guess it's back to proofreading the old-fashioned way.