@tycho, on Oct 7 2008, 10:03 PM, said in [ANN] MissionComputer 4.0 is now available:

lol
what type of files are they?
}don't know, but i got info on them.
...., wtf?

I got info on the folder, obviously. I tend to do that when I want to know the size and number of items within it, as opposed to opening it and hitting "Get Info" on everything inside.

@david-arthur, on Oct 8 2008, 08:07 AM, said in [ANN] MissionComputer 4.0 is now available:

16 MB isn't the 'safe' limit: it's the maximum. Being that close is a bad idea, especially considering that file size is not the only limit that applies to resource files. The developers of both EV Override and EV Nova experienced corruption well before 16 MB; that's why there are so many separate data files.

I see. Well, it's been at the 16 meg limit since beta. I'm at 1.2 and haven't had any reports about file corruption, so, at least in Colosseum's case, it's safe to say its fine. If I were to add more graphical content, however, I wouldn't add to the file, that's for certain. Base and Essentials are 7.8 and 7.4 megabytes respectively, so I'd have room to move some stuff into those if the need arose.

@dr--trowel, on Oct 8 2008, 10:38 AM, said in [ANN] MissionComputer 4.0 is now available:

Where the bloody what are you? Was the audio clearer pre-YouTube?

'Krim-Hwa' is, unfortunately, not the most distinct of words at the best of times.

Try "Sefekhnebs" or "Nehisuankhani".

Wow, Mission Computer runs fantastically now, no more random quits

Though, I'm getting this error sometimes when I open rleD's or rle8's.
It seems to only happen to the graphics that were copied into a different plug.
Any explanation, or should I just stop copying things around?

Attached File(s)

• Picture_12.jpg (96.84K)
  Number of downloads: 16

@ev-wolf, on Oct 9 2008, 05:46 PM, said in [ANN] MissionComputer 4.0 is now available:

Though, I'm getting this error sometimes when I open rleD's or rle8's.
It seems to only happen to the graphics that were copied into a different plug.

Does it always happen under the same circumstances? You're copying them with the clipboard?

