shinRaiden

Link to IEEE Spectrum article about the Doppler Shift problem here. w00t! That's engineers for you. Even if he is a swede. Over half a year with substantiated data to prove that there is a class-A screw-up going to nuke all the data? Amen to Denoir's comment on competition, if you're private sector that's how to get bankrupted or worse real fast. Over here, pagers go off and they come find you. So much for vacations, you broke it - you fix it, and now. That what saved the Mars rovers. They found out they had a buffer overrun, designed their code, and flashed the memory live. Arm-chair quarterback me says nothing flys in the future without that capability. Joy. A friggin plaque. The bane of all "I-nearly-got-myself-fired-for-complaining-that-it-wasnt-going-to-work-but-I-was-righ t-all-along-so-they-sing-my-praises" awards.

Nah, it will smack into the defense sheilds, the debris will ricochet off and knock Cassini's antenna's away from Earth, and bump Cassini into terminal fall into Saturn. Yoda's not ready to be found. But it's still a tossup whether not the whole thing is going to work or not. There was a large writeup about it in IEEE Spectrum a few months back about how a critical communications module from an Italian supplier forgot to compensate for an aspect of Doppler shift. Basically, in doppler shift you get frequency shifting. They remembered to handle frequency drift compensation, but forgot that bps is also related. I forgot how they discovered the problem after launch, but they couldn't test it beforehand in the lab because the vendor didn't want to be friendly with their intellectual property. Any supposedly that's all fixed, we'll see how it goes.

Very interesting observation. I was in Japan when the Fishing-School-Tour boat got hit, that was huge news there. Given the delicate US-Japanese military relationships, I expect that a lot of naval command, especially in the Pacific Fleet got bawled out over the political repercussions. The book "The hunt for the Red October" has a lot of interesting stuff that didn't make it into the movie. Stuff Soviets preferring to skulk around on the bottom and race through canyons to compensate for American eyess-in-the-sky. The Alfa particularly was designed to go significantly deeper than other sub's, but there was plenty of incomplete engineering on that line to make it totally reliable - at least according to assumed Western standards. Other preliminary reports from this incident suggest that according to their map there was no such known seamount in the area that they were cruising in. Whether they were at normal cruising speed or not I don't know, but 30+ knots strikes me as a little fast, even if they were chasing whales for Marine Biologists. It would be interesting to know if the global tectonic deformations and polar rotation deviations as well as any other activity were partly responsible for this accident. I suppose they got a GPS fix of where they wrecked following the crash, and I'm curious to know - though I doubt it would ever be released - what if any the difference was from their projected assumed position.

Humbug. TA2, if and ever, would be a real RTS. TA already has a massive amount of modding, and a lo-impact UI. It also has intense 3d terrain simulated modeling, and advanced physics capabilities. Not to mention support for sick amounts of flash vs peewee hordes. Now that's a lag fest.

I've never seen anything like that. Can't see the contours in the WRPtool screenshots, but the missioneditor and ingame shots seem to roughly match in terms of elevation. Couple of questions: 1) What is the size of the textures? 2) Do you have any landgrid="n"; lines in your config, and if so, what is the value of N?

There has been some work on this, all that Joltan is looking for is the format to do what kegety's browser or OFPwatch do, in returning the strings and such.

They dump out black burnt pcb(?) smoke if you run them above 90f (32c) continually. Anyway, how far back were you planning to go? What's the scope on your research? CRT technology fades back into some really old and esoteric Vacuum tube history, since that's what they are. If you're looking for some light reading, send a request here. Basically though all you are doing is electromagnetically steering an electron beam into a phospher array, and that is old school. Some notes here and here and here. - edit - You're forgetting Hercules, Tandy, and all the various Composite formats. But that's just signalling from the PC and resolution on the Monitor. Well, iirc EGA used defined pixels and VGA just did streams, but that's been a while. There's also the weird component systems still used on Sun and SGI workstations as well. But all that is side-topics, such as text-mode vs graphics-mode. The best thing to have on an old DOS box was a little app that switched the console from 40x25 to 80x43, iirc on the character scale. Running Xtree or DOSSHELL in that mode was cool, and you can do it too on linux with the right boot-time params.

