Mighty Drake, Inc.

.plan Archive 1998-1999

[Home][Products & Services][Contents][What's New]Send email to webmaster


Doing a little work on SDOE.  Trying to get it to compile.  Also, Micheal pointed me at a really good file synch program.

First thing, I'm going to show games that are locked or in progress.  They'll show up in the same list as open games but with a lock symbol next to them.  This behavior was in there originally, but the box was so small we were afraid of wasting too much screen space.  We thought players might get annoyed at seeing games that they weren't allowed to join.  We've learned that it's more important to show people that there is activity on the server.  Someday I'd like to show player lists and scores, but that's probably going to have to wait for Project X.

I'm also toying with the idea of showing how many games are active in the server list.   But that would mean logging into each server.  Maybe start with the one you logged into last time, and then take the rest sequentially?  Similarly, I'm toying with the idea of reading the Server Listing HTML page and parsing out the number of games in the last 24 hours (my roommate just wrote some code to do that a few weeks ago) and displaying that in the server list.  Or, finding out if that information is available directly from the server.

Most of the above is wishful thinking.  To start, just display locked games.   If the other falls out quickly and easily I'll throw it in there.  Otherwise, I'm planning on spending time on the FF code to reduce the thrashing some more.

After that, my immediate wishlist for FF would be:
Separate scale sliders for each force
Move the forces out into a I-Force Studio file (which would make the above unnecessary)

Long term wishlist for FF is adding more forces and moving the references out to the aircraft files.  The latter so that different guns in different aircraft could behave differently.  All of these wishlist items will probably have to wait for Project X, too.

Hmm, still can't get it to link.  I think Michael moved some stuff around.  Need to find out how he's doing it :-)


Well, we were going to work half a day, but Chad's brother was already here, and there were some logistic details to work out before the deathfest... :-)

I'm pretty sure that the server was set up so that player Mighty had a 1/3 damage modifier.  I would splash people several times in quick succesion, only to have them run off.  MAN, that was annoying.  Overall, lotsa fun, though.

Hmm, looking at the ngStats records:
Michael topped the deathmatch totals with 153.7 FPH
Pooooo_Finger a fairly close second at 125.2
I edged Mr Kitty with 108.3 FPH to his 104.2
So I guess my ammo was a little more effective than I imagined :-)  Michael won 12 of 24 levels.  I only won 2.  I think Poooo_Finger won 5.

In CTF, The Bruce ran away with it with a score of 307 with 14 captures and I was a distant second at 159 with 4 captures.  Interestingly, though I was second in scoring I was on the losing team 6 of 8 times.


Got image lists finished.  One thing I don't like about image lists and label lists is that I have to remember to add the LoadLabels(l_ScreenPropList); call in every screen::Init() function.  I know that's going to bite me at some point.  I can't think of a better way to handle it at this point, though.
Michael has the herding behavior working.  Very mechanistic.  We think it's going to work well.


Not a very productive day.  Working on image lists.


Came in to finish label lists and hoped to throw in bitmaps and fonts.  Got distracted when my roommate called me up to join him playing Unreal Tournament CTF.  That ate a coupla hours.  Then got bit by the Fox layout manager again. That ate another coupla hours.  Finally got it working.  Still need to hook up parmImage for labels.  And add in justify options. Michael moved stuff around yesterday.  The layout file is checked out directly to the /media/gui directory.  Apparently, while a DOS copy could write over the layout file while the program had it open, MEW refuses to.  So I had to split the screen reload into two steps.  One to close the file and the other to reopen the file and actually reload the screen.


Hooked up option display screen renderer and resolution combos.  Looks like they work
Adding parmLabelList to layout file


Went through design doc again comparing it to Fox' feature set.  Had a coupla questions and a coupla suggestions.  No major changes.
Michael was showing off some of the new robot interface.  It's looking way cool
Starting to hook up OptionDisplayScreen.  The renderer detection and selection is a mess.  But it's only accessed two places in the code and not touched very often, so it's not worth spending a lot of time cleaning up


Tabbooks loading from layout file.  We're also reading the names of the tabs from that file so they'll localize automagically.
Added some error handling so we won't crash if we don't find what we're looking for in the layout file.  Also some asserts so that hopefully we'll be able to find typos more quickly and easily than if stuff simply didn't show up
Couldn't figure out how Fox does hotkeys.  There's no documentation and no examples.   So I added a little 1x1 button with hotkey "0".  I'm using this to reload the layout file and redisplay the current screen.  This is going to make a huge difference whenever Chad wants to change the art and tweak the layout. 


Hooking up all the other controls to ppf load routines.  These rock.  Now it's just a one-line call in each screen to grab a control from this file.
Moved some cast macros from CGenericData.h into proplist.h.  Used one to fix a bug in GetIntProperty.
Moved some color definitions from GUIButton.h to guidefs.h
Moved background screen definition to layout file
Implemented GUISpinner and hooked it into layout file
Loading OptionSoundScreen from layout file
Started hooking tabbooks into layout file

Finished skating classes last Tue.  The teacher was an incredible skater, but not a very good teacher.  I think the only advice he gave me in the eight-week course was, "bend your knees."  He didn't do a very good job if giving tips and techniques on how to do what he was demonstrating.  And he didn't explain why we were doing the exercises.

Started a new skating class tonight.  This guy is much better.  "Here's what you want to do.  Here's why.  Here's how.  Try these tricks."   I still suck, but hopefully I'll suck less in a couple of months. :-)


No, we don't want to prepend gui/art.  Keep it flexible
Implemented combo boxes, sliders, spinners and text boxes.  Now things are starting to move.
Spent some time trying to figure out how to capture the slider SEL_CHANGED message and update a text box without having to derive a special version of textbox. 
Duh!  Pass in the window as the target and let it update the text box.  It feels like it's time for an afternoon nap :-)
I originally didn't expect to get to the screen layout ppf until Friday.  But the Fox controls have started dropping in so quickly that I want to get that working as soon as possible.  Michael was reluctant to let me do that at first, since it means learning how to work with ppfs.  They're a bit of a pain.  But we think we've found a good collection of layer routines to simplify things.
I have the ppf layout file working.  I just need to do a little more crash protection if something isn't there.  And add in the other control types.  Right now, all I have is buttons.


Made it in onna weekend
Moved RCSimulator\IGApp.* to GUI\GUIApp.*
Oops, turns out Michael had a couple of the affected files checked out.  I was sure I checked for that.
Descended from FXStream to work with our file system
Do we want to prepend gui/art to all gui bitmap reads?


Restricting check list box so it only changes check status when clicking in checkbox.
Turned out to be tougher than I expected.  Since a listitem isn't descended from a window, it can't capture the button press itself.  So the list gets the message, then does all the position normalization to put the coordinates within the size of the item.  That meant learning how Fox measures stuff.  For example, for the window y_pos, I usually think of storing the first line that's visible.  Instead, Fox stores a negative number showing where the scroll window is in relation to the rectangle on the screen.  Not a huge deal, but it took longer than I would have liked.

Got another irrate-sounding email, I think referring to Alien Resurrection.  The subject line was "punk."  It's interesting that that movie has caused such strong responses.

Left a little early.  Bruce scored tickets to the Stars game


<sigh> There's a separate FXxxxFrame class that draws borders.  Can't believe it took me so long to spot that.
Battled with getting the tabs the right size.  Turns out I didn't have the LAYOUT_FIX_WIDTH, etc options as defaults.  Need to define our own window options instead of relying on Fox'
Split the acutal screen instantiation function into its own file.  The correct C++ way to do this is to derive a class from CGUIScreen and override that function.   We're doing this from a static function, so it would be a little bit of a hassle to make that work.  And I suppose we can continue to refer to CGUIScreen * objects all over the place.  Still, this is the only function that is app-specific.  I think I'll leave it for now.  If we need any other app-specific functionality then it'll be easy to split that out into a new class in the future.
Starting to implement CheckListBoxes and ComboBoxes.  Fox has a ListBox class, but not a CheckListBox that I can see.  I'm thinking of writing one and contributing it.   The LGPL license requires us to publish the source to the UI, anyway.
Since we don't want to serialize the CheckListBox I didn't take the time to make it fit with Fox' stuff.  It's now drawing.  Starting to work on getting it to capture messages.
Got it to check/uncheck when clicking anywhere in the selection.  Will look at restricting it to only on checkbox tomorrow


The tabbed control dropped into the UI pretty easily.  At least it compiled fairly quickly.  But I couldn't get it to show up.  Eventually we figured out that it was instantiating a 1x1 window.
After fixing that, I still can't get it to display with a raised frame.  It looks like the size of the frame holding the tab pages is getting automagically adjusted.


Michael and I are going over the app initialization process with an eye toward making the process generic and easy to extend.
Implemented a couple of small changes that came up during this review.
Build a lookup table into the GetFont routine.  Eventually, we'll read this lookup table from a ppf file.  This way, we can easily change the font sizes for different languages without having to recompile the app.
Changed the particular files we look for when trying to verify that we have a valid installation.  Basically, Preload.ppf, ObjClasses.ppf, SoundInfo.ppf and Whodunnit.ppf
Added in app-specific stubs, WantToLaunchSim, AboutToLaunchSim, JustExitedSim, FinishExitingSim
Went over my work and research on Fox
Started attacking options screen in anger


Got transparent buttons sorta working.  It turns out the author of that class assumed that "24 bpp" images take three bytes per pixel.  Under Windows, there's an unused byte with each pixel to keep them dword-aligned.  I remember wasting a day to learn that when I first started trying to display images under Windows.
Later: It turns out that Fox is using one of the options flags to store information about the format that the image is stored in.  Apparently, PNGs always have an alpha channel.  So when I tried to tell Fox not to use the alpha it got confused about the size of the pixels.  When I displayed a 24 bit BMP it displayed correctly.
After hacking around that problem, I found that in addition to the bitmap, Fox is also drawing the gray non-bitmap button.  So when the bitmap is transparent you can see the corners of the gray button.  Oh, well.  Hopefully they'll get that worked out before we ship.  If not, we have the source and can fix it ourselves.
Looking at how to implement dynamically tying buttons to IDs.  Since the message mapping is done using the function name it looks like it can only be done at compile-time.   Michael and I decided that we'll have a lookup table that maps between them.   It's a bit more maintenance, but the number of controls on each screen shouldn't change much over time.  And the layout file will save a huge amount of time at the end of the project.


Got the first stab at going from one screen to the next working
Threw up 50 buttons as a test of speed and to test the deferred display that Fox features.  Looks fast enough
Got Quit hooked up correctly
Got background image display working.  Using programmer art, just to annoy Chad :-)
At first, I was trying to put a FXCanvas control behind the buttons, simply because I was stealing code from an example.  Michael helped me figure out how to capture the paint message in the window.
Next, I was capturing the paint message in the child class.  The only reason I had to do that was a pure virtual function in CGUIScreen.  Since that function is called whenever we switch to a new screen, putting an assert in there will be good enough.   Not quite as good as a compile error, but it's not something that's going to slip through.  And capturing the paint message in the parent class will remove a likely oversight when adding new screens.
Finished hooking up PNG support.  PNGs load a LOT faster than BMPs.  There's something in Fox' BMP code that's really inefficient.
Implemented bitmap buttons


After working on the UI framework last night, Micheal realized the integration is likely to take a lot longer than he had originally guessed.  We're adjusting the schedule accordingly.
Moved my desk so Michael and I don't have to yell across the room at each other
Deferred creation of the buttons, similar to what we did under MFC.  We've decided we don't like the implications.  Basically, that's not how Fox is designed.  It would add a lot of work for us to incorporate future code revisions from the author.   And he releases often.  So I backed all those changes out and rather than fighting the framework, we're going to use it as it has been designed.
Grabbed latest Fox code drop, 0.99.91
For some reason, the buttons weren't showing up on a CGUIScreen that was a FXComposite.   Michael and I looked at it for awhile.  Then we changed the size of the window and saw the buttons on the main screen.  Spy helped us verify that there were two windows.  Then we used the GUIScreen as the parent to the buttons and they magically showed up.  Resized the GUIScreen back to full size and it still worked.  I hate magic solutions.
Got first pass on thin wrapper over FXButton and checked it in


Micheal is done with the inset rendering, so he's helping me get caught back up. He reimplemented the command line, which also holds a lot of dynamic settings. He actually got the sim to run from the command line. When pushing the Fly button, the UI isn't getting out of the way. But the trace statements make it clear the sim thinks it's running.
I found a flathead error. The app would crash when you simply mouse over the Quit button. It turns out I was instantiating a local copy of the button, so it was on the stack and got trashed as soon as we left that function. I have no idea why the Fly button worked. Just blind luck.
Started trying to reimplement our CGUIButton behavior. Michael and I looked at it and agreed that it's just a thin wrapper over MFC and it'll probably be smarter to simply rip it out and put in a fresh thin wrapper over Fox.


Try to restore some old behavior, fight compile errors. This is going to continue for another week, I'm guessing.
Got the UI to a place where it's trying to launch the sim. But it's hard to tell what's going on when using the Glide renderer, because it takes over the entire screen. Luckily, the software renderer dropped in smoothly.
Got OnIdle support working just before I walked out the door.


Didn't make it in this weekend like I planned
Found a buried FAQ item that addresses the problem I'm having. It turns out I need to call the create() function of each window I instantiate after the app->create() call.
Now I'm trying to tie into the button push and launch the sim.
Almost there. Ran into a link error that I couldn't fix. Turns out I was editing the wrong .def file.


