Hello, everyone!

I've now posted MissionComputer 4.0a3, which has a few minor additions and a number of fixes to the problems people have reported from the first two alphas. This is, however, still a pre-release version of MissionComputer, so you should be extra-careful to keep backups.

Please report any bugs or usability issues you find - including ones from a1 that are still present - so that I can fix them for the release version. When reporting bugs, please tell me your system version and whether your Macintosh has a PowerPC or Intel processor.

MissionComputer 4.0a3 is still 11.7 MB, and available from <davidarthur.evula.net/beta/crusoe/MissionComputer400a3.dmg>. It requires Mac OS X 10.3 or greater, and is still a universal binary. (Intel users who experience problems, however, should try running it using Rosetta).

Cool
I have no idea what Asc or AscB are but unfortunately they don't fix the problem

@guy, on Dec 8 2007, 06:56 PM, said in Third alpha of MissionComputer 4.0:

I have no idea what Asc or AscB are but unfortunately they don't fix the problem

Hmm... that was the only thing shared by those two resources that I could imagine causing an endianness issue. I’ll have to give it some more thought.

I know this might be wishful thinking David, two questions/issues/can you/does it already/whatevers.

1. When editing a system or spob can it take the image data from not only the open file where the spob is in now but other files that are in the same directory too... ie: i have a file with all my spob/syst data and another file with all the graphics when i use the galaxy editor it won't draw the images unless they are in the same file.
   This was 4a02 so it may have already been changed.

2. ship editor with the novatools type shan hitpoints viewer to see where weapons are going to exit from on different ship shans.

I know they are prolly new features and not something you would be eager to put in but just hoping you will consider them.

This post has been edited by Lostpinky : 09 December 2007 - 04:43 PM

@lostpinky, on Dec 9 2007, 04:42 PM, said in Third alpha of MissionComputer 4.0:

1. When editing a system or spob can it take the image data from not only the open file where the spob is in now but other files that are in the same directory too... ie: i have a file with all my spob/syst data and another file with all the graphics when i use the galaxy editor it won't draw the images unless they are in the same file.

I’ve been thinking about such things for a long time. The problem is that not all plug-in files refer to the same data set, so I’ve never seen a satisfactory way for MissionComputer to know which files to use for graphics.

@lostpinky, on Dec 9 2007, 04:42 PM, said in Third alpha of MissionComputer 4.0:

2. ship editor with the novatools type shan hitpoints viewer to see where weapons are going to exit from on different ship shans.

At the moment I don’t intend to take on such a complex task when the end result would be simply to duplicate NovaTools.

Fair enough, i've only ever tried to get novatools working once and half the programs didn't work properly i went straight back to MC3.33 i was just thinking in terms of an all in one program that could do it all...

also on another note and it may make me get flamed but to make this project a bit more worth it for you have you considered putting in some advertising maybe from Ambrosia or something like that on the main window. Don't go crazy but maybe the main resource screen at the bottom having like the roll over like at the top of this website, but none of that stupid advertising crap like you see on torrent sites i was thinking more like the game ads that ambrosia do and maybe you could get a kickback from them, I don't know.

But something like that may make the project bring you in something to help with your time, or even if you don't want to go that way maybe putting a donations paypal link on your site, because man you do good work with mission computer and it helps alot of us, the map maker helped me hugely making the layout for the SGN tc.

Just another couple things to consider.

This post has been edited by Lostpinky : 10 December 2007 - 02:10 PM

@david-arthur, on Dec 9 2007, 05:49 PM, said in Third alpha of MissionComputer 4.0:

The problem is that not all plug-in files refer to the same data set, so I’ve never seen a satisfactory way for MissionComputer to know which files to use for graphics.

Just do what Nova does, and let the last plug-in (by name alphabetically) override any duplicate resources in previous ones. That way if someone's silly enough to go about editing a plug-in while it's in the plug-ins folder they'll see what they're going to get, and if they're smart enough to put their project in its own folder it won't matter. Although...maybe there could be a way for the user to specify their data files folder, so if they're working on an add-on and want to see their work integrated into the stock scenario they way it would be in-game, they can while still working on it.

