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've edited my previous post a couple times but I wanted a separate post for this since it's not a bug but a clarification of a suggestion I made in the 4.0a4 thread. The reason I want resizable windows is so I can see what I'm working on in two windows at once. In this screenshot, I'm trying to make dësc resources for outfits that mention what the associated weapons do. I have a ConText file showing weapon stats in the background and I want to be able to read it while typing into a MissionComputer window. Unfortunately the MissionComputer window cannot be resized, so I have to keep switching back and forth between windows and remembering what the numbers are, rather than being able to read them as I'm typing. Big hit to my productivity.
As a side note, when you create a new dësc for a shďp, spöb, or oütf, it would be nice to have the name of the dësc default to the name of the resource you create it for, rather than being blank. "Shuttle", "Shuttle Hire", "Earth", "Earth Bar", "Fuel Tank", etc.
Edit:
It would be nice to be able to view the full listing of more than one type of resource at a time. That is, to see all wëap resources in one window and all oütf resources in another. Or is this already possible and I'm just missing it?
Edit 2:
Running Mac OS X 10.4 on an Intel MacBook Pro with 2GB RAM, Mission Computer is very slow (approx. 2-3 seconds of the "watch" cursor) when closing a PICT resource window.
Edit 3:
Can't remember if this has been mentioned before but I'd like to be able to view PICTs by name in addition to ID.
This post has been edited by Qaanol : 22 February 2008 - 08:01 PM
I can't say whether resizable windows would be a good idea but just looking at that screenshot makes me think the outfit editor could stand to be a lot smaller. There's a lot of empty space plus the name fields at the top are unnecessarily large.
I'm getting high instability playing snd resources. It crashes about every 1 in 5 or 10 times I play a sound.
@qaanol, on Feb 21 2008, 10:38 PM, said in MissionComputer 4.0a5 now available:
Cost field for a shďp resource. I enter the number "50000" (any number over 999) and click into a different field. The cost turns into "50,000" (commas added). I click back in the cost field and it becomes "50" (loses everything to the right of the left-most comma).
Oütf resource ModVal descriptive text for ModType Speed Increase says (1 = 30ş/sec) but the Nova Bible says (100 = 30°/sec).
Fixed, thanks. The latter text was left over from the first two games.
And the Falloff field for the wëap resource defaults to -1, which for sprite weapons causes a fade-in over time effect. Default to zero is preferable.
The RDL interface doesnt have a provision for customised defaults; I could improve RDL, but with only two EV Nova resources still dependent on it, I think its more productive to spend my time writing the remaining real editors.
@qaanol, on Feb 22 2008, 07:25 PM, said in MissionComputer 4.0a5 now available:
The reason I want resizable windows is so I can see what I'm working on in two windows at once.
I understand that under some circumstances it would be useful, but I also think that most of the time it would be unintuitive and counterproductive; I use programmes with this sort of design on a regular basis, and find it quite a nuisance. I may be able to make a few of the windows slightly more compact, but thats as far as it goes.
This is something that was in MissionComputer since 1.0, but I had to break the technology for doing it in order to allow you to open more than one resource at a time. I hope to find a new way to do it before releasing 4.0.
It would be nice to be able to view the full listing of more than one type of resource at a time.
Ive thought about this, but I havent yet come up with a way of doing it that wouldnt create more problems than it solved.
Ill run through it. This happens even if you havent modified the PICT?
If you go to Preferences and un-check Use graphical pickers where appropriate, PICTs will be listed by ID and name just like any other resource type.
@qaanol, on Feb 22 2008, 11:43 PM, said in MissionComputer 4.0a5 now available:
If this is still on the MacBook Pro, Im afraid its probably an Intel issue, which Im not equipped to trace at the moment, but Ill keep it in mind.
Mission Computer is very slow (approx. 2-3 seconds of the "watch" cursor) when closing a PICT resource window.
Does the amount of time it takes increase depending on how many PICTs are in the file? Is it faster if you select a different resource type in the list before closing the PICT window?
Yes, and yes. And perhaps useful to know, it closes fast when "use graphical pickers where appropriate" is unchecked. Specifically, when the graphical picker is used, it takes a certain amount of time to show the thumbnails after clicking to list PICT resources, and the more PICTs are in the file, the longer it takes them to show by thumbnail. Then, when PICTs are still listed by thumbnail and one of them is open, it takes roughly that same amount of time again to close it.
I have revisited MissionComputer just today, it has come a long way since I first used it. I like the changes and where it is going. Nice job.
Couple bugs:
Mac OS X 10.4.9 2 GB RAM (Plug is 12 megs with graphics so far)
Intel or PPC?
@desprez, on Feb 27 2008, 12:01 AM, said in MissionComputer 4.0a5 now available:
Plug is 12 megs with graphics so far
You might want to split that soon. The maximum size for a resource map is theoretically 16 MB, but I find that editing becomes unreliable after 10 MB.
This post has been edited by MadFax7 : 27 February 2008 - 09:47 AM
@qaanol, on Feb 26 2008, 06:57 PM, said in MissionComputer 4.0a5 now available:
Yes, and yes. And perhaps useful to know, it closes fast when "use graphical pickers where appropriate" is unchecked.
As I thought. I happened to be testing it using a larger plug-in than usual yesterday, and experienced the same thing myself. The problem appears to be entirely with the graphical picker itself, taking too long to refresh, rather than anything specific to the PICT editor.
The contribute bit box in the ship editor displays an "X" even though bits are set.
Fixed, thanks.
@madfax7, on Feb 27 2008, 09:44 AM, said in MissionComputer 4.0a5 now available:
Yes, indeed; you can never be too careful about splitting your plug-in. Both EV Override and EV Nova ran into problems with the upper limits during their development (the 16 MB limit is only one of many limits that might hit you, and the others are much harder to measure), as did major plug-ins as early as 1997.
I split up the plug, and I still get frequent crashes, even on files less than a meg.
Also, adding files in the preferences for use with resource selectors doesn't seem to work. Assuming they are for things like a menu when picking a weapon while in the ship or outfit editor. That's what it is for, right?
@desprez, on Feb 27 2008, 08:33 PM, said in MissionComputer 4.0a5 now available:
Did you select the appropriate source file in the resource selector?
@madfax7, on Feb 28 2008, 02:48 AM, said in MissionComputer 4.0a5 now available:
I looked, but the source files don't appear.
Assuming they are for things like a menu when picking a weapon while in the ship or outfit editor. That's what it is for, right?
Adding custom files (other than the contents of the Nova Files folder) to the Resource Selector isnt implemented yet. At the moment the custom files appear only in the File->Open Special menu.
Bug: When importing PICTs into the REL and PICT resources, something's not being handled right, as I can't later save over the file on my hard drive. I get an error about the file currently being used or not closed properly.
@desprez, on Mar 1 2008, 02:39 AM, said in MissionComputer 4.0a5 now available:
When importing PICTs into the REL and PICT resources, something's not being handled right, as I can't later save over the file on my hard drive. I get an error about the file currently being used or not closed properly.
Im not sure what youre trying to do can you describe the exact procedure which produces this problem?
@david-arthur, on Mar 1 2008, 04:38 PM, said in MissionComputer 4.0a5 now available:
Ok. I make a shipyard pict in Photoshop. I save it and then import it into a shipyard pict resource. After deciding that I need to edit the picture, I open it back up in Photoshop, make changes, then I get the error when trying to save the file.
I'm assuming MC's import function is the culprit here, as I've never encountered this problem with EV:N or Photoshop before.
Oh, quick other question. I tend to save my graphics in 32 bit. MC automatically converts this to 16 bit for the rleD resource, right? I ask because my plug sizes are skyrocketing (22 ships = 15 megs!) and I wonder if it is because the graphics are the wrong bit size.
@desprez, on Mar 2 2008, 02:57 AM, said in MissionComputer 4.0a5 now available:
MC automatically converts this to 16 bit for the rleD resource, right?
Yes, it does EV Nova s RLE format doesnt even allow 32-bit graphics, so there isnt really any alternative. Remember that the RLE resource contains mask information as well, and that despite its name, it doesnt really do all that much in the way of compression.
@david-arthur, on Mar 2 2008, 08:30 AM, said in MissionComputer 4.0a5 now available:
and that despite its name, it doesnt really do all that much in the way of compression.
It does load significantly more quickly in Nova, however, in comparision to PICT-based sprites. Also, in my experience an RleD is roughly half the size of an equal PICT-based sprite and mask.
@crusader-alpha, on Mar 2 2008, 05:32 PM, said in MissionComputer 4.0a5 now available:
It does load significantly more quickly in Nova, however, in comparision to PICT-based sprites.
Exactly: this is the real reason for RLEs. The advantage is that in the course of creating an RLE, you apply the mask to create a complete sprite, whereas with PICTs, the game has to do this every single time it loads the data.