That’s odd — it works correctly for me. I’ll have to check it on 10.6. Is anyone else seeing this?
Also, 76 downloads for version 4.2 in the first week after release. Glad to see people are still using it. 
I’m on 10.6 and I can confirm both things people are seeing.
When a plug-in is open in MC420, if the plug-in filename is less than or equal to 32 characters (including extension) then command-clicking on the title bar shows the proper path to the plug-in file.
If the plug-in filename is greater than 32 characters, however, then command-clicking on the title bar shows the path to MissionComputer.app/Contents/Mac OS.
Also, filenames over 32 characters show a generic folder icon in the title bar, whereas those less than or equal to 32 characters long show the proper plug-in icon.
@qaanol, on 27 January 2011 - 01:29 AM, said in MissionComputer: The Saga Continues:
Also, filenames over 32 characters show a generic folder icon in the title bar, whereas those less than or equal to 32 characters long show the proper plug-in icon.
Ah, so it's this again. I actually do have a way of fixing all of these issues, but if I use it, the system also insists on allowing you to move the file using the title bar icon, which MissionComputer can't handle without some architectural changes. So for the moment I'm sticking with the version that's less elegant but can't lead to data loss.
@qaanol, on 27 January 2011 - 01:29 AM, said in MissionComputer: The Saga Continues:
Also, filenames over 32 characters show a generic folder icon in the title bar, whereas those less than or equal to 32 characters long show the proper plug-in icon.
I'm not sure if this is basic knowledge or not, but I would also like to mention non-standard ASCII characters cause the same problem, no matter how short the filename is. This can also be a cause if the non-standard characters are part of a folder's name that is part of the plug-in's path. For example, all of the files for HOTS have standard ASCII characters in their filenames, but the folder I keep all resources related to HOTS in (including the HOTS files) has a 'ƒ' (fancy 'f') character in it. As a result all HOTS files came up with folder icons and directories to Mission Computer. When I remove the 'ƒ' (fancy 'f'), they come up with their plug-in icons.
Interesting. At some point I will need to find a way of handling the proxy icon being dragged, at which point I can switch to the better version of the code. I’ll keep this in mind as I plan the next version.
.ndat is the new format of the data files in EV Nova 1.1. It’s a data fork resource file: the resources are stored in exactly the same format as in a traditional file (with exactly the same limitations), except that the resource stream is stored in the data fork instead of in the separate resource fork.
MissionComputer needed to be able to handle .ndat files in order to continue to provide access to the game’s data, but I would strongly advise against distributing any plug-ins in this format, as it is less compatible, and provides no advantages over the two formats that were already established.
When creating a new oütf, MissionComputer defaults it to have ModType 1 (weapon) and ModVal -1 (invalid resource ID for a weapon). If one creates such an outfit and obtains it in-game, then EV: Nova will crash upon entering space, as it tries to give the player a non-existent weapon.
Not a super-big deal, but just something I bumped up against in making a proof of concept plug-in. Took me a few minutes to figure out why the game was crashing. Tried putting the graphics through BlitZen, almost gave up thinking my concept was disproved, when I realized the problem was just my dummy outfits were flagged as imaginary weapons.
Fixed, thanks.
It might just be my computer, but whenever I edit a plug-in, a copy of it ends up in the trash. I don't know why, but if I edit Nova Data, ends up in the trash. It doesn't affect anything, I'm just wondering if it's my computer or if it's MissionComputer.
Yes, that’s correct behaviour: the file in the trash is the old version that you saved over. If anything should ever go wrong with the saving proces, you can easily recover the last full copy of the file; if not, it will be deleted without getting in the way the next time you empty the Trash.
Okay. Just double-checking.
Actually, I suppose it might be more useful if those files were date-stamped.
Speaking of date-stamping, currently if you open a Macintosh plug-in with MissionComputer, make no modifications, and use the “Save As (Macintosh)…” command, the resulting file will be date-stamped the same as the original for both Date Created and Date Modified. It does not matter whether you save over the file itself, save over another existing file, or save as a new file.
Furthermore, if you open a Macintosh plug-in, make some change, and then do “Save As (Macintosh)…”, the resulting file will in all cases be stamped as modified at the current time, but still created at the same time as the original file was.
The standard operating procedure for Save As on Mac OS X is to replace both the Created and Modified date stamps with the current date and time. That is how TextEdit works, and that is even how MissionComputer itself works when doing “Save As (Windows)…”.
Yes, it probably should work that way — because of Resource Manager issues, 'Save As (Macintosh)' is actually copying a cached file rather than writing a new one the way that 'Save As (Windows)' does, but I can make it manually adjust the creation and modification dates.
Have I mentioned that I really like the “Government classes & allegiances” window? It is excellent.
Also a minor bug with the color picker for paint outfits: clicking all the way at the very end of the sliders causes the position indicator to jump all the way to that end, but the number only increments by 1 in that direction. Clicking anywhere else on the slider causes the indicator to jump to the point of the click and the number to switch to whatever value corresponds to the position indicator being there, but clicking all the way at the end does not.
@qaanol, on 13 February 2011 - 04:44 PM, said in MissionComputer: The Saga Continues:
Have I mentioned that I really like the “Government classes & allegiances” window? It is excellent.
Glad you like it. The name is a bit awkward, and I’m open to suggestions about the handling of xenophobic governments, but on the whole I’m pleased with its functionality.
@qaanol, on 13 February 2011 - 04:44 PM, said in MissionComputer: The Saga Continues:
Also a minor bug with the color picker for paint outfits: clicking all the way at the very end of the sliders causes the position indicator to jump all the way to that end, but the number only increments by 1 in that direction.
No idea why this is happening. The behaviour of the slider comes from the control itself; all I do is take the number it gives me and turn it into an RGB colour component.
@qaanol, on 11 February 2011 - 06:20 PM, said in MissionComputer: The Saga Continues:
… if you open a Macintosh plug-in with MissionComputer, make no modifications, and use the “Save As (Macintosh)…” command, the resulting file will be date-stamped the same as the original for both Date Created and Date Modified.
Fixed, thanks.
A few more minor bugs:
Selecting for a weapon graphic a spïn resource below ID 3000 (hence invalid for a weapon graphic) does not cause a warning in MC 4.2, but on closing the weapon resource and reopening it that one sees that value has been replaced by -1.
Putting a multiplication symbol × in the name—or any text field—of a non-RDL resource causes that character to be replaced with an asterisk * after closing the resource. This does not occur for the shän resource.
Creating or renaming a resource and then saving the file does not make the resource show up in the list. The altered resource must have its window closed for the list to update and include it.
