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).
Yup. Round down. Or you can just include your biggest image at the first ID and leave it at that.
The cölr resource always changes back to the defaults. Otherwise it looks good. Open special will save my life.
@lindley, on Jun 21 2008, 07:05 PM, said in MissionComputer 4.0a8 now available:
After using the "Import from file" button to import a Tiff file into a Pict resource, that file is not deletable or overwritable because the system thinks it is "in use". Usually this means you've forgotten an fclose() somewhere.....
I'd heard about this from other people, but I just spent some time on it, and no matter what I do, I can't reproduce it. Does it always happen? Does it happen when you import pictures into Make RLE as well? What system version are you using, and is your computer Intel or PowerPC?
@lindley, on Jun 21 2008, 10:03 PM, said in MissionComputer 4.0a8 now available:
I managed to make nebula 128 show up in the star map by assigning the pict ID 9502. As the third ID in the first set of 7, this corresponds to the 75% image, not the 100% image. Unless the Nova Bible is wrong.
As Guy has already remarked, the engine behaves strangely with regard to this particular question. MissionComputer follows a vastly simplified procedure which works with the default scenario's nebulae, so if you do yours the same way, your nebulae should appear properly as well. In any case, the pink square it displays as a stop-gap should be adequate for placing systems, even if it isn't as attractive.
@0101181920, on Jun 21 2008, 11:30 PM, said in MissionComputer 4.0a8 now available:
The cölr resource always changes back to the defaults.
Fixed, thanks.
@david-arthur, on Jun 22 2008, 01:43 PM, said in MissionComputer 4.0a8 now available:
PowerPC G4, 10.4.11, latest MC.
The Tiff files are created in Photoshop CS3 (10.0). They are not saved with any special options, just the defaults: (Embed color profile, Macintosh byte order, Interleaved channels, No compression). I then open a plug-in, go to the Pict resource section, and hit command-K to create a new one. I assign it an ID, then give it a name. I click the Import button, and select the file. It imports correctly. Thereafter, the file registers as "in-use" by the system.
This is done while the file size is over 13MB. If there's any built-in limitation to Mac max resource fork size, that could be relevant. There is one anomaly in this respect: Adding all my nebu images only seems to grow the file size by maybe 400k, despite the fact that sum of all the tiff file sizes is over 1MB. This could be due to downsampling to thousands of colors, I suppose.
This post has been edited by Lindley : 22 June 2008 - 09:38 AM
Uncompressed TIFFs are much larger than PICTs for the same data, so the decrease in size isn't surprising. I would be interested in knowing whether the same thing occurs if you save as PICT rather than TIFF, and whether Make RLE has the same problem as the PICT editor.
A note about the FallOff field for fading: a negative FallOff in conjunction with the "translucent shots" flag will cause a sprite that is never visible. I'm not sure that there's really a good way to implement this; I think the best you could do would be to make a note somewhere.
@david-arthur, on Jun 22 2008, 03:02 PM, said in MissionComputer 4.0a8 now available:
I would be interested in knowing whether the same thing occurs if you save as PICT rather than TIFF,
Yes, it seems so. However, I did notice that apparently if you save as a Pict resource rather than a Pict file, it's greyed out in the list. Of course you can open that file as if it's a Nova plug-in and copy the pict resource directly; I'm just saying.
Quote
and whether Make RLE has the same problem as the PICT editor.
It seems not.
Oh, and it'd be nice if I could select more than one pict resource at a time. For deletion purposes, at least.
@david-arthur, on Jun 23 2008, 01:43 AM, said in MissionComputer 4.0a8 now available:
MissionComputer follows a vastly simplified procedure which works with the default scenario's nebulae, so if you do yours the same way, your nebulae should appear properly as well.
Working with the default scenario is nice but not ideal. Could you make it try the first index if it can't find the third?
@lindley, on Jun 23 2008, 02:29 AM, said in MissionComputer 4.0a8 now available:
This could be due to downsampling to thousands of colors, I suppose.
Regarding colour depth, MC always imports at millions of colours with no regard for the original depth, is that correct David? Why is this? Some pics, like the button ends, do not work if they are in millions.
I found something of worth: I was looking at a desc that was 8428 characters long, and when I closed the desc I was greeted by a message informing me that it would cause trouble in Nova. I clicked okay and got a crash to desktop from MC 4.0a8.
I might add that the window looked like it was grayed out. It reminded me of a window that has been shoved to the background in Windows.
@lindley, on Jun 22 2008, 08:27 PM, said in MissionComputer 4.0a8 now available:
However, I did notice that apparently if you save as a Pict resource rather than a Pict file, it's greyed out in the list. Of course you can open that file as if it's a Nova plug-in and copy the pict resource directly; I'm just saying.
MissionComputer can't tell whether a resource file contains a single picture, many pictures, or something else entirely until after you've opened it, so it would have no way of knowing which resource files it should list in Import from File and which it shouldn't.
Anyway, the whole point of saving as a resource would be to use the resource Photoshop generates rather than passing it through MissionComputer's PICT editor. (Remember, a PICT resource is ~not~ identical to a PICT file.)
Now that's really odd - there's next to no significant difference between the code in the two places. I'll have to investigate more closely.
If you turn off the graphical picker in Preferences, you can select more than one resource, just like with any other type. Multiple selections in the graphical picker will require a major revamp of the code powering it, which isn't practical in the 4.0 timeframe.
@guy, on Jun 22 2008, 10:26 PM, said in MissionComputer 4.0a8 now available:
I am thinking of revising the nebula-loading code (the rewrite of the star map I did early in 4.0 will make it much easier), but note that I said you could work the same way as the default scenario, not that you should actually have it loaded.
Regarding colour depth, MC always imports at millions of colours with no regard for the original depth, is that correct David? Why is this?
Because it's absurdly complicated to get it to do otherwise. For the foreseeable future, the solution is to process your images with BlitZen - as was done for the original scenario - and then copy the actual resource it produces, rather than the picture contained within.
@jacabyte, on Jun 22 2008, 10:39 PM, said in MissionComputer 4.0a8 now available:
The crash may be caused by the fact that the window was closing at the time the warning appeared - I'll see if I can find a workaround.
I downloaded, and so far, I love it. I might have found a problem with the RleD system, but it might have been my mistake, so I am going to go over and check again.
@david-arthur, on Jun 24 2008, 02:18 AM, said in MissionComputer 4.0a8 now available:
Right, I understand what you meant, it's just it won't work if you've chosen to just have one image (which seems fairly sensible to me, given Nova's behaviour). Glad that change is possible
I have a question about Mission computer. when making RleD's, I have had a whole lot more luck making sprites with both the sprite and mask with a black background, whereas when I use white for the sprite, and black for the mask like your supposed to, I get this:
using a black sprite and mask:
however, in both cases, it informs me that the layout does not divide evenly into that number of frames when i put in the grid. I tried it in the older version of mission computer, and it worked much better. I don't know what is wrong, or even if there is something wrong, but I though it would mention it.
I had an idea that you could maybe implement. This is by no means necessary, but I think it would be helpful. Create a bit organizer. So in the list of resources, there's a new file labeled "bit". If you want (you don't have to), you can tell it to "create" a bit, which basically just sets a name to it. After that, in the NCB tests and On Purchase (or whatever) boxes, when you can pull down the little menu that lets you search for resource ID's to be put into the NCB, there's a new option titled Bit. This will just go into the bit "resource", and allow you to select one, based on name. You don't have to set it up so that it will make a new entry everytime you use a new bit, or show where bits are connected. I just think this little organizer would be helpful.
You can't name bits because the names can't be saved in the file (well they could if DA came up with an appropriate way of doing so but they certainly shouldn't be saved in the file).
@yamfries, on Jun 24 2008, 08:47 AM, said in MissionComputer 4.0a8 now available:
whereas when I use white for the sprite, and black for the mask like your supposed to,
Who told you this? You need black for the sprite to match the blackness of outer space. White is incorrect.
This post has been edited by Guy : 23 June 2008 - 08:22 PM
@guy, on Jun 24 2008, 01:18 AM, said in MissionComputer 4.0a8 now available:
Rez files might be a problem. But Mac resource forks can have additional resources without worry; Nova will just ignore them.
I rather like the idea of "naming" bits. One addition: You should have the ability to define a range of bits as an array, for mission strings. On the wishlist, anyway. Heck, while we're at it, a "bit analyzer" utility which could automatically name bits according to how they're used would be great. "b0001: OnComplete - Cargo Delivery (139)", for instance. With more complex names for bits used multiple places, and usage summaries for bits so heavily used that the program can't make sense of them.
This post has been edited by Lindley : 23 June 2008 - 08:48 PM
@yamfries, on Jun 23 2008, 04:47 PM, said in MissionComputer 4.0a8 now available:
No, your sprite should always be rendered against a black background, just like anything else you're planning to mask for display against a dark screen.
it informs me that the layout does not divide evenly into that number of frames when i put in the grid.
What are the pixel dimensions of your image, and what number of frames did you specify for your grid?
By definition, the dimensions have to be the same for each frame, and the number of frames doesn't divide evenly into the dimensions of your source grid, this simply isn't possible.
@0101181920, on Jun 23 2008, 07:55 PM, said in MissionComputer 4.0a8 now available:
Create a bit organizer. So in the list of resources, there's a new file labeled "bit". If you want (you don't have to), you can tell it to "create" a bit, which basically just sets a name to it.
I've thought about things like this. Though so far I've been reluctant to create new resource types* that are used solely to aid editing, there are various ways that it could be helpful. Apart from the example you give, I've also considered a similar strategy for dealing with EV Nova 's gövt classes, which are more powerful than the older features they replaced, but also harder to track.
Such resources would, as Guy says, be entirely ignored by the engine, but this wouldn't matter because their purpose would only be to help you record what you were using each bit or class for. I'm not going to do anything this radical in 4.0, but I'll keep it in mind, and I'd be glad to hear anyone else's comments on the matter.
@lindley, on Jun 23 2008, 09:43 PM, said in MissionComputer 4.0a8 now available:
.rez files wouldn't pose a problem - apart from the different data format and the higher size limits, they have essentially the same capabilities of the resource fork.
well, I got SpinApp to work, and thats solved the problem. (all of them)
and thanks for telling me about the sprites. I will remember it in future
I'd be a bit edgy about putting extra resources into a plug-in just for the sake of editting. Do we know if these plug-ins would work on Windows, or if they'd lock up plug-in converter.exe? I'm more in favor of a "bit analyzer," like the one Lindey suggested, that looked up a bit or a list of bits according to where they were used in a given plug-in. Say, "bxxx - cron yyy Tribbles Breeding" or something similar would be extremely useful.
From seeing the "Resource Xxxx has size Nnnn", I don't think the plug-in converter would have issues. I can think of: simple: government class outfit class display weight
complex: bit helper some kind of mission/cron string helper