tenney@well.UUCP (Glenn S. Tenney) (12/30/86)
I finally decided to fork over some green and acquire a copy
of Sublogic's Flight Simulator II for the Amiga. After about an hour
or two of use here are some comments (and a short flame):
1. It takes over the machine (which is understandable), but the mouse
interface is foreign to an Amiga owner. It seems the Amiga version
is a port from the Atari ST version and they ported the GEM interface.
You point to a menu item, click left to pull it down, then click again
either on another menu item, the desired menu item or anywhere else to
forget it all.
2. It comes up in the SFO area. Since I got my intrument ticket here,
I tried to shoot an ILS at SFO, OAK and SJC. No luck! After a phone
call to them today, boy am I PO'ed! "Oh, none of the instrument approaches
in the Bay Area works. We're planning an update sometime soon. Try
calling us back at the end of January to see if it's ready. Oh, and it
should fix the green clouds too." When I asked about the update policy:
"We don't have any policy yet, but in the past you'd send in your original
disk and we'd send the update back out. It might be the same now, but
I don't know." Then we talked about letting such an obvious bug get out:
"So many people wanted it, that they were willing to take it with bugs."
-- short flame --
I think that releasing a program with such an obvious bug (since it
starts up by default in the Bay Area) is an awful thing to do.
Although it IS a nice simulation (and well worth buying, so far), I
suggest you consider waiting a month or so until the next release
gets out. Those of us that are funding your development effort
should be amply rewarded by promptly sending us updates FREE for
some reasonable period of time (not just ONE update). I also feel
that emulating the GEM interface was the WRONG choice. They should
have done the Amiga for the Amiga and then maybe emulated that
interface on the ST. (Having done a port to the Amiga, I do
understand the problems involved.)
--- burner down low ---
-- Glenn Tenney
UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney
ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY
As Alphonso Bodoya would say... (tnx boulton)
Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!wagner@utcs.UUCP (12/31/86)
Is subLOGIC on the net? Wonder if complaining here does any good (although I'm interested in your complaints too). I bought flight simulator when I saw it at the Toronto World of Commodore show. Since I don't fly, I can't comment on the realities of the thing, but I enjoy it from time to time. I notice that the engine sounds and speeds are a little more discrete than I would have thought realistic. That is, as you start to climb, the engine doesn't slow down gradually, but rather, in discrete chunks. Also, as someone pointed out earlier here on the net, the geography database is far from complete. I had just come back from San Francisco area (and hiking in Yosemite) when I got the program, so I thought I'd fly over to the Sierras for a laugh. Well, the supplied maps aren't good enough, so I got out my maps for the area. I'm not sure what happened, but I think I fell off the edge of their database. At least, it seemed to differ greatly from reality. Perhaps I just hit a spot of bad weather. My recollection is unclear - after all, it was 3AM several weeks ago. I probably shouldn't be flying at 3AM anyways - not even a simulator! :-) Someone told me that you should be able to fly under the golden gate bridge. I always chicken out and go over it instead! I didn't buy my Amiga for games, and I have only 2 games other than the public domain stuff on the fish disks (which I almost never play). They are Flight Simulator and Chessmaster2000. Both have their problems, but they're both fun. Incidentally, my copy is called 'Flight Simulator II'. It's program number AM-FS2. And it has an ISBN number! 1-55602-018-X. Is this the copy you have? Keep us up to date when the updates will be available. Michael
sarge@percival.UUCP (Rod Sargent) (01/02/87)
In article <2280@well.UUCP> tenney@well.UUCP (Glenn S. Tenney) writes: >1. It takes over the machine (which is understandable), but the mouse > interface is foreign to an Amiga owner. It seems the Amiga version > is a port from the Atari ST version and they ported the GEM interface. > You point to a menu item, click left to pull it down, then click again > either on another menu item, the desired menu item or anywhere else to > forget it all. I also found this GEM type mouse interface cumbersome at first. However about 50 or 60 hours of flight, one becomes quite proficient at the controls and the interface becomes second nature. >2. It comes up in the SFO area. Since I got my intrument ticket here, > I tried to shoot an ILS at SFO, OAK and SJC. No luck! After a phone > call to them today, boy am I PO'ed! "Oh, none of the instrument approaches > in the Bay Area works. We're planning an update sometime soon. Try > calling us back at the end of January to see if it's ready. Oh, and it > should fix the green clouds too." When I asked about the update policy: > "We don't have any policy yet, but in the past you'd send in your original > disk and we'd send the update back out. It might be the same now, but > I don't know." Then we talked about letting such an obvious bug get out: > "So many people wanted it, that they were willing to take it with bugs." > I think that releasing a program with such an obvious bug (since it > starts up by default in the Bay Area) is an awful thing to do. I was also a little miffed at the ILS shortcoming. While I am more LA flight oriented, I was very disappointed in the lack of functioning ILS approaches at SFO, OAK and SJC. While not ILS ticketed, I do enjoy the practice such approaches give. The port from the ST does not bother me as much as the lack of ability to multi-task. This is a major shortcoming in the use of the equipment. As for the green clouds and other bugs, this is not something that is being widely dispersed as existing and with most software dealers having a NO REFUND policy these days, it is truely appalling. All and all the FSII for the Amiga is a significant improvement over the 8 bit versions, with more scenery and relatively better graphics. Even with the bugs, I have gained numerous hours of enjoyment in flights I might otherwise have been unable to afford. I EXPECT a free upgrade when the BUGS are removed as they should never have let a product with known faults onto the store shelves....at any price. One Item I think you failed to mention in the positive is the use of Multi-User flying. There is great excitement in connecting modems with fellow Amiga (and ST) users for hours of joint flights. I fly somewhat regularly with a 520 ST owner and have found cross country junkets more enjoyable with a fellow plane off your wing...even if it is an Atari.... ;-) Rod Sargent ---------------------------------------------------------------------- .... To live and move among men, live while alive, and sieze the pleasures of the present day. For life is a great bundle of many things.... sarge@percival ....Men see a little, presume a great deal, and so jump to the conclusion. John Locke Knowledge comes, but wisdom lingers. Alfred, Lord Tennyson, Locksley Hall ..!{ucbvax,ihnp4,seismo}!tektronix!reed!percival!sarge! ----------------------------------------------------------------------------
jmpiazza@sunybcs.UUCP (01/04/87)
In article <2280@well.UUCP> tenney@well.UUCP (Glenn S. Tenney) writes: > ... but the [menu] > interface is foreign to an Amiga owner. It seems the Amiga version > is a port from the Atari ST version and they ported the GEM interface. I saw the pre-release version and some menus were lifted from the Mac version -- they still had the "command key" in the menus using the Mac's same clover design! > ... I tried to shoot an ILS ... > [SubLogic rep says] "Oh, none of the instrument approaches in the > Bay Area works" ... I'd be happy to find out how to do it. The manual sufficiently explains how to use VOR; why not ILS? I did notice that the O in the OMI indicater bleeps at me on my way to the Oakland Bay bridge. > "So many people wanted it, that they were willing to take it with bugs." I plea guilty. >-- short flame -- > I think that releasing a program with such an obvious bug (since it > starts up by default in the Bay Area) is an awful thing to do. > Although it IS a nice simulation (and well worth buying, so far), I > suggest you consider waiting a month or so until the next release > gets out. Unfortunately, they can get away with their decision 'cause I think that most buyers would be like me and not know what we're missing. > ... I also feel > that emulating the GEM interface was the WRONG choice. That's an understatement -- very stupid choice on their part, in my opinion. I can't imagine that using Intuition menus was any more difficult than writing their own utilities from near scratch. On second thought, maybe that was the problem: "Hell, I wrote these here neat menu routines so I'm usin' 'em!" Flip side, joe piazza --- Cogito ergo equus sum. CS Dept. SUNY at Buffalo 14260 (716) 636-3191, 3180 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@buffalo-cs BI: jmpiazza@sunybcs GE: jmpiazza
eric@topaz.RUTGERS.EDU (Eric Lavitsky) (01/05/87)
Actually, there may be a real reason for doing the menus the way they did in FSII (not that I'm condoning it!) - Now they can print up the *exact* same manuals for every new version of FSII they sell (Amiga, ST, Mac, IBM?) - Imagine the cost savings for SubLogic! Of course, I see this as being ultimately cheap - just like the folks who did Music Studio - it shows very little commitment on the part of the authors to supporting your machine. Eric -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...topaz!eric ...hplabs!well!lavitsky ...ulysses!eric
ses@oliveb.UUCP (Dean Brunette) (01/06/87)
I know as a fact the interface used in FSII is not akin to GEM on the ST (or
IBM for that matter) since I also own an ST. I thought it was Mac-like, and
this would make sense since the ST version is supposed to be ported over from
the Mac. Either way, I agree that it is a good idea to use your computer's
interface for programs running on it, not another computer's interface. It's
hard enough getting used to each computer...
About the recent Juggler demo postings arriving at most sites corrupted:
Can't the files be ARCed, and since ARC has a checksum utility, it would point
out corrupted files on their creation? It would also shorten Kermit transfer
time from the VAX to Amiga :-)
file -> ARC -> uuencode -> mail
Dean Brunette, Olivetti Advanced Technology Center, Cupertino, CA
DISCLAIMER: OATC couldn't care less about the Amiga... so what I say is
MY business!
(Call Amiga West, (415) 355-7162!)todd@zeke.UUCP (Todd Burkey) (01/06/87)
In article <1838@sunybcs.UUCP> jmpiazza@gort.UUCP (Joseph M. Piazza) writes: >In article <2280@well.UUCP> tenney@well.UUCP (Glenn S. Tenney) writes: >> ... I also feel >> that emulating the GEM interface was the WRONG choice. > > That's an understatement -- very stupid choice on their part, in >my opinion. I can't imagine that using Intuition menus was any more >difficult than writing their own utilities from near scratch. On >second thought, maybe that was the problem: "Hell, I wrote these here >neat menu routines so I'm usin' 'em!" > Why blame GEM? I have a MAC, Amiga, and an ST at home and while it is true that Flight Simulator came out on the ST before the AMIGA, it is quite obvious that they used the MAC style interface as opposed to the ST. It is true that it feels foreign...even to an ST owner. I think I understand why they chose it, though. If you note the exact way the buttons are used, it would be awkward to reserve one button for activating just the menu selections (aka the amiga right button). Instead, it seems practical to only let you pull down the menu the few times you actually want it (i.e. the hard way) and give you more control over flight by using both buttons. I know I would find it very disconcerting to be accidentally pulling menus down when I meant to be just moving a window aside for a quick view of the map or whatever... Don't flame me for having all three computers...The Mac is a carryover from the days when I thought monochrome graphics and 5.7MHz compiling speed was enough and the Amiga is used for some development. Sorry, guys, but I still prefer the ST for major program development (i.e. my VAX VMS and UNIX code ports back and forth very easily...both MW C and OSS Pascal) at home, and as a VAX VT100 terminal with drafting capability (Generic Cadd) at work. You can flame me for the following statement. I do wish more time would go into real product development on the AMIGA than in putting together demos and complex public domain products. I think the AMIGA is an excellent machine, but it really needs some nice, tightly integrated packages for retailers to be able to sell (i.e. for a profit) to get it into the business market. I know, I know. I can say the same about the ST, but at least on the ST, it is fairly trivial to port IBM PC software over, so we will see things like Open Access and more accounting packages than we know what to do with (as long as they are written in C or Basic...). I have a PC clone, too...it makes a great BBS, but is useful for little else except eating up boards (hmm, I think I have got everyone incensed now.) Todd Burkey ..!mecc!zeke!todd -- -Todd Burkey ZYCAD Corporation ..!mecc!zeke!todd
lachac@topaz.RUTGERS.EDU (Gerard Lachac) (01/07/87)
In article <340@oliveb.UUCP> ses@oliveb.UUCP (Dean Brunette) writes: >About the recent Juggler demo postings arriving at most sites corrupted: >Can't the files be ARCed, and since ARC has a checksum utility, it would point >out corrupted files on their creation? It would also shorten Kermit transfer >time from the VAX to Amiga :-) >file -> ARC -> uuencode -> mail Here Here!! I vote for this! Definately shortens the posting, for example, I recently ARCed a backup copy of Matt's new shell he posted last week for backup purposes. Executable ~34k Docs ~20k Arced file of both ~36k -- ---------------------------------------------------------------------------- "Isn't fun the best thing to have?" lachac@topaz.rutgers.edu
grr@cbmvax.cbm.UUCP (George Robbins) (01/07/87)
In article <340@oliveb.UUCP> ses@oliveb.UUCP (Dean Brunette) writes: > > >About the recent Juggler demo postings arriving at most sites corrupted: > >Can't the files be ARCed, and since ARC has a checksum utility, it would point >out corrupted files on their creation? It would also shorten Kermit transfer >time from the VAX to Amiga :-) > >Dean Brunette, Olivetti Advanced Technology Center, Cupertino, CA Yes, they could have been, but unfortunatly arc is not to be found on every unix system in the universe, while uuencode/decode is pretty universal. uudecode is so stupid that it wouldn't be hard to add per record checksums, sequnece numbers and even transliteration checks in a way that files would be compatible with either new or old decoders. Anybody feel like doing a little PD software? -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
kim@amdahl.UUCP (Kim DeVaughn) (01/08/87)
In article <8232@topaz.RUTGERS.EDU>, lachac@topaz.RUTGERS.EDU (Gerard Lachac) writes: > In article <340@oliveb.UUCP> ses@oliveb.UUCP (Dean Brunette) writes: > >About the recent Juggler demo postings arriving at most sites corrupted: > >Can't the files be ARCed, and since ARC has a checksum utility, it would point > >out corrupted files on their creation? > > >file -> ARC -> uuencode -> mail > > Here Here!! I vote for this! > > Definately shortens the posting, for example, I recently ARCed a > backup copy of Matt's new shell he posted last week for backup purposes. > > Executable ~34k > Docs ~20k > > Arced file of > both ~36k Yes. ARC would save about 18K in this case, plus the two postings required for the above two files (after uuencoding the executable) could have been reduced to one posting, and still been under the 64K "limit". I'm not sure it would have helped the Juggler's movie.data files very much though ... on the entire movie.data file in binary form, all 295610 bytes of it, "compress" (v4.0) only reduced it by 0.34%, down to 294605 bytes. Wheeee ... we saved a whole 1005 bytes! (This was using 16-bit compression on an Amdahl 5860). Strangely enough, pack(1) managed to squish it down to 244062 bytes, or a 17.4% reduction. This is one of the few times that I've seen "pack" beat-out "compress". How well ARC would do on movie.data would depend on which algorithm it picked as "best" (should it pick the compress style L-Z algorithm, it would likely be using 12-bit compression, and the results would be worse than above). I'm assuming here that the arcing is done on an Amiga, as I have yet to see a version of ARC that *always* works correctly on *all* UNIX(R) machines. There is another problem (for the movie.data file) as well ... it is BIG. I'm not sure you *can* arc it on a 512K machine. Anyone want to give it a try (I'll see what ARC does with it on a 1.5 Meg machine). I suppose one could split the binary movie.data file into several pieces, and arc each one, but I wouldn't recommend going to such lengths just to save 10% or so ... much easier to split the uuencoded file, as Andy did. With more conventional (and smaller) binary files, I do recommend using ARC ... the only problem is, is that not everyone has it (but if you don't, you should ... it's on Fish Disk #40, and probably alot of Amiga BBS's as well). As for the checksumming that ARC does ... unless you can do your arcing and dearcing on your host system (good luck!), you'll still have to download the file(s) to the Amiga before you'll be able to find out if the file is corrupted or not. The problem (as far as errors that occur during net propagation, anyway) is with the uu-twins ... uuencode/uudecode. Binary data and executables *must* be encoded in some way that will keep the various mailers and news programs happy. Because they are widely available, and very simple to implement/port, the uu's are what are usually used. But the uu's do NOTHING about error checking. I've been considering adding a rudimentary form of error checking to the uu programs ... something like what is done with the Intel Hex or Motorola S-rec formats that are used to download binary files to PROM burners. Simply stated, these formats add a checksum to each line of the encoded file. This would at least tell you if the file was corrupted at uudecode time (usually). I haven't done anything yet, because I'm not sure this is "enough". Given that binaries will continue to be posted to the net, knowing that one has received a corrupted file will usually result in a request for a reposting, or an email copy. This would increase the volume of traffic on the net, and we all know how well received that would be! Seems to me that it would be better to have some error CORRECTION capability, than merely error DETECTION. Of course the better the detection and/or correction capability, the more bits are required (and the bigger the file). How much is enough? Is the most common problem a single-bit hit, or is it a "run" of characters? Or is it (shudder) a truncated file (which nothing short of a reposting is going to cure)? If it's the latter, then maybe simple error detection *is* the most cost-effective improvement. Does anybody know the frequency of the various failure modes in this type of network? Anybody have any data? Then of course there is the logistic problem of getting *any* kind of improved encode/decode program distributed to everybody, and *then* to get everybody using it ... "people resist changes", someone once said :-)! I am willing to do some work on such an improvement, but I'd really like to see some discussion before I run out and invent Yet Another Protocol. My gut feel is that a simple checksum on a per-line basis, and an end-of-file indicator (checksummed, of course) is probably the best compromise, as my experience has been that *most* of the time, a file either makes it OK, has a "hunk" of a line missing, or gets truncated. But what do you think? /kim P.S. A last comment on the Juggler files ... had they been arc'd before being uuencoded, I doubt that I would have been able to get him (her ?) juggling again. -- UUCP: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
tenney@well.UUCP (Glenn S. Tenney) (01/08/87)
The interface problem I earlier mentioned is: Point to a menu; click; point to your choice (or another menu, etc.); click to select. I've never experienced that style interface (Mac, Sun, Amiga) and find it VERY foreign and hard to tolerate. It also seems to keep flying even though a menu is down blocking the screen. Glenn
ses@oliveb.UUCP (Dean Brunette) (01/08/87)
In article <5017@amdahl.UUCP>, kim@amdahl.UUCP (Kim DeVaughn) writes: > > With more conventional (and smaller) binary files, I do recommend using > ARC ... the only problem is, is that not everyone has it (but if you > don't, you should ... it's on Fish Disk #40, and probably alot of Amiga > BBS's as well). I think everyone should have ARC. The IBM community has used it without fail for years now, and almost all postings to comp.sys.atari.st and to comp.sources.ibm.pc are ARCed before uuencoding. > > As for the checksumming that ARC does ... unless you can do your arcing > and dearcing on your host system (good luck!), you'll still have to > download the file(s) to the Amiga before you'll be able to find out if the > file is corrupted or not. I think it's better to know that the file is corrupted SOMETIME, rather than pulling your hair out trying to run the thing... Plus, deARCing on the 'mig' will catch the one in 16 million (or whatever) chance of error in Kermit... Lastly, recently on the net somewhere in *.sources.* someone mentioned of a very hairy patch to the ARC source which would allow ARC to run properly on a VAX running BSD 4.2... and most likely portable to other machines as well. Dunno about Amdahls... don't you guys have anything else there? :-) > /kim > > P.S. A last comment on the Juggler files ... had they been arc'd before > being uuencoded, I doubt that I would have been able to get him > (her ?) juggling again. > > -- > UUCP: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim > DDD: 408-746-8462 > USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 > CIS: 76535,25 > > [ Any thoughts or opinions which may or may not have been expressed ] > [ herein are my own. They are not necessarily those of my employer. ] Dean Brunette, Olivetti Advanced Technology Center, Inc. Cupertino, CA DISCLAIMER: People at OATC know nothing of the ST or Amiga. They couldn't care less...
lishka@uwslh.UUCP (Christopher Lishka) (01/08/87)
I too have enjoyed the multiplayer flying mode...it is interesting to
fly with another person via modem, when the other person is across town.
However, we could not get the multi-player mode to work with the WWI game
scenario. What I really want to do is shoot DOWN the other person I am
flying with (O.K., so it may be a little destructive, but who cares?). At
this point, all we could figure out how to do was run into each other,
although that has not been successful yet either.
My question: is there any way to shoot the other person down (like
a dogfight)? Or how about a two-players against the enemy, in the WWI game
scenario (sort of a two-player cooperative effort). Maybe I read my manual
wrong, but I didn't see any info. Any help is, of course, grealty appreciated.
--
Chris Lishka /lishka@uwslh.uucp
Wisconsin State Lab of Hygiene <-lishka%uwslh.uucp@rsch.wisc.edu
\{seismo, harvard,topaz,...}!uwvax!uwslh!lishkabilld@crash.UUCP (Bill D'Camp) (01/09/87)
[]
The version of the Juggler which I managed to get was arc'ed. It was
available on People-Link and on a local BBS. (For some reason the uued
originals never made it, (or I missed them). I can't remember the size
of the arc file, but it was in excess of 1900 xmodem blocks (I thought
that sucker was never going to finish downloading). As I recall the
compression ratio wasn't all that great, but I had no trouble unarcing
it and getting it to run.
--
_ /|
\`o_O'
( ) Aachk! Phft!
U
(serious self-portrait?)
Opinion? I thought you said onions.
UUCP: crash!pnet01!billd
ARPA: crash!pnet01!billd@noscdoc@j.cc.purdue.edu.UUCP (01/09/87)
In article <5017@amdahl.UUCP> kim@amdahl.UUCP (Kim DeVaughn) writes: >Yes. ARC would save about 18K in this case, plus the two postings >required for the above two files (after uuencoding the executable) >could have been reduced to one posting, and still been under the 64K >"limit". There is one problem I think you all are missing. For reliable transfer of binary files across USENET (read both mail and news), you MUST convert them to readable characters of some format or another. Sending binary files (which ANY arc'd file is), is not reliable, so you would still have to uuencode the arc'd file. Sure this may save some time, but not that much! And then, it would probably be more preferable to use compress instead of arc, since alot more people have access to compress, that do not have access to arc. -Craig Norborg comp.sources.amiga moderator doc@j.cc.purdue.edu BTW: Arc (uuencoded and probably split) will be one of my next postings...
cmcmanis@sun.uucp (Chuck McManis) (01/09/87)
In article <230@uwslh.UUCP>, lishka@uwslh.UUCP (Christopher Lishka) writes: > My question: is there any way to shoot the other person down (like > a dogfight)? Or how about a two-players against the enemy, in the WWI game > scenario (sort of a two-player cooperative effort). Maybe I read my manual > wrong, but I didn't see any info. Any help is, of course, grealty appreciated. > -- > Chris Lishka /lishka@uwslh.uucp No, the serial protocol doesn't transmit the bullet information apparently. Nor does it transmit the position of the enemy biplanes, so the program has no way of knowing when you shoot or what you are shooting at. I have heard rumors to the effect that there will be a multiplayer mode in Amiga-Jet and that you will be able to shoot down the other player. Of course you will be flying F-16's rather than Cessna's. Personally, I would like to see something along the lines of Plato's Airfight where more than two people can be playing, and they can choose "sides." That would probably require a MIDI interface though for the psuedo networking involved. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
glee@cognos.UUCP (Godfrey Lee) (01/11/87)
In article <5017@amdahl.UUCP> kim@amdahl.UUCP (Kim DeVaughn) writes: (about improving uuencode/uudecode) >......... My gut feel is that a simple checksum on a per-line basis, >and an end-of-file indicator (checksummed, of course) is probably the >best compromise, as my experience has been that *most* of the time, >a file either makes it OK, has a "hunk" of a line missing, or gets >truncated. But what do you think? I think that you are correct. You also had reservation about getting a new version accepted. The experience on the net is that if you can make a demonstrable improvement (in this case, you CAN), and it is backward and forward compatible, by that I mean old programs can read new files and new programs can read old files, then it will be accepted. The vehicle for posting such a program is mod.sources. Another person thought that because the current uuencode/uudecode programs are so dumb, that it would be possible to add information to the file and stay compatible. I have noticed from the juggler posting that in fact any information after column 64 (?) is ignored. I discovered this when I re-uuencoded the defective binary to correct it, and noticed that the extra character on the end of the defective line is gone. So, a one character checksum at the end of each line will add only 1.56% to the total length of the file, a reasonable price to pay. -- ----------------------------------------------------------------------------- Godfrey Lee, Cognos Incorporated, 3755 Riverside Drive, Ottawa, Ontario, CANADA K1G 3N3 (613) 738-1440 decvax!utzoo!dciem!nrcaer!cognos!glee -----------------------------------------------------------------------------
kim@amdahl.UUCP (Kim DeVaughn) (01/11/87)
In article <2880@j.cc.purdue.edu>, doc@j.cc.purdue.edu (Craig Norborg) writes: > In article <5017@amdahl.UUCP> kim@amdahl.UUCP (Kim DeVaughn) writes: > > Yes. ARC would save about 18K in this case, plus the two postings > > required for the above two files (after uuencoding the executable) > > could have been reduced to one posting, and still been under the 64K > > "limit". > There is one problem I think you all are missing. For reliable > transfer of binary files across USENET (read both mail and news), you > MUST convert them to readable characters of some format or another. > Sending binary files (which ANY arc'd file is), is not reliable, so > you would still have to uuencode the arc'd file. No Craig, I think you misunderstood my earlier posting. I am very well aware of the necessity to ship binary around the net in a "readable character" form ... typically uuencoded. This is why I was taking the uu format to task, and suggesting some form of improvement that would provide error detection, or possibly even error correction. The two test files mentioned previously were a 34K binary, and a 20K text file. For transmission purposes, the binary would need to be uuencoded. It would then "mass" 48K. The document file needs no such encoding, and would go at 20K. Thus there's 68K to send, and since it's over the 64K limit (which causes some braindamaged mailers to truncate the file), it *should* be posted in two parts. The arc'd file was stated to be 36K, which will uuencode to 49620 bytes, or approximately 50K. Ergo ... 68K - 50K is 18K (and 50K is less than the 64K limit, so it could all go at once). In this particular case, the size of the binary (34K) and the text file (20K) together is 54K, which coincidentally is also 18K larger than the arc'd file (36K), but this is not what I was refering to. > Sure this may save > some time, but not that much! In this particular test case, arcing the files and then uuencoding them saves 25% ... not an insignificant amount. On the other hand, the amount of compaction varies widely depending on the kind of file(s) one is dealing with at any given time. Typically, binary files compact the least, and source code the most (due to the large quantities of "white space" found in most program source). Text/document files usually fall in between. The amount of compaction is also very dependent upon the compression algorithm chosen. As I pointed out with the Juggler's movie.data file, Compress 4.0 (which uses 12 or 16 bit Lempel-Zev encoding, depending on the size of machine one runs it on) could only squeeze it by 1005 *bytes* (about a third of one percent)! Pack(1) (which uses Huffman encoding) did far better in this case, getting about a 17% reduction. This surprised me, because Compress usually does alot better than Pack. This is one of the nice things about ARC ... it will choose the "best" algorithm to use on each *individual* file it processes at arc-time: NONE, Run Length Encoding, Huffman (similar to "pack" or "squeeze"), or 12-bit Lempel-Zev (similar to "compress"). Thus, within any give .arc file, any or all of the four formats may be present. > And then, it would probably be more > preferable to use compress instead of arc, since alot more people have > access to compress, that do not have access to arc. I'm not so sure we should use either after having read Mike Meyer's recent posting where he talks about the possibility that running some form of compression prior to uuencoding can actually result in larger files being transmitted from site-to-site. I'd like to see any more information that anyone has on this. [ Mike: I'd like to give your Amiga "tar" program a try ... it would be nice to be able to handle directories! Any chance of you'll be posting it? ] ARC is readily available from Fish Disk #40 for the Amiga version, and Compress 4.0 is on Fish Disk #6. Also, someone (sorry, I don't remember who offhand) is currently porting Compress 4.0 to use Manx. There are some other possible problems in using either ARC or Compress. Compress is usually compiled in 12-bit mode for use on micros due to memory size limitations. On UNIX(R) boxes like VAXen (and Amdahl's :-) ), Compress is compiled for 16-bit compression mode. I do not believe you can uncompress a 16-bit compressed file with a 12-bit compiled program. So one may run into some problems using compress depending on where one does the compress and uncompress. Also, Compress is not part of the standard System V release package to my knowledge, so a significant number of sites mat *not* have it. ARC, on the other hand, is only starting to become available on UNIX machines. There have been a couple of postings to net/mod sources, and quite a few bug reports and hacks to get the posted code up and working on various systems. Hopefully, a "clean" version will emerge sometime soon ... hard for me to trust ARC right now on other than an MS-DOS machine (or an Amiga?). BTW, the ARC on Fish Disk #40 still has a few bugs with wild-cards and using RAM:. It also requires the use of MS-DOS style file-names, which is why I'm not currently using it. Getting back to the root of the problem that started this discussion ... as Mike pointed out, the solution, really, is to fix the news s/w and mailers. All of them. All versions. Everywhere. This may occur in 1997, but not in 1987! Barring that, and after some additional thought, I think a reasonable solution is to enhance uuencode/uudecode to provide error detection, with isolation to the bad line(s). Wayne Hamilton has suggested an approach that would be backward compatible with the existing versions of the uu programs (thanks, Wayne!) Correction will still require a repost/remail, but since the bad line(s) will be identified, only they will require reposting. Hopefully, this will meet with the approval of the backbone sites, etc. Of course this won't help much on a really badly mutilated posting or file that's truncated (the checksumming will be in a block at the end of the file, following the current uu's "end" line). Hopefully these cases will be in the minority. Currently, I estimate the cost will be an increase in file size of about 5%, which seems reasonable to me, so I plan to go ahead with this. I've no idea of the cost of the additional processing required as yet. Any comments will be appreciated. /kim > BTW: Arc (uuencoded and probably split) will be one of my next postings... ^^^^ Glad to see that you finally got your news s/w back up. Have you actually made any postings yet ... none have arrived here. -- UUCP: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
tenney@well.UUCP (Glenn S. Tenney) (01/12/87)
On the Mac (which I too have) you point to the menu item at the
top; press to bring it down, point to what you want; release to
select. The Flight simulator is VERY different: point; click;
point; click (a 2nd time to finally select). This is very
foreign to me, and what I was TOLD was the way GEM does it. Since
I don't have an ST (yet) I relied on what I thought was a correct
association with the way GEM does it. If GEM doesn't do it
that way, sorry, but it is still weird regardless.
-- Glenn Tenney
UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney
ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY
As Alphonso Bodoya would say... (tnx boulton)
Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!billd@crash.UUCP (Bill D'Camp) (01/13/87)
[]
Craig Norberg mentioned that using compress was probably a better idea
than using arc, because more people had access to it. That must be
why he stores all of the sources in compressed files. It's also why
I haven't ftp'd anything from his sources archive lately, everytime
I do, the version of compress which I have says "not in compress format".
It does this in spite of being transferred in image mode. Anybody have
any suggestions? I have arc, and the uu twins.
--
_ /|
\`o_O'
( ) Aachk! Phft!
U
(serious self-portrait?)
Opinion? I thought you said onions.
UUCP: crash!pnet01!billd
ARPA: crash!pnet01!billd@noscpaulc@hplsdrb.HP.COM (Paul Carroll) (01/19/87)
Just a couple more (minor) gripes and bugs in Flight Sim II:
1. I just went back to Flight Sim II after about a month
and I also found the menus to be a little
distracting at first. However, after the first
use of the menus, I was able to revert back. I
don't think this is a problem.
2. I also had problems trying to do ILS landings in San
Francisco and was disappointed to learn that ILS
won't work there. I have flown down to
Champaign, ILL where the ILS does work (and saved
the airport on a data disk so I can try ILS
landings at any time). I happened to have bought
Flight Sim II for my Atari 800 about a year ago
and its documentation does address ILS a little.
Basically, it contains a tutorial on how to land
and takeoff at Champaign. What's also
interesting is that a 1976 Jeppson(sp?) Pilot's
Textbook that I have (was used for real flying)
doesn't cover ILS either. Is ILS that new
(probably wrong group to ask, anyway)?
3. The Seattle database seems to be thrown together
rather quickly. Having flown THROUGH Mount
Ranier and taxied around Seattle International, I
was disappointed when I compared this with the
other areas. At least other areas detect when
you hit the side of a mountain. Still, it was
fun to fly around Washington state.
4. A major disappointment with Flight Sim II is the
setting of the VOR's. I hate to click on the
button 180 times to get to the heading I want
(which is usually the opposite of what it's
currently set to). This is also weird since the
Atari 800 version handled this fairly nicely,
with the ability to set each digit. If there is
a way of setting the VOR more easily, I'd sure
like to know. In case it isn't obvious, I set
the VOR to headings and use autopilot so I can
fly cross-country. (Not that I HAVE to, but it
makes flying a lot easier).
All in all, Flight Sim II is still the best software I've bought
for the Amiga. Now, if Jet is better ...
Paul Carroll
Hewlett-Packard Logic Systems Division
Colorado Springs, CO
hplabs!hpfcdc!hpldola!paulcjones@dg_rtp.UUCP (01/24/87)
In article <2900001@hplsdrb.HP.COM> paulc@hplsdrb.HP.COM (Paul Carroll) writes: > 4. A major disappointment with Flight Sim II is the > setting of the VOR's. I hate to click on the > button 180 times to get to the heading I want > (which is usually the opposite of what it's > > Paul Carroll > Hewlett-Packard Logic Systems Division > Colorado Springs, CO > hplabs!hpfcdc!hpldola!paulc Try just holding down the mouse button, it should just auto-increment, be careful however you will over shoot the setting!! Greg -- Greg Jones Data General, RTP, NC ...!seismo!mcnc!rti-sel!dg_rtp!jones