Oh, is the frame count 1-based?
I can't see any other reason for an error, except the problem I had when I didn't halve (undocumentedly) the skipping value on an rleD (which still doesn't make sense).
So, this happens on both types?
It would appear that the very last line of data is not being copied. Is the source or destination file pushing the 16MB limit?
What is the reported size of the resource, before and after?

Update: It looks like the new copy-paste system is sometimes losing the last byte of the resource. I'll see if I can track this down for 4.0.1.

Nonconventionally Creative: Copy-paste handles resource data directly, without parsing, so that isn't an issue. As for the skipping value, the documentation I have says that it represents the number of bytes skipped, so it's perfectly logical for it to be twice the number of pixels for a 16-bit (i.e. 2-byte) graphic.

@nonconventionally-creative, on Oct 9 2008, 04:41 PM, said in [ANN] MissionComputer 4.0 is now available:

Oh, is the frame count 1-based?
I can't see any other reason for an error, except the problem I had when I didn't halve (undocumentedly) the skipping value on an rleD (which still doesn't make sense).
So, this happens on both types?
It would appear that the very last line of data is not being copied. Is the source or destination file pushing the 16MB limit?
What is the reported size of the resource, before and after?

I'm pretty sure it's happening with both types, they aren't pushing the limit, and I'm not sure why checking the size would matter.
I'm not a graphics person and the sprites I'm using/copying aren't mine (they're from other people's plugs), I don't know anything about frame counts and the like.
The original graphic (from the maker's plug) works fine, it's after I copy them to from that plug to a different plug then open it that I have the problem (I am using command-C/V to copy/paste). I will say that it doesn't happen to EVERY rleD/rle8 that I copy, some of em still worked.
The first couple times this happened to me, many more error messages followed the first one (I'd press 'ok' in error message #1 and it bring up error message #2, then I'd press okay and it would take me back to error message #1, then back again. It did that about 3 times before MC finally fully quit), although I'm not able to recreate this, but I'll keep trying.
Here's two more separate error messages (btw it quits right after the message, letting me save if unsaved):

Attached File(s)

• Picture_1.jpg (55.75K)
  Number of downloads: 10
• Picture_2.jpg (43.29K)
  Number of downloads: 11

This post has been edited by EV Wolf : 09 October 2008 - 07:53 PM

@david-arthur, on Oct 9 2008, 05:40 PM, said in [ANN] MissionComputer 4.0 is now available:

Update: It looks like the new copy-paste system is sometimes losing the last byte of the resource. I'll see if I can track this down for 4.0.1.

Nonconventionally Creative: Copy-paste handles resource data directly, without parsing, so that isn't an issue. As for the skipping value, the documentation I have says that it represents the number of bytes skipped, so it's perfectly logical for it to be twice the number of pixels for a 16-bit (i.e. 2-byte) graphic.

The documentation here, which was all I had to work with, said pixels, which made more sense to me from the perspective that you can't skip half a pixel. It only makes sense if you're writing values to a byte buffer. Since it didn't occur before the copy, the problem wouldn't be a parser problem (including cases of a malformed resource) anyway.
By "last line" I meant just some part, i.e. one byte, at the end.
My question remains, why does the frame count seem to be 1-based?

@joshtigerheart, on Oct 8 2008, 06:12 PM, said in [ANN] MissionComputer 4.0 is now available:

I got info on the folder, obviously. I tend to do that when I want to know the size and number of items within it, as opposed to opening it and hitting "Get Info" on everything inside.

type=size now? haha, i'll stop taking the piss now. thanks for being a good sport.

@nonconventionally-creative, on Oct 9 2008, 09:30 PM, said in [ANN] MissionComputer 4.0 is now available:

The documentation here, which was all I had to work with, said pixels, which made more sense to me from the perspective that you can't skip half a pixel.

That's just a forum member's summary of the format, so it's not particularly surprising that should be imperfect. The genuine documentation from spriteworld.org (which seems to be down now) says bytes.

@nonconventionally-creative, on Oct 9 2008, 09:30 PM, said in [ANN] MissionComputer 4.0 is now available:

My question remains, why does the frame count seem to be 1-based?

Because that's simpler than having it zero-based.

EV Wolf: I've reproduced the problem, and should be able to track it down.

That's odd, all I can find on SpriteWorld.org about RLEs is about PPC/68k incompatibilities and sizes and the different methods that needed to / could be used; no data on implementation. I did get the sources, but they don't have much commenting and the code is to obfuscated for me to understand with my current level of language comprehension.
And since arrays references start at 0, I don't see how it is simpler. Maybe more logical from a user's perspective, but not from code.

EV Wolf: Found and fixed, thanks. It turns out that it always lost the final byte if copying one resource, or the final byte of the final resource if copying a group; it's just because most resources have padding at the end that it had no real effect except on certain RLEs (perhaps also some PICTs or snds). I've fixed this for 4.0.1. In the mean time, the Resource Copier is unaffected.

Nonconventionally Creative: I use 1-based arrays wherever possible, as I don't believe in designing things unintuitively just because the processor likes it. For frame counts it would be particularly weird to call the first frame 'zero'. Here's a screenshot that I took from the SpriteWorld documentation back when I was implementing the RLE format:
rleformat.png (118.53K)
Number of downloads: 12

@david-arthur, on Oct 11 2008, 11:48 AM, said in [ANN] MissionComputer 4.0 is now available:

EV Wolf: Found and fixed, thanks. It turns out that it always lost the final byte if copying one resource, or the final byte of the final resource if copying a group; it's just because most resources have padding at the end that it had no real effect except on certain RLEs (perhaps also some PICTs or snds). I've fixed this for 4.0.1. In the mean time, the Resource Copier is unaffected.

Great, I'll just use resource copier for now. I was wondering why some of them were not affected, it was because I copied some in batches and some individually, it was really confusing and irritating, thanks for the fix

EDIT: Oh, and another question (which I know has been brought up before, I just forgot your answer): Is it possible for you to make it so you can select and copy multiple 'graphical' resources? (without having to go to the preferances and turn graphics off) If not, could you make it easier to toggle between the two, such as when your editing PICTs, could you make a checkbox at the top right of the window to toggle between the two. And is there any way to make it so that when you switch between graphical or not, it updates immidiately, instead of have to re-click on the resource type your editing.

This post has been edited by EV Wolf : 11 October 2008 - 02:43 PM

@ev-wolf, on Oct 11 2008, 03:36 PM, said in [ANN] MissionComputer 4.0 is now available:

Is it possible for you to make it so you can select and copy multiple graphical resources, such as PICTs and RLEs and the like? If not, could you make it easier to toggle between the two, such as when your editing PICTs, could you make a checkbox at the top right of the window to toggle between the two.

Both of these are on the list, but the second will likely come much sooner than the first. (Multiple selection in the graphical picker will require a major upgrade to the custom control which powers it.)