Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
So, MissionComputer 3.3.3 was on one occasion unable to open a file for you? What sort of system do you have?
Has anyone else experienced this?
I'm on Mac OSX.3.9, but, it only happened that once. I didn't even have to restart Mission Computer. I just tried again and the second time, it worked fine.
Okay, actually tried this out on some files now and the speed is impressive :). What's the new format? How come it wasn't used earlier? The only suggestion I'd make for the new version is to change the buttons on the splash to say something like "Create a Mac plug-in" and "Create a Windows plug-in". There are a couple of issues I've been having, though they aren't related to the new version: Program quits with a NilObjectException in the App:PrepareNovaFilesItems routine whenever I click Okay in the preferences. I don't have any Nova files selected in the prefs. Scrolling is kinda broken in the graphical pickers. Home/End/PageUp/PageDn do not work, holding down the scroll buttons scrolls it only very slowly and clicking inside the scroll bar to jump a page length only jumps a very short distance.
This post has been edited by Guy : 24 January 2007 - 08:17 PM
@guy, on Jan 24 2007, 08:17 PM, said in MissionComputer 3.3.3 public beta:
Okay, actually tried this out on some files now and the speed is impressive :). What's the new format? How come it wasn't used earlier?
The new format is actually the old format, used in every version of MissionComputer prior to 3.1. I switched back to it for 3.3.3 because I had discovered ways of working around most of the reliability problems that prompted me to switch over in the first place, but it appears some people are still experiencing some slightly different ones. Im thinking of adding a preferences option allowing users to choose between the two, so that people for whom this format works can use it, but those who have trouble can use the slower but more reliable method instead.
The only suggestion I'd make for the new version is to change the buttons on the splash to say something like "Create a Mac plug-in" and "Create a Windows plug-in".
That probably makes sense; I gave them these names at a time when I was lobbying to get .rez support in the Macintosh version of EV Nova , but it doesnt look like thats going to happen.
Program quits with a NilObjectException in the App:PrepareNovaFilesItems routine whenever I click Okay in the preferences. I don't have any Nova files selected in the prefs.
I actually caught this myself, and have fixed it for beta 3. (In fact, in beta 3 the preferences window doesnt even have an OK button. )
Scrolling is kinda broken in the graphical pickers. Home/End/PageUp/PageDn do not work, holding down the scroll buttons scrolls it only very slowly and clicking inside the scroll bar to jump a page length only jumps a very short distance.
Keyboard scrolling in the graphical pickers doesnt exist, and isnt going to any time soon. Page-length jumping I can look at.
Dragging the scrollbar thumb has always worked perfectly for me. Is it the scroll arrows on the ends that are the problem? I never use those (in any programme), but if people agree that it would be helpful, I might be able to speed them up.
@david-arthur, on Jan 26 2007, 01:17 PM, said in MissionComputer 3.3.3 public beta:
Ah yes, well congratulations on discovering the workarounds :).
Such a pity, that would make things so much more simple. Or even better, have both platforms use resource-in-data-fork.
Yeah, dragging the bar works fine. I would usually use the scroll wheel but that's out here so if the page-jumping and scroll arrows could be fixed that would be great :).
@guy, on Jan 25 2007, 09:19 PM, said in MissionComputer 3.3.3 public beta:
Actually, I rather like .rez its far easier to interpret, since it was designed specifically for EV Nova s needs, and without the limitations that were necessary in 1984.
Ive increased the amount page-jumping moves (I hadnt noticed that, since I always leave Mac OS X set to Scroll to here), and Ill take a look at the scroll arrows, though at a glance it looks like theyll take a little bit more work.
Yes, I kinda like the .rez format (and I know pretty well the resource file format limitations, guess why Apple is making us developers moving away from resources, however they're proposing each resource as a file each in the application bundle, and perhaps plists to group small stuff, and I don't really like it, especially less practical for mod makers, just check out SketchFighter), in fact I investigated it and I realise it's two formats in one: - the first one is the wrapper format, it's a simple archive format with a list at the beginning with each item containing the chunk name (in fact, an offset to the name, or 0 if no name), position and length, with an offset index for the file so that a global index number can work for multiple files (useful in the case of resources). Notice this format is little-endian. - the second one is a specialisation of this format for the purpose storing resources coming from Mac resources, with each chunk being a resource, except the last chunk (or at least, the one named "resource.map," I dunno if it has to be the last one) which contains a structure which plays the same role as the resource map at the end of a Mac resource file (as a Mac resource is more than a chunk with a name, there's the type and ID too), notice that this structure is big-endian (as are all the resources, but that's because they come directly from Mac resources by mere copying, the rez format cannot make any assumption about the contents of resources so they are not byte-swapped).
I think the first format is more general (after all, it has BRGR's signature in it) and Becky uses it for other stuff, after all MaineCoon said (source "EVN will then convert the .bin files into a new format, .rez, which is the BurgerLib resource format."
Yeah .rez may be nice but resource-in-data would mean we could still use other editors like Rezilla. Does resource-in-data still have all the same limitations as resource forks?
@guy, on Jan 26 2007, 05:16 PM, said in MissionComputer 3.3.3 public beta:
Does resource-in-data still have all the same limitations as resource forks?
To the best of my knowledge, its byte-for-byte identical to the standard resource fork, just stored in a different place no the disk. Back when I was writing my .rez parser, I experimented with a resource-in-data parser as well, but found it hellishly complex.
Oh, for some reason I thought it had less restrictions but I guess that wouldn't really make sense.
I just remembered another problem I was having though: I had a spin resource with sprite dimensions set to 0x0 (deliberately) and when I tried to open it in MC it quit with an exception.
@guy, on Jan 27 2007, 05:05 AM, said in MissionComputer 3.3.3 public beta:
Fixed, thanks.
Hello once again
Ive posted the third public beta of MissionComputer 3.3.3. This version resolves most of the outstanding issues that are within the scope of this upgrade, and adds several user-requested features; the change list is below. Id still like to hear about any bugs you experience, especially if they involve data loss or are new to 3.3.3.
Id still like anyone who has participated in the beta test and would like to be added to the credits list to tell me their name as they would like it to appear in the about box.
Beta 3 can be downloaded here:
MissionComputer for Mac OS X (3.2 MB)
MissionComputer for Mac OS 9 and earlier (3.7 MB)
Changes since beta 2 are as follows:
Added the ability to list custom files and folders in the Open Special menu.
When selected from Open Special, both the Nova Files folder and custom folders are displayed in a special viewer which lists the resource types present in each file.
You can now choose between the two methods of opening and saving files.
Unique-ID generation is once again functional in the New Resource and Paste commands.
MissionComputer's preferences are re-designed as a non-modal window with a clearer interface for selecting data files and files for the Open Special menu.
If you have the CompletionSound option enabled, MissionComputer will now play a sound in the event that it takes more than ten seconds to open a file.
Editors now select themselves on activation in Mac OS X (mostly an aesthetic thing).
Re-organised the oütf and ďntf editors to eliminate the tab panels, and designed a special variation of the oütf editor for the earlier games. (These updated editors require a screen resolution of 1024x768 or larger.)
MissionComputer no longer tries to fix creator codes, as the need for this has passed, and it was starting to cause more problems than it solved.
The ellipsis box next to the ModVal field in the oütf editor now works properly for the non-lethal bomb ModType.
Reconfigured the s˙st editor to 1024x768.
cicns are now displayed with a graphical picker if you have that option enabled.
The oütf editor now properly labels the ModVal field for murk-modifier ModTypes.
Enlarged the default Resource Selector, Cartographer, and DITL editor windows.
Increased the amount the graphical picker advances if you click inside the scroll bar to jump a page.
Changed Npďf plug-in and .rez plug-in to Macintosh plug-in and Windows plug-in, since .rez support on Macintosh appears to be a lost cause.
The spďn editor no longer crashes when opening a resource with dimensions of (0,0).
The OK button in the ränk editor is now enabled properly.
Adjusted the default preferences to more sensible values
Nice :). What was the problem with the spins anyway, was it trying to do some calculation using the values?
Just a feature request: The ability to revert a file or individual resource back to the last saved state.
(edit) A couple of minor issues with dialogs: DLOG resources are saved as 25 bytes when they should be 24. DITL user items are displayed as being 2 pixels wider and taller (to the right and down) than they actually are.
This post has been edited by Guy : 29 January 2007 - 08:02 AM
@guy, on Jan 28 2007, 08:47 PM, said in MissionComputer 3.3.3 public beta:
It checks for the existence of the PICTs/RLEs to make sure that they meet the specifications, and so it was trying to work on a 0x0 buffer, which is equivalent to a non-existent buffer.
Ill look into both of these the second should be easy enough, but I have a feeling the first might cause more trouble than it would solve.
Also, a quick survey, which has no bearing on 3.3.3, but might help in the development of a subsequent upgrade that Im calling Crusoe. What Id like to know is how many people are using MissionComputer to develop for the first two Escape Velocity games; would a loss of support for them seriously inconvenience people, or is MissionComputer effectively being used as an editor for EV Nova only already?
Nova only in my case.
Me, too. Only Nova.
I recently found a problem with the latest beta release. Where in older versions of Mission Computer, if you try to open a damaged beyond use file, it refuses to do so, but with 3.3.3, it never says die. It will keep trying to open the file when it is impossible to do so.
@scienceguy8, on Feb 1 2007, 01:16 PM, said in MissionComputer 3.3.3 public beta:
What sort of damaged file do you mean? Does it just sit there forever, or is there an error message of some sort?
Does it make a difference whether you select ResBundle or ResourceFork as your importer in the Preferences window?
This post has been edited by David Arthur : 02 February 2007 - 04:59 PM
I do not know about the ResBundle or ResourceFork, but I will check it out later. What happens is that it just continues to load. There is no error message like in older versions of Mission Computer.