I'm not familiar with RezConv, but it sounds like text-encoding is indeed the main problem (possibly applying to the whole file, not just the resource names that you see). Unless anyone is experiencing problems with MissionComputer-generated .rez files, I think it has to be a RezConv issue.
-
I've got a couple minor things to report on the newest version:
First: I noticed that mission ships can now be set to appear "adjacent to specific system." However, selecting this does not bring up an input box, so it seems to be effectively unusable.
Second: The scroll wheel on my Mighty Mouse works fine when opening up MC; however, it quits working after running MC for a while. I'm pretty sure I've isolated the cause as re-assigning a resource's Resource ID (simply opening the resource or doing a "get info" doesn't produce the same effect).
I think the second bug has been there for a while, but I'd never really paid attention before.
Again, very nice work on the latest version!
-
QUOTE (Archon @ Sep 3 2009, 09:44 AM) <{POST_SNAPBACK}>
I noticed that mission ships can now be set to appear "adjacent to specific system." However, selecting this does not bring up an input box, so it seems to be effectively unusable.
Fixed, thanks.
QUOTE (Archon @ Sep 3 2009, 09:44 AM) <{POST_SNAPBACK}>
The scroll wheel on my Mighty Mouse works fine when opening up MC; however, it quits working after running MC for a while. I'm pretty sure I've isolated the cause as re-assigning a resource's Resource ID (simply opening the resource or doing a "get info" doesn't produce the same effect).
I have to implement scroll-wheel support case by case, and don’t always think of it because I don’t use one myself. Could this possibly be the explanation, or have you noticed it working, and then not working with the same list?
-
QUOTE (Archon @ Sep 3 2009, 10:42 PM) <{POST_SNAPBACK}>
It seems that it works in every case where scrolling is possible before re-assigning a resource ID, and then quite working on all of them after. Quitting MC fixes the problem.
Hmm... I suspect this is beyond my control.
-
All right; it's a really minor bug anyways since its usually much easier to just type in the first few letters of a resource, although it's nice when searching through resources via the "magnifying glass" (searching from within a resource) because type-to-find doesn't work in the drop-down menus.
One final note for now; I was putting some systems together in what I thought was a typical nova-esque pattern, but when I opened up Nova, I realized that the systems when viewed in the star map were much further apart than they appeared in MC. Of course, it's nice to have more of a God's eye view in the editor for ease of viewing, but could there perhaps be a way to toggle between the MC minimized scale and a 1:1 Nova scale? It would make things a bit easier in judging the proper distance between systems. I suppose it's really a minor note, since the MC system editor is so much nicer and easier than non-graphical interfaces, but it would be a handy tool.
-
QUOTE (Archon @ Sep 5 2009, 09:09 PM) <{POST_SNAPBACK}>
All right; it's a really minor bug anyways since its usually much easier to just type in the first few letters of a resource, although it's nice when searching through resources via the "magnifying glass" (searching from within a resource) because type-to-find doesn't work in the drop-down menus.
Actually, it probably shouldn’t be hard to copy the document window’s type-to-find code into the Resource Selector.
QUOTE (Archon @ Sep 5 2009, 09:09 PM) <{POST_SNAPBACK}>
Of course, it's nice to have more of a God's eye view in the editor for ease of viewing, but could there perhaps be a way to toggle between the MC minimized scale and a 1:1 Nova scale?
1:1 is hard to define, since the game doesn’t name its zoom levels. When the Zoom control in MissionComputer’s star map editor is set to 100%, one pixel is equivalent to one unit of distance as defined by the resource format, which is the closest thing to an absolute scale I’ve been able to set.
-
bows head in shame at double-post
Another minor one, but one that can really mess with folks: the contribute/require fields will show up with an x rather than a check if only 4H or 8H (or both) are checked. This seems to be the case with all resources, and as far as I can tell, only these two fields.
OK then, after a bit more testing, it seems that the bigger problem is that said flags will actually disappear after closing and re-opening the plugin, but so far, that seems only to happen with Require, not Contribute. I'll keep you posted if I find anything else odd about contribute/require.
This post has been edited by Archon : 17 September 2009 - 09:02 PM
-
Oh no, not again . . .
Contribute/require fields have always been strange, but I thought I'd worked out the last such problems in 4.0. I'll have to do some more exploring.
It's odd that Require would be affected but not Contribute, though; because the two fields are identical as far as the format is concerned, I use the same code to handle both (and for all resource types).
-
Nothing new to add on the subject of contribute/require or wheel scrolling, but I do have one request. Could you add a standard resource number box to the spöb list in the sÿst editor? The current version works fine, unless you want to add a planet from another resource file. For example, for some reason which we will not discuss, I'm trying to swap New New York to spöb 2 and Rigel III to spöb 1 in the Rigel system for Anathema. With the current system, I can't do that unless I copy both planets into Anathema's data files and then delete them.
Again, you can certainly work around it (and everything else about the sÿst editor is pure gold), but it's irritating and seems like it should be easy enough to add a standard ResID box to the interface.
(edit)I'm not sure if this is an MC issue or a Nova issue, but it seems that mission ships flagged to start out in a particular system "randomly, cloaked" just hyper in after a delay. They do cloak afterwords, which leads me to believe it's an engine error, but thought I'd bring it up anyways.
This post has been edited by Archon : 27 September 2009 - 11:54 AM
-
QUOTE (Archon @ Sep 27 2009, 01:43 AM) <{POST_SNAPBACK}>
Could you add a standard resource number box to the spöb list in the sÿst editor? The current version works fine, unless you want to add a planet from another resource file. For example, for some reason which we will not discuss, I'm trying to swap New New York to spöb 2 and Rigel III to spöb 1 in the Rigel system for Anathema. With the current system, I can't do that unless I copy both planets into Anathema's data files and then delete them.
Adding an editable list of resource IDs would actually be a little tricky, because of the way the sÿst editor edits both sÿst and spöb resources at the same time. What I can probably do is add a resource ID field to the Resource Selector pop-up window, so that you can add resources not present in one of the listed files.
If you just want to change the order in which planets appear, won't the Move Up and Move Down buttons do what you need? Perhaps someday I'll make that list box support drag and drop reordering as some do.
QUOTE (Archon @ Sep 27 2009, 01:43 AM) <{POST_SNAPBACK}>
I'm not sure if this is an MC issue or a Nova issue, but it seems that mission ships flagged to start out in a particular system "randomly, cloaked" just hyper in after a delay. They do cloak afterwords, which leads me to believe it's an engine error, but thought I'd bring it up anyways.
Unless MissionComputer is incorrectly saving the value as 'Jump in after a delay' – which doesn't appear to be the case – this must be a matter of engine behaviour.
-
QUOTE (Sp3cies @ Sep 29 2009, 08:33 PM) <{POST_SNAPBACK}>
When trying to look for a rlëD using the magnifying glass in the shän field I found that it can only find PICTs and not rlëDs.
One of the limitations of the RDL template format is that it can't handle fields that can take more than one resource type. Some day there will be a real shän editor, but in the mean time I'll change the template to call for rlëDs instead, since that's the most common choice.
-
QUOTE (David Arthur @ Sep 30 2009, 02:25 PM) <{POST_SNAPBACK}>
Some day there will be a real shän editor…
I'm holding you to this now! Armageddon comes and there's no shän editor, it's your ass!
(unrelated edit)
One thing that could be a useful addition to the wëap editor's awesome new range visualizer thingy would be an extra feature that "blacks out" the portion of the weapon's life before its prox safety kicks in (or out, as the case may be). Again, just a little thing, but it would be a cool little feature.This post has been edited by Archon : 04 October 2009 - 02:23 AM
-
Sorry for the double post, but I think I just figured out that weird "phantom saving" bug from a while back. The problem (that being making a change but not being able to save) seems to occur when I modify a resource, then without closing that resource, navigate to another (it doesn't matter if it's already open or not). This crops up often when I'm modifying mission dëscs, because I'm going back and forth between the dësc and mïsn files. If I simply close the resource I modified instead of opening another, everything works fine. Also, MC will still ask if I want to save if I try to close the plug or quit, so it's never resulted in a loss of data.
-
QUOTE (Archon @ Sep 30 2009, 03:50 PM) <{POST_SNAPBACK}>
I'm holding you to this now! Armageddon comes and there's no shän editor, it's your ass!
In fact, in certain hypothetical universes there already is a shän editor!
QUOTE (Archon @ Sep 30 2009, 03:50 PM) <{POST_SNAPBACK}>
One thing that could be a useful addition to the wëap editor's awesome new range visualizer thingy would be an extra feature that "blacks out" the portion of the weapon's life before its prox safety kicks in (or out, as the case may be).
Sounds like a good idea. I'll take a look at it the next time I have the wëap editor opened up.
QUOTE (Archon @ Oct 5 2009, 11:01 AM) <{POST_SNAPBACK}>
The problem (that being making a change but not being able to save) seems to occur when I modify a resource, then without closing that resource, navigate to another (it doesn't matter if it's already open or not).
Does the problem persist after you've closed the edited resource? If it doesn't, then that's correct behaviour; editor windows don't record their changes the the main file until you close them, either directly or indirectly (by closing the file). If it does continue, then I'll have to keep trying to reproduce the issue.
-
QUOTE (David Arthur @ Oct 5 2009, 04:50 PM) <{POST_SNAPBACK}>
Does the problem persist after you've closed the edited resource? If it doesn't, then that's correct behaviour; editor windows don't record their changes the the main file until you close them, either directly or indirectly (by closing the file). If it does continue, then I'll have to keep trying to reproduce the issue.
Oooooohhhhhhhhhhhhhhh.
OK well I guess it's not even a bug then. Seems odd, though, that I can make a change and then save (without closing the window), but can't make a change, switch windows, and then save. Is that how it's supposed to work?
-
QUOTE (Archon @ Oct 5 2009, 06:03 PM) <{POST_SNAPBACK}>
Seems odd, though, that I can make a change and then save (without closing the window), but can't make a change, switch windows, and then save.
The ability to save while the newly modified resource is open is a slightly hack-y workaround, since it involves the resource using its own Changed indicator to override the global one. I could probably find some alternative, but it has always seemed substantially more trouble than it was worth given that everything gets sorted out when you close the window.