No?

I'd second the exit-point viewer request. NovaTools is outdated. MissionComputer is the way of the future. Compatibility dammit!

Do you have a list of known, unresolved issues just so that we don't report old ones again?

@guy, on Dec 10 2007, 08:22 PM, said in Third alpha of MissionComputer 4.0:

Do you have a list of known, unresolved issues just so that we don't report old ones again?

I’d actually like to hear about old issues again; some issues (particularly Intel-related ones) are difficult for me to test directly, so it’s useful to get a fresh report of alpha 3 alone, especially since it's been long enough since alpha 2's release that some issues may even have been fixed before they were reported.

Lostpinky and Qaanol: Certainly I agree that a shän editor would be useful — it’s simply well beyond the scope of the current MissionComputer project. At the moment, it’s about fixing bugs and perhaps adding small new features.

Okay, here's a couple of old ones:
- Help is still bung on Intel.
- Still nothing to indicate that a file is already in use and it will appear to save successfully when it actually fails.

And some new stuff about rles:
- Could you make the RLE Maker default to just rleD?
- When returning to an open file after creating an rle, the buttons along the top are all greyed out (though you can actually still click them).
- Showing the mask in the rle viewer will show it inverted from the mask you would put into the rle maker. Is this intentional?
- The message about a greyscale mask (which will also be shown if you used a colour image) appears after the rle has been created. Wouldn't it be more useful to show it before and give you the option to cancel?
- I'm not entirely sure but it seems the rle maker does not dither. If so, would it be possible to add an option to do so? Perhaps it could be done with Core Image or Image Events.

This post has been edited by Guy : 11 December 2007 - 04:59 PM

Guy: Help is still bung on Intel. View Post
Help is generally strange — I think I may drop the help viewer entirely, and have it just open the relevant HTML files in Safari.

Guy: Still nothing to indicate that a file is already in use and it will appear to save successfully when it actually fails.
The problem is that, as a general rule, if MissionComputer doesn’t tell you such things, it’s because no one has told it ; if it’s actually suggesting that it has saved successfully, though, there ought to be something I can do about that.

Guy: When returning to an open file after creating an rle, the buttons along the top are all greyed out (though you can actually still click them).
Fixed, thanks.

Guy: Could you make the RLE Maker default to just rleD?
How come? Providing both rlë8 and rlëD is standard behaviour, so it ought to be the most common option.

Guy: I'm not entirely sure but it seems the rle maker does not dither. If so, would it be possible to add an option to do so? Perhaps it could be done with Core Image or Image Events.
You’re correct that it doesn’t dither. Properly speaking, the picture you supply ought already to be a 16-bit image, and so I don’t intend at the moment to duplicate the functionality of BlitZen (which, unlike the basic NovaTools editors, runs natively on Mac OS X).

Guy: Showing the mask in the rle viewer will show it inverted from the mask you would put into the rle maker. Is this intentional?
Only because it would require a significant amount of extra calculation to display it the other way around (the one you see is the one MissionComputer itself uses to draw the sprite). If I add a DeRLE-style function, I’ll make sure to properly invert the data.

Guy: The message about a greyscale mask (which will also be shown if you used a colour image) appears after the rle has been created. Wouldn't it be more useful to show it before and give you the option to cancel?
I can see the logic. In many cases the greyscale nature of the image comes from just one stray pixel, so the resultant RLE isn’t actually compromised, which is why I had it go ahead but warning you to check the results.

Beyond that, though, MissionComputer doesn’t actually know for certain that the image was greyscale until it has processed every pixel. The message isn't just based on the depth of the image supplied, but on the actual contents, which is much more useful; if you supply an image in which every pixel is black or white, MissionComputer won't complain even if the picture is legally 8-bit.

@david-arthur, on Dec 12 2007, 12:12 PM, said in Third alpha of MissionComputer 4.0:

