@spoony, on Dec 10 2008, 02:16 PM, said in MissionComputer 4.0.3 update available:

The ramifications of this would be that an effectively unlimited amount of data could be contained in a single file? Instead of the very irritating 16Mb recommended limit we must adhere to with resource forks? If this was the case I would simply worship whomever was responsible for the change.

At first glance it appears the answer is no.

@spoony, on Dec 10 2008, 02:16 PM, said in MissionComputer 4.0.3 update available:

The ramifications of this would be that an effectively unlimited amount of data could be contained in a single file? Instead of the very irritating 16Mb recommended limit we must adhere to with resource forks?

I don’t believe so. With a data-fork resource file, the exact same contents as would go in the resource fork are just saved in the data fork instead, so I all think the same limits still apply. The only real differences between them and normal resource files are that a) you can't have both resources and data in the same file, and b) the resources aren't lost if they're saved to a non-Macintosh drive.

@spoony, on Dec 10 2008, 02:16 PM, said in MissionComputer 4.0.3 update available:

and then you stare at it blankly wondering if your computer has finally gotten smart and started defying you.

‘General, our smart bombs have sat down with their smart bombs and signed a peace treaty!’

@rudy, on Dec 10 2008, 11:39 AM, said in MissionComputer 4.0.3 update available:

At first glance it appears the answer is no.

@david-arthur, on Dec 10 2008, 11:47 AM, said in MissionComputer 4.0.3 update available:

I don’t believe so. With a data-fork resource file, the exact same contents as would go in the resource fork are just saved in the data fork instead, so I all think the same limits still apply. The only real differences between them and normal resource files are that a) you can't have both resources and data in the same file, and the resources aren't lost if they're saved to a non-Macintosh drive.

Once again, sad panda face. My OCD side hates the 16Mb limit.

Quote

‘General, our smart bombs have sat down with their smart bombs and signed a peace treaty!’

:laugh:

@spoony, on Dec 10 2008, 03:36 PM, said in MissionComputer 4.0.3 update available:

My OCD side hates the 16Mb limit.

If it makes you feel any better, try to remember that the format was designed for the original 1984 Macintosh, and it would take 128 of those just to hold a 16 MB file in memory.

@david-arthur, on Dec 10 2008, 12:59 PM, said in MissionComputer 4.0.3 update available:

If it makes you feel any better, try to remember that the format was designed for the original 1984 Macintosh, and it would take 128 of those just to hold a 16 MB file in memory.

Oh I definitely understand the limitation... my first computer was a Mac 128K, charming little machine that.

I just wish Nova would have migrated to a more versatile data storage type by now. Packaged files would be nice (akin to what we do with .redplugs). I also wish it was more intelligent about loading that data (in my mind hyperspace is a perfect time to load things).

It can all go into the ' requests for EV4' category though, I suppose.

Sorry for continuing the hijack of this thread, and hijacking for my own purposes as well, but:
What does this mean for pilot files? Will they likewise be transferred? Will the new version read old pilot files? Will it automatically convert them? Will it include instructions on converting them (back) to resource-based? What will the extension be for new
I do have an interest in pilot files because I've written a pilot reader that can (more-or-less) reads both Windows and MacBinary pilots (although I haven't finished debugging the MacBinary reader yet) and prints (to standard output, but the amount of data is colossal and should be redirected to a file from the shell) all known data, as a precursor to a converter I haven't filled in all the unknown offsets yet, so I can't create the converter until I at least figure out the sizes of the remaining data.

There's really nothing to see here at all. Nova 1.1 may have the capability to read data-fork resource files but without any means to convert such files to .rez, using them would actually be bad for cross-platform compatibility. Pilots certainly aren't going to change their format as we would still want compatibility between 1.1 and older versions (that said, converting between data-fork and resource-fork is trivial: "cat <resourcefile>/..namedfork/rsrc > <datafile>" or vice versa).

This post has been edited by Guy : 10 December 2008 - 10:03 PM

@guy, on Dec 10 2008, 10:01 PM, said in MissionComputer 4.0.3 update available:

...that said, converting between data-fork and resource-fork is trivial).

Yes, as I said earlier, the data format is identical; it’s just saved in a different place. To convert, all you do is move it from one place to the other (which I think can even be done at the command line), and if you have code that can read resources from MacBinary, it probably wouldn't be too much work to modify it so that it reads directly from a data-fork resource file.

Still running into the MakeRlE program not dividing large images properly. This image should be 9x12 or 335x335 pixels per frame, but MC keeps reading it as 335x334. I haven't run into this problem with any smaller sprites.

Spoiler Warning: This ship will be appearing in Acheron. I am releasing this image only for debugging purposes. Do not repost. Do not download this image unless you are OK with seeing the ship before release.

sprite
mask

@crusader-alpha, on Dec 12 2008, 01:09 AM, said in MissionComputer 4.0.3 update available:

Still running into the MakeRlE program not dividing large images properly. This image should be 9x12 or 335x335 pixels per frame, but MC keeps reading it as 335x334. I haven't run into this problem with any smaller sprites.