It's not displaying the button.  If I move the button instantiation to after the app->create I don't see the button.  I figured that out right at the end of the night.  Time to pour over the sketchy docs and figure out why.


Still plowing through compile errors. Every time I add a new CPP I get a blizzard of errors
Woo hoo!  A successful compile.  It's going to be funny watching this thing crash and burn when I throw up the first screen
Man, MFC has really woven itself into our stuff

Talked with Scoo about hosting the web site for his season as coach on mightydrake.com
Set him up with a sub-web and gave him admin permissions


Intentionally broke the app, again. Trying to get GUIScreen etc to compile.

Played a game of Age of Kings with Bruce, Scoo and Jacob.  Mo's phone is messed up and he couldn't stick around.  I'm still annoyed at DPlay.  The docs imply that it'll work through the firewall, but recent newsgroup posts show that it's still broken.   I'm very upset that it has been a couple of years since this first turned up and MS still haven't fixed it.


Successful display of a window with a button that doesn't do anything. Woo hoo!

Michael set up the Linux box with a web directory for me. I'm pointing it at the plan page on my own web site for now. I need to think of something fun to do with it.


Successful compile
Turns out we already have a bunch of #ifdefs to pull the multithreading stuff out for non-Windows environments, anyway.  So it was easy to add another test to those #ifdefs that we could apply at compile-time.
Need to add GetAppDir and GetAppName functions.
Next step is building the first screen


Stomping compile errors
I was making good progress until I came up against the need to replace MFC's multithreading.


Need to figure out if there's a way to make things like FXDECLARE generic.  I'd like to shield the low level app from the framework as much as possible
Started compile attempts
Commenting out lotsa windows stuff
Looks like this will work.  I'm just afraid that I'm going to write myself into a corner


Took a coupla days off because a friend of mine, Jean, came to town.

Then, on Monday, I had to take my cat DunnoYet to the vet to be put to sleep.   We've been fighting his cancer for the last few months.  Up until a few weeks ago his temperment had been the same as always.  Then he went downhill fast.  It was time.  I'm going to miss him.

Installed Voodoo3 to replace G200
Michael suggested I simply drop Fox into the existing app instead of starting a new app from scratch
I think MFC is woven too tightly into the current app
Yeah, they both want to be the app framework, and they both want to create the window.   Instead, I'm going to try to replace all MFC-specific calls with Fox-specific calls.  I'm also going to try to add an extra layer.  There's a lot of generic app stuff in this app.  I'm going to try to split out the app-specific stuff.   For example, we don't have pilot stats in the Project Y.  So that goes in the decendant to the class I'm writing.
In addition, there are several Windows calls we make in the current app.  For example, get current directory.  I may move those up into Fox.


Starting new project using Fox
Spent forever figuring out how to appease the compiler
Fought what looks like an unimplemented feature in Windows.   GetTextFace(hdc,0,NULL) should return number of characters to hold font name.   It always returns 0
Figured out how to load an image from a file
This guy really likes everything in his source files, including images
Started setting up Fox to be part of our source tree


Wow, I haven't had much to talk about for awhile.  Let's get to it.

The job scene
By dragging my feet long enough, I was able to get another short gig with Michael and Chad at Parsoft/Inertia Games.  I'm working on their Project Y doing the UI.   Apparently Activision owns the code to the UI in SDOE.  So we're taking the opportunity to look for a cross-platform application framework to use in future projects.

Michael had already found a site with several app framework links
Seem to be settling on Fox
Figured out how to specify coordinates for controls, rather than go through their layout manager.
fltk probably would have done the job, too.  Though it crashed on me several times when playing with the OpenGL demos
I kind of like (Broken link: http://www.halcyon.com/www3/jesjones/Whisper/Home.html) Whisper, but the demo startup is really slow.   Haven't figured out why

Arcade games
Mighty's Arcade has grown. A coupla months ago Andy and I took his Gravitar to an auction to sell and came home with a Missile Command and a Ms Pacman. Then a month later I discovered eBay and bought a Black Knight 2000 pinball. About that time Andy got in touch with a local vending company and got permission to take a few empty arcade game cases. He's installing Microsoft Arcade and MAME and building his own arcade game.

The "dining" room is nearly a full-fledged arcade, now.  Altogether, we have Asteroids, Missile Command, Ms Pacman, Black Knight 2000, a cocktail Gorf, a mostly-working Arch Rivals (basketball game), an empty Battle Toads that Andy is turning into a PC arcade game, and an empty shell to a Pole Position that was used as a trash can before we got it.

Back when Missile Command was a hot game, I managed to roll it over one time.   When I was down at UT.  So far on this one, my high score is 257k.  But that's with bonus cities at 8,000.

My BK2K lasted for about a month, and it rocked. Then it started failing. Right after kicking a ball out it would lock up. We traced it to a relay and replaced that relay. No change in the symptoms. When I discussed it with my dad his immediate response was a loose wire. So, we need to trace everything around and find that wire. Maybe this weekend.


It turns out SDOE doesn't work through Linux kernel v2.0.x.  Kegel told me ANet works fine with v2.2.x.  So I upgraded the firewall to RH 6.0.  It went in seamlessly and it worked.

As a side benefit, I'll be able to play AoE with Eric.  DPlay 6.0 doesn't know how to talk through a NAT.  With the new kernel, apparently I can get one connection at a time through there.  How annoying.  But that's Microsoft for you.  They always seem to find something to leave out.


I didn't know I was going to be a network administrator
Finally got the Linux machine set up with IP Masquerading.  The Linux community is still a bit hobbiest-oriented.  It took me a week to figure out the syntax to tell Linux that it had two network adapters.  I started to try to upgrade the kernel to 2.2.x (in order to use IPChains, the approved program for masquerading,) but the instructions I was using didn't match what I was seeing happening on my machine.  Apparently ipfwadm, the old way to masquerade with, isn't installed by default.  I eventually found the package for it.

When I finally got it all in there, I got a file system error, basically I think a cross-link.  It took a couple of hours to fix that.

Andy helped me get the attributes on the script correct.  Then it worked on the first try.  Everything we've tried so far has worked.  Quake, mail, ICQ, AIM, RealPlayer, Seti@Home, etc.  Way cool.

The newsgroups helped a lot.  The linux.redhat.* groups aren't heavily trafficed.   The comp.os.linux.* groups look much more useful.

Got the latest version of Scorekeeper for my geek box and TurboStats.  That's a lot of fun.


I got Linux running on my 486.  I decided to go ahead and upgrade the memory from 8 to 32.  Man, 30 pin 4x32 parity memory is expensive.  About 4x the going rate.  Had to buy a new NIC.  That went in painlessly.  I was having trouble reading the original NEC 3x CD-ROM, so I picked up a 24x for it, too.  Couldn't get that to work under Win 95, even after reloading Windows.  I thought about scrubbing the disk.  Per Andy's suggestion I went ahead and started the installation, and Linux was able to read the CD-ROM without any trouble.

Linux went in without too much trouble.  Got the default Red Hat 5.2 GUI to work, and then KDE.  It's slow on a 486.  Got Netscape up and running.   Noticed that the built-in web browser won't read the table I have below.  Gonna change that.

Do you have any idea how hard it is to get FrontPage to stick to the capitalization you want?  I agreed to update History in Pictures for Michael.  I edited several image properties so that the links to images matched the case of what was on disk.   Over and over, it changed it back.  Some would be okay one time, and I'd change something else and they'd go bad, again.  Finally, I started editing the html page in Multi-Edit before posting.  It was the only way I could guarantee that the case would be correct.


I'm on the General Patch Beta team.  Got our first installment last nite.   I'm going to try to get some online time tonite.

Saturday I was online.  Flew against a guy who gave me his ICQ #.  When I stopped flying for the day I typed his number in and he authorized me.  He then immediately bragged that he had rented the CD and was in the process of copying it to his HD before returning it.  He was proud to admit that he had already copied four or five other games.  Seemed to think, "I can't afford them" is a valid excuse to steal.  I tried to shame him into not doing it again, but I don't think I made an impression.

Real Life
Had jury duty yesterday.  I was among the first group picked from the main jury pool and we spent all day in the selection process.  It was for a personal injury case.   Fortunately, I didn't get picked.

About 8 years ago the plaintiff had slipped at work and messed up his back, badly.   He was very nearly bed-ridden for over two-and-a-half years.  Finally, he goes to this highly-respected back surgeon.  The surgery is fairly successful.  Then this guy heads back home (to New Mexico) and starts up a carpet cleaning business.   He ignores the doctor's repeated attempts to get him into physical therapy.  I never learned what prompted him, but the guy then decides to sue the doctor for unnecessary surgery, along with the hospital for conspiracy in allowing the surgery.


This guy should blame himself for the pain he's in today.  We was a tall guy, and obviously out of shape and overweight.  I wouldn't be surprised to learn he weighs 400 pounds.  And I'll bet if he started physical therapy today it would help him quite a lot.  It would be excrutiatingly painful.  But it would have been immediately after the surgery, too.  Rehabilitation often entails a short period of painful work before the recovery begins.

Instead, he wants to blame someone else and make them pay enough to support him for the rest of his life.  I think what the plaintiff's lawyer was banking on was the doctor had a history of cocaine addiction.  The defense pointed out that the doctor had checked himself in for treatment ten years ago and had been subject to "regular" random testing ever since.  He has tested clean.  Other than that, the doctor is a published expert in back surgery.  And I simply can't see how he can allege that the surgery was unnecessary.  Before the surgery he could hardly walk at all.

Grr.  This case fits my notion of the unjustified lawsuits brought on by today's irresponsible citizens with a jackpot mentality.

The lawyers were interesting.  The plaintiff's lawyer was actually the most impressive.  He was relaxed and able to come up with concise questions.  The doctor's lawyer seemed slightly unprepared/disorganized and repeated himself a lot.   The hospital's lawyer had a bad habit of starting to ask a question, then going off on several tangents to try to qualify the question more and more.  He was really hard to follow.

Okay, let's go back to Normal paragraphs and see how it looks.

FS:SDOE hit the shelves last week.  Haven't picked up my copy, yet.  Looks like the average of the messages on the boards are about right.  It looks bland at first, but the flight models really grow on you.  Due to the low end Activision marketing chose, we had to really keep the ground units sparse.  On a fast machine one should be able to sprinkle enough around to be interesting.

I'm really pleased and surprised to hear how much people are enjoying the multiplayer.   Since that was my first stab at network coding I was pretty worried.  I think the smooth game play is due to Eric's code and the stability is due to ANet.  And of course the scoring is Michael :-)  I'm just glad to hear that my code appears to be holding up.

Michael and I talked about writing a quick front-end to build a mission on the fly.   I was thinking of something similar to the original Red Baron.  In RB, for two opposing sides you could choose the plane types, the number in each group, the altitude of each group, and the orientation of each to the other.  That should be really quick to write.  And it would get transferred over, making for a quick turnaround.

Game Dev Conference:
That was last week in San Jose.  Unfortunately, I'm really, really bad at meeting people.  So I don't think I got nearly as much out of it as I should have.   I should be working my contacts with Michael to get to know the Ritual crowd, and Will to get to know the Bloodshot and Ensemble crowd.  Instead, I went there knowing nobody.

One very interesting group that I met on the first day was Cognitoy.  They're doing a game called Mind Rover that is very nearly a 3D version of Robot Club.  The similarities are uncanny.  They attach drivetrains and sensors to a generic body.   They have a visual programming tool.  The levels are defined in the same language that's spit out by the visual tool.

Where they're different is apparently they've spent two years developing this product, compared to the approximately 9-12 disjointed months that we had.  Also, their language is focused on this one problem, rather than trying to live two lives as an adventure game language and an arcade game language.

The short bit I saw looked really good.  In many ways, this is the Robot Club we dreamed of.