Guy: Still nothing to indicate that a file is already in use and it will appear to save successfully when it actually fails.
The problem is that, as a general rule, if MissionComputer doesn’t tell you such things, it’s because no one has told it ; if it’s actually suggesting that it has saved successfully, though, there ought to be something I can do about that.

Don't you receive some sort of error if you try to open the file with write access?

@david-arthur, on Dec 12 2007, 12:12 PM, said in Third alpha of MissionComputer 4.0:

Guy: Could you make the RLE Maker default to just rleD?
How come? Providing both rlë8 and rlëD is standard behaviour, so it ought to be the most common option.

Well these days the standard seems to be just rleD. Even pipe himself once said the rle8s are unnecessary. By making it default to rleD you're encouraging the user to save space (and time) by not creating the pointless rle8s.

@david-arthur, on Dec 12 2007, 12:12 PM, said in Third alpha of MissionComputer 4.0:

Guy: I'm not entirely sure but it seems the rle maker does not dither. If so, would it be possible to add an option to do so? Perhaps it could be done with Core Image or Image Events.
You’re correct that it doesn’t dither. Properly speaking, the picture you supply ought already to be a 16-bit image, and so I don’t intend at the moment to duplicate the functionality of BlitZen (which, unlike the basic NovaTools editors, runs natively on Mac OS X).

Ah, true, it is easy enough to dither beforehand.

@david-arthur, on Dec 12 2007, 12:12 PM, said in Third alpha of MissionComputer 4.0:

Guy: The message about a greyscale mask (which will also be shown if you used a colour image) appears after the rle has been created. Wouldn't it be more useful to show it before and give you the option to cancel?
I can see the logic. In many cases the greyscale nature of the image comes from just one stray pixel, so the resultant RLE isn’t actually compromised, which is why I had it go ahead but warning you to check the results.

Beyond that, though, MissionComputer doesn’t actually know for certain that the image was greyscale until it has processed every pixel. The message isn't just based on the depth of the image supplied, but on the actual contents, which is much more useful; if you supply an image in which every pixel is black or white, MissionComputer won't complain even if the picture is legally 8-bit.

Ah, of course. Oh well, perhaps just change the message to something like "the image was not black and white as Nova requires"?

Hey, I just noticed something: Pasting a full-colour image into the mask appears to automatically reduce it to 16-bit in the preview. Could you do that for the sprite as well?

@guy, on Dec 11 2007, 06:42 PM, said in Third alpha of MissionComputer 4.0:

Don't you receive some sort of error if you try to open the file with write access?

Not as often as you would think, but I’ll see if I can track down the particularly egregious problem you’re experiencing.

@guy, on Dec 11 2007, 06:42 PM, said in Third alpha of MissionComputer 4.0:

Hey, I just noticed something: Pasting a full-colour image into the mask appears to automatically reduce it to 16-bit in the preview. Could you do that for the sprite as well?

Makes sense — the conversion to 16-bit was something I added so that MissionComputer could conduct the aforementioned checking-for-non-black-pixels, but I’ve modified it to run on the sprite image as well.

By the way, I’ll give ten bonus points to anyone who recognises the tune MissionComputer 4 plays (for all of three notes) after completing a long task.

- I'm not sure if this was brought up before or if it' a new bug, but the DITL and DLOG resources aren't displaying properly. Some take more than a few seconds to load and the scroll bar just seems to go on forever with nothing but gray to look at.

- I'm having to force-quit MC when opening STR#, either they are too big for the new alpha to handle or something.

- If I have any say in it, I like the 3rd version of MissionComputer's welcome window layout and background better than the new one which is kinda bland and kinda big. It's much easier to read the old one. But keep the new button names though

- Why do some of the pics display properly when the others don't? It would seem that they would either all work, or all not work.

Sadly enough, I'm still having to use the 3.3 version to edit my plugs, a lot less random crashes. I like all the improvements though and you have my full support, I wouldn't still be editing plugs if MissionComputer wasn't still around, thanks for all your hard work!

Oh, and one more thing! I've been wanting to edit the cicn's since forever, but it won't let me. I remember a few years back I was able to edit them with ResEdit or something, but why won't it edit in MC?

