@orcaloverbri9, on May 28 2008, 09:27 PM, said in MissionComputer 4.0a6 - latest alpha now available:

How so? A "revert" button in the desc editor would be incredibly trivial if you keep a copy of the original desc lying around, and there's a good chance you do (if not, it's one extra line of code). I can't imagine something like that taking more than two lines of extra code and an extra control, and possibly only one line.

Basic revert functionality is probably possible, though slightly more complicated than you describe, and in fact it's already on a list of things to do. It's the request for a real undo system that's impracticable without a rewrite of MissionComputer that would make 4.0 look trivial by comparison.

Well, they say 20% of the functionality takes 80% of the effort; given that, I'm willing to settle for the first 80% of the functionality.

I simply don't want to lose a desc because I accidentally hit another key when I meant "copy", or somesuch. This wasn't a problem in 3.3.3, but in 4.0 it seems any changes are immediately permanent unless you close the entire file.

This post has been edited by Lindley : 29 May 2008 - 08:45 PM

@lindley, on May 29 2008, 09:45 PM, said in MissionComputer 4.0a6 - latest alpha now available:

I simply don't want to lose a desc because I accidentally hit another key when I meant "copy", or somesuch. This wasn't a problem in 3.3.3, but in 4.0 it seems any changes are immediately permanent unless you close the entire file.

So you're referring just to the ability to restore an individual, open resource to the state it was in before you opened it, something parallel to previous versions' Cancel button, which closed the editor without writing changes? That, at least, is definitely on the list.

Yes, that's all I'm requesting.

Not only is this on the list, it's even checked off: I implemented it so long ago that I had forgotten about it until I looked again today. Just choose 'Revert this Resource' from the Resource menu, and your resource will be restored to its condition when you opened the editor.

(Mr. Banks)What wonderful service!(/Mr. Banks)

Don't suppose it could get the Command-R treatment or something.....

@david-arthur, on May 28 2008, 10:48 AM, said in MissionComputer 4.0a6 - latest alpha now available:

It's definitely a very bad idea to have the same file open in more than one programme at the same time, but if you're still having trouble, perhaps something else is going on too. This is happening in the star map editor, rather than when editing an individual system? Can you describe the circumstances under which it occurs, and tell me your processor and system version?

OK, it did it again. I opened a copy of my plug-in and proceeded to edit the system's government through the star map by selecting the systems that were blue and opening the system editor, typing govt 129 in the appropriate field, closing the window with the close button on the window frame, then opening the star map again. it crashed when I clicked on the star map bar in the system resource list after about three repetitions of the aforementioned process.

OS Version 10.4.10, 700 MHz PPC G4 640 MB SDRAM. Need anything else?

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffffc

Dose this mean anything? lot more were that came from.

Another nice addition would be a button in the system editor that would bring you back to the star map.

Looks like a null reference to me.

@of-doom, on May 23 2008, 02:06 PM, said in MissionComputer 4.0a6 - latest alpha now available:

what's rEVisited?

Ok, it's actually Clavius rEVisited. Here's how it goes:

There's a port of EV classic for the Nova engine. KMQ made a bunch of VERY nice looking versions of the EV ships, planets, stations, etc. This became rEVisited, a graphical and gameplay update for EV Classic on the Nova engine.

Clavius rEVisited is my somewhat longstanding work to bring the old Clavius and Beyond plugin up to being fully compatible with rEVisited. There's even a topic in this forum about it.

This post has been edited by CaptJosh : 01 June 2008 - 12:44 PM

@lindley, on May 30 2008, 08:35 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Don't suppose it could get the Command-R treatment or something.....

For a relatively rare command that destroys recent work, I'm reluctant to give it a keyboard shortcut that might be hit by mistake. I suppose I could add both Command-R and a confirmation dialogue, although that might undo any benefits of the shortcut.

@imhotep, on May 30 2008, 11:00 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Another nice addition would be a button in the system editor that would bring you back to the star map.

The loss of flexibility for layering of editors (star map -> system -> planet -> description, for example) is the great unresolved question of allowing multiple editors open at the user's discretion; I still hope to find something like this by the time of release.