Got to see my aunt and her family while in San Jose.  They're fun people.   I should probably find more excuses to get out there to see them.

  Went to the arcade auction last weekend.  We took our cajones and a truck and bought games this time.  I got Asteroids.  Bruce got a cocktail table Gorf.  Andy got Gravitar.  I thought about getting a pinball machine.  But while discussing it with Mo I came to the conclusion that I wanted to hold out for Black Knight.  They didn't have any Missle Commands this time.
  Michael sent me the Bessie model and a Fokker Triplane that Chad is working on.  Way cool.
  Got an assert when trying to apply damage across the net on a part that apparently had already been detached/deleted.
  Found a crash where we were trying to deref through a NULL pointer when deleting an AI path
  Added an INI switch to disable chat easter eggs.   Defaults to off.
  Implemented chat egg to detach all parts
  When someone leaves the game, display a message
  When game migrates to me, reset locked flag so it doesn't show up in the game list
  Align labels
  Helped Michael track down a crash
    Something involving detaching parts.  Possibly, one got detached multiple times
  A few last bits for Parsoft.
  Fixed buglet where the squad list wouldn't stay scrolled down.  As soon as we changed a player (ex. ping) we reset the list to the top.
  Played a dozen times trying to crash network code with new non-respawn.
  Crash happened when detaching a part when remote plane crashed.  Memory usage appeared acceptable.
  Cool, my web site host answered back immediately.  He pointed out that my script had a coupla errors.  Apparently, there may have still been some vestigial pieces of the site on the old server, and that's what the script was pointing at.
  Finally getting around to building a Thrustmaster file.   It turns out, the simplest is simply to copy the keyboard.inp and edit the syntax for the TM setup.  Looks like it's going to work great.  I also found a good program called Fox Two that actually helps a lot in programming the TM setup.
  Did another 20 mins worth of work for Parsoft on Wed.  Just added a message when the host goes away so that everyone knows why they're not seeing any other planes.  Takes about 5 mins to time out, though.  Actually, it should have been 20 mins work, but with my sleep schedule I had been up about 20 hours at that point and I got stymied by silly compile errors for about 45 mins.
  Apparently, moving Frontpage to a new machine marks everything as out of date, including my Perl script.  This new server doesn't appear to provide a way for me to recompile the script, so my Thought for the Day is broken.   Just sent an email asking my host to recompile it for me.
  Went to AdLibs last nite.   Lotsa fun.  Rosy and Sylvia were late, and our table was right up front, so I was alone at the table for 10 mins.  Of course, the MC had fun with that for awhile.  "You're alone?"  "For now."  "For now, yeah right.  The women will be flocking to the table in a few minutes."
  Did 10 mins worth of work for Parsoft a coupla days ago.   Apparently, a bug report was written backwards.  We were seeing lobbies/sessions for other games using LAN protocols.  Kegel gave me a workaround.   We filter incoming sessions with our session ID.
  Got my new computer a week and a half ago.  P2/400 w/128 meg, 16 gig, TNT and Voodoo2.  Still installing stuff.
    Another Mickeysoft irritation.  I got two pointing devices.  A PS/2 trackball and a USB mouse.  But somewhere down there they go through the same driver.  Therefore, there's only one Control Panel applet, which means only one speed control.  When I get one comfortable, the other is way off.   Emails to Logitech and the USB forum haven't produced a response, yet.   Mickeysoft responded with, "Sorry.  Don't work.  No workaround."
  Successfully sending mission across
  Found out how to handle session lost.  Turns out, Activenet is returning that info in the return code, not as a packet
  Finished handling session lost.  Was crashing because we were deleting the dialog inside of PumpMessages.  Changed it so it sets a state that we can handle later
  Got mission send to compile
  Started working on sending mission file across
  Frequency of score requests based on network speed
  Keep track of who is master.  If he leaves, go away
  Hmm, somehow I was still using the mission display name when I wanted to use the filename.  Showed up in localization
  Tried catching ActiveNet's session-lost message.  We're never getting one.
  Crash when trying to join second or third server.  Turns out, I was using a list that had "leftover" sessions, then joining a server which deleted those session, and then we were trying to access deleted memory.  I have really learned that one should not alias pointers.  Pass IDs around.
  Found dupe lobby MFU.  Turns out I was forgetting to zero-fill the GUID we were testing with.  Doh!
  Implemented latest activenet
    That fixed a bug where host migration lost the locked attribute of a session
  Highlight player in debrief screen
  Ran a network game.  Man it's neat having the score correct :-)
  Sheesh!  Finally finished with scoring.  You would think we can't count.  There were a coupla problems.
    First, for single player scoring, lumping everything together in the CPlayer object works just fine.  In multi-player that was a problem.  We were having trouble splitting out AI kills and deaths.
    Also, the entire scoring thing is inherently confusing.   Each plane doesn't keep track of its kills.  It keeps track of who killed it.
  Working on scoring
  Network touch-up
    Added ping label to server list
    Added Double-click to mute/eject labels to lobby/create
    Verified that none of the missions use the wrong squadron nationality (ie, German squad for a British plane)
    Verified we handle wrong password in a reasonable manner.
      The report was you had to exit the lobby and rejoin.  Not what I saw.
    Added test for blank game name
    Found where we can see 180+terrain tiles.  We only allow for 120.
  Fixed not counting kills in Free for all (introduced to not count friendly kills)
  No longer show ??? in NW Debrief screen
  Changed names of a coupla missions
  Verified that in Straggler mission, JU-88 is banging his props on a small ridge on takeoff
    Turned out to be a bogus invisible poly
  Ordered a P2/400 from Wayne
  Went through all the missions and made sure all bombing missions had only one objective
  Verified we're acknowledging joystick calibration
  Changed win condition test so that if the player meets his objectives, he wins.  Also, don't bother telling him if the opponent met his objectives.
  Met with Buck and Andy on Sat.  Trying to map out a path
  Lazy this weekend.  Didn't work.
  Added GotRadioMessage sound
  Fixed off-by-one when returning to mission screen
  Typed up how one can kill the sub and still get "sub escaped" debrief
  Finished laying out of score
    Since we're using a proportional font, it was hard to right-justify the score.  Michael noticed that one digit is about two spaces.   So I just go through and replace one space with two.  Looks good enough for me.
  Started on in-game scoring option
  Mute in lobby
  Fixed a crash bug introduced by leaving session delta open
    Wasn't deleting sessions when going back to server list
  Fixed can't join bug introduced by server ping
    I was using the string that included the ping
  Added Server ping
  Fixed miscount in lobby list
    Was turning off session deltas between lobby list and lobby screen.
    Apparently that was confusing ANet.  Leaving it on fixed it.
  Added Kills and Score labels to bottom box of net debrief screen
  Added display of aircraft that fail CRC
  Using network-friendly CRC check
  Fixed crash bug if you Esc out of network screen
  Added wait cursor all over the place
  Rearrange how screens are painted during Init
  Bold player names in chat box
  Bold system messages that go into chat box
  Helped Michael track down area where we weren't calling idle handler during texture cache creation.  Net players were getting dropped
  Captured Top Gun screenshot :-)
  CRC check aircraft files
  Fixed leaking file handle when testing net mission CRC
  If we were more than two lines from the bottom we wouldn't scroll.  Since we can send more text than that, I now make sure we check to see if bottom line was previously visible.  If so, scroll to keep it with new text
  Found bug in mission list, display name vs file name
  Don't even list missions with too many aircraft
  Changing to reliable protocol during game setup
  Found where we're still getting into network games with no name.
    I was testing to see if there were no pilots in the pilotstats directory.  I also needed to check to see if the name was blank.  If so, default to the first pilot in the stats directory
  ping, kills, score labels
  Finished rejoin
    It turns out I was enumerating sessions on the wrong server
    Also, I was reentering when joining the session and creating the player
  Fixed dupe servers
  Kegel pointed me at how to get the current list of servers
  Got rejoin 95% finished
    For some reason, we're joining the wrong server.  I'm mimicking the behavior of the UI.  I wait for a server to come by, then I join it.   I wait for a session to come by, then I join it.
  Changed ping
    I now track how much time has passed since the last PumpMessages.  If over a threshold (200 ms) throw away the ping request/response.   Pass those intervening times to the ping routine so it can calculate the average lag inherent in this system rather than relying on a hard-coded number
  When message box is up, refresh it when updating squadron list, option list, etc
  Don't redraw lobby if highlighted.  Otherwise, if people are coming and going it would keep un-selecting, making it hard to get in
  Show ping in create/join screen
    Had to put support into owner-draw listboxes.   Hard-coded for now
  Show ping in lobby
    Don't redraw player if highlighted so we can kick if needed
  Sick for a coupla days
  When changing lobby counts, don't change order
  Sheesh, it's been nearly a month since I updated this
  When changing the count on lobbies, don't change their order
  Looked at adding ping to servers.  But they're all getting reported to me as 9999.  Need to look into that.
  Happy Thanksgiving
  Played in the annual GJ Lactic Acid Bowl.
  Good turnout.  Let's see if I can remember everyone.   Dave, Rosy, Bruce, Mo, me, Wench, Mike, Doug, Dale, Pete, Terry, Jeff, Eric, Christy, Terry's kid, Nathan, a walk-on whose last name was Gilmour, so we called him Happy.  Kathy for a short time.  Kim and Janet stopped for a few at the end.
  Played in the annual GJ Lactic Acid Bowl.  I'm way out of shape, so I paced myself.  Covered Mo the entire day.  Right at the end of the game I managed to sneak out to the side.  Mo was trying to cover two people.   Pete threw the ball to me, I juggled it, but since there was nobody close I was able to keep concentration.  When I finally got a handle on the ball the only person I had to beat was Christy.  Happy got in her way and I got around her easily.  I started to coast, when I spotted Rosy trying to catch me from across the field.  He took a dive at the five, but only got one finger on me.  So I scored my annual TD.
  Show "No squadron" in the selection box upon entry
  Changed squadron list box in create/join screens.  It is starting to look usable
    It's now a listbox, not a CheckListBox
    Using a bitmap to indicate ready/not ready.  Sort of a light on/off bolding player name
  Got a silly ICQ virus warning from a friend.  At 10:00 pm last nite Steph sent a message via ICQ that said "Don't use ICQ on Nov 25.   There's a virus that goes off that day."  Obviously, the only way I could see the message is if I fired up ICQ.  Doh!  Apparently, someone was playing a practical joke on her.
  Changed player name indent to try to make it stick out a bit more
  Dropped display of max players by No Squad
  Fixed small memory leak in listbox
  Also refresh lobby list
  Now refreshing game list when backing up from create/join
  Need a separate "not ready" that says people need to choose a squadron
  kick user option
  onFly someone not ready goes to game list
  Lock game checkbox to keep anyone else from joining
  Default to user's name for network game name
  Pilot name first time in
  From create screen, when backing out delete the session from the network's list
  Fixed double-create when creating a game
  Fixed crash when backing out of lobby list
  Update player count in lobbies as they change
      This is to give me four columns
  In NW debrief, instead of -1, put ???
  Fought a network game with Michael, probably for over an hour.
    In addition to us in Spits, there were two FWs, two Me-262s and two P-38s on AI.  The Spits are still incredibly nimble, so it was a lot of fun.   We'd fight each other for awhile, and then we'd hear the jet engines or see tracers going by.  So we'd break off and kill AI for a few minutes.  Eventually, our frame rate started to suffer, and we started seeing texture bugs.
  Chased fictitious localization bug regarding mission names
  Fixed a localization oversight in NW debrief
  Went back in SourceSafe and found the check-ins that broke networking.
    Finally figured out that when I added a new test to protect against a NULL pointer I had accidentally left a variable declaration inside the braces.   So the variable declared outside the braces was never getting changed.  A higher level function was thinking that the call was failing.  The compiler should have an option to catch that sort of thing.
  Spent the entire evening trying to figure out why networking is broken
  Put a start/stop routine in so we can turn off pinging when we're about to do something expensive, like change screens.  Otherwise, we end up with artificially high numbers.
  If ping too high, warn user
  If benchmark fails, force 1/2 realtime
  Implemented ping.
    Compared to the DOS prompt ping, we have an inherent latency of 50-60 ms, because we're only polling the ANet call 30 times per second.  By the time it gets noticed on the far side and resent and then noticed on this side we've lost a lot of time.  Hmm, I should consider looking into dpio to ping at a lower level.
  Michael figured out the lack of attribution.  It turns out the shells from the surrogate aircraft were hitting the target and were also doing damage.  About half the time the surrogate version would do a bit more damage than the network version.  Michael's going to put code in the tracer class to check if it's hitting a plane, and if so, check to see that it came from a local plane.
  Added soft max players limit that's set in the prefs
  Testing network scoring
    Not all planes got in the first time.  Jay's rebuilt the software texture cache and was weeded out.
    Not all scores getting attributed.  After a few more tests with Michael he   determined that explosions are interpreted as the plane damaging itself. If it does enough damage to itself then the score will never get attributed to the plane that actually did the damage
  Enforce limit of 16 players
  Found out we can't see Internet games.  It looks like ANet's new dpShutDown is the culprit.  When we close the lobby to create a game it's disconnecting us from the server.  Going back to the old dpClose behaves better.   I didn't figure that out quickly enough to include in tonite's build.  Got a call in to Dan Kegel.
    Turns out the not seeing internet games was a questionable doc problem.  It said, "If flags is not set to 1 then dpShutdown disconnects from the server."  The "...is not..." threw me.
  When coming back from NW briefing screen we weren't keeping the ready status
  Cleaned out several bugbugs
  Using localized string for reporting when someone is onna slow machine
  Got around to hooking up machine speed test when joining a game.
  Helped Michael arrange ANet DLLs.  We think he may have had a lib/dll mismatch
  Added arrays to really support the accessor Michael needs
    On one test, I actually got a positive score
  Got listbox with icons to highlight correctly
  Successfully checking for and handling unknown missions and failed crc
  Don't allow god mode in network games :-)
  Spent a lot of time trying to explain to Michael how the VNode stuff works.
  My little accessor was broken because I was going against the wrong array.  As we were looking at it we figured out that I'm not storing the squad/plane of remote AI aircraft. That'll likely be a problem for scoring.
  Incorporated the latest ANet build.  Runs much better than the last
  Horizontal scrolling in chat input box
  Implemented icon showing status of games in list (fast net, realtime, pwd)
  Pulled some constant strings into app string table
  Added accessor so that Michael can get the squad/plane from a VNode
  Fixed crash bug when backing from create/join screen back to internet lobby
  Spent most of the day implementing the new screens.
  Starting to add in support and display of network speed and realtime settings in the current games list
  Spent most of the day fighting mouse handling.
    Flag added our "Messageboxes" in at the last minute, and she never envisioned them needing to do anything except more than Ok/Cancel.   My edit boxes and buttons almost worked.  I could type into them.  When I tried to pass mouse moves and clicks I could shift the focus.  But they just weren't falling into place.  So we decided to split out the name and password boxes into separate screens.  The create dialog in particular had gotten pretty complicated, anyway.
  If deleting the last pilot, create a new one so we never end up with 0.
  Gave scoring to Michael.  It turns out we're getting the allegience wrong.
    When we read the mission we compare the allegience each plane to the one the player is in.  Since each local machine is keeping track of who has killed it, it thinks that every time it dies it's a negative score.  So that's what it sends out to everyone else.  We need to adjust that at runtime.
  Lots more testing
  We're shooting to clear our high priority bug list by Monday.   70-odd to start with, but most are dupes or are already fixed.  Down to 20-odd by the end of the day.  Most about networking.
  Lotsa testing
    How to combat pausing.  It's gonna happen on our target machine.
    Tried sacrificing frames. Not enough help.
    Let creator choose to run at 1/2 realtime for a level playing field
    How do we present it to the user?
    If running at realtime
      Live with pauses, or
      Ratchet down below realtime when we detect frequent pausing
      Implement a benchmark and warn people on slow machines that they're prolly gonna be at a disadvantage
    What we would really like to do is punt and require a faster computer.  But our Europe market can't handle that.
  Fixed: Only the host sees names correctly.  Everyone else sees the host's name
  Ran tests for Dan Kegel to try to track down slow ANet performance
  Implemented in-game chat
    Disappear after 10 sec
    Visual indicator that you're in chat mode
    Esc out
  Reduced min display frame rate to 10
    Tried several tests, but couldn't get valid test case
    Pausing I saw could have been due to the surrogate machine spitting out lotsa trace output
  Saw wing bending on a P38 that didn't go across
  Wrote up explanation of damage and delay for QA
  Added delay and hertz to prefs
    Host sets
    Will remove before shipping
  Chat line longer that 220 characters weren't sent at all.   Now they truncate
  OK button in NW debrief screen goes to main menu
  Reran timing test of ANet Nov build.  Even worse timings than last time with their debug DLL, 300 ms.  Swapping to the release dll brought it down to < .1 ms.
  Helped mom free up some disk space
  Ran multiplayer test
    Michael was running a debug build and got it to die in a process damage call
  Filter multiplayer out of theater list
  Working on ping
  Move multiplayer directory under missions
  Not getting plane names from bigfile
  Don't show "Artificial Intelligence" in vehicle ID.   Just blank.
  Incorporated the latest ANet version.  It was intolerably slow.  Calls to dpReceive were taking 100+ ms.  Plus, apparently their interrupt handler is similarly hobbled.  Loading a mission was on track to take 1/2 hour.
  Ran the game over the net today.  Worked pretty well.   Couldn't get TCP/IP to work through Michael's firewall, so we had to use Kali and IPX. 
  Got to chat for a minute with some Kali guys.  Pretty cool.
  Got fast network checkbox into create game popup.  Chad had to make a bigger background bitmap.  Hooked it into prefs file
  Finished vehicle ID showing user name
  Added Esc support to all network screens.  Added bonus, this adds Esc response to all screens where a text box had focus (ex. Pilot screen)
  Added fast/slow network checkbox
  Started adding name to vehicle id overlay.  Not getting vnode where I thought I would If a game has started, don't put it on the list of games to join
  WatchForServers apparently gives me the server list all over again.  So, clear the server list just before watching for servers
  Since I have found a couple of servers that work, I managed to test that backing out of create throwing people out of join.
  Also tested internet join a game that doesn't have a password
  Sending log files to Dan Kegel to try to track down why I'm not seeing lobbies in most servers.  gtest does see them.
  Implemented the host leaving and kicking everyone else out with him
  Fixed simple bug handling squadron combo in create/join screens.  If you brought down the combo and then didn't choose a squadron we'd end up with LB_ERR and consequently a look up to a NULL pointer and try to deref through it.
  Tested arming.  It appears to be consistent with single player.  But I've never successfully fired the rockets.  They always seem to fizzle.
  If there's no password on a game, don't put up the password box on join
  Oops, accessing a static through something that's inlined by default across a DLL boundary doesn't work.
  Got scoring almost finished.  It went faster than I expected.  I got to the point where I'm sending the correct info back and forth until one player quits.  My messaged IDs overlap, so the they start feeding each other bogus information.  I should be able to fix that first thing tomorrow.
  Eric implemented a fix to combat warping on respawn
  My baby bro asked to use space on my web site.  Need to research FrontPage sub-webs to see what it would take to let him do that
  Started learning about the scoring property lists.  I turns out, a plane doesn't keep track of what it shot.  It keeps track of what shot it.  So I think what I'm going to do is every few seconds I'm going to ask each plane how many times I shot you.  Take a snapshot.  That way, if someone quits I'll have my score from him current to within a few seconds.  Hopefully, that'll also let us keep track of exactly who killed who how often.
  Spent half the day with Eric researching warping planes.   He figured out that he was reading old values from the queue as though they were current.
  Added in packet serialization
  Add "Can't init network" to NetworkDialog
  Add "Changing to" to create dialog
  Check no valid game chosen on join
  Got Ready working.
  Damned CCheckListBox doesn't support tab settings
  It turns out Eric didn't realize that we were using unreliable packet delivery.  So he's not handling out-of-order packets.  At first, I thought I could do that easily, but upon reflection I don't think that's the case.
  Options on remote side weren't getting shoved into prefs object
  Reproduced "explosion on regen" bug.
    Apparently, the plane on the remote side was just disappearing without blowing up.  When the new plane is created, the old plane gets levitated to the spawn point.  (Cool to watch.)  Most times, they'd overlap and the extra plane would take damage and explode.  Even if they don't overlap, the old plane is designated as a hulk, so it has a timer in it that blows it up a few seconds later. The new plane is unscathed, since all this is happening on the remote machine.
  Sending kill list across
    We're not seeing the kill list even on the local side
  Getting strings from string tableAdded a few error boxes
    AI doesn't shoot at aircraft with autopilot turned on
      Wrong.  It was working.  It just looked like they were turning away.  Coincidence.
    When the connection is momentarily "lost" the remote machine still knows where the aircraft is.  It simply doesn't show it.   We still padlock that spot, the AI buzz around, you can F5 to look at it.
  Michael and I flew against each other for awhile.  We found out the FW-190 has almost no elevator authority.  It can make only lazy turns, and a Typhoon can easily out-turn it.  The Spit has way too much authority.   Almost any stick motion causes red/black out.
  Once we start flying, don't allow new players and don't list ourselves in active games
    Doesn't work
  Tested to verify options work.  Wasn't sure about g and torque effects
  Implemented Network debrief screen I think it works, but the sim crashes when a remote pilot ejects.  So I'm having a lot of trouble testing.
  I'm not sending the list of kill across, just the count.
  Fixed bug where I wasn't disabling all buttons while ipx name/pwd box was up
  Save network join password separate from create password
  Fixed assert when tapping <CR> in password box of join screen
  Fixed aircraft appearing on top of each other.  Turned out to be my bug.  I left off a -1 when doling out aircraft.
  Save off net options in prefs
  Save off net game name and password in prefs
  Implemented password in IPX and TCP/IP
  Lotsa testing
    Turrets - I think they work
    Verifying that AI doesn't fire at a remote airplane
    Bombs drop and keep dropping on remote side.  Flutter on remote side
    Arming info needs to be sent across
    We're regenerating sometimes when we shouldn't
      Two aircraft starting on top of each other at start of mission
      Even the junk aircraft are getting regenerated
    Need to clean up dead aircraft and parts more quickly in network game.  It's really dragging down the performance
  Fixed bug in briefing->create where we lost track of which mission we were in
  Changed buttons in game name box to ok/cancel
  Hacked in network options. I'll do it differently when I put it in the prefs file
  Implemented naming of games.  Not doing password, yet.
  Implemented IPX screen.  Took about 45 mins.
  Got brief screen to work in both create and join.  Ended up moving even more down to MissionBase.  Originally, I was planning on letting the AirplaneAssignments, etc messages run those.  But that would entail either new query messages, or sending a CanIPlay message, which would cause dupe probs.
  Doing a bFirstTime test in the fillsquadron and FillPlayerList was the quickest.
  Crash turned out to be a cross-DLL boundary problem.   The inline function calls weren't getting processed correctly.  In the past, I guess I was calling through a pointer that was already sanitized.
  Fixed a few last minor differences between using the listbox as my array and using an STL vector
  Spent all day on one screen.
    While the host player is in the briefing screen we still need to handle squadron changes.  When the joining player is in the briefing screen we need to handle option changes and the launch message.  In both cases, we need to build the chat string.  Splitting that functionality away from the UI wasn't too hard, though it took a lot longer than I expected.  And it made for some really ugly code.  I now have the pointers back and forth between the UI objects and this message handler.  Yuck.
    It turned out, handling the launch message was really tough.   In all other cases, we could handle the messages in the background while the briefing screen is up.  With the launch message, I need to get at some routines that are in GUIScreen.  But my message handler never knows about CBriefingScreen and the briefing screen never knows about the message handler.  I had to make a little object with a static GetInstance function and a virtual launch function that was called by the message handler.  Then, in the init routine of both join dialog and briefing screen they set the static this pointer to an instance of a derived object that knows how to call into the current screen to get at the launch function.  Yuck, again.
    Crash in first attempts since ripping everything apart
  Got squadron choice UI working on both sides.   Basically, it's all there except the ready checkboxes.
  Flew two network games.
    The first was 3-player+1 AI.  I was in an FW with an AI wingman vs John and Chad in P-51s.  Chad hit the ground fairly quickly.  Not sure what happened to the AI plane.  I got too low and fixated on John in my 6 and ran into the ground.  We're still losing track of dead aircraft.  They tend to hang in mid-air on remote machines
    The second was 7-player.  That was pretty cool.  I had a P-51 on one machine and a Typhoon on the other.  In the P-51 I ran into an FW.   Took me out.  In the Typhoon I ran out of ammo and was trying to ram John.   Almost got him a coupla times.  Then all of the machines crashed at the same time.  There was more noticeable warping/pausing in the 7-player game.  But it was there during the 3-player.

