@razzle-storm, on Jun 11 2007, 08:09 PM, said in First public alpha of MissionComputer 4.0:

Another thing I've been having trouble with is that I have to adjust the resolution of my computer to work with some types of files. Most notably when I'm working with the ship editor, and the system editor. Those two pictures are at a 1152 x 720 resolution, and if I change it to 1280 x 800, they fit fine (maybe a scroll bar or re-adjust option could be put in?).

Oh darn. I know he made it to fit 1024x768. 720 wasn't expected.

This post has been edited by Guy : 22 June 2007 - 05:55 PM

@nil-kimas, on Jun 10 2007, 02:38 PM, said in First public alpha of MissionComputer 4.0:

When you open and close a resource, it scrolls the resource list so that the resource you closed is at the bottom of the window.

It’s something I’m still working on; the usability issues surrounding it are slightly complicated, and I haven’t found an option that seems perfect yet.

@guy, on Jun 10 2007, 09:00 PM, said in First public alpha of MissionComputer 4.0:

Are you sure it's the fault of having to grey everything out? Surely that wouldn't take a noticeable amount of time.

That’s the only thing that’s happening when you switch windows. The shďp editor has more than 150 controls; activating and deactivating all of those takes longer than you would think.

@razzle-storm, on Jun 11 2007, 04:09 AM, said in First public alpha of MissionComputer 4.0:

Those two pictures are at a 1152 x 720 resolution, and if I change it to 1280 x 800, they fit fine (maybe a scroll bar or re-adjust option could be put in?)

MissionComputer 3.3.3 and above require 1024x768 or greater — supporting smaller screens would require significant sacrifices of usability, and it’s been a long time since Apple sold monitors that weren’t capable of such a resolution.

Razzle Storm said in First public alpha of MissionComputer 4.0:

(for example, typing in the value of 9000, -9000 results in the spob disappearing from the screen, because the screen only opens to the maximum width/height it needs to when you first open it. Not sure if this is a good thing or a bad thing)

I’m not sure either, but it seems better than any alternative that I’ve been able to come up with; I don’t want to default to the maximum possible values, because that would make the mini-map essentially useless for typical systems.

@guy, on Jun 11 2007, 04:35 AM, said:

Speaking of the system editor though - if I click the zoom button to maximise I see this:

Fixed, thanks.