Story: Grandpa was a doctoral candidate in NucPhys when the US tagged into the WW2 ring. Any and all doctoral candidates got 'drafted' into research projects, Grandpa got sent to the Rad lab at MIT. He got put on a variety of projects mainly as a support engineer, IE the lab mice would create some new black box and he'd have to go test it in flight. They flew out of Boston once and flew into a cloud or something and got totally lost. I forget all the particulars of how it happened, but by the time they saw land they were on fumes and a prayer losing engines on a B-17 iirc. They didn't have enough gas or glide to make the airport, so they planned to ditch on the only place they had space, the crowded beach on a nice summer day. They buzzed the beach to warn people away, who just smiled and waved. They got the message the second time as the gear came down and they started plowing sand. As soon as they stopped, the crew jumped out and threw a tarp over the custom-built radome and grandpa, a redneck nuc engineer, had to guard it with an ax until the MP's and a gas truck showed up. Later, he got assigned to be the primary technical liason to the 15th Airforce. His supervisor handled the paperwork to get him a civilian rank equivelency pass, and stressed that Grandpa needed expedited access and transport. When he got the pass, it was stamped as a full Colonel. While in Italy, he flew several times over Eastern Europe surveying the Eastern Front as part of tuning and training various Radar systems. He got to be good friends with his base commander, who gave him the keys and a full tank of gas to any one of the former Nazi commandant's private collection of exotic cars when ever Grandpa felt the urge to take a little drive. After training the 15th AAF in their new radar systems, he was transfered to the the 8th AAF in England. They also were ferrying a B-17 with a experimental and rather tempermental radar. On test flights, Grandpa was normally stuffed into the bombbay so that he could setup his oscilloscopes and other tools, and easily access the radar in-flight. While cruising, the pilots would sometimes let him fly, and he even played with a few blind-flight radar-guidence systems. On this trip, they had special orders to fly west out over the Atlantic, far outside the normal flight path for transit from Italy to England. Later looking at the calendar explained that they were in flight during D-Day, and the southern British radar operators didn't want to see any aircraft coming in except over Ireland and Scotland. During the middle of the night, most of the crew was asleep while the plane was on autopilot. Grandpa being a scientific engineer however, relished the opportunity to play with his toys undisturbed. Adjusting the frequency of the radar system, he noticed abnormal splotching to the west. After additional tuning and analysis, he realized that he was getting a reflection off of some nearby thunderclouds. Adjusting the flight path to the west, he steered the plane directly into the center of the thunderstorm. When the radar screen was completely washed out in reflections, he grabbed the intercom from his setup in the bomb bay and yelled "ENEMY FIRE OFF THE PORT SIDE!" - just as a bolt of lightening struck nearby or on the plane. Once the crew had recovered from the 'evasive manuvers' and had woken up, they threatened risking a court-martial by practicing high-altitude bombing runs over the North Atlantic. After arriving in England, he located his cousin that he had had some rivalry with growing up. The cousin had joined the Army, and proudly boasted of the rank of a Sargeant or such, and wondered what miserable E-9 private equivelency Grandpa had been begrudged. Grandpa smiled and pulled out his Colonel's pass, and promptly ordered his cousin to be his personal driver when ever possible while he was in England. Afterwards he moved to Los Alamos NM, back when it was still only a PO Box in Santa Fe, and played with experimental nuclear reactors and high-energy systems until he retired. He'll be 91 in March, and climbs mountains every day, except when he has to shovel the snow.

Asus A7N8X-E pre-Ultra 400 (No pwr fix.) Athlon XP 2500+ Barton 11x166 (Need pull my TBird back from the family box to boost it back to 10x200.) 2x 512mb PC3200 @ Dual-Channel Soundstorm SPDIF out to SB Audigy 2 Platinum to Sony Stereo headphones and Zalman 6-way headphones. BFG GeForce 6600 GT OC 128mb AGP8x - Nvidia 66.93 drivers. 2x CTL 910TF 19" Monitors for a spanned 3200x1200x32. Custom homemade fan octopus: modified Radio Shack power adaptor feeds 2 sets of 2 adjustable speed 90cm fans with felt pads that sit on top of the monitors. Additional parts from Lowes and Home Depot. 1x Maxtor 20gb and 1x Maxtor 40gb. (Moved the 120gb WDC over to the server so that sharable data is on a dedicated server. All my OFP and VBS development files and backups and archives are on a set of four shares from the server.) Scrap Alps ps/2 keyboard (med. springs) and scrap MS PS/2 wheelie mouse. 100Mbit swtiched and cabled network across the house. pic diy