Anyway, it was fun.

  Gawd, dammit.  FrontPage just went and changed the cell widths of all of the left-hand cells both here and in the archive page.  Now I need to go through both of them with a text editor and fix them.  Much faster than using FrontPage.  Wonder when I'll have time.  Grr.  I hate Microsoft.
  John offered me a bonus if we ship on time.  Everyone else already had one in place.
  To that end, he has asked everyone to put in 70 hour weeks until we ship, with core hours being 9am - 7pm, and the rest we can allocate as we wish. Not a bad crunch for our industry.  It's only about 10-15 hours more than I was already working.
  Ran some more tests for Eric.  He implemented speed calculation of the remote aircraft.  He's doing it simply by finding the distance to the previous position.  Or, as he puts it, he's simply subtracting the two matrices.   That's close enough for our needs.
  John asked if I needed anything for networking.  I suggested that we find another PC for Eric, because running his tests can eat half of my day.  He said he recognized that, but that Eric feels that it would take more time for him to learn all the idiocyncracies of Windows than he wastes of my time.  OTOH, Eric commented today that he's getting more comfortable with the IDE.

IAC, John said he'd try to take over Eric's tests from me.  As a bonus, that will put John right where he needs to be to address network performance.

  Finally ripped into the squadron/player list.  Looks like it fell out nicely.  I should be able to finish the Join side tomorrow.
    I used to keep a pointer to the CNetPlayer as the data to the listbox entry.
    Now, I have an object that holds either a player pointer, or a squadron pointer.  It also holds what squadron it belongs to.  The squadron object holds how many aircraft there are, and how many are currently occupied. The player simply chooses what squadron he wants to fly in.  He gets put at the bottom of that squadron.  So the first player into a squadron is the leader.
  I may drop the idea of the host enabling/disabling AI aircraft.  I think the double-checkbox UI would be very confusing.  Instead, whatever aircraft are in the mission get flown.
    Spoke with John as I went out the door.  He agreed with me.  If you want a different number of aircraft, make a new mission.
  Fixed the crash after flying a network game.  After flying the mission we drop back to the initial network screen.  If we end up shipping with the respawn then we'll have to keep that.
  John and I flew H2H for a few mins.  I started on his tail and stayed there for a few mins.  I didn't have him padlocked, so a coupla times I lost him. I think in the end he had the advantage, and then the game crashed.  He introduced a bug in the Glide code while trying to fix Banshee support.  I think he has already fixed it.  Anyway, it was pretty fun :-)
  Well, apparently it was official earlier this week.   Zues got canned from MCI for running the Indy clan server and dialups using MCI equipment.  Bummer.
  Haven't updated for a few days.
  Got AI-controlled planes in multiplayer
  Now sending name of mission file across.  The mission files are small, so eventually I'm just going to send the mission file itself.
  If the mission file is chosen, then someone joins, they get the change mission message before the player object is finished being created.  So joiners now have to send a CanIPlay message to let the host know they're available.
  Still need to send player list
  Started doling out plane assignments instead of hard-coding one and two.  For now, just starting at the top and handing them out sequentially
  Similarly, telling all clients the vnode of the AI aircraft on the host so they synch up
  Guns coming across.
  Damage coming across.
  We have a damage modifier.  It was getting applied both on the sending machine and the receiving machine.  So we were only applying 4% of the damage.  When we applied it only on one side the target aircraft blew up good.
  We're looking forward to plumetting productivity as we play a lot of network games :-)
  Got cable router at home
    Installation should have taken 90 mins, took 3 hours
    They left without setting up DNS, gateway, etc.  But they did leave the numbers
    My first download happened to be a 1-meg file.  I almost didn't get a chance to see how big it was because it only took about 1.5 sec to download.
    Their page to add extra IP addresses was down, so I couldn't hook Bruce up last nite.  Hopefully tonite.
      Yup, the page said it should be ready in an hour
  Wigged out completely and forgot that I had scheduled lunch with Manning.  Ended up being able to reschedule the cable around lunch.  Chad and Michael were there, too.  Didn't talk about anything substantial.  Just keeping in touch.
  Got two machines to use the aircraft in a mission, rather than creating extra aircraft.
  Started fleshing out UI messages.  Got mission change.   Need to accept ack.
  Decided to send the mission every time and save it to a temp file.  Our largest is 13k, and that completely removes unknown mission and bad crc hassles.
  I keep on going back and forth from "assume it always works" to trying to set up a system where I keep track of what message I'm waiting on from which user, with timeouts, retries, etc.
  John talked about an input system similar to my command line system.  Other objects call it and tell it what they handle.  The object keeps a list.  If a new input hook shows up, it's added to the list.  The list is persistent.
  Went in for a little while on Sun, but didn't get anything substantial done.
  Started setting up messaging system between the Create and Join screens.
  Spoke with Eric about how I'm going to communicate what plane the player is in and which planes in which squadrons are AI.  He's going to call me and I'll give him a structure with the number of total aircraft, and two arrays, one being an enumeration of the squadron for each aircraft and the other being the aircraft index within that squadron.  The first plane will be the player's.  The rest, AI.
  Our bullets may not have enough punch.  And our cannon may have too much.  When shooting JU-88s, they explode nicely from a coupla seconds of cannon fire.  But when I ran out of cannon ammo I couldn't finish one off with MGs.  Our AI gets dumb after a few mins and starts flying slow, wide circles.   And their gunners aren't firing back at the moment.  So I could leisurely sit behind the target and fire only as the sight tracked across.  Saw lotsa junk flying off.  I think I had 160 rounds in each of four MGs, but couldn't finish it off.
  I was trying to get a good screen shot of the Spit and JU-88 in close formation.  Then I got the idea of doing a Top Gun shot.  But I was too close to the JU-88 when I flipped over, and I crashed into it.  We'll probably do that when we hook up machines with different aircraft.  The frame rate is good enough onna P2/400 with a Voodoo2 that it's really easy to fly formation.
  More networking tests.
    Bending working again.
    Still not perfect at destroying both planes.  But Eric thinks it's good enough to set aside for now.
  Lotsa work on UI.
    Just before leaving tonight, Michael had some suggestions on how to combine a couple of listboxes to free up some screen space.
  Flew the sim several more times.  I'm cheating by using the HUD.  Especially with the P-51.  Its wingtip stalls below about 200 kts are just too tough.  Shot down several aircraft.  I'm getting much more consistent.   And patient.
  Chad upped the firing rate.  Now, there's only about 15-20 secs of firing time in a Spitfire.  Takes some serious discipline.
  Chad also added a chevron to the canopy of the P-51.   That's a huge help in keeping track of your orientation.
  Another Chad addition is a rainbow at the edge of the world.   With the winds, you can never reach it :-)
  More networking.
    Currently working on enumerating missions and aircraft within a mission.   We're going to have a separate multiplayer directory to hold network missions.
    Currently, we don't send any ground unit info across.
    Getting better at landing and running a wing into a fence.  I think we used to send bending across, but that may have been luck.  Anyway, things fall off pretty much correctly, but bending is gone.  And when the plane is destroyed the surrogate is still freezing just before death.
    Made sure to init static vars in the constructor (CNetInfo)
    Talked with Eric, Michael and John about starting missions.  We're going to list the planes in the mission.  The host toggles them as AI or player-controlled.  Players choose their plane.  Host controls AI of each plane not controlled by a player.
  Flew the sim a few times.  Shot down my first FW190 that was set to cap, and therefore was shooting back.
  John has written some really cool additions to padlock.   It automatically zooms in when the target nears your nose, and zooms out as it goes away.  That helps a lot with orientation, but the bubble of the P51 and our head roll still makes it tough.  I keep getting to a low airspeed and the wingtips on the P-51 stall.  It's tough to get out of.
  He also added a boresight padlock, which lets you padlock a point on the ground.  I haven't tried it, yet, but it sounds way cool.  I really wanted that in A-10 Cuba.
  Lotsa work on networking.
    Implemented deleteplayer/session in lobby and create/join screens
    Eric has bending working.  Took several tries to land and drive past a fence with enough force to bend, but not to break
    But when the host plane is destroyed, the surrogate is still freezing at that point.
  John wants me to implement thaw/freeze, in case we need to keep the game respawn hack.
  Michael and I discussed how we handle weapon fire
  Took most of the day to straighten out dupe/not enough players.  The calls to PlayerExists are new, and the additions to the player map are called from a few different place.
  Emailed Dan Kegel asking for an FS:SDOE lobby server.   He said it should be up tomorrow.
  My POP3 accounts are still screwed up.  My roommates' email is forwarding to my Onramp account.  I've sent three messages over the last week to my web host and haven't gotten a reply back.
  Got the Lynksys hub.  Haven't tried plugging into it, yet.  Suppose I should try that pretty soon.  I have some class 3 cable around.   Need to go buy some class 5.  One thing I really don't like about it is the noisy fan they have in it.  That kind of constant noise really gets on my nerves.   I need to try setting up some other fan in its place.
  Luka's thyroid level was in the normal range.  So she's back on pred.
  Spent all day fighting our duplicate sessions bug.   Finally got it with Michael's help.  It turns out my less test to the map template was bad.  For some reason I had forgotten about memcpy and wrote my own.   It's embarrassing that I didn't get that right.
  Updating and adding a few links in my web page.  When I bought my printer I spotted Robot Club on the shelves.  It finally made it to the marketplace.  I wonder how well it'll do.
  Michael and I are having trouble hooking up with Manning for lunch.  On Wed I put him off to work on networking.  Today he put me off to handle a client.
    Success!  Finally!  We have two planes flying with each other.  It's incredibly smooth even across the network.  The remote plane is about 3/4 of second behind.  But Eric says that's because he hard-coded all the tuning variables for these first tests.
    I was making little progress.  When I went to get lunch, Eric took over my computer and started working on it.  He also found the code hard to follow at first.  We spent seven solid hours parked in front of those two machines until it finally started working.
    I hadn't understood what Eric wanted.  I thought all he needed was the little NetInfo structure.  But he needed the sim actually running on the PC.  I spent last three days trying to finish incorporating CNetInfo.
    It turns out Eric set it up using a token ring architecture.   That's not at all clear from the code.  But that does make some of the packet-building code make sense.  Eric and Michael believe that there's a client/server setup of some kind on the PC side, but that doesn't stand out in the code, either.  I should have asked Eric for help earlier.  I think he was irritated at the number and types of errors we had to slog through in my code.
    Because of my misconceptions, I had a lot of clumsy code in there.  Among my problems, I was running out of pre-allocated packets and trying to deref a NULL pointer.  When we start up, the second node to come up recieves a lot of messages.
    At another point, I wasn't stripping my message-type identifier on the front of the buffer before passing it on to Eric.  So it wasn't looking like a legitimate message to him.
    For some reason, operator (NetInfo *) didn't work.  It was casting the pointer to the entire object and returning that, not going through the operator and returning the member I wanted.  I had to change that to a regurlar member function.
    I have a hacked-in message for the master to tell the clients to fire up the sim.  That's happening, but we're dying at some point during initialization. Every time we receive a del_player message we crash, so we may be timing out and then hitting that code.
    Fought a coupla bugs from a few headers left over in the GameEng directory from when I was moving files around.  Dunno how that happened.   I know I specifically deleted those.
  Bruce ordered his pooter.  Need to email Z about the router.
  I ordered a 10/100 Linksys hub and bought a Compaq IJ900 printer.
    The color isn't real good on the printer.  Very orange.
    No response on web site after three days.
  Didn't make it in to work, today.
  Didn't make it to practice.  From what Bruce said, I don't think there was one.
  Did make it to the batting cages.
  Finally washed my car.  Still need to polish, wax and vacuum.
  Spent all night changing this .plan file to a table.  I like it a lot better.  Learned a bit of table arcana.  It turns out, for each cell there's a field for how many columns and rows the cell crosses.   As I added an extra column for some indented text near the bottom, all the previous rows went wacky.  Most didn't reach all the way across, even though the table width was 100%.  Some of the left-hand colums were much wider than the 0% I ased for.   I had to go back and manually set the date rows to colwidth=4 (there's an editbox in the cell dialog.)  Those nested one deep needed to be 3 wide, etc.  Only took five minutes once I knew about it.
  Spent awhile moving CNetwork and CNetInfo and a couple of others to GameEngine.  Eric doesn't want those there.  So, I had to move them back.  Not a big deal, but between DevStudio and SourceSafe it's a bit of a pain.
  Converted CNetInfo to STL.
  Found a weird leftover bug from A-10 Cuba.  They pre-allocate all of the packets at startup and keep them in their input, output and free queues.  Eric makes one call to get a packet and another call when he's finished with it.  All we were passing was the pointer to his data.  When A-10 was giving him the packet they were immediately putting the packet into the free-packet queue.  Eric generates output packets while he has that packet.  So if we were ever to use up all of the free packets we'd overwrite the one he's using.  I asked Eric to take a structure instead of just a simple data pointer.  The struct is just a pointer to his data and a pointer to a cookie for me.  When he passes it back I can use the cookie to move the packet into the free queue.
  Pulled off of dupes (that's 95% finished)
  Talked with Eric about what he needs for networking.  He has "gobs of code" to talk to a very simple struct of function pointers.   I've pulled most of the relevant source code from the A-10 code base.  Got it to compile and link.  But it has some MFC dependencies.  I haven't figured out how tightly those are wired in.  First glance, not very.
  Success yesterday.  Got to the point where as far as ActiveNet is concerned, we've started the game.  I created a session on one machine and joined it from another.  A whole lot of cleanup left, but we're nearly ready to fire off the sim.
  One thing left from yesterday was the handling of the names and sessions lists.  I started by showing the name too many times.  I can cut back on some of that by not calling EnumPlayers.  But there's more to it than that.   In trying to remove duplicate names I ended up with the problem where if two people show up with the same name I only show the name once.  I need to use the ActiveNet unique ID to determine if I already have the name.

That turns out to be an ordeal.  The ID isn't a simple int or long.  It's a 12-byte GUID-ish thing.  It's not convenient to keep that around.  I ended up having to learn the STL map collection to hold it.  Not really a major deal, but not trivial, either.  While trying to bend examples I would end up with one compiler error that extended across three line.  "You did this wrong."  Fine.  That was a lot of help.  Finally got it to compile before leaving tonight.

I made three false starts today.  Which is good, because usually I get bull-headed on just bang my head against a wall if my first try doesn't fall out immediately.  But my mistakes were basically trying to clean up my the dupes way too late.  I was trying to let the listbox drive.  No way.  I finally figured out that I need to decide very early on whether or not to keep a given AddPlayer message.  I think it's going to fall out fairly well.

  Chatted with my brother on AIM for awhile.  He seems to think I undersold myself on this job.  In general, I agree that my resume is worth more than I'm making here.  OTOH, I was hired primarily for networking, final UI implementation and force feedback.  The only one I have prior experience with is the MFC-base UI stuff.  The others I'm learning on the job.  Given that, I think my boss still got a good deal, but it's not so far out of whack.
  Found an old screengrab that Mark made.  Apparently from back when the pilot was blown around by the slipstream.  We had a pilot's head poking out the window.  Chad called it the Ace Ventura pose.  That one is going to make it into HistoryInPictures.
  Pushing on.  John wants me to get to the point we can fire up a network game.  I should be able to finish that tomorrow afternoon.
  Played softball.
  I fought one bug for four days.  A stack overflow, not something one expects to see in Win32.  Normally, it's caused by recursion, and it usually takes minutes to run out of disk space before it complains.  This was giving up immediately.  I'm embarrassed at not being able to track it down on my own. I probably would have gotten it in a day, but John insisted that I try to incorporate Activision's Netfunc C++ wrapper. With their nested template architecture, the inner workings of Netfunc extend all the way to the user interface.  They even have a global g_netfunc object that is used all over the UI code.  And again, they have so many indirections that I literally still don't know how they fill their transport listbox.

John appeared to be catching on to what they were doing faster than I, so I had planned on enlisting his help in sorting it out on Friday.  But he went back to Austin on Thu. With Michael's help, I started isolating the bug.  Eventually, I got all the way back to where we were not calling Activenet at all.  So it was definitely in our code.  In the end, it turned out that I had taken a temp array that used to be allocated on the heap and made a simple array on the stack.  I was using an Activenet constant to set the size.  It turns out the constant was 256k. Now, in today's machines that shouldn't be a big deal.  But Mickeysoft's stack checking code barfed on it for some reason.  Changing it back to a heap allocation fixed the problem.

  It was nice to get back to writing new code, yesterday.   Especially since I get the distinct impression that John is disappointed with my progress so far.
  Today, I got a first stab at chat working.  I can go all the way into the HG2 lobby and talk between two machines here.  There's some garbage at the end of the string, but that's a detail.  When I try to talk between us and their HG2 demo on the same machine, I can see a message they send, but HG2 crashes if I try to send to them.  Next, I'm going to clean up the string.  Then, I'm going to see if my toy MFC program can talk back and forth with SDemons.
  On the home front, we lost our cable on Thursday.  The phone company is digging around the neighborhood and they must have cut the line.  I didn't bother calling right away because I figured they had brought down the cable for the entire neighborhood, as usual.  Apparently not.  I tried to call them either Friday or yesterday, and their phones were apparently messed up.  Finally got someone today.   The lack of cable hasn't bothered me much, because I haven't been home much.
  Bruce has finally decided to buy a computer.  Had Manning bid on one, but he came in way high.  He accidentally include NT, which I think is several hundred dollars.  Even without that, one of our clan buddies, Malibu, can probably undercut him.  Right now, he's looking at a Celeron 300 w/128 meg, 7 gig, Voodoo2 and no monitor for about $1650.  A P2/400 is right at $2000.


  Changed combos to listboxes in network screen
  Moved instantiation of network object to the app
  Started laying out chat screen
  Got a call-back from Mitsubishi last night(!)  Basically, they're still treating me like an idiot and were referring me back to tech support.   Got through(!) on the main service line, again it doesn't look likely.
  Called TCI to ask if they have any recommendations on VCRs.   They're still acting like the digital box works by some sort of magic.  They don't know of anything that works with it.
  Onramp sees the new IP address.  Work and Zeus both see the old one.
  Took Luka off of pred.  She goes to the vet next week for another blood test.
  Finished implementing building server list with delta objects.   Currently using a timer to pump the messages.  Need to do something more general, methinks.
  Right now, I'm grabbing the server name through OnNetMessage and not admitting that I'm processing the message.  I don't like that.  I considered implementing a PostProcessMessage routine so that I could re-grab the server list.   But I'm not sure I like that, either.  We'll live with this hack for now.
  My goal is to get chat working by tomorrow.  It might happen.
  FINALLY got a call back from the contractor about the phone.  He had gotten the order on Thu and was waiting for the other utilities to mark their lines.   He's supposed to call back tomorrow with a date.  We'll see. :-)
  Bruce says I've still got pauses on the home machine.
  Got a response back from my web host saying that everything looks like it's working from his end.  He did change all of the passwords.  And it sounds like he set up a mighty mailbox instead of having that one forward.  At work, I'm still seeing the old IP address.
  Spoke with the vet about Luka.  It sounds like she might have hyperthyroidism. It could lead to heart failure, eventually.  I am supposed to take her off the pred in order to run a test.
  I started noticing really slow mail delivery (often hours.)  Onramp helped me track it to the route between mightydrake.com and onramp.net.  Asked my web host about it, and he suggested moving me to a different server.  That's been going on for about five days, now.  The web page comes up, and all the email settings appear to have gone across.  But neither of my rommies' mail accounts work, and I think nothing is getting forwarded.  Also, I can't publish anything.  I sent a message, but if he replied then it will not have gotten forwarded.
  Started suffering the Blue Screen O' Death on my home machine, yesterday.  Turns out the CPU fan was giving out.  It would run for awhile and then give up.  That threw me for awhile.  Got a new one and installed it today.

While diagnosing the problem, I reinstalled Windows.   Apparently, something got overwritten, because now I have pauses every few minutes.   Usually, this is caused by TCP/IP being bound to the NE2000 adapter, and it not being able to find a DNS server.  I checked that and that's not it.  I may have to hold my breath and install Win 98.  Until now, this machine worked well enough that I didn't feel like taking the risk.  But this pause is probably going to force the issue.

  For a coupla weeks now I haven't been able to ftp a large file up to a site.  I've been trying to upload some QW demos for friends.  I've tried WS_FTP to indyclan.net, and FrontPage to mightydrake.com.  No joy.  That might also push me to Win 98.
  Reformatted this page.  I don't like what I've ended up with.  I'm trying to mix bulleted lists with normal paragraphs.  Basically, I want each subject within a day to have some sort of marker, ex. a bullet.  And I want paragraphs
  Good and bad today.  I successfully implemented enum transports, servers and sessions. Started implementing the delta objects, and run into a documentation problem.   As usual, the info was there, I just missed it.  It was hidden in the comments to the delta structure.  I expect the first field in the struct to tell me how to interpret the rest.  Instead, the first byte of the second field (a char array) tells me.  I spent two hours pouring through the Netshell source and never found that.   That source in impenetrable to me.
  Flew the sim a few times.  Actually got shot at by a plane a coupla times. But eventually they all flew themselves into the ground.  They act as though they have no power.  But my planes climb like crazy. One time after all my targets had crashed I took some pot shots at the AA guns.  I must have gotten one hit, because I heard a crew member yell :-)
  Turns out, when the aircraft code clamps the control input due to force limits we lose the desired final control position.  The controls were never maxing out unless you wiggled the stick.  OTOH, we want to keep a slight dead zone or filter to combat jitter.  So if we're still within the dead zone we resend the last value every frame.
  Ordered a Palm III late in the afternoon two days ago and it arrived today.  I'm impressed.  I'm giving my old Palm Pilot to my roomie.  It was an original Palm Pilot 1000 upgraded to a 5000 and then upgraded to a 1 meg Professional.  I need to add a Palm Pilot page to share the nifty utilities I've found.
  Most of the day fought a version mismatch.   The project was using old anet libs and dlls.  The symptom was that some transports would come through the enumerate callback, but not all.
  Also got stuck for an hour where DevStudio wouldn't admit that it was pointing at the correct vc50.pdb, which apparently holds debug info.  A rebuild all finally fixed it.
  Finally decided that the network stuff written before I got here will probably work pretty much as-is.  They started to implement the network message handling as a multiply-inherited class.  But digging through there, that's not inherent in the lowest level stuff.  Whoever wants to get network messages can simply register a new client and that client will get them.  There may be some slick C++ way to incorporate the client into the app to pass the messages on.
  Fun stuff: John was testing takeoffs.  Getting better, but not there.  We had a line of B-17s on a taxiway.  They weren't able to make the tight 180 to the runway.   They apparently don't know that the ailerons aid turning on the ground.  So they're trying to do it with all rudder, but they're not gunning the engines.  Anyway, one overshot the runway and was trying to get back, overshot the other way and crashed into the line.  Suddenly, we heard all the "Ow! Ugh!" screams from the crewmembers of both aircraft taking damage.  A new feature we just added in :-)
  Didn't hear from the phone company.  Forgot to call until after 5:00.  Grr.
  Slow going.  Implementing UI by hand.  Ugh.
  More customer service frustration.
    Yesterday, talked with Mitsubishi customer service, finally!   It took about a week of trying to get through.  Sounds like I'm SOL on a new PROM.  I'm supposed to hear back from them by Friday.  We'll see.
    My phone line got cut when I had my sprinkler system installed.   Southwestern Bell came out that day to fix it, but they didn't bury the line.   A contractor was supposed to do that in a coupla days.  That was two weeks ago.  Called this morning about it.  Told someone would get back with me to set up an appt.  No word by 4:00.  Called again and was told that someone had gone out and "repaired" something.  But that they wouldn't have buried the line.   Supposed to hear back tomorrow.  We'll see.
  Was lazy and didn't work this weekend.
  I did set my mom up on Cyberramp (pretty low prices) so I could get her on the Access newsgroups.  In just a few minutes she had come across several postings that caught her eye.
  A breakthrough today.  I had missed a sentence in the docs that says that I have to constantly call dpReceive in order to pump the enum functions.  Now that I know it works, I can use the delta functions that they recommend.
  I wanted to stick with the DevStudio resource editor to throw the screens together and test the usability.  That seems the quickest to me.  John insisted that I go ahead and start implementing this in the UI.  Since Flag is gone at the end of the month, he's really anxious that I become the UI expert before then.
  Took a first stab at the sequence of screens.  John had some suggestions on combining a few.  Makes them less wizard-like.  They certainly break what has become the UI convention.  We'll have to try them to see if they work.
  Very little progress.  The old Parsoft ANet stuff is broken.  Didn't get updated as the rest of the system evolved.
  The very lowest level stuff in ANet is in a separate .cpp file.  It compiles, but I'm not sure how useful it'll be.  It looks like we're going to have to write this thing from scratch.  The only advantage of having the NetShell source is that we can look to it to see how to get past some of the early problems I had last week.
  Added RunControlPanel() for flag.  If we have a DX6 device, call it to throw up its panel.  Otherwise, call JOY.CPL directly.  This way, if there's a custom control panel we'll call it but we won't leave the user with nothing.  Not certain it'll come up over the game.
  Finally got the CD from Activision, but they "hid" the NetShell stuff.   At first glance it looks like it'll be messy to rip out their game framework and integrate it with our stuff.  Let's face it, it's all interface.  That means really tight ties to the framework.  We'll see.  That's what John wants me working on.
    Later: I've been looking at simply replacing the framework with ours.  That's not going to happen.  Tomorrow I'm going to look at the lower level network stuff and see if we can use that and throw out all the UI.
  I had spent some time looking at how to hook my chat into the rest of the game.   John says we need to get the requirements from Eric and Michael, first.
  Yesterday, just spent a lot of time taking chunks of the chat example and putting a C++ wrapper around it.
  Split it away from the user interface.
  Finally got chat working today.  It turns out that the dpSend function writes on 6 bytes off the end of the send buffer.  This is the Send command.  It seems mighty odd to me that the Send command is writing on my buffer.   And especially that it's writing outside of the pointer+size buffer that I told it about.
  Time to start giving some thought to the messages I want to be sending back and forth.
  Stumbled across previous ANet code in Dogfight.  Now that I know how ANet works I'm going to see about incorporating that code in place of mine.  It appears that it already has send and receive queues implemented.
    Later: That was written before NetShell was a likely alternative, so there's a lot of extraneous code.  Turns out there's very little that can be used.
    A corporate funny.

