Ambrosia Garden Archive
    • ResEdit crashes like crazy


      Ok, I've has this ResEdit problem since I began to tinker with Nova, but just now decided to bitch about it.

      Basicaly, it freezes, and makes me force-quit ResEdit and then relaunch classic all the bloody time.

      I estimate it freezes about every 25th opening of a weap or outf resource. So that's pretty darn often.

      The plug-ins don't like ResEdit force-quiting, and frequently need to be repaired after such an operation because the file doesn't close properly.

      Most of the time this merely results in me having to re-do work since the last save.
      Sometimes, the file needs to be repaired and then I have to go back and re-label various resources.
      Once, the file could not be repaired and I had to use an old backup. Hours of lost work!

      As you can imagine, under such circumstances I save VERY often and back-up the file every few saves.
      But this is really a pain.
      Why the heck would the NovaTools templtaes be causing this?

    • I've honestly never had a lot of trouble with them, and I've hacked my shan editor all to hell too. But I am a minority. Make sure you boost the ram allocation up highly when using ResEdit.

    • As stated in the NovaTools docs, you need to boost ResEdit's RAM allocation to at least 10Mb (preferably more). ResEdit was designed for editing strings and template resources - not 24-bit sprite graphics and animations.

    • Why not just use MC? It has support for everything but ppats now, is OSX native, and generally just an awesome program.

    • (Removed as it was mean)

      This post has been edited by tycho61uk : 18 November 2005 - 06:11 PM

    • The outf editor is particularly prone to crashing. This annoys the hell out of me too but there's nothing you can do about it. Usually my files don't get damaged by this so I don't lose much work and I just groan and open it again. I still haven't caught on to MC yet...

    • tycho61uk, on Nov 18 2005, 12:08 PM, said:

      You mean Mission Converter? That badly designed, crashy, barely-carbon, 'Made with REALbasic' piece of junk? :laugh:
      View Post

      If you are in fact talking about MissionComputer, did it ever occur to you that telling me about such problems as you experience might be more productive than resorting to insults?

      This post has been edited by David Arthur : 18 November 2005 - 05:20 PM

    • David Arthur, on Nov 18 2005, 08:11 PM, said:

      If you are in fact talking about MissionComputer, did it ever occur to you that telling me about such problems as you experience might be more productive than resorting to insults?
      View Post

      I apologise, that was mean. Sorry dude. I'll remember to make it up to you in future 😉

      My impression of the program is based on the two occasions that I seriously tried to use it in place if ResEdit. The first time, it crashed, corrupting everything I had done for the last hour. The second time, it froze (after spending an age trying to load a plug), requiring a reboot. MC, at least the last version I used (which was about 4 months ago) also suffers from interface-overdesign IMHO, a phenomenon common in REALbasic-made applications.

      I was once an avid RB-fan myself (back when it was at version 2.1 and didn't suck), so I know how tempting it is to go overboard on the interface when you should be spending time on the code. I have heard this from other people too. It only takes a one or two bad experiences to loose all faith in a program.

      That said, this wasn't the first time I've stuck my foot in my mouth! Once again, I'm sorry.

      This post has been edited by tycho61uk : 18 November 2005 - 05:42 PM

    • Although MC has not fully replaced ResEdit yet, it is still my main editor of choice. I've not had any real substantial problems with it, and any that I have had have been more than made up for by the convienience of being able to write descs from the mission resource itself.

    • tycho61uk, on Nov 18 2005, 12:42 PM, said:

      As stated in the NovaTools docs, you need to boost ResEdit's RAM allocation to at least 10Mb (preferably more). ResEdit was designed for editing strings and template resources - not 24-bit sprite graphics and animations.
      View Post

      Well, I had its RAM allocation at 100 Megs. Didn't seem to help.

      This post has been edited by Desprez : 18 November 2005 - 06:08 PM

    • tycho61uk, on Nov 19 2005, 05:08 AM, said:

      barely-carbon, 'Made with REALbasic'
      View Post

      I think this is one of the sticking points for me. I just get the feeling that it would all be a lot better if it was made with Xcode.

    • tycho61uk, on Nov 18 2005, 05:25 PM, said:

      The first time, it crashed, corrupting everything I had done for the last hour. View Post

      This was an actual crash, not an exception that MissionComputer itself recorded? What version was this in? I haven't seen or had reports of very many actual crashes.

      Quote

      The second time, it froze (after spending an age trying to load a plug), requiring a reboot.

      This sounds like a problem that a number of people had with version 3.1: opening files was rather slow in that version, such that many people (generally people who had slower computers than my G5 🙂 ) believed it had crashed. I've since optimised it a great deal more, and added a progress bar to make it clear that something is happening.

      Quote

      MC, at least the last version I used (which was about 4 months ago) also suffers from interface-overdesign IMHO, a phenomenon common in REALbasic-made applications.

      Can you explain what it is that you don't like about the interface? I've put a great deal of effort into finding the simplest ways of expressing EV resources. While I know some people don't like the tab-based arrangement I've used for a number of types - I'm not all that fond of it myself, for that matter - I consider it preferable to the huge fields of tiny check boxes that characterise NovaTools (I should also mention that I've put a fair bit of work into simplifying several editors in version 3.3).

      Given that, as of the current build, MissionComputer amounts to 45,629 lines of code, I don't think it can really be called interface-focused. 🙂

      With regard to the 'barely Carbon', I'm not sure exactly what you mean by that, unless you're referring to the occasional interface-drawing glitches; I don't particularly like them either, but they don't interfere with actual functionality, and are merely the result of using REALbasic 3.5, which was designed for Mac OS 10.1.

      Quote

      Once again, I'm sorry.

      All right. 🙂

      Guy said:

      I just get the feeling that it would all be a lot better if it was made with Xcode.

      Oh, no doubt it would be, but when I was first writing MissionComputer (which, after all, was released before EV Nova), most people, myself included, didn't even have Mac OS X. It's not impossible that I might some day write a new editor in Cocoa, but at the moment it's rather unlikely, as it seems like the effort involved in re-creating what I already have would be better spent on new abilities, unless I had some other reason to carry out the transition.

    • David Arthur, on Nov 19 2005, 12:25 PM, said:

      Oh, no doubt it would be, but when I was first writing MissionComputer (which, after all, was released before EV Nova), most people, myself included, didn't even have Mac OS X. It's not impossible that I might some day write a new editor in Cocoa, but at the moment it's rather unlikely, as it seems like the effort involved in re-creating what I already have would be better spent on new abilities, unless I had some other reason to carry out the transition.
      View Post

      Yeah, fair enough. It is a great program and I admire the work you've put into it. Not sure why I don't really use it - maybe it's the speed. ResEdit is just so fast (unless you're using the grayscale interface <_<). Or it may simply be I'm too used to ResEdit to change - I'm sure I'll change eventually. 🙂

    • Yes, ResEdit does tend to crash, but I haven't had any corruption of files in several months. Of course, this might be because I've developed a "cmd-S twitch", and save the file every couple of minor changes. 🙂

      As for MissionComputer, from my limited testing, it looks like an excellent editor: it doesn't crash, the integration of the desc editor with everything else is very nice, and ResEdit has nothing like the galaxy map (although a bit more point-and-clickness there might be nice). However, I personally prefer the "huge fields of tiny check boxes that characterise NovaTools"- it's nice to be able to open a single window and see everything about a resource at once. Also, MC's inability to open more than one window at a time is a royal pain if you want to quickly compare a couple of resources, or incrementally change two resources to match, both of which I do regularly.
      (Hmm... Could you add a "Resource Comparer" to some version, if you can't do anything about the one-window-at-a-time problem? It wouldn't have to be fancy, just a pair of RDLs set side-by-side.)

      Edwards

    • Edwards, on Nov 19 2005, 05:50 AM, said:

      because I've developed a "cmd-S twitch", and save the file every couple of minor changes. 🙂
      View Post

      I know EXACTLY how you feel....

      Also, you can add my name to the "prefers to see everything at once camp."
      Perhaps it should be noted that I also use Autruo's fine NovaTools update 1.0.1. and I like the layout much better.

      ----------
      About MissionComputer. Here are my thoughs. Please note that I'm not trying to be snide, this is just my 2˘ (also this is version 3.2, so I may need to check out the new version.)

      I don't much care for the interface, and in an editor of this type, I'd say that's 90% of the reason for using it.

      For a number of reasons, the interface actively interferes with my ability to change and/or examine anything. I'll try to explain why I feel this way.

      First, it bugs me that it currently uses only 1/5 of my screen realestate. Forcing me to click endless tabs (or in the case for ships and weaps constantly scrolling up and down) when there's no reason I shouldn't be able to see everything all at once. It is practicaly unforgivable to hide stuff behind tabs and in scroll boxes when there is screen space just begging to be used.

      I understand that the tabs are supposed to make the layout more organized, but by making parts of an open resourse hidden behind a tab, I find it hinders me more than helps. I am a firm believer that there is a better soultion to this problem.
      With a well designed layout, it should be possible to see everything AND keep it straight forward and organized.

      Furthermore, this is compounded by inappropriate box sizes in the ship, weap editors particularly. A field the practicaly the size of the editor window to hold 1 number? An inch tall box that holds a paragraph of text, requiring yet another scroll bar when there are acres of unused space right above?

      Second, if I simply want to review the specifics of a particular resourse, I have to click every single tab, every time. That's 6(!) tabs for the misn resource, and I still would have to click back and forth to make sure everything is correct.

      I shouldn't have to make multiple clicks to change (or even just view) one little flag on an item.

      I think the theory of website navigation holds here. Everything should only be 1-2 clicks away from eachother. Otherwise the interface becomes cumbersome.

      For example, in Nova tools, you don't ever need more that 2 clicks to reach everything you need to know about a resource. A third click only occurs getting to the color wheel to change a color. You don't even need to click to see the color, and if you know the hex value you don't even need to open it to change it.

      Third, I frequently find myself having to make a minor change to dozens of resources at once.
      Let's say I'm making a plug and, after testing, I decide that my weapons all need to recoil more. So I want to go through and add 10 to each weapon's recoil.
      This would take forever in MissionComputer.
      After I open the resourse, the fact that I would still have to use the mouse to scroll down every single time to find the recoil field, then go back to the keyboard to enter the new value, then go back to the mouse to click "ok" and move to the next entry (enter or return won't activate the "ok" button) multiplies my time to edit by about 4 or 5 times.
      For comparison, in NovaTools I can get into a sequence of repeating keystrokes, and very quickly fly through all the records. Maybe requiring a single mouse click (but often not even requiring me to move it - so I can just quickly tap the button an move on.)

      Some things, I'm sure, come down to personal preference, but I'm not convinced that the tabs and scroll fields are doing what you want them to do.

      You mentioned that you didn't like the huge fields of check boxes in NovaTools, and you prefer the tabs over that. These aren't the only two solutions, there IS middle ground available.
      I could personaly improve and address the problems in a layout like NovaTools. But I don't think there's too much I could do to fix the problems inherent in a tab system.

      Again, I'm not trying to be overly critical. I've really got no right to complain about a project that you generously invested your own personal time into for the benefit of the EV community. I am just providing my own experience, and I hope it comes across as helpfull and constructive. No worries though, it's your project after all, and you'll do with it as you see fit.

      This post has been edited by Desprez : 19 November 2005 - 08:18 AM

    • If NovaTools automatically created descs like MissionComputer and the Shan editor could handle large ships it would still reign supreme, but as it can't and won't MC is the way to go for the future.

      What ever happened to EVONE? It has dropped off the face of the earth...

    • Edwards said:

      Also, MC's inability to open more than one window at a time is a royal pain if you want to quickly compare a couple of resources, or incrementally change two resources to match, both of which I do regularly.

      That is on my list of 'things to do something about', and I've thought through the basic logic, but as it will involve taking apart and re-assembling both the document window and every single editor, it's not going to happen overnight.

      Desprez said:

      First, it bugs me that it currently uses only 1/5 of my screen realestate. Forcing me to click endless tabs (or in the case for ships and weaps constantly scrolling up and down) when there's no reason I shouldn't be able to see everything all at once.

      Until relatively recently, MissionComputer's primary audience included people with 640x480 monitors, which constrained window sizes significantly. I'm now in the process of switching to larger windows; for 3.3, I've replaced the EV Nova düde editor with a larger tab-less version, eliminated the separate pop-up window for jamming in the gövt editor, and changed the scrolling list in the EV Nova gövt editor into regular check boxes, and none of the new editors are tabbed. I'm also exploring doing the same things for other resource types in future versions.

      Desprez said:

      Furthermore, this is compounded by inappropriate box sizes in the ship, weap editors particularly.

      MissionComputer doesn't have shďp or wëap editors - what you're seeing their are RDL scripts working through a generic RDL-based editor, which are an improved and EV-specific equivalent of ResEdit's templates, not equivalent (or intended to be equivalent) to either NovaTools or MissionComputer's actual editors.

    • David Arthur, on Nov 19 2005, 02:25 PM, said:

      Until relatively recently, MissionComputer's primary audience included people with 640x480 monitors, which constrained window sizes significantly. I'm now in the process of switching to larger windows; for 3.3, I've replaced the EV Nova düde editor with a larger tab-less version, eliminated the separate pop-up window for jamming in the gövt editor, and changed the scrolling list in the EV Nova gövt editor into regular check boxes, and none of the new editors are tabbed. I'm also exploring doing the same things for other resource types in future versions.

      This is certianly good to hear.
      I wonder if it would be possible to let the user change or customize a given layout, including window sizes. But I don't know how realbasic works or if that is really feasable or not.

      Quote

      MissionComputer doesn't have shďp or wëap editors - what you're seeing their are RDL scripts working through a generic RDL-based editor, which are an improved and EV-specific equivalent of ResEdit's templates, not equivalent (or intended to be equivalent) to either NovaTools or MissionComputer's actual editors.
      View Post

      Ah, well that explains things.

      You've already got functional galaxy and system editors.
      Aside from that, I think most people spend the majority of time in the misn, weap, outf, ship editors. Streamlining these would go a long way to alliviate most interface issues.
      If I can be of any help here, don't hesitate to ask.

      This post has been edited by Desprez : 19 November 2005 - 04:57 PM

    • Desprez said:

      I wonder if it would be possible to let the user change or customize a given layout, including window sizes.

      I've never seen any programme with anything resembling a standard interface allow customisation in ways that don't actually detract from usability, so I'm not going in that direction.

      Desprez said:

      Aside from that, I think most people spend the majority of time in the misn, weap, outf, ship editors. Streamlining these would go a long way to alliviate most interface issues.

      At the moment, shďp is the most likely candidate for the next resource type to get a proper editor, and it will of course be a fully-modern streamlined editor like the recent ones for smaller resources.

      I was never particularly satisfied with the oütf editor, although I've improved it a bit for the close-to-release 3.3.1, particularly in its handling of ModVals. mďsn is the oldest editor, relatively unchanged since I first designed it to edit EV Override under Mac OS 9; it's also the most complex, apart from the big multi-resource Cartographer ones. I may revisit it in some future version.

      (On a side note, today I enlarged and de-tabbed the chär editor.)

    • 3.3.1? But 3.3 isn't even out yet, is it? Of course, with the addons pages not being updated I guess we wouldn't know if it was.