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).
@qaanol, on 16 February 2011 - 09:55 AM, said in MissionComputer: The Saga Continues:
Putting a multiplication symbol × in the name—or any text field—of a non-RDL resource causes that character to be replaced with an asterisk * after closing the resource.
The multiplication symobl isn’t a MacRoman character. The asterisk is the closest equivalent available when I convert text encodings; without conversion, it would merely be garbled. (And when I test, the same happens with the shän editor, as expected.)
I’ve recorded the other two issues, and will fix them in the next release.
@david-arthur, on 16 February 2011 - 02:03 PM, said in MissionComputer: The Saga Continues:
Very good, seems I was mistaken about the shän.
There is a problem with MissionComputer 4.2’s RLE creation, that in my tests causes upwards-moving dots to appear on the left edge of sprite, and a checkerboard pattern along the very bottom of the sprite.
Witness, this is the exported sprite image of an RLE created in MC:
Spoiler
And here it is animated:
It may be difficult to see the dots on the left of the sprite above against the background of these forums, but they are there and should not be. The bottom row of pixels in each frame shows a checkerboard whereby every other pixel has been turned black, even when it should not be.
This next RLE was created in EnRLE from the same source image, and does not show the problem dots. It does, however, have other problems, with pixels not appearing exactly where they should. For example, look closely at the top edge of frame one:
And the animated version of the EnRLE sprite:
The source image is black and white, with no isolated dots anywhere:
And here is the source animated:
Edit: The problems with EnRLE are due to striping, when there is a large horizontal section all the same color. Introducing small fluctuations in the colors makes EnRLE work perfectly. MC, however, still has its same problems with or without striping.
This post has been edited by Qaanol : 21 February 2011 - 08:22 PM
Curious — it may be just a question of alignment issues, but I'll have to take a look.
While we’re looking at the RLE maker (and these request are much lower priority than fixing the aforementioned bug) would it be possible for the “Grid layout:” fields to default to the last used values, rather than the values “6×6” that they currently default to? There’s no need to remember the values after quitting the program, but once the user has entered values for one RLE, I’d like those values to be the default for the next.
Also, the functionality to automatically generate a spïn or shän while creating an RLE is very nice. Would it be possible to add that feature to the RLE viewer? That is, when viewing an existing RLE resource, to have a button that generates a spïn or shän with one click (say, clicking the “spïn” button or “shän” button pops up a window asking for the name and ID to give the new resource.)
This post has been edited by Qaanol : 22 February 2011 - 07:25 AM
I’m noticing significant delays when opening a spïn resource that points to a large PICT.
In particular, with a 7200×200 PICT and mask that together weigh about 500KB, it takes upward of 3 seconds to open the spïn that points to them. I would expect no delays whatsoever in any case. Note that there is no delay when opening the file, nor when opening one of the PICT resources. It is only the spïn that drags its heels.
There is a long delay in turning on or displaying the graphical picker when large PICTs are present, but I don’t know if that can be avoided elegantly.
@qaanol, on 23 February 2011 - 07:07 PM, said in MissionComputer: The Saga Continues:
In particular, with a 7200×200 PICT and mask that together weigh about 500KB, it takes upward of 3 seconds to open the spïn that points to them.
I believe the spïn editor still divides the sprite grid into individual frames, a relic from when it was going to display a rotating preview. But as I’m not particularly likely to implement this, it can probably be deactivated.
Generating spïn/shän resources from the RLE viewer sounds like a good idea, and should be easy enough to implement.
I don't know if there's much I can do about the speed of the graphical picker, though — I suspect it's the resizing that takes most of the time. Perhaps it could be threaded like the RLE decoder.
The “Government classes & allegiances” window has some list sorting problems. Although manually clicking to sort the lists works fine, there is an issue when any of the four list boxes are populated (either initially or upon recalculation). The list will show up with one of the column headers highlighted, indicative of a sort order (ID or Name, with an up or down arrow). But the list will not actually be sorted in that order. It does not appear to be sorted in any meaningful order.
Also, while that window and its lists are tremendously useful, it would be even more useful if there were a way to view a similar display for Classes. That is, one list would show the Class numbers in use, and three more would show Member Governments, Allied Government, and Enemy Governments. Essentially it would just switch the left-most column of the current window from “Governments” to “Classes”. Considering the processing that’s already done to enable the current functionality, I suspect the requisite data are already being generated at least in transit, and it would just be a matter of storing and displaying them.
Edit: In a similar vein, it would be helpful if there were a way to display Contribute/Require bits, as a list of Bits, which when a bit is selected then would show a list of resources that contribute it and a list resources that require it. Of course these last two lists would need three columns, for Type, ID, and Name. And it would be nice to have something similar for ScanMask.
This post has been edited by Qaanol : 27 February 2011 - 05:42 AM
@qaanol, on 27 February 2011 - 04:54 AM, said in MissionComputer: The Saga Continues:
The “Government classes & allegiances” window has some list sorting problems.
Fixed, thanks.
...it would be even more useful if there were a way to view a similar display for Classes.
I think this should be possible. The only bit of data I don’t already have is a list of which classes ‘exist’, but it should be easy enough to scan through the data I collect about the governments and see which class values are used.
Contribute/Require bits and ScanMasks would take some more thought, because of their increased complexity and (in the former case) the sheer number of resource types involved, but I’ll keep it in mind for future versions. (The other obvious candidate is an NCB tracer of some sort, but that would require an NCB expression parser, which I don’t feel like taking on at present.)
@qaanol, on 21 February 2011 - 07:19 PM, said in MissionComputer: The Saga Continues:
Fixed! It was an alignment problem — not, as I had suspected, in the sprite loader, but in the RLE row-encoder itself.
It only occurred if, within one row of a sprite, the rightmost pixel was visible, but the second pixel from the right was transparent. In this case, the transparency immediately preceding that rightmost pixel (which, in your sprite, was the entire row) was not saved, causing that single visible pixel to be shifted to the left.
The cause was one line of code which said < where it should have been <=. The reason I never discovered this in testing is that in most sprites, the visible portion does not actually touch the edge of the image.
Awesome, glad to hear it!
Does that RLE encoding fix also correct the “every other pixel on the bottom row is black” problem? That one, as far as I can tell, is a masking problem, and it occurs as early as loading the mask in the RLE creation window, where the preview image itself shows a perforated bottom row.
That appears to be the result of either a slight irregularity in the loading process, or perhaps one in the image itself — I can’t tell for sure which is the ultimate cause, but either way I’ve been able to fix it.
If double-clicking a government in the class viewer's list opened that government in the editor, would this be useful, or a nuisance?
And is there any way of 'naming' the classes that would be productive?
Am I missing something about the use of the "Show The Contents of Open Special"? Is there a way that MC will display the Open Special resources when adding content? I have the "show contents" box checked, and the folders all specified, but when I try and make a new plug, (in this case, trying to add a pair of planets), none of the Open Special content is displayed.
PPC OSX 10.4.11/ MC4.2.0
If that box is checked, then your Open Special files should appear in the source menu (alongside the game's data files) in resource-selector dialogue boxes - the ones you get when you click the magnifying glass next to an ID number.
It doesn't cause the actual contents of those files to appear inside your plug-in, the way that some of the 1990s editors did.
@david-arthur, on 04 March 2011 - 03:24 PM, said in MissionComputer: The Saga Continues:
Useful. Although, I would prefer that the Class Viewer remain open, unlike how the Star Map closes when you open a resource from it (I would also prefer that the Star Map remain open.)
The only way I can think of that would be useful is to allow the user to manually name the classes. Which I guess could be stored as a non-Nova resource such as cläs, as previously discussed. The only thing necessary to store, of course, is the association between number and name.
This post has been edited by Qaanol : 04 March 2011 - 05:39 PM
@qaanol, on 04 March 2011 - 05:37 PM, said in MissionComputer: The Saga Continues:
Although, I would prefer that the Class Viewer remain open, unlike how the Star Map closes when you open a resource from it (I would also prefer that the Star Map remain open.)
The star map has to close because it edits cached versions of the various sÿst resources, which could potentially overwrite the changes you made in the individual editors. The 'Edit star map' button in the bottom-left corner is the best solution that I can safely provide.
Where no such concerns exist, I would of course keep all such windows open.
This is probably a beginner issue, but I scanned through the 16 pages of this thread (emphasis on 'scanned'), and was not able to find an answer. I am trying to use 4.2.0 (I used MC years ago, so I am familiar with the basic operation of it), but for some reason, the Resource Copier utility is not opening the .ndat files. The files open just fine when you go through the normal process of opening them to edit, but when I try to use the Resource Copier, I get a message saying that MC can't open the file because "It may not have a resource fork." I know that back before Nova 1.1, MC was capable of opening and copying resources from the Nova Data files to plug-ins with the Resource Copier.
Any ideas?
Open an ndat file and Save As Macintosh. Work with the resulting file.
Yes, the Resource Copier is a very bare-bones tool (heavily inspired by Apple's Font/DA Mover and ResCopy XCMD, which date back to before System 7). It has seen only superficial changes since I first created it for MissionComputer 2.0, and so can only work with standard resource files; in late 2002, .ndat and .rez didn't even exist.
At various points I've thought about updating it, but that would involve a substantial re-write, and it's never seemed a priority given that so many of the functions for which I originally created it are now available in the main editor. I suppose I'd be interested to hear how extensively people are still using it, and for what purposes.
@qaanol, on 11 March 2011 - 10:18 PM, said in MissionComputer: The Saga Continues:
This worked. Thanks for the suggestion!
@david-arthur, on 12 March 2011 - 09:47 AM, said in MissionComputer: The Saga Continues:
I used it in the past to help create a plug that includes some of the existing stock variants into more systems and tweaking existing weapons. SInce I don't have that plug anymore, I'm redoing it, so it involves large amounts of small modifications to existing resources. I don't know about much other folks use it, though.
This post has been edited by erikthered : 12 March 2011 - 06:44 PM