Now here's some actually useful information, rather than just rechewed cud... Calpop has a much flatter network than other large colo's and server farms, they take 2 hops where tomsyer and others take 3-4. If you had 12 hops to Sri Lanka or Beirut on the same grade line it would be better compared to 14 hops to next door. This is why you'd see a significant advantage at calpop over Tomsyer, and not from the geophysical location. The only time that physical location makes a difference is if your server is on the Moon or Mars. That said, if you want to talk to Europe, your odds of a EU-optimum are still going to be east, because that is where the trans-Atlantic trunks are. However, this is my results from my tracert run from my connection. Your milage will vary, as will the telco's interconnects. I get 12 hops to calpop, and that's with switching backbones here in Seattle. If I coulld connect on the same backbone, I think one, maybe two hops could get dropped. My suggestion is have folks from around the world ping and tracert to the various farms you're considering, and see how that averages out.

Hmm... I see an advisory to all ops experienced and otherwise on how to PREVENT a potential loophole. Thank you for your kindness in helping the community, both private and public, learn how to better admin their servers. If there is a solution, then how is it a problem? A quick question, is this on self-hosted only, or is it also present on remote dedicated? The first thing that came to mind was how if you edit a mission in the editor on an island without a properly config'd intro, preview it, then exit to the main menu, the mission continues on the main screen and you still have full mission interface functionality. I'm wondering if these two issues are somehow related, ie incomplete mission unloading and system reinitialization?

Amen to that. Better yet, put all the configs in seperate pbo's, as there will always be corrections and expansions down the road.

For 35K lines of code? Change control is hard enough with 300, it's a nightmare with 35K and fingers constantly in the mess here. I just split the main config into root classes, then split those into main groups like tanks and planes, then split those into sides. That way if you want to touch just the M1A1, it's real easy to find, and you can also look at the definitions in the All, LandVehicle, Tank, and M1A1 classes all at the same time quicker and easier.

As there is a lot of code that is not applicable to armor or ammo in the configs, I've found that it can be helpful to replace the values with variables defined in an include file. That way, you can quickly scan and correlate values across many components more easily. There are two ways to automate this, you can either #include out the values, or redirect them through variables. For example, change this block of code <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> armor=560; armorStructural=2.0; to #include it out you would replace that section with <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #include "path\includefile.hpp" and in that file you would have <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> armor=560; armorStructural=2.0; The other option is to replace the values with variables and reorganize the management in an #include'd define file <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #include "path\IncludeDefsFile.hpp" class mytank : tank { armor=MyTankArmor; armorStructural=MyTankArmorStructural; }; and in the IncludeDefsFile.hpp you would have <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> // armor #define bisM1A1armor value #define MyTankArmor 560 //ArmorStructural #define bisM1A1armor value #define MyTankArmorStructural 2.0

Tracerouting to BTL yields more interesting data. While my local ISP and BTL use the same backbone provider (Alter.net, now owned and operated by MCI Worldcom), it still 'costs' 14 hops and ~120ms from here to there. So in that case, it comes down to the server offerings and support.

In your \users\*username*\userinfo.cfg file you have two values: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> fovTop=0.750000; fovLeft=1.000000; This is set up for 4:3 scaling, which is correct for the following: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> 0640 x 0480 - VGA 0800 x 0600 - SVGA 1024 x 0768 - XGA 1600 x 1200 - UXGA 2048 x 1536 - QXGA You should adjust the scaling to 5:4, ie <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> fovTop=0.800000; for these resolutions: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> 1280 x 1024 - SXGA 2560 x 2048 - QSXGA For widescreen displays, your scales may vary. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> 04 : 03 - fovTop=0.750000; 05 : 04 - fovTop=0.800000; 16 : 09 - fovTop=0.562500; 16 : 10 - fovTop=0.625000; // 1920 x 1200 WUXGA, 3840 x 2400 WQUXGA Here are some HDTV formats, use the scales posted above: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> 1280 x 0720 - 16:9 1920 x 1080 - 16:9 But if you have a plasma screen your direct inputs may vary, unique fovTop values are listed below: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> 1024 X 0852 - .83203125 - 32" (81.28cm) 1024 x 1024 - (1:1) - 42" (106.68cm) & 43" (109.22cm) 1024 X 0768 - (4:3) - 42" (106.68cm) & 43" (109.22cm) 1365 X 0765 - .56043956 - 50" (127cm), 61" (154.94cm), & 63" (160.02cm) 1365 X 0768 - .562637362 - 50" (127cm), 61" (154.94cm), & 63" (160.02cm) Afaik you have to edit these in Notepad, there is no direct method. Some of these resolutions are admittedly esoteric, I just included them for reference. For multimonitor displays, your <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> fovLeft=1.000000; will normally equal your number of displays. The only exception to all this is if you use your displays in portrait mode, or multimonitors in portrait mode. In those cases, you would swap the values of the two fov settings.

