MissionComputer 4.0a6 - latest alpha now available

@pipeline, on May 24 2008, 02:19 AM, said in MissionComputer 4.0a6 - latest alpha now available:

Hmm. Not familiar with how REALBasic handles things like this.

Any chance of a Cocoa port?

Nope. DA has considered this one, and I think even started work on it. The result was that he decided it was far too much work for very literally almost no gain.

Does RealBasic compile to native code, or does it use a Java-like runtime?

I only ask because some aspects of MC seem slower than they should be at times. Window openings and the like.

@lindley, on May 24 2008, 06:07 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Hey, thanks. That saves me some time and frustration. Now if only there were a diff utility of some kind to assure me that nothing's changed besides what I expect......

Rezilla can do a resource map comparison.

@pipeline, on May 24 2008, 02:19 AM, said in MissionComputer 4.0a6 - latest alpha now available:

Any chance of a Cocoa port?

I started one back in 2005, and got as far as completing the document window and most of the input/output model. I was able to produce the best resource browser I've ever seen (snappier than ResEdit at its prime, unlimited undoes, and Intel-ready from day one), and it confirmed my belief in the massive superiority of Cocoa/Objective-C over everything else there is, but it also became quite clear that I was never going to re-write all the existing editors. Even finishing off the remaining editors for version 4.0 has been incredibly tedious at times.

Here's a screenshot of Beiderbecke 0.3. Everything you see is functional (but that PICT is read-only, and there aren't really any other editors).

Lindley said in MissionComputer 4.0a6 - latest alpha now available:

Not if you used the control-click (aka right-click) to do it. Just have three little buttons somewhere, normally greyed out, for "Edit spob,, Edit desc, Edit bar," which becomes active when you do this. Maybe also change the syst highlighted outline to something other than red or yellow (green?) to show the selected object is inside it.

Hmm, I'll think about it. I consider the 4.0 star map basically done, but I'll keep it in mind for 4.1.4

@lindley, on May 24 2008, 02:40 AM, said:

Does RealBasic compile to native code, or does it use a Java-like runtime? I only ask because some aspects of MC seem slower than they should be at times. Window openings and the like.

Yes, the code is native. The slowness has more to do with the fact that any window that usefully represents an Escape Velocity resource necessarily has an unreasonable number of controls in it.

Actually, it would be much easier if it was interpreted - I'd be able to do much more in the way of self-writing code, and get rid of much of the tedium involved in creating editors. As it is, MissionComputer has written reasonable amount of its own code, but still, the process of creating an editor involves significant amounts of typing the same line of code hundreds of times with only slight changes to the variable names.

I hate that sort of coding.....

Another idea on the star char/desc thing: Allow the player to open a modal window from a menu or button, which changes its contents based on which syst is selected like Quicktime's "movie inspector" window. This modal window could contain a means of selecting from the spobs in the syst, with the first auto-selected for convenience. Whichever one is selected, the window could display the landing and bar descs for it side-by-side.

I think I prefer this idea because it doesn't clutter the existing interface, while giving one-click access to landing descs (two clicks if multiple spobs are in the system). When the user no longer wants these descriptions, they simply close the modal window.

I just hope Alpha7 comes out soon and addresses the random quitting problem Alpha6 has which really forces me to use 3.3.3.

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

Actually, it would be much easier if it was interpreted - I'd be able to do much more in the way of self-writing code, and get rid of much of the tedium involved in creating editors. As it is, MissionComputer has written reasonable amount of its own code, but still, the process of creating an editor involves significant amounts of typing the same line of code hundreds of times with only slight changes to the variable names.

Have you tried creating using arrays that hold the Name and type of variables?

@lindley, on May 24 2008, 10:33 AM, said in MissionComputer 4.0a6 - latest alpha now available:

I think I prefer this idea because it doesn't clutter the existing interface, while giving one-click access to landing descs (two clicks if multiple spobs are in the system). When the user no longer wants these descriptions, they simply close the modal window.

This sounds reasonable (though I think you mean a non -modal window ), and I'll definitely keep it in mind for 4.1.

@godzfire, on May 24 2008, 11:23 AM, said in MissionComputer 4.0a6 - latest alpha now available:

I just hope Alpha7 comes out soon and addresses the random quitting problem Alpha6 has which really forces me to use 3.3.3.