Your server won't respond, but I'll look into it. Your sprite grid is 3015*4020, is it? Is the problem always that the height is one pixel too small? Does it ever affect grids that have the same number of rows and columns?

Yes, the problem is that the height is one pixel too small, per frame. 4020/12=335, but MC is reading it as 334. I haven't checked with grids that have the same number of rows and columns yet, but I can do that later today.

My only concern is that your glorious missioncomputer header graphic now has to be slightly resized to fit in the fixed width.

Just finished playing around a little bit with the latest version of MC, and I'm quite impressed. I was upgrading from 3.2, and the new features are very nifty. I'll be using this as an instrumental tool in Noir development!

I don't know if this was brought up or not. But is it possible to add 2 more layer modes for the galaxy map editor? On top of having regular hyper routes, you also have hypergate routes system as well as wormhole routes. You would also have 3 checkboxes so that a developer can toggle how many modes they want simultaneously.

@coraxus, on Dec 19 2008, 01:49 PM, said in MissionComputer 4.0.3 update available:

I don't know if this was brought up or not. But is it possible to add 2 more layer modes for the galaxy map editor? On top of having regular hyper routes, you also have hypergate routes system as well as wormhole routes. You would also have 3 checkboxes so that a developer can toggle how many modes they want simultaneously.

I've thought of this, and it would certainly be appealing. The problem is that hypergates and wormholes are planets, not systems, and likewise link to planets rather than systems. I would have to load and process a whole new set of resources in order for them to be shown.

@david-arthur, on Dec 19 2008, 03:36 PM, said in MissionComputer 4.0.3 update available:

I would have to load and process a whole new set of resources in order for them to be shown.

A new set of resources, would this set of resources have to be something like what EV Nova itself uses to show hypergate routes on the galaxy map once a player "lands" on a hypergate?

@coraxus, on Dec 19 2008, 05:54 PM, said in MissionComputer 4.0.3 update available:

A new set of resources, would this set of resources have to be something like what EV Nova itself uses to show hypergate routes on the galaxy map once a player "lands" on a hypergate?

In order to show hypergates, the star map would have to be aware of the spöb resource – which it currently ignores entirely – and also process much more of the sÿst resource than it currently does. (At the moment, it only pays attention to a system's name, position, links and, most recently of all, its government.)

Is there any chance you could reconfigure the Open Recent list to be in order by date, instead of being alphabetized, so it fits with the rest of the system?

@0101181920, on Dec 19 2008, 09:10 PM, said in MissionComputer 4.0.3 update available:

Is there any chance you could reconfigure the Open Recent list to be in order by date, instead of being alphabetized, so it fits with the rest of the system?

The Open Recent menu was ordered by date when it first appeared, but everyone complained, so I revised it to appear in alphabetical order even though that's much harder. (Both the Finder's Recent Folders submenu and the Recent Items in the Apple menu are in alphabetical order, so it's probably the more consistent of the two possibilities in any case.)

Hmm, would it be possible to make it an option? That would be cool. Ah, well, it doesn't matter so much.

Would it be possible to integrate ConText and ResStore capability into MC? Like a "spreadsheet view" that will display all of one kind of resource at a time in a spreadsheet window? I cannot get ResStore to work on my MBP for the life of me (and ConText works only when it feels like it), and I'd really like the ability to change the same setting across multiple resources simultaneously with the ease that I can paste the same number into every single cell in a column if I needed to.

EDIT: Two more little issues I have with MC (see, I'm using a lot more now). One, while it's great that -Q will close all windows, it's not so great that it will close all open windows before asking me if I'm really sure I want to quit. The W is pretty close to the Q on normal keyboards (probably the vast majority), and it's annoying to see all my many open windows vanish when I only meant to close the top one.

Second, whenever I click on a field in the ship editor (may be the same with all editors, haven't checked), the insertion point appears to the far left by default. This is just a little pet peeve I have. For the lack of ConText and ResStore working, I'm manually changing the explosion IDs of all the ships in a beta plugin I'm revisiting, and since I'm only changing the last digit in the explosion fields, I'd rather not have to first click again or use the arrow key to move the insertion point to where I want it so I can change the one digit. Sigh, 10 ships down, 172 to go... having to click so many times to do one task just ruins my efficiency, and I'm sure MC is all about making Nova plug development efficient.

EDIT2: I have a really cool interface feature suggestion: The Quick Edit feature. It would be a third window section in the main interface to the right, and it could function as a drawer with an open/close button in the lower right corner of the resource viewer (so it doesn't irritate, it stays closed if it's closed to begin with, stays open if it's open). Whenever you select a single resource, an editor with an abbreviated layout or list layout (whichever fits better and/or is easier to make) is automatically displayed in the Quick Edit window, though grayed out as inactive until you click on it. Clicking on it activates it, and you can make whatever changes to the resource you want, then move on. Multiple windows for those who prefer it will still be an option by merely double-clicking on the resource or using the Open button as usual. Of course, with multiple resources selected, the Quick Edit window will display the text "Multiple Resources Selected". What do you think?

This post has been edited by Geek : 24 December 2008 - 04:42 AM