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).
All right, that's all I needed (that being you telling me that everything's all right :laugh: ). Functionally it's pretty much no problem at all since as you said it all sorts out on closing the window and if worse comes to worse you'll get the save prompt when you close the plug.
In the mission editor, a red X remains next the FailText box even if it refers to a valid desc.
QUOTE (Lindley @ Oct 22 2009, 11:22 PM) <{POST_SNAPBACK}>
Fixed, thanks.
Necro'd to spread the good news: new version! Yay!
Is there a changelog somewhere?
This post has been edited by Archon : 01 January 2010 - 05:38 PM
QUOTE (Archon @ Jan 1 2010, 05:36 PM) <{POST_SNAPBACK}>
It's one of the smaller updates; I just wanted to get out some of the bug fixes and small new features that had been accumulating since 4.0.5. You can see the full list by going to Help and clicking on the version history.
Two minor problems to report in the newest version. When you have a list organized by name and delete a resource, it re-organizes by ID number after the delete. Also new shäns default to -1 transparency, but they should default to 0. -1 makes them turn bright white when passing over an object.
Also, exit points and compression should probably default to 0, not -1.
Last one for tonight: in the wëap editor, the colors for the beam and corona are switched in the graphical display.
This post has been edited by Archon : 25 January 2010 - 05:26 AM
QUOTE (Archon @ Jan 24 2010, 10:01 PM) <{POST_SNAPBACK}>
When you have a list organized by name and delete a resource, it re-organizes by ID number after the delete. Last one for tonight: in the wëap editor, the colors for the beam and corona are switched in the graphical display.
Fixed, thanks (though at the moment it isn't possible for MissionComputer to fully replicate the game's corona rendering).
Also new shäns default to -1 transparency, but they should default to 0. -1 makes them turn bright white when passing over an object. Also, exit points and compression should probably default to 0, not -1.
At the moment, RDL scripts assume that all SHORTs should default to -1, but I'll make a note of this and see if I can add DEFAULT field.
Cool cool!
I'd just like to note that version 4.0.7 is now available from davidarthur.evula.net, featuring the bug fixes discussed during the last month and some small improvements.
Classy icons.
QUOTE (Qaanol @ Jan 31 2010, 07:55 PM) <{POST_SNAPBACK}>
:huh:
I have an odd observance to report. When selecting a color (this occurred when picking Map and Ship colors for a gövt resource) I click on the swatch and the Color Picker opens. I chose to use the RGB sliders. Using the cursor to drag the sliders, I set Red to 255 and Green to 191. I closed the graphical picker. If I opened it again immediately it was fine. If I closed the picker and saved the plug-in, then when I opened the picker again, the Green value had changed to 190. This happens repeatably. However, in the RGB slider color picker, if I type the number 191 into the text field for Green, then I can close the picker, save the file, and the correct value is remembered.
Oh, also I'm getting random crashes. All of a sudden MissionComputer will freeze, the cursor will become a beach ball, and after about 5 seconds MC will unexpectedly quit. A window then will appear asking if I want to reopen.
Edit: Also also, when in the sÿst editor, clicking "add planet" then "new planet" lets me enter the resource ID for a new spöb…except when I put in a number (600), it actually makes spöb resource 128. And when I make another and put in 601, it makes 129.
Edit 2: It just crashed again. I can send you the crash report if you want. I had just changed the type of a spöb (ie. its picture.) Then I saved the plug-in. Then I was about to make a chär but it crashed before I got the chance.
This post has been edited by Qaanol : 27 February 2010 - 09:53 PM
Double post because I figured out how to reproduce the crash: with a plug-in open, I create a new resource (any type). After closing the new resource, I then click the title bar of the main plug-in window as if to move the window. As soon as I click, MissionComputer crashes.
This is MC4.0.7 under OS X 10.6 on a 2.2-GHz MBP.
Edit: Pasting in a resource is also sufficient.
Edit 2: The sÿst editor's mechanism for choosing what spöbs are in that system strikes me as unwieldy. Even without the above-mentioned bug, there doesn't seem to be an easy way of just typing in the resource ID of a spöb I want to put in a system, or switching which spöb is in there (instead of removing one and adding another, to simple alter the resource ID as one would in ResEdit). This is especially troublesome when I don't have or want the spöb resource in the same file as the sÿst resource.
This post has been edited by Qaanol : 28 February 2010 - 12:35 AM
QUOTE (Qaanol @ Feb 27 2010, 09:39 PM) <{POST_SNAPBACK}>
When selecting a color (this occurred when picking Map and Ship colors for a gövt resource) I click on the swatch and the Color Picker opens. I chose to use the RGB sliders. Using the cursor to drag the sliders, I set Red to 255 and Green to 191. I closed the graphical picker. If I opened it again immediately it was fine. If I closed the picker and saved the plug-in, then when I opened the picker again, the Green value had changed to 190. This happens repeatably. However, in the RGB slider color picker, if I type the number 191 into the text field for Green, then I can close the picker, save the file, and the correct value is remembered.
I can't reproduce this - every time I set either the map or paint colours to 255/191/0, it gives the same value the next time I open the picker. In some resources, there are colour fields whose internal resolution is lower than that of the colour picker (which inevitably leads to some colours being rounded) but that doesn't seem to be the issue here. Can you give me the exact set of sets that produces this result?
Oh, also I'm getting random crashes. All of a sudden MissionComputer will freeze, the cursor will become a beach ball, and after about 5 seconds MC will unexpectedly quit.
These things are always hard to track – I hope the problem isn't an incompatibility with 10.6. Crash logs are, unfortunately, far too low-level to be of any use to me. Has anyone else been experiencing this, especially since upgrading?
Also also, when in the sÿst editor, clicking "add planet" then "new planet" lets me enter the resource ID for a new spöb…except when I put in a number (600), it actually makes spöb resource 128. And when I make another and put in 601, it makes 129.
Fixed, thanks. (The problem was that the internal calculation finding the first available ID was overriding your choice rather than the other way around.)
QUOTE (Qaanol @ Feb 27 2010, 11:18 PM) <{POST_SNAPBACK}>
The sÿst editor's mechanism for choosing what spöbs are in that system strikes me as unwieldy. ... there doesn't seem to be an easy way of just typing in the resource ID of a spöb I want to put in a system, or switching which spöb is in there (instead of removing one and adding another, to simple alter the resource ID as one would in ResEdit). This is especially troublesome when I don't have or want the spöb resource in the same file as the sÿst resource.
The system editor is intrinsically unwieldy, because it has to deal with multiple resources at the same time. I'm working on a way of allowing you to add spöbs by ID number, but there's no elegant way of handling spöbs that are in a different file than the sÿst resource.
What behaviour do you need with respect to 'switching' that can't be accomplished by removing the old planet and then adding the new one?
QUOTE (David Arthur @ Feb 28 2010, 10:54 AM) <{POST_SNAPBACK}>
I'm seeing this in every “normal” color picker I've checked in MissionComputer: If I click and drag any of the RGB sliders to 191, then click the ‘OK’ button, when I reopen the color picker it has changed to 190. If I hit enter to close the picker, or if I type in the value with the keyboard, then the 191 remains properly. I'm trying to find another application that uses the built-in color picker and has a standard button to close the window, but in the Finder and in Pixen all I'm seeing are floating palettes.
In the oütf editor I'm seeing a different problem with Paint outfits. I know they are restricted by the engine to 15-bit colors. At first all the MC-RGB sliders are set to 31. I click the swatch to use the built-in color-picker, and see all the normal RGB sliders as 255. Then I set (for example) Red to 254 and close the standard picker. The MC-picker has Red down to 30. I open the built-in picker and see Red is now 246. I close that and see MC has 29. I open the picker to see 238. Close it and see 28. I repeatedly open and close the standard color picker without changing anything and see the value of Red progressively dropping by 1 in the MC picker, and correspondingly 8 or 9 in the standard picker, until it hits zero. This is not restricted to Red nor the specific starting value (other than 255 which works fine.)
QUOTE
It's definitely crashing exactly when I try to move the base plug-in window after having added a new resource to the plug-in. It doesn't matter, as far as I can tell, what type of resource, whether its window is open or closed, whether I've saved or not, nor even whether MC actually saved the resource.
That last point brings up a side note: when I create a new resource and don't change anything in it, then close its editor, the new resource is not actually created. I find this mildly frustrating, as I sometimes want to make placeholder resources all at once, then go through them later and fill in the specifics. Yes, I know it's as simple as typing a key to change the name of the resource before closing it, but if I'm making many resources at once that gets repetitive. Conversely, if I somehow accidentally hit ⌘-K, and I accidentally hit enter to okay the suggested resource ID instead of clicking cancel, then I don't think it's to much to ask for me to have to hit delete to delete the resource.
And that last point brings up another minor thing I've noticed. Some of the dialog boxes, notably the resource ID entry window for a new resource and all the context-windows brought up by magnifying glasses that I've checked, don't acknowledge ⌘-. as a shortcut for the Cancel button. Similarly, tab doesn't usually cycle through the Okay and Cancel buttons the way it does, for example, in the “Are you sure you want to close without saving?” dialog. Also, that last dialog doesn't recognize ⌘-D for Don't Save.
And I've found another crash, this time due to an out of bounds error. If the Graphical Pickers are used (for cicn, PICT, rlë8, or rlëD) and no resources of the selected type are in the file, then after clicking (or hitting tab) to move focus to the graphical picker area, hitting the down arrow key or the right arrow key causes MC to crash.
Thanks.
I suppose I'm just looking for simplicity. To me it is a lot faster to click once (or hit tab repeatedly) to select the field I want, then type in an ID number, than it is to click once (or more if I have to scroll, or use both tab and the down arrow) to select a spöb, click again to remove it (because the delete key doesn't work here), click again to remove it from the system but not delete the resource, then click again on the Remove button in the confirmation dialog (or hit tab and then space because the default button is Cancel instead of Remove), then close the sÿst editor because removing the spöb actually just made its name un-bolded but still doesn't allow the Add Planet button to work for that NavDefault, then reopen the sÿst editor, then click or hit the down arrow repeatedly (I don't have to hit tab now because the spöb list is selected by default), then click Add Planet, then click Add Existing Planet, possibly click to select a different file, then click or hit the down arrow repeatedly to highlight the proper spöb, then hit enter or click OK (note that neither tab nor ⌘-. will select Cancel, that would have to be done with the mouse).
And after all that, if I suddenly realize I picked the wrong spöb, clicking Undo button in the sÿst editor does not actually undo the addition of the spöb, and I would have to repeat the whole process anew. Furthermore, if instead of adding an existing spöb, I wanted to add a spöb that does not exist in any currently accessible file, I would have to select which NavDefault it should be (no big deal), click Add Planet, click Create New Planet, type in the ID (no big deal), hit Okay, close the sÿst editor or save the file, switch to main MC window for that plug-in, select the spöb list, select the newly-created spöb, hit delete, hit the Delete button, then switch back to the sÿst resource I was editing (if I saved the file to make the spöb creation real—if I closed the sÿst to do that, then I have to select the sÿst list in the main plug-in window, then select the sÿst I want, then open it again.)
All I want is a standard text-entry field for spöbs in a sÿst. If MC can't find the proper resource, just display a standard-size circle or an X on the map. In fact most of the time I don't even need the map. I'd be happy if, instead of the tabs at the top of a sÿst resource being “Planets” and “Attributes”, they were “Edit” and “Display”. So you open the sÿst and see all the fields for editing, including the NavDefaults as text entry just like the Links are. Perhaps there could be a minimap radar-style display like there is currently in the Planets tab, but that isn't even necessary. If you click on that minimap or the Display tab, then it shows the big map as in the current Planets tab.
What exactly is the Undo button in the Planets tab supposed to do? All I can see it doing is, if I change Name, Location, or Type, then it reverts them. Unless I hit Apply, or click to select a different spöb, or click Move Up or Move Down first, in which case Undo does nothing.
Edit: Now I'm seeing crashes not after pasting in a resource but when choosing Get Info from a graphical picker, then afterwards trying to move the main plug-in window by dragging its title bar. Still getting crashes from trying to move the window after creating a new resource. It could well be something on my machine, I don't know.
This post has been edited by Qaanol : 28 February 2010 - 01:20 PM
I haven't seen anything like the crashes you're reporting, and I certainly haven't changed anything related to most of the functions you mention since version 4.0, if not earlier. Did their appearance coincide with your upgrade to 10.6?
QUOTE (Qaanol @ Feb 28 2010, 12:39 PM) <{POST_SNAPBACK}>
If I click and drag any of the RGB sliders to 191, then click the ‘OK’ button, when I reopen the color picker it has changed to 190. If I hit enter to close the picker, or if I type in the value with the keyboard, then the 191 remains properly.
I can't reproduce this, and in any case I don't supply the colour picker. If your behaviour in the colour picker is what makes the difference, then the colour picker itself is the problem.
In the oütf editor I'm seeing a different problem with Paint outfits. I know they are restricted by the engine to 15-bit colors. . . . I repeatedly open and close the standard color picker without changing anything and see the value of Red progressively dropping by 1 in the MC picker, and correspondingly 8 or 9 in the standard picker, until it hits zero.
A certain amount of smoothing is inevitable every time you convert between resolutions of 31 and 255, but I've adjusted the rounding algorithm slightly in a way that seems at least less likely to produce this problem.
. . . when I create a new resource and don't change anything in it, then close its editor, the new resource is not actually created.
This behaviour has been around for a long time, and at one point had significant benefits associated with it, but I suppose at this point it would be at least more standard to mark new resources as dirty.
In most cases there's nothing I can do about any of these. The context windows don't do it for the simple reason that they don't have a Cancel button; most do accept Return to dismiss, and I'll fix the ones that don't
All I want is a standard text-entry field for spöbs in a sÿst.
I'm afraid this simply isn't practical because of the necessity of loading the appropriate resource data into memory. The only way I could offer such fields is if I stopped allowing graphical manipulation of the map, or created two distinct system editors.
That's exactly its function. It's the opposite of Apply, except that since I increased the amount of direct manipulation in the system editor you no longer need to click Apply before moving on. It used to be called Discard, but that didn't seem quite right after the redesign. Undo probably isn't the right name either, though — perhaps I'll change it to Cancel.
Save As Macintosh does not change the creator and type codes as one might expect.
If I open a resource file that is not Növä/Npïf (for instance, the output of EnRLE) with MissionComputer and either use the keyboard shortcut or the menu to Save As Macintosh, the resulting file appears to retain its original creator and type codes, and therefore does not become a valid EV Nova plug-in. In this case Save As Macintosh is currently indistinguishable from Save.
On the other hand, opening that same file with MissionComputer and choosing either Save As Windows or Save As NDAT and saving it does what is expected. Once that is done, then Save As Macintosh successfully creates an Npïf.
So my request is to have Save As Macintosh in fact force the creator and type codes to be valid for Nova plug-ins.
This post has been edited by Qaanol : 09 March 2010 - 06:42 PM
QUOTE (Qaanol @ Mar 9 2010, 06:32 PM) <{POST_SNAPBACK}>
In this case Save As Macintosh is currently indistinguishable from Save.
As in every other programme, Save As differs from Save in that it allows you to save a new copy of the current file, rather than over-writing the existing version with your changes. The reason there are two Save As commands is to allow a simpler way to save a resource file as .rez, or a .rez file as standard resources. Would it be clearer to you if it were named ‘Save As (Macintosh)’ instead?
If Save As changed the type and creator codes to Npïf/Növä, it would be useless for people editing EV data files, or resource files of other types. If you want to change a file's creator code, use the Document Info command in the File menu.
any ideas about whether this would run on any versions opf Linux? thanks.
I have at times successfully compiled MissionComputer for Windows, and most of the issues affecting a Linux version are the same, but the resulting programme is hardly useable and not likely to become so.