The trick is determining whether it really is random (which is made more difficult by the fact that I've never been able to reproduce it). Can you give me the details about the circumstances in which it happens for you, and whether you're on Intel or PowerPC?

@nonconventionally-creative, on May 24 2008, 11:59 AM, said in MissionComputer 4.0a6 - latest alpha now available:

Have you tried creating using arrays that hold the Name and type of variables?

If I were writing in an interpreted language like HyperTalk, I would something very much like this, and have MissionComputer generate its own code on the fly, but with complied code that isn't an option. Even as it is, an impressive amount of the programme's code was automatically generated, but there's still a sizeable amount of boring code that would be as much work to automate as it is to write.

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

If I were writing in an interpreted language like HyperTalk, I would something very much like this, and have MissionComputer generate its own code on the fly, but with complied code that isn't an option. Even as it is, an impressive amount of the programme's code was automatically generated, but there's still a sizeable amount of boring code that would be as much work to automate as it is to write.

I don't see why that makes a difference, although, I grant that my only experience is Java and a little C++. I looked up REALbasic on Wikipedia and it says it's object oriented, so, roughly:
Make a class (type) containing fields for name and type of the display
Instantiate for each Resource Type - for example, a Boom would have

ID, SHORT_DEC
Name, STRING_256
FrameAdvance, SHORT_DEC
SoundIndex, SHORT_DEC
GraphicsIndex, SHORT_DEC

where SHORT_DEC, STRING_256 are some compile-time constants

Then when drawing to the screen, just calculate the total height from the size of the array (each should be a fixed height) and draw the names as the labels and use if(type==SHORT_DEC) {...} else ... to get the values of the fields.
Then another method to save the values of the fields.

Naturally, none of this would work for the binary types (image/sound), and not for the flexible-sized STR# without some work.

That's exactly the principle on which RDL scripts are based; if you open a wëap or shän in the current alpha (or many other types in older versions), you'll see something like this in action. If I were developing a general-purpose resource editor, I would create a vastly expanded version of RDL, and base all the editors upon. For the special purposes of EV Nova , though, I decided early in the 4.0 development process that it would be easier and produce better results if I concentrated on writing editors for the few remaining resource types, rather than trying to develop a structure like this which could do everything needed for a useful editor.

@david-arthur, on May 24 2008, 12:30 PM, said in MissionComputer 4.0a6 - latest alpha now available:

The trick is determining whether it really is random (which is made more difficult by the fact that I've never been able to reproduce it). Can you give me the details about the circumstances in which it happens for you, and whether you're on Intel or PowerPC?

Mac Pro, Intel Xeon Dual 2.66ghz, 1 gig RAM, OSX 10.4.11. Honestly, the crash is totally at random. I could be working fine editing something, then click something, and BAM, it's crashed. 3.3.3 does not do this, which probably is already known.

@godzfire, on May 24 2008, 03:29 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Mac Pro, Intel Xeon Dual 2.66ghz, 1 gig RAM, OSX 10.4.11. Honestly, the crash is totally at random. I could be working fine editing something, then click something, and BAM, it's crashed. 3.3.3 does not do this, which probably is already known.

Have you tried using the option in the Get Info window that tells the system to run MissionComputer in Rosetta, rather than natively? The addition of Intel-native code is one of the major changes in MissionComputer 4, and the Intel code has problems with 10.4.

The discussion here inspired me to open up Beiderbecke, my experimental Cocoa-based editor, again and try it out. Sure enough, it works perfectly when running natively on an Intel Mac running 10.5, even though I wrote it on 10.3 before the first Intel-based Macintoshes were available.
Beiderbecke_on_Intel.jpg (174.08K)
Number of downloads: 25

Unfortunately, the same still seems not to be true of MissionComputer. I've discovered some further issues with DITL and DLOG resources, so if you're planning to edit them (or to edit a .rez file which even contains them, though normal Mac plug-ins should be fine), you should switch into Rosetta mode while you do so.

I've noticed there doesn't seem to be any kind of undo capability in the latest version----not even a way to close an editor and say "don't save changes" except by closing the entire plug. This can cause some annoyances. Can something be done about it?

@lindley, on May 27 2008, 12:21 AM, said in MissionComputer 4.0a6 - latest alpha now available:

I've noticed there doesn't seem to be any kind of undo capability in the latest version----not even a way to close an editor and say "don't save changes" except by closing the entire plug. This can cause some annoyances. Can something be done about it?

Certainly not within the scope of 4.0, I'm afraid, and even beyond that it looks iffy.

@david-arthur, on May 27 2008, 06:24 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Certainly not within the scope of 4.0, I'm afraid, and even beyond that it looks iffy.

Not even in the desc editor? That's where it's most needed.

For a long time the mantra was "work with a copy of your files" but in this day and age even that sound advice does seem a bit antiquated, what with the prevalence of auto-save and undo features throughout the software kingdom.

The very first time I uses this alpha I tried to manipulate the syst resource graphically with a plug in I had been working on with mission computer 3.x and after a few edits of the galaxy the program crashed and deleated all the edits i hade made. This was probably my faly because I also had open the same file on mission computer 3.x. Anyway since then I tried the syst editor and found the same problem when opperating without simultanious use of resources. anyone else find this?

@imhotep, on May 28 2008, 12:38 PM, said in MissionComputer 4.0a6 - latest alpha now available:

The very first time I uses this alpha I tried to manipulate the syst resource graphically with a plug in I had been working on with mission computer 3.x and after a few edits of the galaxy the program crashed and deleated all the edits i hade made. This was probably my faly because I also had open the same file on mission computer 3.x. Anyway since then I tried the syst editor and found the same problem when opperating without simultanious use of resources. anyone else find this?

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?

@david-arthur, on May 27 2008, 02:24 PM, said in MissionComputer 4.0a6 - latest alpha now available:

Certainly not within the scope of 4.0, I'm afraid, and even beyond that it looks iffy.

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.

Oh, and possibly a new variable, as if that makes it any less trivial.

This post has been edited by orcaloverbri9 : 28 May 2008 - 08:31 PM