As for the crash you describe, it's clear that the editor framework gets less stable if you open and close a succession of windows in a short space of time. I still hope to be able to improve this, but in the short term, perhaps what you need is a 'Government' field in the star map editor.

@david-arthur, on May 31 2008, 06:58 AM, said in MissionComputer 4.0a6 - latest alpha now available:

perhaps what you need is a 'Government' field in the star map editor.

Great Idea, Love the product by the way, loads much faster and the asthetics are greatly improved. I can't wait to use this program more often but do desire stability that 3.3.3 had.

Good work and Thank you very much.

Question, even with MC4 opening in Rosetta, I am still getting some crashes. Does a crash log exist for this program, and if so, where?

@godzfire, on Jun 1 2008, 06:34 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Question, even with MC4 opening in Rosetta, I am still getting some crashes. Does a crash log exist for this program, and if so, where?

I'm afraid there isn't a log that will tell me anything useful in the event of a crash. If MissionComputer encounters an error, it will pop up a dialogue box telling you what happened and where, both of which are very useful in tracking it, but of course it can't do this if it has crashed.

Have you been able to identify a pattern to your crashes, and has it changed at all since you switched to Rosetta?

Even though this has already been called to your attention, I'll mention the suggestion here:

A warning when a dësc is saved with more than 8192 characters. "This dësc is longer than 8192 characters and will not display properly in Escape Velocity: Nova. (Cancel) (Save Anyway)"

And maybe a Preferences box that is checked by default enabling the warning. "Warn if dësc exceeds length limit of 8192 characters."

EDIT: Actually even simpler would be to just add text after the character-count to say "(max 8192 will display in EV: Nova)". No warnings, no checkboxes, just an extra line of text in the dësc resource editor.

This post has been edited by Qaanol : 02 June 2008 - 05:51 PM

@david-arthur, on Jun 1 2008, 10:41 PM, said in MissionComputer 4.0a6 - latest alpha now available:

I'm afraid there isn't a log that will tell me anything useful in the event of a crash. If MissionComputer encounters an error, it will pop up a dialogue box telling you what happened and where, both of which are very useful in tracking it, but of course it can't do this if it has crashed.

Have you been able to identify a pattern to your crashes, and has it changed at all since you switched to Rosetta?

I don't know REALBasic, but when you build a C/++ program, you can ask the linker to output a linker map. This allows you to take Windows' "crash at address" values which are otherwise meaningless, and figure out which function they correspond to----possibly even the line number, although that part may be unreliable if you're compiling optimized. This is the same information that the debugger uses to jump to the proper line when you breakpoint. Is there anything similar you can set up?

I've been using MC4alpha a lot recently and I love it. The only thing is the lack of NCB help; Are you going to restore the NCB help feature? I'd consider that an essential feature, I find myself referencing it a lot in MC3.3.3.

Or, you could just stop allowing text to be entered into the box once the limit has been reached.

@lindley, on Jun 3 2008, 09:18 AM, said in MissionComputer 4.0a6 - latest alpha now available:

This allows you to take Windows' "crash at address" values which are otherwise meaningless, and figure out which function they correspond to----possibly even the line number, although that part may be unreliable if you're compiling optimized.

MissionComputer is coded at much too high a level for anything of this sort to be meaningful.

@shlimazel, on Jun 3 2008, 12:09 PM, said in MissionComputer 4.0a6 - latest alpha now available:

I've been using MC4alpha a lot recently and I love it. The only thing is the lack of NCB help; Are you going to restore the NCB help feature?

Yes - it was lost only because the format in which it was stored isn't Intel-friendly. It'll be back as soon as I re-implement it in a new format.

Oh, excellent. Thank you.

@lnsu, on Jun 3 2008, 11:02 AM, said in MissionComputer 4.0a6 - latest alpha now available:

Or, you could just stop allowing text to be entered into the box once the limit has been reached.

That might cause issues with the way escaped characters are handled - I'm not sure how MC handles that, so watch it.