@jacabyte, on Jun 24 2008, 11:06 AM, said in MissionComputer 4.0a8 now available:

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?

Extra resources are no problem whatsoever - plenty of plug-ins contain a vers resource, or a custom icon, or for that matter the 'dsďg' resource that MissionComputer saves to make sure that the resource fork is working. The convertor just reads the resources from one format, and writes them in the other, without paying any attention to what they mean.

I can think of one thing that you could add that would be nice. If you could add the ability to select multiple systems and drag them to a new spot on the map, that would make life easier. I have had to change where I want my systems to be about 3-4 times. It's kinda annoying to have to drag each individual one.. haha but this is just a petty annoyance and the solution I propose may not be a simple one at all. Just a though

Eirikr: You're right on both counts - this would be a very good thing to have, and it wouldn't be simple to do. I'll keep it in mind for future versions.

I'm just worried about what EVNEW might do if it encounters a strange resource. It already butchers DLOGs.

You might have to redo part of the converter, and tell it to cut out the bit designations, but it doesn't matter. The designations are only to make the creating simpler, and you generally only convert it for final form or testing, where you don't have to have any of it.

@guy, on Jun 24 2008, 03:50 PM, said in MissionComputer 4.0a8 now available:

I'm just worried about what EVNEW might do if it encounters a strange resource. It already butchers DLOGs.

...so, since plug-ins already contain resources which are 'strange' in EVNEW's eyes, we know that the only problem is that they get wrecked, which doesn't matter if they don't do anything.
0101181920: Neither the official Mac-to-Windows convertor nor my two-way convertor has any trouble with unrecognised resource types.

Remember, we're talking about something I've already said I won't do for 4.0. My only interest in it at the moment is in hearing whether people would find it helpful, and how they would want it used, and both of those are secondary to comments about 4.0 itself. If at some point I do decide to act on this idea, rest assured that I'll deal with the problem of making it work.

@david-arthur, on Jun 25 2008, 09:33 AM, said in MissionComputer 4.0a8 now available:

...so, since plug-ins already contain resources which are 'strange' in EVNEW's eyes, we know that the only problem is that they get wrecked, which doesn't matter if they don't do anything.

True, though if you and a windows developer are working on the plug together you would have problems. I guess you could always keep them in a separate plug. Alright, I'll agree with it :). You could do scan bits and c/r bits too.

This post has been edited by Guy : 24 June 2008 - 07:42 PM

The Resource Selector currently only shows files in its drop-down list that contain the desired resource type. However, it still defaults to the current file, even if the current file does not contain resources of that type. I suggest this be modified. Keep the current file in the drop-down, but don't default to it.

On the subject of moving multiple systems----odd as it may sound, rather than simply allowing translation of multiple systems, I'd be in favor of being able to apply any well-defined mathematical function to the positions of a group of systems. Say you wanted to spread out systems to create a space in the middle; you could define a center point and move them away from it by some Gaussian amount, so that the largest distortion is near the center but the rest adjust in a natural way to the change.

This post has been edited by Lindley : 24 June 2008 - 11:37 PM

For some reason, and I suspect that I know why, this is consistently crashing on my little indigo iBook. DA, could you kindly direct me to the last OSX version of MC that uses the smaller window sizes?

For what it is worth, however, this version works rather well on the main home computer that has a proper resolution capacity.

@lindley, on Jun 24 2008, 10:18 PM, said in MissionComputer 4.0a8 now available:

The Resource Selector...still defaults to the current file, even if the current file does not contain resources of that type.

Fixed, thanks.

@lindley, on Jun 24 2008, 10:18 PM, said in MissionComputer 4.0a8 now available:

I'd be in favor of being able to apply any well-defined mathematical function to the positions of a group of systems.

It's an interesting idea, but implementing it would take a bit of thought, and it would require a scripting system; you would define that function by writing a little programme which MissionComputer would then run. I'll keep it in mind, but it would definitely be an 'advanced' function, and I don't know how great the demand would be.

(I remember TomWoozle was once working on a programme which would lay out galaxies according to a semi-random formula. I wonder how far along he got.)

@rmx256, on Jun 25 2008, 08:54 AM, said in MissionComputer 4.0a8 now available:

For what it is worth, however, this version works rather well on the main home computer that has a proper resolution capacity.

So you think the screen resolution is causing it to crash? That would be strange - the system usually has no trouble with allocating windows larger than the screen, even if they are inconvenient for the user. Are there any other differences between the computers - system version, processor?

The last version to support 800x600 monitors was 3.3.2, but the 1.x-3.x versions of MissionComputer are substantially different from 4.0 under the hood, so I don't know that it would prove much to try it.

