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).
I now have a MacBook running 10.6, so I can actually test this (finally). The information you've posted strengthens my suspicion that it might be tied to the fact that the New Resource window is a sheet — the simplest solution might be simply to make it something else.
Update: I've confirmed that I can reproduce the issue under 10.6 — but not 10.5 — and will look for a solution.
This post has been edited by David Arthur : 02 July 2010 - 05:26 PM
I don't know what y'all were talking about, but I'd like to publicly thank Mr. Arthur for contributing this handy piece of kit for us all for not one dime.
Here. I just made two pumpkin pie pans, with whipped cream. Have an e-piece.
What happened to cookies? Or does pumpkin pie trump cookies?
Either way, I second Mk.32's thanks and appreciation. Mr. David Arthur, you. Are. A legend.
Indeed, thank you David Arthur. MissionComputer is the marquee tool for creating and editing EV Nova files on Mac OS X. It really makes things simpler than they would be otherwise.
I have another feature request, although I don’t know how difficult it would be to implement (and of course it is not nearly as important as crash-resolution.) It is just, when viewing the Facilities tab of a spöb, it would be quite helpful if the labels for the commodity prices could check for the presence of STR# 4000 (or possibly 4003?) and display the strings from there.
It wouldn’t have to be anything fancy, and it certainly wouldn’t have to auto-update or deal with STR patching. It could just be, when a file is opened, check whether it contains STR# 4000. If it does, and that resource contains at least 6 fields, then remember the text in the first 6 fields. From then on, whenever a spöb resource is opened, it can use those labels for the commodities. It doesn’t matter to me whether the strings were kept on a per-file basis, or just whatever was the last file to be opened containing the right resource. The latter might be a little nicer, since then it would work for all open files as long as one of them contains the right strings.
I mention this because it is a bit tedious having to remember which commodities replace which stock Nova commodities in a plug-in. And of course, when MC exits, it need not (indeed probably should not) store the commodity names. It can revert to its defaults when it is relaunched.
This post has been edited by Qaanol : 03 July 2010 - 02:46 PM
QUOTE (EVWeb @ Jun 30 2010, 05:13 PM) <{POST_SNAPBACK}>
The second bug was in the ranks editor. For some reason if you check either of these two contribute fields, then it will not save the whole thing, but it only happens if you check either of these.
Fixed, thanks.
QUOTE (Qaanol @ Jul 3 2010, 03:44 PM) <{POST_SNAPBACK}>
… when viewing the Facilities tab of a spöb, it would be quite helpful if the labels for the commodity prices could check for the presence of STR# 4000 (or possibly 4003?) and display the strings from there.
Implemented — I used 4003 since the ones in 4000 can get quite long even if you're just following the standard values.
Also, another recent experiment: roid_1july.png (92K) Number of downloads: 23
Well it's nice to see it on a Windows computer, though it doesn't look nearly as nice... I understand it's still Alpha (maybe Beta) but that doesn't change the fact Windows' windows just kinda ruin the look.
Well, at least its interface is a lot nicer-looking than EVNEW ever will be.
QUOTE (DarthKev @ Jul 8 2010, 07:23 PM) <{POST_SNAPBACK}>
I understand it's still Alpha (maybe Beta) but that doesn't change the fact Windows' windows just kinda ruin the look.
I'm afraid the aesthetics of the Windows interface are a bit beyond my remit.
And yes, this is very much alpha. Everything you see is real, and the programme is largely functional, but it doesn't have the completeness and useability that characterise a beta.
QUOTE (David Arthur @ Jul 8 2010, 09:54 AM) <{POST_SNAPBACK}>
Awesome, thanks a ton!
QUOTE (EVWeb @ Jul 2 2010, 01:02 AM) <{POST_SNAPBACK}>
I keep encountering the create a new resource and try to move the window bug . . .
QUOTE (Qaanol @ Jul 2 2010, 01:18 PM) <{POST_SNAPBACK}>
I confirm that attempting to resize the main window after creating a new resource causes MissionComputer 4.0.8 to unexpectedly quit under OS X 10.6.4. . . . Same behavior as when trying to move the main window after creating a new resource.
Fixed, thanks. (And for the record, it was tied to a change in how sheets are handled.)
QUOTE (Qaanol @ May 21 2010, 11:55 AM) <{POST_SNAPBACK}>
Opening a file with name longer than 32 characters works, but the bar at the top of the window shows the default Folder icon rather than the MissionComputer file icon.
I've found the cause for this — and, indeed, the fix, but unfortunately I can't implement it right at the moment. The problem is that it would also enable dragging the proxy icon to another spot, and the current document window doesn't handle it very elegantly if an open file is moved. I'll keep a record of it for future versions, however.
QUOTE (Qaanol @ Feb 28 2010, 01:39 PM) <{POST_SNAPBACK}>
. . . the “Are you sure you want to close without saving?” dialog . . . doesn't recognize ⌘-D for Don't Save.
Bug report in MC4.0.8 under OS X 10.6.4 (repeatable, not critical)
When a new resource is created and modified, the file is saved, and then the editor window for that resource is closed immediately after saving the file, that resource does not appear in the list or get added to the count in the main window. It looks like it was not created, even though it was. Clicking in the list of resource types on the left side of the main window makes it appear properly.
Method: Create new resource Make any desired changes to that resource Save file Close resource editor window
Result: Main MC window does not show the new resource in the list, nor include it in the count of resources of that type
Follow-up: Click on any resource type on the left, or nagivate there with Tab then press an up or down arrow. The new resource suddenly appears.
A couple feature requests (I know, I know, it never ends!)
I would like to be able to select multiple (all) lines in a STR or STR# resource and copy them as text.
It would be quite nice if the drop-down menu for selecting cargo type in the mïsn and öops resource editors were to show the cargo types from STR# 4002 (or similar) when applicable. Similarly, in the düde resource booty selection area, it would be nice if the checkboxes were labeled from STR# 4003 when possible.
Apologies for the deluge of requests, and thank you again for the excellent editor.
mïsn already does this (and has for some time) — just make sure that the 'All Cargo' STR# is present in the file. I can't think of any obstacles to doing likewise in öops and düde, so I've added that to the list.
Selecting and copying the contents of an STR# seems reasonable, but what delimiter should it use to separate them?
QUOTE (David Arthur @ Jul 24 2010, 02:22 PM) <{POST_SNAPBACK}>
Ah, how silly of me, I had neglected to copy the STR# into another file. Thanks for adding öops and düde too.
I was thinking just a new line. For my purposes, I want to paste into a text editor so I can modify the strings more conveniently, then enter them back into MissionComputer one by one. Anything more fancy than a line break, I would do a replace-all to get rid of.
QUOTE (Qaanol @ Jul 24 2010, 03:45 PM) <{POST_SNAPBACK}>
I was thinking just a new line.
That was my first thought too, but the problem is that an individual entry can legally contain a line-break. I suppose any line-breaks contained in the copied strings could be replaced with some sort of SGML-style code.
QUOTE (David Arthur @ Jul 24 2010, 05:25 PM) <{POST_SNAPBACK}>
It could, sure, but I’m not asking for that. I’m fine with my copied text having line breaks between STR# fields and potentially line breaks within STR# fields. I’m not expecting to be able to batch paste any text back into MC and have it magically be parsed into a STR# resource. I mean yeah, that would be nice and all, and if you want to do it that way then great, but if you don’t want to implement pasting text-to-STR# in MC then I wouldn’t bother with any markup or special delimiters on copying STR#-to-text.
Minor bug report: In the mïsn editor dropdown menu for selecting what system the special ships appear in, there is an option “Adjacent to specific system” which does not provide an entry field to enter a specific system, and moreover is not documented in the Nova Bible, so I suspect it is not a valid setting (although I have not tested to see if there is an undocumented engine feature.)
At the risk of going off-topic, I have a question for Qaanol. Are you finding all these bugs by chance while just using the program, or are you actually running it through its paces and actively looking for bugs to help out with squashing them?
Yes.