As I said on Monday, there are six people at Activision involved in the NetShell source thing.  One email on Monday said that they expected to send it that day.  It was the middle of the afternoon, so I wasn't surprised when it didn't show up that evening.

So yesterday I replied to that email, so that they could see that they were the ones who planned on sending it so quickly, just asking what the status was, explained that I had plenty to work on, if it's going to be delayed, just let us know so we can plan for it.  Apparently that caused another flurry of emails and CC's.

So today I have to call Dan about the problems I'm having, so I mention that I still haven't heard anything concrete about NetShell.   That must have caused another flurry, but none were CC'ed to me this time.

A little later, John asks, "Have you emailed Activision about NetShell today?"

I say, "Yeah, I talked to Dan about it."

He says, "Okay, you better lay off of them."

So I explain that I've only mentioned it once per day.   But with all the internal emails it appears to have been blown up into something bigger over there.  John told me later that we should be getting a FedEx with it tomorrow.

  Learned that Dan Kegel is the same Dan Kegel that practically every ISDN page on the net points to.  I leaned on his page heavily when I was researching ISDN for the house.
  Similarly, the guy creating our missions is Mark Barrett, someone I used to see a lot on Compuserve in the GAMDEV forum.  Neat to meet this guy in person.
  Another funny customer service bit from TCI.  I left a message on Monday, got a return call at 3:00 today.  Surprisingly, they believed me right away that the guy hadn't left a remote for this unit.  I expected a hassle about that.  So she said they'd drop one off.  I told her that with my universal remote in the living room, I really didn't need a another one of theirs.  I don't think she really believed me that my universal was actually able to control the new box.  And anyway, their accounting really isn't set up to keep track of who doesn't have a remote, so they're going to bring one, anyway :-)
  Over the weekend started (three or four times) toy MFC program to set up a connection, poll servers, etc.  Spoke with Dan Kegel about error I was getting with winet2.dll.   He advised that I use netshell, which is apparently ready enough for us to consider. Dan Stanfill or Abe Goldberg will send us the source.
  Update 6:00 - Amazing how many people this takes.  Looking at CC's in the emails:   Dan Kegel told Dan Stanfill who told Abe Goldberg.  Someone told Rick Baumgartner who told Trevor Snowden who told Chris Grunca to put together a code and EXE dump for us.
  Putting a front end on chat demo to show when players enter, leave, etc.  The examples I'm starting from are One Big Function C programs.  Lotsa globals.   Despite that, it's moving pretty steady.
  Has customer service disappeared in America all of a sudden?
    Called Mitsubishi.  Couldn't get through to regular customer service.  Tech support says VCR just won't work.  Won't allow 3-digit channel numbers.  This debacle has been going on for two weeks, now.  I've talked to nine different people at five different numbers.  Only one appeared to understand how the VCR worked and what I was talking about.
    Called Home Theatre for assistance with the Mitsubishi mess.  No return call.
    Called TCI.  Apparently they didn't leave a remote.  No return call.   Another case of treating the customer like an idiot.  When the first guy "installed" digital in the rest of the house, that consisted of plugging it into the cable outlet, the power outlet and running a phone line.  When I asked to get one more they insisted that a technician had to come out and install it.  They would not simply drop off the box and let me do it.  The room was already wired and a phone line happens to run right next to it.  Grr.
    Called MasterCard to find out why my card was being denied.