Locating the server on the west coast does not guarantee superior performance over servers located in more competitive markets like Dallas, Chicago, or the Northeast. For example, if I traceroute the 14 hops from my DSL modem through Seattle to Blackdog's Tacticalblunder on Tomsyer.net in Fort Worth, TX, the first 8 hops are still in the Seattle metro area, and the first 7 are at the house, local ISP, and metropolitan ISP. Hops 9 and 10 are cross-metro, and 11-14 are inside the data center. This gives about a 10~20 ms ping advantage to me as there is a direct backbone link between Seattle and Dallas on Savvis. When Blackdog had his server previously on Ev1servers, the preferred backbone between here and there had an additional hop in Chicago, adding ping and lag. There's nothing you can do about the backbones, those are switched on metrics decided by the Telco's. What you can do is run a battery of traceroutes to get a feel for your ISP's connections and upstream metro providers. From there, look for datacenters that use the same backbone providers, and do traceroutes against their sites using samples from Netcraft. The next problem you're going to have is who's going to be connecting. Basing the server on the west coast could theoretically enhance your connection, although you would likely only have a single hop anyway from Portland to LA or SanFran, as you could to Dallas or Chicago etc., but would significantly impact foriegn connections, especially from Europe. You would probably have at least two hops before hitting the international demarcation points, and in any case would not be able to get as internationally friendly a location network-wise on the west coast. For an example of that, grab a bunch of server IP's from OFPwatch and traceroute them to see where the hop bottlenecks are. That can also help you position your server to maximize the gaming potential.

For the benefit of those who don't get outside their own timezone that often, here is a cheat sheet: 0800 +12 DATELINE, NZ 0700 +11 In-between islands 0600 +10 E Australia 0500 +09 Japan, Koreas, C Aus +:30 0400 +08 E Asia, W Australia 0300 +07 SE Asia 0200 +06 E. Kazakhstan 0100 +05 Central Russia 0000 +04 (Mon, Jan 10 and above) Caucus region 2300 +03 Baghdad, Moscow, East Africa 2200 +02 Eastern Europe 2100 +01 CET 2000 GMT Great Britain 1900 -01 Cape Verde, Azores 1800 -02 Central Atlantic 1700 -03 E Brazil 1600 -04 W Brazil, Venezula, Chile 1500 -05 US East Coast 1400 -06 US Central 1300 -07 US Mountain 1200 -08 US West Coast 1100 -09 Alaska 1000 -10 Hawaii 0900 -11 C Pacific 0800 -12 DATELINE For those of you who walk around standing on your heads enjoying your summery days, just add an hour to get your time to show up. Unfortunately I have other commitments that day and will be unable to make it.

1:24000 resolution (30M) USGS DEM (elevations) & DLG (topographic vectors) data will be taken offline permanently Jan 30th from the USGS bulk anonymous FTP server. If you need any raw data for map development, please contact me ASAP. I will try to get as much of the other major USMC bases as possible before the drop-date. Scavanged data: * Camp Lejune, NC : All 9 sections have 1:24K DLG road coverage. 66% elevation contour coverage. All 9 sections covered with 30m DEM data. * Camp Pendleton, CA : DLG data is useless, you'll have to find other sources for the road and building data. Full coverage in 30m DEM's for the 8 sections. * 29 Palms, CA : I'll be happy to archive data for this range, however Globalsecurity indicates that much of the terrain has elevation ranges of up to approxiamtely 1300m, so care should be exercised in mapping the area.

Some mobo's share resources between different PCI slots, putting the card in a particular slot may make it vulnerable to interference. I have system-wide issues along those lines if I have the 1394 adaptor from my Audigy2 enabled. If this is the case, moving the card or disableing system resources in the BIOS may resolve the issue. There should be a chart in your mobo manual about that. You should also check your audio configuration settings in the un-Creative utilities. Make sure your speaker settings are correct, and disable any funky EAX filters or effects, as those could also have an undesirable impact on audio quality.

How many people here use Keyhole? It might be cool to make a .KML to cover this as well.

www.jollygreen.org has two extended clips of Jolly Green Giant CSAR extractions in Vietnam.

make some dirt patches and place them across the road and other places instead of playing with the road. Gives a lot more potential variation. That would work just like the crater models.

But reports out of Acheh and northern Sumatra are still sparse... Bernama Malaysian News

That and tossing in static IP's from a non-NAT class too can add some healthy chaos to the security mix.