@david-arthur, on Jun 25 2008, 01:47 PM, said in MissionComputer 4.0a8 now available:

It's an interesting idea, but implementing it would take a bit of thought, and it would require a scripting system; you would define that function by writing a little programme which MissionComputer would then run. I'll keep it in mind, but it would definitely be an 'advanced' function, and I don't know how great the demand would be.

I'm not sure there's a need for a full scripting system, although that would be awesome. Just a simple equation parser (easy using lex and yacc) and a way of selecting the elements for it to operate on. Perhaps it could be extended to a full scripting system in the future.

@guy, on Jun 24 2008, 08:24 PM, said in MissionComputer 4.0a8 now available:

True, though if you and a windows developer are working on the plug together you would have problems. I guess you could always keep them in a separate plug. Alright, I'll agree with it :). You could do scan bits and c/r bits too.

As long as we're dreaming.... The bit-descriptor lookup table could be either stored as, or convertible to, a comma- or tab-delimited text file. That would make it easy to share with Windows developers, and would also be handy if a Mac developer was switching back and forth between MC and another editor.

EDIT: Lindley, if DA doesn't soon add batch syst repositioning to MC (which would of course be awesome), it can be done it with ConText/ResStore and some spreadsheet calculation.

This post has been edited by Dr. Trowel : 25 June 2008 - 09:29 AM

@lindley, on Jun 25 2008, 10:15 AM, said in MissionComputer 4.0a8 now available:

I'm not sure there's a need for a full scripting system, although that would be awesome. Just a simple equation parser (easy using lex and yacc) and a way of selecting the elements for it to operate on. Perhaps it could be extended to a full scripting system in the future.

Actually, I think a scripting system would be easier. With scripting, I could simply expose MissionComputer's internal variables to the script; with equations, I'd need to spend all sorts of time parsing to work out that x means SystemPos(237, 1) and so on.

Not that any of this is in the plans for 4.0.

Ah, you're like me then. Why do the quick hack when you can redesign the architecture in twice the time?

Has anyone else noticed the following sequence of events?

- Open game data file
- Open 'Star Map'
- Open particular system
- Open spob in said system
- Close said spob
- ... not back into the system or galaxy map, necessitating reloading either? I mean, shouldn't the galaxy map or system simply reload itself?

@lindley, on Jun 25 2008, 11:05 AM, said in MissionComputer 4.0a8 now available:

Ah, you're like me then. Why do the quick hack when you can redesign the architecture in twice the time?

MissionComputer has been made of quick hacks (or in some cases very slow ones) for long enough - getting rid of them is one of the main purposes of 4.0. In any case, though, I really do mean that the scripting system would be literally less work than a formula, not just that it would be more elegant.

@rmx256, on Jun 25 2008, 02:50 PM, said in MissionComputer 4.0a8 now available:

... not back into the system or galaxy map, necessitating reloading either?

This is correct behaviour. The code for the behaviour you're expecting was broken by the switch to allowing you to have more than one resource open at a time, and I haven't yet rewritten it. It's on my short-list of things which need to be done before the release of 4.0.

really, it would be awesome if you included a program that took multiple images and turned them into a grid. I have been fighting with programs like that for years, and they never work quite how they should. it would be so awesome to have a program integrated into mission computer.

@david-arthur, on Jun 25 2008, 04:39 PM, said in MissionComputer 4.0a8 now available:

This is correct behaviour. The code for the behaviour you're expecting was broken by the switch to allowing you to have more than one resource open at a time, and I haven't yet rewritten it. It's on my short-list of things which need to be done before the release of 4.0.

Would not this:

Open galaxy map.
Click to open star system. Galaxy map stays open in the background.
Click to open planet. System stays open in background.
Close planet. Other windows still open.

Be one possible solution?

Perhaps an option-click could open the new window and close the old one.

Good to hear improved DLOGs in the next alpha
Just a couple of related requests:

1. When opening a DLOG, automatically bring up the dialogue info.
2. When editing a DITL, write the DLOG resource when clicking OK on the dialogue info (perhaps change the label to Save) rather than when closing the window. This would allow you to have just a DITL and no DLOG if all you're doing is changing the layout of a dialogue stored somewhere else.

This post has been edited by Guy : 26 June 2008 - 04:31 AM

@yamfries, on Jun 25 2008, 09:01 PM, said in MissionComputer 4.0a8 now available:

really, it would be awesome if you included a program that took multiple images and turned them into a grid. I have been fighting with programs like that for years, and they never work quite how they should. it would be so awesome to have a program integrated into mission computer.

p2s and m2s don't work for you? Granted, occasionally they'll give me a sprite that has banding artifacts of some type, but for the most part they're fine.