@ev-wolf, on Dec 14 2007, 05:55 PM, said in Third alpha of MissionComputer 4.0:

- I'm having to force-quit MC when opening STR#, either they are too big for the new alpha to handle or something.

I can confirm this is an issue on Intel. So that's DITL, DLOG, vers and STR# that have issues.

@ev-wolf, on Dec 13 2007, 11:55 PM, said in Third alpha of MissionComputer 4.0:

If I have any say in it, I like the 3rd version of MissionComputer's welcome window layout and background better than the new one which is kinda bland and kinda big.

The 4.0a3 welcome screen is actually smaller than 3.3.3’s, but it’s no surprise that you find it bland, since the art isn’t in place yet; I’ve only just finished it, so it will probably be there to impress you in the next alpha.

@ev-wolf, on Dec 13 2007, 11:55 PM, said in Third alpha of MissionComputer 4.0:

Why do some of the pics display properly when the others don't? It would seem that they would either all work, or all not work.

Can you be more specific? Which pictures don’t work?

@ev-wolf, on Dec 13 2007, 11:55 PM, said in Third alpha of MissionComputer 4.0:

Oh, and one more thing! I've been wanting to edit the cicn's since forever, but it won't let me. I remember a few years back I was able to edit them with ResEdit or something, but why won't it edit in MC?

MissionComputer doesn’t have a cicn editor — developing one would take a good deal of work, and in general my focus has been on resources that don’t already have a satisfactory editor.

@guy, on Dec 14 2007, 12:47 AM, said in Third alpha of MissionComputer 4.0:

I can confirm this is an issue on Intel. So that's DITL, DLOG, vers and STR# that have issues.

Hmm... if STR# has a problem too, that may help me trace what is causing it; evidently it’s one of the more complicated field types that occurs in standard Macintosh resources but not in Escape Velocity ’s custom types.

And remember, everyone, Intel support is experimental; if you have trouble with it, try switching MissionComputer to run in Rosetta.

@david-arthur, on Dec 14 2007, 07:19 AM, said in Third alpha of MissionComputer 4.0:

The 4.0a3 welcome screen is actually smaller than 3.3.3’s

What I meant was that the buttons were bigger and more spread out, making them harder to read, I liked having them all in a row. Trinix agrees:

@trinix, on Aug 28 2007, 06:37 PM, said in MissionComputer 4.0 second alpha now available:

Honestly, I don't like the look of the current MC4 welcome screen. It is ugly, and doesn't fit anywhere on my Mac. The oversized buttons, and the background, it just doesn't look right when you piece it all together the way it has been done on the Mac.

@david-arthur, on Dec 14 2007, 07:19 AM, said in Third alpha of MissionComputer 4.0:

Can you be more specific? Which pictures don’t work?

Actually, I read a little bit from the MC alpha 2 forum, Pace already brought it up:

@pace, on Aug 27 2007, 10:31 PM, said in MissionComputer 4.0 second alpha now available:

And the PICT part has a weird way of showing some images:

(same goes for the RLE list)

You said it was an problem on Intel, so I guess I'll try Rosetta. I was just confused as to why most of the PICT's and RLE's were displayed 'inverted', but some of them did display correctly. I would think that they would either all work, or all not work. :blink:

@ev-wolf, on Dec 14 2007, 01:15 PM, said in Third alpha of MissionComputer 4.0:

You said it was an problem on Intel, so I guess I'll try Rosetta. I was just confused as to why most of the PICT's and RLE's were displayed 'inverted', but some of them did display correctly. I would think that they would either all work, or all not work. :blink:

I haven’t been able to trace the cause in the first place, so I can’t say why only some are affected. Either way, I haven’t been able to reproduce it on PowerPC.

We determined that pics which didn't need to be scaled for the thumbs were fine, remember? Except on Leopard the problem is gone altogether.

@guy, on Dec 14 2007, 03:25 PM, said in Third alpha of MissionComputer 4.0:

Except on Leopard the problem is gone altogether.

Really? Perhaps that means the problem isn’t in my code at all.