QUOTE (David Arthur @ Dec 16 2010, 02:21 PM) <{POST_SNAPBACK}>

I have a full star-map editor, but shän is actually the one major EV Nova resource type for which I don't yet have a direct-manipulation graphical editor, or even a preview like in NovaTools. The problem would be working out precisely what calculations the game performs and replicating them exactly, as incorrect information would be worse than none at all.

I’d be happy to help with figuring out what calculations the game performs. Are there some in particular that you do or don’t already know? For example, weapon exit point placements with all the x, y, z, and compression parameters; or how colors are combined when there are lights, shields, engine glows, and/or transparency; or what exactly the “Adjust for off-axis graphics” flag does. (Whatever the off-axis graphics flag does, the stock Nova scenario does not use it, and it doesn’t change anything in the NovaTools shän preview as far as I can tell.)

This post has been edited by Qaanol : 17 December 2010 - 06:21 PM

QUOTE (Qaanol @ Dec 17 2010, 03:21 PM) <{POST_SNAPBACK}>

(Whatever the off-axis graphics flag does, the stock Nova scenario does not use it, and it doesn’t change anything in the NovaTools shän preview as far as I can tell.)

I believe it has something to do with banking graphics, though I'm not certain. It's actually more of a hunch, really.

I do have some references for the calculations, but it's a big project which I don't feel able to take on right at the moment. When I do reach the point of having something worth testing, I'd be glad of your help in verifying that the information it gives is correct.

QUOTE (David Arthur @ Dec 17 2010, 02:11 PM) <{POST_SNAPBACK}>

Inspired by this discussion I've got out the Windows version again, and can report that the Save command now works, which makes it largely useable for many resource types.

Star_map_16_December_2010.png (60.75K)
Number of downloads: 17

I believe the only word I can come up with for how this makes me feel is "giddy."

Minor (like, super minor) apparent inconsistency: when opening or saving a file between 15 and 15.5 MB in size, MissionComputer gives a warning that the file “is more than 14 MB is size”, but it does not give that warning when a file is between 14 and 15 MB.

Are you using Mac OS 10.6? Its Finder now reports file sizes in decimal units (1 MB = 1000 KB = 10002 B), whereas MissionComputer calculates them in traditional binary units (1 MB = 1024 KB = 10242 B). 14 traditional megabytes is more than 14.6 decimal ones, which may be the source of the discrepancy.

Yep, that appears to be what’s happening. Good call.

I continue to be impressed with the stability in utility of MissionComputer 4.1.1. It makes plug-in editing far simpler than any other tool I’ve used.

Something I thought of that would be nice: a quick way to view government relationships. Two modes strike me as useful. One would show, for each Class, what gövts belong to, are allied with, and are enemies of that Class. Another would show, for each gövt, which gövts are its allies and enemies. These would be most useful in a form that could be viewed from within the program, and also exported as text files. A third mode could show, for each gövt, which Classes its in, allied with, and enemies of. This last one is less critical, as that information can be obtained directly with ConText, or even viewing individual gövt resources in MC. But the idea is to see the information for all governments simultaneously.

And I again proclaim my desire to be able to view the lists of more than one type of resource at a time. As in, the main window could just show the list of resource types and how many there are of each. Then clicking (or double-clicking) on one would open a window showing the resources of that type. It is quite useful to be able to view the lists of multiple resource types at once, and I often find myself copying the list of resources of one or more types into text files just so I can view them while working in MC. Sometimes I even print them out. I would far prefer to be able to view the lists of resources of multiple types in MC simultaneously.

@qaanol, on Jan 9 2011, 02:31 AM, said in MissionComputer: The Saga Continues:

Something I thought of that would be nice: a quick way to view government relationships.

All of these have potential — the third, of course, would need to be an independent mini-programme in the Utilities menu, rather than integrated into the main functioning of MissionComputer. I'll give the issue some thought.

In the past, the best solution to the opacity of government classes I was able to come up with was closest to your first suggestion: I would invent a dummy 'cläs' resource, that would allow the user to name each class. The gövt editor would then be able to choose classes with the Resource Selector just like it can for fields that take a resource ID, and the cläs 'editor' would really be a utility that scanned all the governments to see who was a member, an ally, or an enemy. I wasn't, however, particularly comfortable with the idea of just inventing a resource type that had no effect on the actual game.

The advantage of this is that it would be nice and concrete, and wouldn't require the gövt editor to scan the entire file every time you typed a number. Does this sound like a useful approach?

@qaanol, on Jan 9 2011, 02:31 AM, said in MissionComputer: The Saga Continues:

And I again proclaim my desire to be able to view the lists of more than one type of resource at a time. As in, the main window could just show the list of resource types and how many there are of each. Then clicking (or double-clicking) on one would open a window showing the resources of that type.

I've been thinking about this too. ResEdit, of course, behaved exactly this way, and it's generally agreed (except among certain sorts of Linux extremists) that the spatial view is the best way to navigate a hard drive. Resources are different, in that they're actually non-hierarchical files which we organise by resource type merely for convenience, but I sort of suspect that the same might apply.

This would require an additional layer of linked windows (document -> type -> editor), but MissionComputer 4 has proved stable enough that I'm not as worried about this as I might have been back in the days of 3.x. It would, however, be a change substantial enough that it would need to replace the current behaviour — I couldn’t offer a choice between the two modes in Preferences.

I fully support the ResEdit method of doing things.