When I open a spöb from the syst editor, it closes the syst editor to open the spob. (I haven't tried opening a s˙st from the galaxy editor, but I imaging it might do the same thing.) Since MC supports multiple open windows now, I think it would be better to leave the syst editor open behind the spob.

I noticed that the undo command shortcut doesn't seem to work, at least when writing something in the text field. Also, will it be possible to add a "revert" command if the developer wants to have the plug-in back the same way the last time they saved it?

Yeah, revert file would be nice if revert resource can't be done once you've close it.

@david-arthur, on Jun 10 2007, 06:18 PM, said in First public alpha of MissionComputer 4.0:

I’ve considered it — I’m not sure whether it will be possible to add one without slowing down the rendering unacceptably (even the game itself has trouble with this).

There must be a Vornoi diagram algorithm which is fast enough to work decently. That's all you really need.

I know there's a parallel approximate-Voronoi algorithm which can be implemented using GPGPU principals which would be definitely fast enough; but I doubt you're looking to add GPU code to this thing just now.

@nil-kimas, on Jun 11 2007, 01:31 PM, said in First public alpha of MissionComputer 4.0:

When I open a spöb from the syst editor, it closes the syst editor to open the spob. (I haven't tried opening a s˙st from the galaxy editor, but I imaging it might do the same thing.)

This is intentional. Since the s˙st editor also edits the spöb resources used by the system, if you edited one of the spöbs while the system was open, the system editor might subsequently overwrite that spöb with the older version that it was editing. In previous versions of MissionComputer, I could deal with this, because the system editor knew when the spöb editor had been opened and closed, but now that editor windows are no longer modal, users can open and close them in whatever order they like.

I’m still hoping to find a way to get the s˙st and spöb editors to communicate, but I don’t yet have a satisfactory one; it’s for the same reason that you can’t have systems and the star map open at the same time.

@coraxus, on Jun 11 2007, 07:35 PM, said in First public alpha of MissionComputer 4.0:

I noticed that the undo command shortcut doesn't seem to work, at least when writing something in the text field.

MissionComputer doesn’t, and for all practical purposes can’t, support Undo.

@coraxus, on Jun 11 2007, 07:35 PM, said in First public alpha of MissionComputer 4.0:

Also, will it be possible to add a "revert" command if the developer wants to have the plug-in back the same way the last time they saved it?

I suppose so — Revert is really nothing more than closing and re-opening it, so I’ve never seen the point, but it should be easy enough to add if people want it.

Lindley said:

There must be a Vornoi diagram algorithm which is fast enough to work decently.

It’s not just a matter of drawing the information. Even reading through the resources takes more time than you would think, and for borders it would not only need to read the Government field from the s˙st resource, but also cross-reference it with the gövt resource’s Colour field.

@david-arthur, on Jun 12 2007, 04:05 PM, said in First public alpha of MissionComputer 4.0:

It’s not just a matter of drawing the information. Even reading through the resources takes more time than you would think, and for borders it would not only need to read the Government field from the s˙st resource, but also cross-reference it with the gövt resource’s Colour field.

Well, couldn't that be amortized by maintaining a few arrays in RAM when the galaxy editor is open? It would be pretty straightforward to determine when those needed to be updated, I'd think. (I mean, you're doing it for syst resources anyway in order to display them. How much trouble could it be to do the same for govt resources?)

This post has been edited by Lindley : 13 June 2007 - 11:28 AM

Currently the checkbox for planet-type ships is labeled "Vulnerable only to planet-type weapons" or something like that. I've found that setting a ship to Planet-type does more than change what weapons it's vulnerable to. It also changes the escort behavior (they don't stay in a fixed formation) and the AI when flying around (they just sit there and turn to fire when necessary, rather than flying around and doing stuff according to their Inherent AI). It seems like the checkbox should be relabeled as simply "Planet-type ship" or something of that nature, and the tooltip should explain everything that planet-type ships do differently than normal ships, not just what weapons it can be hit by.

Will there be a support for selecting more than one resources? For example I'd select 3 ships in the ship category and I can delete, copy, or duplicate them all. I figured it's much convinient to do things like that.

@nil-kimas, on Jun 14 2007, 06:09 AM, said in First public alpha of MissionComputer 4.0:

Currently the checkbox for planet-type ships is labeled "Vulnerable only to planet-type weapons" or something like that. I've found that setting a ship to Planet-type does more than change what weapons it's vulnerable to. It also changes the escort behavior (they don't stay in a fixed formation) and the AI when flying around (they just sit there and turn to fire when necessary, rather than flying around and doing stuff according to their Inherent AI). It seems like the checkbox should be relabeled as simply "Planet-type ship" or something of that nature, and the tooltip should explain everything that planet-type ships do differently than normal ships, not just what weapons it can be hit by.

Speaking of flags, The 'Ship Scoops Asteroids' does two different things, depending on whether or not the ship has a scoop. Without a scoop it will activate 'Economy-at-work' behaviour. I think it deserves a mention somehow.

@coraxus, on Jun 14 2007, 07:06 AM, said in First public alpha of MissionComputer 4.0:

Will there be a support for selecting more than one resources? For example I'd select 3 ships in the ship category and I can delete, copy, or duplicate them all. I figured it's much convinient to do things like that.

Yes, I meant to ask that too.

@coraxus, on Jun 13 2007, 03:06 PM, said in First public alpha of MissionComputer 4.0:

Will there be a support for selecting more than one resources?

I’m looking into it. Now that MissionComputer can open multiple resources at once, there’s no reason in principle why this shouldn’t be the case.

@guy, on Jun 13 2007, 06:29 PM, said in First public alpha of MissionComputer 4.0:

Speaking of flags, The 'Ship Scoops Asteroids' does two different things, depending on whether or not the ship has a scoop. Without a scoop it will activate 'Economy-at-work' behaviour.

Thanks for reminding me.

economy-at-work?

You ever notice when shuttles and cargo drones do nothing but go back and forth between two planets in a system?

That's Economy At Work.

Guy, since you’re on Intel, are you also seeing RLE resources rendered incorrectly as you are with PICTs and cicns?

For PICTs (and RLEs if it affects them), am I correct in understanding your original report as saying that they are displayed incorrectly in the resource browser, but the editor works without trouble?

Yup, that's correct. RLEs are not affected though.
I've just spotted one PICT that isn't affected. The only thing I can see different about it is it happens to be exactly the same dimensions as the thumbnails. Speaking of sizes though, it would be nice if the thumbnails kept the original proportions.

@guy, on Jun 14 2007, 05:17 PM, said in First public alpha of MissionComputer 4.0:

I've just spotted one PICT that isn't affected. The only thing I can see different about it is it happens to be exactly the same dimensions as the thumbnails.

Interesting — that makes it sound like it’s the scaling code that’s the problem, which I wouldn’t have expected to behave at all differently on Intel (and why would RLEs be unaffected?).

Does the same thing happen to the nebula images in the star map editor at zoom levels other than 100%?

@guy, on Jun 14 2007, 05:17 PM, said in First public alpha of MissionComputer 4.0:

Speaking of sizes though, it would be nice if the thumbnails kept the original proportions.

Good point — it is.

Hm, the Nova nebus look fine when I put the relevant resources into the same file. But if I do the same with EV nebus I get pink squares at all zoom levels :huh:

Also, the cicns aren't being scaled at all (since they're small enough) so they shouldn't be affected either, should they?

@guy, on Jun 14 2007, 08:07 PM, said in First public alpha of MissionComputer 4.0:

Hm, the Nova nebus look fine when I put the relevant resources into the same file. But if I do the same with EV nebus I get pink squares at all zoom levels :huh:

It works for me — are you sure you have both the nëbu resources and the 100% PICTs? (At least at the moment, MissionComputer doesn’t use the other PICTs; it just scales the 100% version.)

@guy, on Jun 14 2007, 08:07 PM, said in First public alpha of MissionComputer 4.0:

Also, the cicns aren't being scaled at all (since they're small enough) so they shouldn't be affected either, should they?

I wouldn’t think so — I’ve changed some things around in FinderCanvas since a1, so we’ll see whether this sort of thing is still happening when I have a2 ready.

@david-arthur, on Jun 16 2007, 03:43 AM, said in First public alpha of MissionComputer 4.0:

It works for me - are you sure you have both the nëbu resources and the 100% PICTs? (At least at the moment, MissionComputer doesn't use the other PICTs; it just scales the 100% version.)

Ah, that's probably why. There isn't really such thing as '100% version' of a nebu pict, there's merely between 1 and 7 sizes of the pict and Nova will decide which one is best (rather poorly, I might add) based on the size of the picts and the size it should be at the current zoom level. I suggest just choosing the largest one available (the last one) and scale that as necessary. Since Nova's decisions are so poor I've forced it to do the same thing in EV/O by only having one image (the largest one from the original games) which means MC can't find the one it's looking for.

@david-arthur, on Jun 16 2007, 03:43 AM, said in First public alpha of MissionComputer 4.0:

I wouldn't think so - I've changed some things around in FinderCanvas since a1, so we'll see whether this sort of thing is still happening when I have a2 ready.

Okay

This post has been edited by Guy : 15 June 2007 - 05:14 PM