"It showed a lot of activity."

"How much is a lot?" asks I.

"Seven charges between Aug 7 and Aug 28."

"One charge every three days is suspicious?"

  Worked on networking all day.  The ActiveNet docs are really bad.  I really could have used a very simple step-by-step description of a few most common scenarios.   Specifically, where does each piece of code reside.  It's really unclear how they envision this to work.  Even better would be if they were to put one more layer over top of the dp lib to make the calls simple.
  Another tip from Robert Dunlop.  Look at the effect info for DIEFT_POSNEGCOEFFICIENTS to see if it supports the positive and negative fields
  Tested a running average on forces I get from Eric.  Put in 3 and then 5 samples.   It only helped maybe a teeny bit, and I felt it added lag, so I didn't check it in.
  Implemented change suggested by Robert Dunlop in rec.games.programmer to fix SW jitter problem  The example uses the DIEP_START flag when modifying the effect.   That causes the motor to stop and restart
  Found bug when taking control of a crew position
    We weren't releasing control of the previous position.
    When taking control, go through and remove control elsewhere
    Still have some pathways that don't turn off the effects
  Test FF in options screen
    Swap axes (FS has it also)
  Implement self-center when not applying control forces
  Figured out that CH has a strong motor and is sloppy.  Probably still need to smooth over three frames or so.   Don't want to overdo it, or there will be lag
  Began work on multiplayer layout
  Explored constant force.
    Too much trouble.  Handling CH vs SW is easier.  Went back to spring force
  Implemented switch between CH vs SW field interpretation
  If input init fails the renderer pointer is uninited during cleanup
  Grab sdsim.def when flag checks it in
  Hook up preference for CH vs SW
  Hook up pref to disable force feedback
  Had dinner with mom
  To do:
    Turn off FF when you jump out/crash
  John brought in a Sidewinder FF stick.  Seemed good at first.
  Installed and tried out FS 98 with FF.  The forces are way too tardy.  At least 1/10 second and probably more.  They also don't match the actions of the plane very closely.  Later, I think I found out why.
  Found the spot to implement force application every frame.
  Noticed a jitter in the SW FF in SDOE.  Started tracing out force values.   They looked okay.  Switched to toy test program and found out the horrible truth.  The SW FF appears to turn off the motor every time it recieves a modification to an effect.  Even if you're sending the same value over and over, the stick jitters.  I've tried using the Spring and Constant Force effects.  Identical results.  I'm posting on the newsgroups to see if anyone is aware of a workaround.
  I also determined that the SW FF and the CH ForceFX interpret some of the DX fields differently.  Fortunately, the workarounds to this are fairly straightforward.
  Look at EnumEffects to decide whether to apply forces to rudder pedals
    John decided we shouldn't bother
  Set guns to continuous and turn off.  Paired them up with sound
  Finished implementing passing through two separate gun forces.
  Correct typos in contract
  Add runtime switch to disable force feedback.  Not hooked up, yet.
  Got a three month gig at Parsoft.  Started Tuesday (today's Sat.)
  Spent last weekend between interviews looking at Activision's ActiveNet.  Basically the same thing as DirectPlay.  Though the Game server/Lobby terminology is different.   Not certain if that functionality is different.  I don't like how I '76 implemented their network screens.  They don't show enough servers at once.  And there's no convenient master server list to go against.  Several other nits.   Setting up the marshaling area is the big job I have coming up.
  But this last week I've been working on force feedback.  Played with a toy program for a coupla days.  Got it into the game in a day, though it didn't feel right.  Today I went back to my toy and figured out how to set up the DX fields correctly.   Now it feels pretty good.  A B-17 is a heavy mother and the P-38 never comes close to maxing out.  I'm using the ratio of forces coming in from the control surfaces to the max that a human can exert.
  Actually, getting force feedback in the game in a day is a bit of a misinterpretation.   They had a stub Force Processor that was never getting called.  That would be the Correct Way to do it.  But that sort of architecture has three or four levels of indirection, which makes learning it time consuming.  John said that if it were three months ago, we'd do it right.  At this point, finished albeit a little brittle is Good Enough.
  One thing left to do is a result of not doing it Right.  Currently, the only time the joystick force is updated is when the user moves the stick.  I still need to find a place to update it continuously.  For example, if the user pulls the plane up into a stall, the force on the stick should slack off as the plane slows.  Right now, it doesn't do that.
  I also need to explore how to do the gun shake differently.  Currently I keep sending Start commands.  That causes a bit of stutter that shouldn't be there.   I need to start it up for infinity and send a Stop command.  Fortunately, I can just buddying up with the gun sound start and stop.  Everywhere the player is in control and we play send a command to the sound, we also send one to the gun.  What could be simpler?
  Met Manning for lunch.  Talked about cars, planes, a little about how Videotex has dropped software development completely.  They're selling mostly non-linear video editing systems.
  STL has been going slowly.  Per Michael Harrison's advice, I'm using the SGI STL, specifically the STLPort version.  Couldn't get it to compile in VC 5.0. Watcom would compile, but the program crashes (doesn't appear to be tied to STL.)  Found someone else in the newsgroups with exactly the same error messages I'm getting.  Eventually, he wrote back saying that the problem had to do with a namespace decision in this version of STL.  He said to look in config.h and comment out #define __STL_USE_NAMESPACE_FOR_RELOPS.  That appears to work.  So now I'm on to actually playing with toy examples.  I'll submit a bug report to STLPort and see what they say.
  Met exterminator in the morning to treat for termites.
  Re-fixed A/C condensation mess over garage.  Long story, but the gist is that the drain pipe from the condensation pan is nearly clogged, so the pan is overflowing onto the ceiling and from there onto my car.
  One roomie brought a kitten home six weeks ago.  This weekend my other roomie brought home a puppy.  Current count, four cats and a dog.  I'd say we have too many animals, now.
  Started teaching myself STL.  Should have done this months ago.
  I'm making most of the clan practices, but they're not helping much.  A couple of our players have bot-like aim.  They consistently nail dodging players from across the room.  In a 3v3 practice match InjunBen usually scores more than the lower four players combined.  We're superfluous.  Just targets.  And there are a couple of others that are nearly that far above us.  I've suggested that the good players spectate and give pointers, rather than simply killing us for forty minutes.   I have a feeling that they don't have the patience for that.
  Had a clan scrimmage last nite.  Man I suck.  My high score for two games was -1 (that's negative one.)  Every time I went for a decent weapon, I died.   Team play is a very different game from FFA.  I've searched out a few servers that have the competition patch and plan on trying to find some pickup games.  Also, I'm going to try to play a lot of CTF.  Finally, Zues has instituted a practices three times a week and requires everyone to be present at two each week.
  Ordered Unreal and it arrived today.  It runs on my machine, and it's really pretty.  But a P166 sans MMX isn't enough machine for this game.
  I forgot to mention some feedback I've gotten on my site.  First, there were two people who found my ricochet articles.  One was in a class at some Nintendo-sponsored trade school, and it sounded like the articles helped him.  That was cool.  Then last week I got a message about my movie reviews that was titled: "HOW BADLY YOUR'E REVIEW SUCKS" and started out with "YOU FUCKING IDIOT!" and went on in a protracted ad hominem attack.   Apparently this woman thinks that Sigorney Weaver is God and really took offense to my Alien Resurrection review.  I crafted a level-headed response and in the end we agreed to disagree.  So I guess my approval rating is riding at a shaky 66% for the time being :-)
  Forgot to mention that I visited Parsoft again last week.  Michael showed me his latest.  I still think their texture artists have produced the best WW II plane art that I've seen.

One fun bug he mentioned had to do with their pilots, now installed in some aircraft.  He said that the pilots are made of cylinders, so that when they fall they exhibit an appropriate response to real aerodynamic effects.  What they neglected to take into account is that the structures of their aircraft don't block the airflow.  So the pilots in the plane were subject to the airstream.  He said pretty quickly, the arms would be above their head and flopping around, and eventually would take enough damage and fall off :-)

We discussed how things are going.   From what he describes, their engine and tools are largely finished, and they work well.  Therefore, the technical tasks of adding new aircraft and other objects and systems and their behaviors is moving along faster than they anticipated.  Most of their roadblocks are now logistic problems with outside organizations.

For example, Michael is trying to find information on the instruments used to monitor the engines used in the P-38 (Parsoft is dedicated to providing a very high fidelity sim.)  The original manufacturer doesn't have the info, because the government had them destroy the blueprints and tools not long after the war.  One government office may have the info, but they refuse to work by email, fax, nor phone, but rather require snail mail corespondence.  So a week after sending the letter, Michael still doesn't know if this is a valid lead.  One good source for that info would be the Confederate Air Force.  So far he's not gotten a response from them.  I have a friend who has a friend in the CAF.  Typing this entry reminded me I need to chase that down for Michael.

  Played softball against the (Some Religious Organization) Trophy Hounds.  And the name fits.  The only reason it was a close game was they only had nine players and late in the game we got lucky and hit the gaps.  If they had had ten they would have crushed us.

After the game I asked them what league they signed up for next season.   They responded that they belonged in D league.  Um, no.  They have six or seven people that hit at least 200 feet consistently.  Those aren't D league hits.   And then when we backed off, they pounded grounders through us.

Apparently there's a B league team, because they said they got run-ruled twice.  Great.

The final score was 19-18 or so.  We went into extra innings, and I had an uncharacteristic choke and tipped the ball.  Overall I went 1 for 5.  I had two solid line drives, one of which the center fielder misjudged, but somehow stretch-armstronged it and snagged it way over his head.  Two popups when I tried to get fancy and place the ball.

My fielding was marginal.  The outfield did a bad job of throwing to empty spots in the infield.  One or two of those I should have had but didn't quite get.  Caught one hot line drive near the end.  But it was a lucky catch, because I took my eye off it just before it got to my glove.  I'm doing that a lot, lately.

The final play of the game was a sharp one right over second base, which I dove for (my new kneepad saved my knee.  I will give no more blood to this game :-) and again I took my eye off it at the last instant.  My glove was exactly one ball diameter off the ground, so it tipped my glove on the way by.  They had two outs with runners at 2nd and 3rd and I might just have been able to catch the batter.

We all need more practice.  Our outfield let the wind carry several over their heads early in the game.  Toad pitched well, especially considering the ump was calling them really tight.  Walked a couple during the game, and then I think only one in the extra inning when they started with a 3-2 count.   Anyway, this is the last game of the season for me.  I'm out of town for all of the makeup games.

  I have a rant:
    I first heard about DIVX a couple of months ago.  For those who haven't heard of it, DIVX is a new video disk format that builds on DVD.  Unlike DVD, DIVX is designed as a pay-per-view system.  You buy a disk, and the first time you play it a timer starts and you can continue playing it without any extra charge for 48 hours.  After that, you have to pay again to watch it.  Your player dials a central office every couple of weeks to report what you've watched and when and charges your account.  For more info see http://www.bandivx.com/
There are many problems with this system:
  • The player is $100 - $300 more expensive than DVD.
  • You have to run a phone line to the player.
  • DIVX is not slated to release letterbox versions of movies.
  • The entire meter-is-running mindset hassles.
  • Not all disks can be converted to infinite play (Silver DIVX.).  Some will remain PPV forever.
  • Even after being converted, Silver DIVX only applies to one account.  On someone else's player it'll be PPV again.
  • Off-the-shelf infinite play disks (Gold DIVX) on any player will be more expensive than current DVD for purely greed reasons.
  • Price of first 48 hours is more than current rental prices.
  • For privacy-paranoid people, viewing habits will probably be tracked and used for marketing.
  • This pay-per-use system would likely migrate to audio CDs and computer software in the future.
  • Used DIVX disks could be kept and rewatched for a price, but will more likely be thrown away, adding to the landfill problem.

Basically, it'll be more expensive and more hassle.   There's exactly one upside.  If you "rent" a DIVX you don't have to return it because it'll simply expire.

Every poll I've seen shows people are over 90% against DIVX, and most show over 95% against.  Almost nobody wants it, yet Circuit City is arrogant enough to think that they're going to ram it down our throats anyway.

In a VHS/Beta-type race, DVD has already won.  There are a couple of thousand DVD titles available at reasonable prices, and available for rent for less that the cost of DIVX.  And dozens more being added every month.  I find it really disappointing that some of my favorite movies (Aliens, Star Wars, Raiders of the Lost Ark) are being held hostage to a losing format.

Last year I think I spent over $1000 at Circuit City.  I have decided to take my business elsewhere until Circuit City abandons DIVX.  I also intend to explain DVD vs DIVX to friends and family and recommend that they also boycott Circuit City.  It's not a hard sell, since everyone I know who understands the difference is against DIVX, even if they don't plan on purchasing a DVD in the immediate future.

  Had a clan match last night, and I sucked.  I think my frag ratio was about .01.  In the first game I had 4 (four) frags.  8 in the second.   Pathetic.  It seemed like every time I came up against someone with a lightning rod they killed me with just a touch.  I hold my own in FFA, but I seem to embarrass myself in team matches.  Part of it is not knowing the levels well enough to instinctively find the health and armor.  The funny thing is that Bruce took over the third game, because it was on his favorite level.  We were completely wiping the floor with their faces, when they declared victory.  They said they play best of two and add the frags for both levels to decide the winner.  Huh?  By that criteria they one by a single frag.  So we're going to rematch them next week with our strongest players and put an end to that nonsense once and for all.
  Getting a handle on the keyboard interface.  Right now it's basically set up to be called once per frame to test against a bool table to see if a key is down or not.   I'm trying to decide if and how to implement a keyboard handler that lets us call back into the app on a keydown/up event.  I should probably put the key->game function layer on top first, and see how that works out.
  We're all still leery of Red getting out of control.  I'm lightly pushing for another intermediate step beyond P1.  Some game that's releasable, but far less ambitious.  That way, we'll have a lot of the tools and systems in place and we won't have to invent those wheels at the same time that we're trying to take on the really hard parts of the game we really want to do.  I threw out four brainstorming ideas, but haven't recieved much response, yet.
  Finally got to play softball.  Lost 22-17.  We kept up with them pretty much the entire game.  I don't stoop to vulgarity often, but they blew Satan prior to that last inning.  Their pitcher always bloops it to short right, so Mo and Rosy cheated way forward.  So tonight he pounds his first line drive in three seasons.   And a few others had a similar inning.  I made one embarressing fielding mistake, where I didn't get in front of a hard grounder, and let it under my glove.   I know better than that.  I hit three solid line drives.  On the first, I hustled to first base and made the turn and watched the ball hit the heal of the outfielder's glove and bounce up his arm.  So I went for second and opened my knee in the slide, as usual.  Rosy worried us one time.  He was overthrown at third, so he went for home.  But the ball hit the fence and stopped and so they had plenty of time to make the throw.  The throw got there, but the catcher bobbled it, so he made it.  Our new shortstop, Frank, hit three taters in four at-bats.  The last was an exciting two-error set of bursts from base to base.  And Jay had a good night, one line sharp drive that the shortstop stole from him, and later a shot just fair of the left-field line for a stand-up double.  And Toad got a decent line shot that made it through the outfield gap for a home run.  I forgot to ask if that's his first.
  Our clan finally had a LAN party on Sat.  It went pretty well.  We had Zues, Poultry Boy, The Bruce, Sparky, Duwa Ditti, me and Nrgizer, who was in from out of town and didn't have a computer.  Learned that Sparky is a keyboard player, so we all encouraged him strongly to learn mlook.  Learned that Zues doesn't strafe, which is astounding considering how well he does.  Mo didn't make the LAN party, so we didn't have his loud comic relief, though PB gave up his machine to Nrgizer and we learned that he does a Flintstone run under the desk while playing.  Dinner at Texas Land and Cattle was good.  Nrgizer ended up sleeping at my place and almost overslept, but he made his plane.
  Finally got the palette right in the MGL build.  Still no joy on the DIBSection version.  I hate the Windows palette manager.
  Still need more cleanup on the keyboard handler.  It's a mess.
  Went to Speed Zone with Wench a coupla days ago.  Did two laps around the Grand Prix course.  52.xx the first time, and 47.xx the second.  The sims really helped my ability to look ahead and judge how I wanted to group corners together.   The one multi-car race track we tried gave almost no opportunities to pass.   Bruce says the slick track is better.  But the real blast was the dragsters.   In case you've never seen them, they're on rails, so there's no steering.  And they have an auto-brake system after the finish line.  All you have to do is watch for the green light, stomp on the gas, and hit the shift button 1/4 of the way down the track.  In those three seconds you hit 75-80 MPH, and it took all my guts to keep the gas down all the way through the finish line.  That braking area looked really short.
  Met with Andy for the first time in weeks.  He says sound is ready for integration.   He's going to start working on the scripting language.  We discussed some of the facets of what our scripting language needs.  We need a dirt-simply low-level way to create an object and move it around.  But we also need a higher-level layer that will probably be basically an event-catcher.  And another division is initialization.   That should probably be an entirely different syntax.  At LTI it seemed to me that mixing the init stuff with the main loop script led to lotsa tight coupling and hard-to-maintain code.
  Softball was rained out late in the afternoon.  Bummer.
  Played a makeup game yesterday.  Lost 11-9 or so.  Man am I out of shape.   I'm still sore.  We had four no-shows, two of them last-minute.  We got enough ringers, but had to shuffle people around.  I was catcher.  Only had one real chance at a tag and Bruce overthrew me.  I hit two choppers and a blooper to short right.  They only had nine, and the right line was wide open.   But I couldn't put it there.  Just before I went up my last time I said, "We don't have to worry about a double-play.  All of our team can beat it out."  So I hit one straight to short and didn't have the energy to beat it out.   How embarrassing.  Mo twisted his back funny while base running and is prolly out for a few weeks.
  Been incredibly lazy the last week or so.  Got Starcraft and am up to the last Terran mission.  They were pretty easy up until this one.  As usual, I get too complacent with the low-level units and don't bother learning the advanced weapons.   Up until this mission, that worked fine.  I was able to sucker the computer into fighting on my terms.  I'd pick off lone units or bottle their attack with the terrain so that I could get more units on them than they could get on me.  But now it's kicking my butt with lockdown missiles and cloaked units.
  Softball:  Rained out last week.  Got our butts stomped 17-2 this week.   And this team lost by the run rule their last game.  They made a couple of mistakes in fielding, but most of their team hit really well.  They had three or four line drives that carried forever.  Looks like we have two trophy-hounds in our league this season.  I had two solid base hits right up the middle.  On the second, Scott grounded to third.  He must have bobbled it, because I was able to slide into 2nd (ripped open the knee again.)  I bobbled a couple of throws in from the outfield (I do that too often) but did manage to make a couple of infield plays.  One was a lucky stab at a blistering grounder between me and 1st.  Toad pitched the entire game and did a good job.  He did suffer one brain fart while on 2nd when I was 3rd base coach.  Fly ball to semi-deep left.  I had told him to come half-way if it went to left.  Upon the catch, he took off without tagging, and my screaming, "Back!   Back!" didn't get through.  I also sent Gary home on what I thought would be a close throw.  It wasn't as close as I thought, and the throw was on target.  Oh, well.
  Still not productive.  Too much time reading newsgroups.
  Got ExDawn to work with MGL's Bounce demo.  Palette is still wrong.  That still leads me to believe an order of operation problem.  Or, I have an #ifdef mistake.  I'm going to clean this up.
  Need to force myself to play with some of the other 3D libs.
  I've been remarkably unproductive the last few days.  Fighting palettes in Windows.   I'm not trying to do anything fancy, so this should be fairly straightforward.  It might be an order of operation problem.  But the code is so ugly and hacked that I think I'm going to give up on this version for the moment.
  Finally got most of the MGL demos to run.  Some sort of compile error for the MesaGL lib.  Haven't bothered to figure it out.  I'm just going to use one of the 2D blitter examples and plug our stuff into there.  Looks like it'll go in easily.
  Next, I'm going to step back and see if I can encapsulate ExDawn into something approaching a lib.  Try to figure out how to generalize the init to work with the different blitters more easily.
  Found a GPF in Windows that doesn't appear to happen in DOS, when we pass outside of the map.
  Won our first game of the season.  (Actually, our first was rained out.)  I got three doubles (okay, two were errors.)  Bruce got two taters (okay, one was an error.)  Final score 18-11.  We batted around the first inning, and then were a bit slow the rest of the game.  Ripped open my knee sliding into 2nd, as usual.
  My roomie's 30th b-day party.  Saw several ex-GJ (Grand Junction Pizza) people I haven't seen in a year or two.  I scored the best time in Win, Lose, or Draw by evoking "Periodic table" in 15 secs.  I can't draw worth a damn, but I'm very good at getting an idea across.  I would have gotten "Amistad" as quickly but the other team refused to let me use the black marker because I had to go into the other room to get the marker :-)
  Playing with getting the palette to the screen.  Both SetDIBColorTable and SelectPalette/RealizePalette.  No joy, so far.
  Getting keyboard support in.  Using OnKeyDown/Up.  Not getting the arrow keys, though. This is good enough for my rough tests.  When I want to go farther I'll first learn DInput.
  First face-to-face meeting in a few days.
  Discussed Forrest's other time commitments over the next few weeks.
  Discussed keeping detailed timesheets as a personal tool to monitor our own productivity.
  Trying to reconcile "creative environment without deadline dates" vs "project management."
  While skimming other examples that use CreateDIBSection it jumped out at me that I was forgetting to initialize the biSize member var.  Doh!  I find it unconscionable that MS doesn't return an error code for this type of very common oversight.
  Got ExDawn running in Windows, upside-down with the wrong palette.
  Still battling CreateDIBSection.    It turns out I was misreading my debugger.  Both the return code and the bits pointer are NULL.  Still no answer from the newsgroup.
  Just before giving up I downloaded MGL.   Turns out it's they've decided to release it free, including source.  I tried to figure out how to simply stick the MGL init in place of my code that uses CreateDIBSection, but the example I was pulling from was too complicated.  The demo is designed to be much more robust than I care about right now.  I'm going to try to compile their demos as they are and then start pulling out the pieces I need.
  Non-programming: Worked on taxes.  Took awhile to figure out how to get MYM 12/DOS to print the category report I wanted.
  Pretty much all non-programming today.  I don't remember getting anything done after the clan match.
  Had a clan match.  My roommate played the first game in E1M2, and it was close.   Near the end we camped in the RL room and kept them at bay.  My feeling is that the RL room in that level is very vulnerable.  One person firing rockets as cover for two to lob grenades could easily clear that room out.  I played in the second game, their level choice..  I don't think anyone camped, yet we won resoundingly.  Something like 150 to 30.  Then after the game we formed a human stack.
  Got squirrels in the roof, again.  When I first started asking around I had trouble finding advice that I believed.  So here's what I learned from Michael Bodan, a pest guy in Plano 972-519-0355.
  • Get a trap and bait it.  He has this goop that he sells that works well, plus he says you must have nuts since squirrels are sight feeders.
  • When I caught a squirrel the city of Richardson transported them to an animal preserve of some kind up in McKinney.
  • Reset the trap.
  • Now here's the real trick.  When you think you've got them all, staple one layer of paper over all of the holes they squirrels might be using.
  • If they punch through any of the papers, reset the trap near that hole.
  • If the paper stays intact a few days then you're probably done.
  • Plug up your holes.
  • Make sure to check the spots where two angles of roof come together.  I think that's what happened to me this time.
  • Funny aside:  In addition to the squirrels, last time we caught three birds, plus the same bird twice.
  Got around the OnIdle stuff by making the dialog non-modal.  Someone in a newsgroup pointed out that the app never got a chance to start its message loop.  Doh!
  The rendering code appears to run.  At least, there aren't any GPFs.
  Can't get CreateDIBSection to work.  It's returning NULL for the bitmap handle, but what looks like a valid pointer for the bits.  GetLastError returns 0.  I've never seen GetLastError return information that helped solve a problem.
  Visited Michael Harrison at Parsoft.  They're doing some really neat stuff.   Their physics engine is incredible.  He described how Eric has a little test model he plays with.  Basically, he took a box, put some wheels on it and set it on a roller-coaster-type track.  Without any modifications to the code, it behaved pretty much like you would expect.  He also described how thoroughly they're modeling airflow around every foil and surface.  The example he gave was that Michael implemented rockets about the same time that Eric implemented damage caused by G-loads.  So the next time Michael fired a rocket it set up an oscillation in the wing that ripped it off.  We're talking modelling so accurate that they have to deal with real-world interactions.  Most impressive.
  Got it to compile in Windows, MS VC5
  No blitter, yet.
  Trying to fire each frame (sans blitter) in OnIdle, but it's never getting called.
  Fixed the res change.  Found an uninitialized variable in the original code.   I know optimization nuts will disagree, but I strongly recommend that you always init variables when you declare the variable.  Example: VBE_vgaInfo * pVesaBuffer = NULL;
  Non-programming:  Lunch and dinner with my brother.  He's going to Germany
  Added a keyboard layer to get Watcom-specific #ifdefs into one place
  Changed main to call init, run, close in anticipation of porting to Windows
  Somehow broke the res change
  Something broke the DJGPP debugger
  On-the-fly res change in DJGPP only
  Rough port of Extrinsic Dawn to Watcom
  Unable to get it to work with the Watcom debugger.  Didn't think of trying a toy program.  First thing to try next.
  Checked newsgroups.
  Fiddled with web page.  Accomplished nothing.
  Checked newsgroups.
  Installed full version of Worldcraft.  Man is it slow with the the demo levels.
  Got an unusual amount of email.
  Fiddled with web page.  Still looking for a background and logo that I like.
  Spent forever getting Wench's single email to download.  Wonder if the slowdown is related to the Windows NT crashing that was reported in the news?
      This is to give me four columns

Please email comments, typos, errors, dead links, and any suggestions to webmaster@mightydrake.com. (Privacy statement)
Copyright 1997-2007 Mighty Drake, Inc. All rights reserved.
Last modified: September 24, 2006
News feed
Best viewed with: Hosted by: Composed with: In association  with: Fight Spam
Opera Mozilla
Microsoft Internet Explorer Netscape Navigator
Site5 Microsoft FrontPage Amazon.com Spamcop.net Popfile
Opera or Mozilla or Explorer or Netscape Site 5 FrontPage Amazon.com Spamcop.netPopfile & Greylisting