Ambrosia Garden Archive
    • David Arthur, mission computer, and why both are in the topic title


      PROBLEM SOLVED (somewhat), read below

      i'm having issues with your software, the newest version. i suppose i could e-mail, but i don't want to. that being said, my problem:

      mission computer has a knack for pissing me off. it likes to not be able to save the current resource upon clicking the ok button. instead, it says something like "i can't save this, would you like to try again?" cancel and try again! are the options, but cancel deletes the entire thing, and try again! saves a blank resource, there by ruining my concentration.

      at first, it was alright, i could deal with it. but when it happend every ****ing resource, regardless of if i saved right before editing it, it becomes annoying.

      i am also running into "cannot save prfk file, try again?" and it tries again. this doesn't do much, i don't know what a prfk is in regards to my plug, but i don't care.

      whats the score here?

      my computer is an imac 500, i have over 600 megs of ram, and am running the newest version of mission computer available on 10.2.8.

      ------------------
      the antichrist will be elected by fax machine.

      (This message has been edited by antihero (edited 08-13-2004).)

    • Sometimes it does it. No problem. No-one's actually forcing you to use it, right?

      ------------------
      One wonders just HOW the "Engine Upgrade" increases the ship's speed by 150 AU/hr in the original EV....
      Patiently waiting for (url="http://"http://evula.org/aftermath")Aftermath(/url); FH2; and UT's (url="http://"http://freepgs.com/starfleet_adventures/index.php")SFA(/url)

    • Quote

      Originally posted by Aelran:
      **Sometimes it does it. No problem. No-one's actually forcing you to use it, right?

      **

      i like its interface better than resedit. that being said, sometimes is not the same as every other minute.

      ------------------
      the antichrist will be elected by fax machine.

    • nevermind, figure it out.

      apparently, mission computer assigns the same id at times (ie, sometimes it will assign id number 222 to a spöb, then turn around and assign 222 to the next spöb you create). since both spobs have the same id, the newer one is deleted. the spöbs was just an example, it happens with all of it.

      ------------------
      the antichrist will be elected by fax machine.

    • I've had this issue as well. Its mostly only a problem with descs, so far.

      EDIT: I mean that its most annoying with descs. It happens with other resources as well. The only time it tends to be a repetitive problem is when editing "System Attributes" in a syst----it really doesn't like that for some reason, and I have to be careful what I do there.

      (This message has been edited by Lindley (edited 08-13-2004).)

    • Since it fits the subject line for this thread, I'll report another MC issue here:

      When you import a graphic with a resolution other than 72 dpi into ResEdit, it displays it as if it were a 72 dpi image with the same dimensions (in inches) -- in effect, it will take a properly-sized (in pixels) landing pic and show it as something the size of an icon. ResEdit does not , however, actually lose data -- if you copy the (apparently) postage-stamp-sized image out of ResEdit and back into an image editor such as GraphicConverter, you can see that all the original pixels remain intact even though ResEdit won't show them to you. (Nova doesn't successfully access the extra data, but it is there.) Regarding all this, see my comments and screen shots (url="http://"http://www.ambrosiasw.com/webboard/Forum9/HTML/005544.html")here(/url).

      MC, on the other hand, seems to actually downsample high-dpi images that are imported into the program to 72 dpi images with the same inches-by-inches sizes -- those exported from the program do actually have less information than those that go in.

      It would be much friendlier if, upon import of a PICT with a resolution other than 72 dpi, MC either (A) threw up a warning about Nova's pickiness about resolution or (🆒 altered just the resolution header (?) of the image to reclassify it as a 72 dpi image, without data loss.

      Generally, though, MC is a great program -- after working with NovaTools for a while, it is often a relief to return to MC!

      ------------------
      (url="http://"http://home.comcast.net/~drtrowel/")Dr. Trowel's E.S.W.P.(/url) -- Cold Fusion graphics for EVN Override, EVN:O bug fixes, 'n more.
      Very Good Stuff: (url="http://"http://www.evula.com/escape_velocity/")EVula(/url) (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) (url="http://"http://www.evula.org/infernostudios/search.html")EVPlugSearcher(/url) Play FAQs: (url="http://"http://ev-nova.net/faq/")N(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=EV+Nova+FAQs&number;=30&DaysPrune;=20&LastLogin;=")N(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=EV+Override+FAQs&number;=53&DaysPrune;=20&LastLogin;=")O(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=Escape+Velocity+FAQs&number;=28&DaysPrune;=20&LastLogin;=")C(/url) Dev FAQs: (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=EV+Plug-in+Developer+FAQs&number;=29&DaysPrune;=20&LastLogin;=")A(/url) (url="http://"http://www.ambrosiasw.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=31&SUBMIT;=Go")B(/url)
      For a Limited Time Only: (url="http://"http://www.ambrosiasw.com/webboard/Forum26/HTML/018106.html#")The Silly Plug Contest!(/url)

    • This problem has existed for some time, and affects different people at different intervals. I haven't been able to trace it; most of the code which is seemingly responsible hasn't been changed since long before it started occurring. I've added a few more safeguards against data loss in a new version I'm working on.

      Quote

      Originally posted by Dr. Trowel:
      It would be much friendlier if, upon import of a PICT with a resolution other than 72 dpi, MC either (A) threw up a warning about Nova's pickiness about resolution or (🆒 altered just the resolution header (?) of the image to reclassify it as a 72 dpi image, without data loss.

      MissionComputer doesn't even know about resolution; I'm just using standard system routines, and this seems to be how they react to non-screen resolution pictures. I agree that it's somewhat irritating, but it's easily worked around (and after all, there's no good reason for screen graphics to be anything other than 72 dpi), and changing it would basically require that I write my own PICT decoder, which would be kind of ridiculous for something this minor (and which I'm not willing to take on after the amount of trial and error it took to produce my still-imperfect RLE decoder).

      ------------------
      David Arthur | (url="http://"http://davidarthur.evula.net/")davidarthur.evula.net(/url) | (url="http://"http://www.ev-nova.net/")EV-Nova.net(/url)
      The people united can never be ignited!

    • Quote

      Originally posted by Dr. Trowel:
      **Since it fits the subject line for this thread, I'll report another MC issue here:

      When you import a graphic with a resolution other than 72 dpi into ResEdit, it displays it as if it were a 72 dpi image with the same dimensions (in inches) -- in effect, it will take a properly-sized (in pixels) landing pic and show it as something the size of an icon. ResEdit does not , however, actually lose data -- if you copy the (apparently) postage-stamp-sized image out of ResEdit and back into an image editor such as GraphicConverter, you can see that all the original pixels remain intact even though ResEdit won't show them to you. (Nova doesn't successfully access the extra data, but it is there.) Regarding all this, see my comments and screen shots here.

      MC, on the other hand, seems to actually downsample high-dpi images that are imported into the program to 72 dpi images with the same inches-by-inches sizes -- those exported from the program do actually have less information than those that go in.

      It would be much friendlier if, upon import of a PICT with a resolution other than 72 dpi, MC either (A) threw up a warning about Nova's pickiness about resolution or (🆒 altered just the resolution header (?) of the image to reclassify it as a 72 dpi image, without data loss.

      Generally, though, MC is a great program -- after working with NovaTools for a while, it is often a relief to return to MC!

      **

      I don't know what causes that problem, but there's a simple solution.

      1. Open the file in a program that shows it at the proper size.
      2. Take a screenshot.
      3. Crop the screenshot down to only the image itself.
      4. Viola. The new image will not have scale issues.

      ------------------

    • Yeah, now that I'm aware of the problem there are other simple solutions I can apply, too -- for instance, I can use Photoshop or GraphicConverter to change image resolutions without resampling.

      I would never have run across this issue with MC (and the related limitations of NovaTools and Nova itself) if I hadn't tried to use scanned photos as landing pics. I recognize that it's not something that large numbers of people are going to come across. If resolving this isn't trivial programming, forget it. 🙂

      ------------------
      (url="http://"http://home.comcast.net/~drtrowel/")Dr. Trowel's E.S.W.P.(/url) -- Cold Fusion graphics for EVN Override, EVN:O bug fixes, 'n more.
      Very Good Stuff: (url="http://"http://www.evula.com/escape_velocity/")EVula(/url) (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) (url="http://"http://www.evula.org/infernostudios/search.html")EVPlugSearcher(/url) Play FAQs: (url="http://"http://ev-nova.net/faq/")N(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=EV+Nova+FAQs&number;=30&DaysPrune;=20&LastLogin;=")N(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=EV+Override+FAQs&number;=53&DaysPrune;=20&LastLogin;=")O(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=Escape+Velocity+FAQs&number;=28&DaysPrune;=20&LastLogin;=")C(/url) Dev FAQs: (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&forum;=EV+Plug-in+Developer+FAQs&number;=29&DaysPrune;=20&LastLogin;=")A(/url) (url="http://"http://www.ambrosiasw.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=31&SUBMIT;=Go")B(/url)
      For a Limited Time Only: (url="http://"http://www.ambrosiasw.com/webboard/Forum26/HTML/018106.html#")The Silly Plug Contest!(/url)

    • My only real problem with MC and EVONE (besides MC randomly deleting resources as in this thread and EVONE being really unstable) is just how slow these apps are. Even the classic versions take much longer to launch than ResEdit. Windows open like snails in the affore, while ResEdit simply pops them forth.
      I love NovaTools. If ResEdit was useful for OSX in other ways than Nova then surely someone would rewrite it, but it isn't; so if I want to work on my stuff in X I must use one of these. I do keep backups, but after the first five or so times MC (especially) destroys something important because it assigns the wrong ids to things or whatnot I am really inclined to just restart and fire up ResEdit.
      Basically I just don't understand why everyone dislikes NovaTools so much! The s˙st editor of EVONE is about the coolest thing ever but aside from that both it and MC are lacklustre compared, at least in stability. I've heard that some people think that Resedit crashes a lot: try (url="http://"ftp://ftp.mirrors.ausmac.net/pub/mac/Util-SW/super-resedit-24.hqx")Super ResEdit(/url). I don't remember where I got it but I don't think that it's crashed more than four times the entire time that I've been plugging, which is certainly more stable than 3.0.

      ------------------
      Drinking causes hangovers.
      (url="http://"http://www.freewebs.com/rmx256/index.htm")Kemet T.C. Website(/url)

      (This message has been edited by rmx256 (edited 08-16-2004).)