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).
QUOTE (Archon @ Apr 6 2009, 01:51 PM) <{POST_SNAPBACK}>
(edit)Oh yeah, I forgot the important part. After re-opening the files (after restarting the app) I closed them again and got the following message: "MissionComputer has encountered a nil object error in the DocWindow:FileClose routine that prevents it from running. An additional error was encountered while trying to display this message. "If this problem continues, please report these details on the EV Developer's Corner."
It happened twice, so I figured I'd do what you said and post them.
I'm getting a similar error when I open the program. I'm not even trying to open a specific plugin. I've tried restarting my computer and reinstalling the program, but it still doesn't go away.
The error is "Mission Computer has encountered a nil object error in the App:xPrefsRead routine that prevents it from running."
This is followed by "Mission Computer has encountered an unidentifiable error in the App:Open routine that prevents it from running."
Both errors are followed by messages saying there were additional errors trying to display the error messages. Any idea what might have happened?
This is a known issue - delete your MissionComputer Preferences file and it should go away. I was waiting for the add-ons directory to be updated before releasing the new version that fixes this, but given the timeframe on which that's occurring, I should probably just go ahead and post it.
QUOTE (David Arthur @ Apr 26 2009, 05:00 PM) <{POST_SNAPBACK}>
Ah, I was just about to post and say that deleting my prefs fixed the problem. Thanks anyway though!
A few more updates for you:
The first two have to do with nit-picks over the Prox. and Blast Radius fields. The mouse-over tooltip for Prox. Radius is the same as that for Blast Radius: "The radius (in pixels) of the blast damage." I'm sure most folks know what proximity radius means/does, but it should probably be addressed just in case.
The second prox/blast radius-related issue is graying the fields out. With a lot of weapon types, MC will gray out certain fields if they're not applicable; for example, if a weapon is set as a projectile turret, the durability and jamming fields will be grayed out. IIRC, beams ignore both proximity and blast radius. Since the attributes seems like they could apply to beam weapons, I think it would be helpful to gray them out to avoid user confusion.
Moving on to slightly more substantial matters, while trying to make a beam weapon that would "sweep" across an arc (completely impossible, I discovered), I spent some time fiddling around with the "fires at fixed angle" field. It seems that any time you flag a beam to fire at a fixed angle, be that through the function in MC or through giving it inaccuracy in ResEdit, it will simply fire straight ahead. This is true regardless if number of beams owned and whether or not they are flagged to fire simultaneously. It may be wise to disable the fire at fixed angle feature on beam weapons.
Wait, I think I remember one more thing, I'll be right back.
Fiddles with Nova and MC
OK never mind, I thought I had one or two more things relating to types of beams and inaccuracy, but I guess not.
Anyways, one final bug. I have no idea what triggered this, but a few weeks ago, when I tried opening Nova Data 1.ndat for version 1.1.0, MC sat and churned for probably 2+ minutes without doing anything. Trying to force-quit didn't help; MC would disappear from the force-quit menu, but it would still be open in the dock, and re-opening the force-quit menu would cause MC to re-appear (good lord that was a lot of hyphens). The really befuddling part is that I can open all the other .ndat files, and I can open Nova Data 1 from the 1.0.10 files. I can certainly do some troubleshooting if you'd like, but I figured I'd ask before I started mucking with variables.
Man, if only beams could fire at fixed angles, or beams with inaccuracy and count > 1 would stay in one place after fired. You could make such cool stuff happen.
QUOTE (Archon @ Apr 28 2009, 02:49 PM) <{POST_SNAPBACK}>
The first two have to do with nit-picks over the Prox. and Blast Radius fields. The mouse-over tooltip for Prox. Radius is the same as that for Blast Radius: "The radius (in pixels) of the blast damage."
In fact, this is another thing that I've fixed but not got around to releasing because of the add-ons page upgrade.
IIRC, beams ignore both proximity and blast radius. Since the attributes seems like they could apply to beam weapons, I think it would be helpful to gray them out to avoid user confusion.
Thanks, I've disabled the proximity and blast fields for beams.
It may be wise to disable the fire at fixed angle feature on beam weapons.
I haven't tested this myself, but I'm always reluctant to disable something that's technically valid: a future version might declare it a bug and fix it, or someone might find something undocumented and interesting for which it could be used.
...when I tried opening Nova Data 1.ndat for version 1.1.0, MC sat and churned for probably 2+ minutes without doing anything.
No idea what's happening here – I just opened Nova Data 1.ndat without any difficulty. Given the excessive oddity that's involved in importing an NDAT (I do so wish that format had never been invented) my first guess would be something odd with the way that particular file is stored on your disk.
Agreed.
I know this is probably not the best time to ask for a feature to be added, but I just thought of something that might be pretty useful: a visual rangefinder for weapons. I thought of it for beams, and I don't know how difficult it would be to incorporate a slider-bar into the interface, but it seems like the BeamLength field naturally desires a click-and-drag entry method. That is, you drag the slider, and however far it is from the end, that's how long the beam is.
The simple version: Put a slider-bar horizontally across the wëap editor window, perhaps right where you currently have the first dividing bar, immediately above the BeamLength field. Moving the slider changes the number in BeamLength to equal the number of pixels from the left that the slider is positioned, and changing the number in the field makes the slider jump to that value. If a value is entered that's outside the slider's range, the slider goes all the way to the end. The slider could be grayed out if the weapon isn't a beam, if you want. This would make me thoroughly happy.
The slightly more intricate version: When the weapon is a beam, it functions as above. When the weapon is a projectile, the slider moves to match the range of the weapon (Count * Speed / 100 pixels). This would make me ecstatic. An optional frill: The slider is never grayed out, and moving it changes the weapon's Count (or maybe Speed: there could be a little button to toggle this, whose state doesn't get saved) so the range matches.
The moderately fancier version: For beams, the region of the bar to the left of the slider is colored. It could be all one color or, if you want, the color from the BeamColor field. I'm thinking somewhere around 3-5 pixels wide. An optional frill: The beam is drawn as it would appear, taking into account color, width (to a limit of maybe 16 pixels, unless it appear behind text and stuff in which case it needs no limit), corona color, corona, and whatever makes the beam taper off at the point. This would ignore lightning and fading in or out.
The super-snazzy version: For projectiles, a dot starts at the left edge, moves at Speed along the line until it reaches the slider, then repeats. Maybe a Preferences option should be available to disable this for people that prefer no motion. An optional frill: For projectiles, the dots would appear every Reload at the left, rather than one at a time in a loop. An excessively decadent possibility: For projectiles, as above, plus taking into account BurstCount and BurstReload, plus fading in or out. For beams, include Reload, BurstCount and BurstReload, plus fading.
Really, the first two versions are all I want. The latter two were just whimsical musings on what's possible. If you made a slider that showed BeamLength or projectile range as appropriate, and when the slider moved it adjusted BeamLength, but was grayed out for non-beam weapons, that would be awesome. Just remember to update the slider's position when the weapon type is changed. No need for colors or animations or anything. Thank you so much for taking the time to read this,
~Qaanol
This post has been edited by Qaanol : 08 May 2009 - 06:16 PM
That sounds like a good idea. I can't do anything about it at the moment – I'm on the emergency Mac mini while my Mac Pro receives service for graphics card troubles – but I'll give it a try as soon as the primary computer returns. I think all of the options are technically possible (and for the most part not even all that complex), so I'll do some experimenting to see how much seems genuinely useful.
Two more suggestions, both easy, one semi-useful, one utterly ridiculous.
Some resources are set to, when opened, set the cursor to the beginning of the resource name. Some are set to select the entire resource name instead. The latter can be very irritating in the case when somebody's sausage-fingers accidentally hit (enter). or (return), thus renaming the resource "." or "". (As an aside, how the hell do you punctuate that sentence?) It may just be me, but I'd love to see all the resources simply set the cursor to the beginning when a resource is opened.
The second and completely arbitrary/nit-picky one is this: when you're in the mission editor, if you set the number of auxiliary ships to 0, MC sets it to -1 (which is technically inaccurate). I know that the difference between 0 and the empty set makes no difference in this case, but even if you don't do anything about it (I certainly wouldn't), the a**hat in me wanted to point it out.
Don't kill me.
Personally, I would rather that the whole name was highlighted on every resource. Makes for quick and easy editing without the use of a mouse. Just my thoughts.
True, but it also leads to a fair number of botched deletes, and if it starts at the beginning, you can still select the whole name by hitting (shift)(down arrow). You can usually even make it before the window pops up with practice.
QUOTE
Can you post a plug-in containing just the affected resource, and one which works properly?
Doesn't work
Works
Just got back to my EV Firefly project after a number of months, and found I had to download Nova again for the first time in forever. Got 1.1.0.
Am I right in thinking that the Resources directory of the package acts just like the old Nova folder, eg, just create a "Nova Plugins" directory and "pilotlog.txt" there and all?
And how do I update my plug-in files to work with the new format?
Plug-ins and pilots now reside in username /Library/Application Support/EV Nova/
No need to reformat anything. There's even a handy TC-picker interface if you hold Shift when opening Nova.
QUOTE (Lindley @ May 30 2009, 01:19 PM) <{POST_SNAPBACK}>
MissionComputer can open and save the new format, but everyone will thank you if you don't convert your plug-ins. The new format offers no advantages of any value, and while the new version can handle the old format without any trouble, the reverse is not true.
Okay, good to know.
...It's not working. I start Nova with shift down, it gives me the "select folder" box, and I select the folder containing my plug-in files; but then Nova still starts with the default boot screen and music.
I even bothered to open, "modify", and save all my plug-in files in Mission Computer so that they'd pick up the right icon (not sure if that actually makes a difference).
EDIT: Ah! I need to create a "Nova Files" folder within my plug-in directory. Well, that's a bit different. Makes a kind of sense though.
This post has been edited by Lindley : 30 May 2009 - 04:49 PM
when i start it , a dialog box apears saying "missioncomputer has encountered a nil object error in the Apps:xprefsread routine that prevents it from running" !!!!! :mad:
That's a known bug. Delete the mission computer preferences and it should work again.
One thing I liked in NovaTools which MissionComputer seems to be lacking is a means to preview a shan in terms of both base image + glows + whatever else, all at the same time. Is this something that will be added at some point?
Possibly sometime – I've never got around to the shän editor because it would be so much work just to duplicate something NovaTools already has, but with new Macintoshes not running ResEdit, there's a bit more justification than there used to be.