@evweb, on Jan 9 2011, 11:34 AM, said in MissionComputer: The Saga Continues:

I fully support the ResEdit method of doing things.

Agreed.

Also, I don't recall seeing as many feature requests before I asked for a search feature. I'm starting to feel a little guilty about the prospect of having opened a can of worms. Oops.

When you say cläs, you mean actually making a new resource type, and actually saving it in the plug-in file, in order to give each class a name? It would certainly work, though I’ll remain neutral as to whether it’s a good idea for now. It seems like it shouldn’t hurt anything, as the marginal disk space used by a cläs would just be its name string. In fact it seems right in line with my idea for naming Contribute/Require bits.

On the other hand, introducing a resource type that’s ignored by the Nova engine does have the potential to confuse new developers. Or maybe it’ll make things a lot simpler for new developers to understand. Probably the latter. Until they get in a conversation with someone on Windows who doesn’t have MC and thus is completely unaware of the cläs resource.

So to me personally, it does not matter whether the functionality is implemented through a new resource type or just through a menubar utility, so long as it provides a quick way to view gövt and Class affiliations, sortable by gövt and by Class, and sub-sortable by members, allies, and enemies.

I did just find what I think is a minor behavioral inconsistency in MC. I hesitate to mention it because it’s actually kind of useful in a way. But if you have a mission set to use a certain dësc, and that dësc resource has no name, then in the mïsn editor when you click to edit that dësc, the window shows the name of the dësc as the default ("Offer <misnRID>: <misnName>" etc.) but it does not actually give that name to the dësc resource. However it is useful because if in fact you do want to give that name to the dësc resource, you can just select, copy, and paste right there and then it will be applied.

@darthkev, on Jan 9 2011, 03:05 PM, said in MissionComputer: The Saga Continues:

I'm starting to feel a little guilty about the prospect of having opened a can of worms.

It's nothing to be worried about, especially when they turn out to confirm that there's demand for something I was thinking of doing anyway.

@qaanol, on Jan 9 2011, 06:14 PM, said in MissionComputer: The Saga Continues:

When you say cläs, you mean actually making a new resource type, and actually saving it in the plug-in file, in order to give each class a name?

Yes, that was the idea. At various times I've considered doing the same for Contribute/Require bits or even NCBs. I would, of course, have a note right in the cläs editor explaining that it isn't a real resource type, but as I said I'm extremely wary of adding anything that isn't part of the format as such. For the moment I think I'll explore the possibility of a utility which displays the class information in an organised fashion, without actually reifying it as a resource.

@qaanol, on Jan 9 2011, 06:14 PM, said in MissionComputer: The Saga Continues:

But if you have a mission set to use a certain dësc, and that dësc resource has no name, then in the mïsn editor when you click to edit that dësc, the window shows the name of the dësc as the default ("Offer <misnRID>: <misnName>" etc.) but it does not actually give that name to the dësc resource.

It actually does write that name, but only if you make some other change to the dësc resource that causes it to get saved. I could change this behaviour, but I'm not sure that would be an improvement.

Another (small) feature request. It would be nice if the star map would visually distinguish inhabited systems from uninhabited systems of the same government. For example, an inhabited system could have a thicker (or filled) circle of the color of the government, and an uninhabited system of the same government could just have a thin circle of that color.

I mention this because affiliating uninhabited systems with governments is useful. That way flët, përs, and mïsn ships that are set to appear only in systems belonging to a certain government can (I believe) appear in those uninhabited systems. At the same time, it is also helpful to have inhabited systems display differently from uninhabited ones.

I can see the desirability of such a feature, but the star map editor's internal database is already getting a little top-heavy with such extra information.

I would personally like two features.

1 - to be able to view the info on multiple items at once
2 - for MissionComputer to change the ids of any descs, pictures, shans, and other assorted items to the new id given to either a ship or outfit

Both are potentially possible, but both would require some rethinking of how the Get Info window works. I'll give them some thought, but they won't be in the coming update.

QUOTE (EVWeb @ Jan 15 2011, 05:38 PM) <{POST_SNAPBACK}>

I would personally like two features.

1 - to be able to view the info on multiple items at once
2 - for MissionComputer to change the ids of any descs, pictures, shans, and other assorted items to the new id given to either a ship or outfit

I second both of these. The first is a convenience that would be nice.

The second is a potentially great productivity enhancer. The resources that are fixed at the ID of the ship/outfit/mission plus some offset, having those change to match changes to the ID of the thing they’re tied to would be excellent.

Additionally, for resources whose IDs are specified by a text field, like the BriefText of a mission, it would be nice if there were a way, from the parent resource (mission in this case), to change the ID of the child resource (desc in this case) and the ID in the text field all at once.

For example, if I have a mission with BriefText 5040, and I want to keep the text exactly the same but change the ID of the desc to 5050, I want to be able to do that in one step. The idea here is to make it doable without needing to switch to the list of desc resource, because you’re working on missions and want that list open. On the other hand, I would much prefer to be able to have lists of more than one resource type open simultaneously (maybe as columns in a single “spreadsheet” style list, if multiple windows is infeasible?), in which case this is a non-issue.

The 'spreadsheet' is an interesting thought. It would avoid the window proliferation of ResEdit's model, but I think it would be less intuitive, and it might even be harder to implement. In any case I think I can make proliferation less of an issue through improved window management.

Version 4.2 is now up on the add-ons directory (and accessible from davidarthur.evula.net), with the previously discussed government-class table, the multiple STR# support, and an improved Window menu.