@yamfries, on Jun 25 2008, 05: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.

Yes, I've thought about something like this. It definitely won't happen in 4.0, but sometime I may start working on a Sprite Maker to go in the Utilities menu. Like Lindley, however, I wonder what it is about p2s and m2s that makes them unsatisfactory.

@qaanol, on Jun 26 2008, 02:11 AM, said in MissionComputer 4.0a8 now available:

Would not this ... Be one possible solution?

No. The star map editor, by definition, has all s˙st and nëbu resources open at the same time. If you were able to open the s˙st editor without closing the star map, that system would be open in two editors at once, easily leading to edit conflicts and lost data.

Behaviour like you describe, while appealing, is what led to many of the problems that plagued previous editors. That's why I waited so long to allow multiple resources open at once in MissionComputer, and why I'm still very careful about it.

@guy, on Jun 26 2008, 03:15 AM, said in MissionComputer 4.0a8 now available:

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.

Actually, I was just experimenting with this yesterday - I altered it to work the way you describe, and then put it back again. Does anyone else have a preference for how this should work?

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

No. The star map editor, by definition, has all s˙st and nëbu resources open at the same time. If you were able to open the s˙st editor without closing the star map, that system would be open in two editors at once, easily leading to edit conflicts and lost data.

Hmm. Depending on the time required to update a resource, it might be feasible to write changes to the file whenever one changes which window is on top. That starts to get a bit delicate, though, so it may not be the best design choice.

@lindley, on Jun 26 2008, 09:53 AM, said in MissionComputer 4.0a8 now available:

Depending on the time required to update a resource, it might be feasible to write changes to the file whenever one changes which window is on top.

And reload every time you switch back, in case it has been changed in the mean time? Anyway, one of the design principles is that the changes aren't written until you close the window, so that you have a chance to choose 'Revert this Resource' if you don't like the changes you've made.

DA, have you experimented with pass-through STR and/or STR# viewing (or editing)? I'm thinking of how convenient this would be for the message buoy field in the syst editor, but there are other places where it would be nice, too.

@dr--trowel, on Jun 26 2008, 10:18 AM, said in MissionComputer 4.0a8 now available:

DA, have you experimented with pass-through STR and/or STR# viewing (or editing)? I'm thinking of how convenient this would be for the message buoy field in the syst editor, but there are other places where it would be nice, too.

I haven't built anything like this, but it is a fairly obvious hole, and has been sitting in my list of desirable features for a while. It's possible that I might be able to do it without too much work, but as you may have noticed from my recent responses, I'm trying to close off 4.0 fairly soon, so it's more likely to come in a later version.

@david-arthur, on Jun 26 2008, 11:20 AM, said in MissionComputer 4.0a8 now available:

I haven't built anything like this, but it is a fairly obvious hole, and has been sitting in my list of desirable features for a while. It's possible that I might be able to do it without too much work, but as you may have noticed from my recent responses, I'm trying to close off 4.0 fairly soon, so it's more likely to come in a later version.

That's fine, of course. Just thought I'd ask.

@david-arthur, on Jun 27 2008, 01:42 AM, said in MissionComputer 4.0a8 now available:

Actually, I was just experimenting with this yesterday - I altered it to work the way you describe, and then put it back again. Does anyone else have a preference for how this should work?

Heh. Why did you put it back?

@guy, on Jun 27 2008, 07:49 AM, said in MissionComputer 4.0a8 now available:

Heh. Why did you put it back?

It seemed to against the model (used by both ResEdit and MissionComputer) which treats DITL and DLOG as if they're 'really' one thing, which happens to be divided into two resources for technical reasons (three if you count dctb). For it to be intuitively obvious, I think greater changes would be required, and I don't know if they would be beneficial.

• I suggest that you don't make new weapons fade in by default.

• I can't type a negative into number fields for any resource, which I need to type "-1"

• This is minor, but I can't use the delete key in the home key island to erase characters that are to the right of the cursor.

• I think graphics in the weap resource should default to "3000" instead of "2999."

Hmm, what about a little warning that pops up if you use resources that are employed by the game, or at least a little number beside the place where you put the ID signifies the highest ID employed by the game?

@jacabyte, on Jun 27 2008, 04:00 PM, said in MissionComputer 4.0a8 now available:

I suggest that you don't make new weapons fade in by default.
I think graphics in the weap resource should default to "3000" instead of "2999."

Fixed thanks - and fixed the latter issue for Sound as well.

@jacabyte, on Jun 27 2008, 04:00 PM, said in MissionComputer 4.0a8 now available:

I can't type a negative into number fields for any resource, which I need to type "-1"
This is minor, but I can't use the delete key in the home key island to erase characters that are to the right of the cursor.

Oh, thanks - I've found a workaround to the delete key thing, which will also make it easier to fix such fields as don't accept negatives, but should. It will take a little bit of time to implement, but the programme will ultimately be better for it.

@david-arthur, on Jun 28 2008, 01:11 AM, said in MissionComputer 4.0a8 now available:

It seemed to against the model (used by both ResEdit and MissionComputer) which treats DITL and DLOG as if they're 'really' one thing, which happens to be divided into two resources for technical reasons (three if you count dctb). For it to be intuitively obvious, I think greater changes would be required, and I don't know if they would be beneficial.

Okay, well I guess it's not important - the DLOG can always be deleted afterwards if it's not needed.

The Explosion field resets to -1 when a wëap is closed and reopened.

And a suggestion: It's nice that you have grayed out the fields that don't apply to the current resource, such as being unable to specify BeamLength for a non-beam. That makes it easy to tell what is and is not relevant. I'd like a preferences check-box to disable that graying out. Sort of a "manual override" option just in case someone finds an undocumented feature that treats fields weirdly.

Hm, I was going to suggest leaving in all the RDL templates for direct editing of the data, with a menu item or something to open a resource with the RDL template rather than the editor.

@guy, on Jun 28 2008, 10:41 PM, said in MissionComputer 4.0a8 now available:

Hm, I was going to suggest leaving in all the RDL templates for direct editing of the data, with a menu item or something to open a resource with the RDL template rather than the editor.

I too would like this.

Click a button to edit a desc flags the current resource as dirty.

@qaanol, on Jun 28 2008, 09:57 PM, said in MissionComputer 4.0a8 now available:

The Explosion field resets to -1 when a wëap is closed and reopened.

It sounds like you're entering an index number. The Explosion field, like all other such fields in MissionComputer, takes an actual resource ID, so anything less than 128 will be ignored.

@qaanol, on Jun 28 2008, 09:57 PM, said in MissionComputer 4.0a8 now available:

I'd like a preferences check-box to disable that graying out.

This isn't practical, because of the way the rigging adapts depending on your selections; the inactive fields are quite often being entirely ignored in favour of different calculations. Guy's idea of keeping RDL as an option might be more viable.

@guy, on Jun 30 2008, 04:00 PM, said in MissionComputer 4.0a8 now available:

Click a button to edit a desc flags the current resource as dirty.

From which editor?

@david-arthur, on Jul 2 2008, 09:21 PM, said in MissionComputer 4.0a8 now available:

It sounds like you're entering an index number. The Explosion field, like all other such fields in MissionComputer, takes an actual resource ID, so anything less than 128 will be ignored.

This is both correct and a different custom from the Nova Bible. Entering 128 did work. I'm not sure I have a suggestion, other than to note that it was not intuitive to me and caused frustration. Especially with the check-box next to it reading "Type-zero sparks". Perhaps simply changing that to "Type-128 sparks" would suffice.

@david-arthur, on Jul 3 2008, 01:21 PM, said in MissionComputer 4.0a8 now available:

From which editor?

Hm, just missions it seems. Excluding the offer desc.

@qaanol, on Jul 3 2008, 12:01 AM, said in MissionComputer 4.0a8 now available:

I'm not sure I have a suggestion, other than to note that it was not intuitive to me and caused frustration.

Good point. I'll revise the labels and help tags to make it clearer.

@guy, on Jul 3 2008, 01:21 AM, said in MissionComputer 4.0a8 now available:

Hm, just missions it seems. Excluding the offer desc.

If the field for the dësc ID was previously set to -1, clicking the edit button changes it to match the ID of the new dësc resource, so the mission actually has been changed. This doesn't apply to the offer description, since its ID is fixed rather than specified in the mďsn resource.