Stuff I've read lately

"Rainbows End" (Vernor Vinge) - Vinge hasn't written a lot of stuff. I've read his far future stuff (A fire upon the deepness in the sky), which is pretty good. This book is much nearer future. Wearable computing is nearly ubiquitous. And medical technology has gotten pretty good (the "heavenly minefield" as Vinge calls it). The book follows several viewpoints, but the key one is an Alzheimer's patient recently cured. He is trying to adapt to the new culture, and restore some of what he's lost (as well as finally maturing!).

New Stars Status

Lots of minor problems need fixing. So, I grabbed a bunch and fixed them:

1. Selecting a planet crashes the program, if the production window has been closed.
• Fixed the update calls to check for the window's existance
• Added the "change production" button to bring the window back
• Defaulted the window to not be shown


2. No enemy designs in the ship designer
   
• Added an interface from the nstclgui dll back to Tcl
• Updated the ship designer code to show it


3. GUI oddities when clicking near planet names and fleet flight paths
• Fixed the ordering of canvas objects so planets are on top

This is taken from the JOAT the turn after they detect the WM scout. I suspected the scan code was not clearing private info. Now I am sure...

Hey Taxi!

I was looking for a fun little game to play when I get tired of whatever it is I'm working on. I'm tired of solitaire, and the statistics in free cell make it too stressful (same for spider solitaire).

So, I've started hacking Hey Taxi into Tcl. I worked on it about 5 minutes last night, and in less than a half hour this morning, I've got a pretty fun framework. Here's a screen shot:



I've bound up arrow to -10 Y acceleration. If you go below 0, you move up properly. Not sure how much I'll need to add to keep it fun... I think I at least want X thrust.

Update: I added X thrust.

Source for heytaxi.tcl

set ::gravX 0
set ::gravY 1

set ::velX 1
set ::velY 1

set ::taxiID 0

proc eventLoop {} {
  if {$::taxiID == 0} { return }

  incr ::velX $::gravX
  incr ::velY $::gravY

  set coord [.c coords 1]
  if {$::velY < 0 || [lindex $coord 3] < [.c cget -height]} {
     .c move $::taxiID $::velX $::velY
  }
  after 1000 eventLoop
}

proc thrustUp {} {
  incr ::velY -10
}

proc thrustLt {} {
  incr ::velX -5
}

proc thrustRt {} {
  incr ::velX 5
}

pack [frame .fVel] -side top
pack [label .fVel.lLX -text "X Velocity:"] -side left
pack [label .fVel.lVX -textvariable velX] -side left
pack [label .fVel.lVY -textvariable velY] -side right
pack [label .fVel.lLY -text "Y Velocity:"] -side right

pack [canvas .c] -side top

set ::taxiID [.c create rectangle 10 10 20 20 -fill yellow]

bind . <keypress-up>    thrustUp
bind . <keypress-left>  thrustLt
bind . <keypress-right> thrustRt

after 1 eventLoop

New Stars Status

Small changes, but good.



I added the calculations for terraforming to the planet display. I haven't updated the environment bars to show the swing, but you can see the final habitability. I have also been working on correlating our planetary production formula to the original Stars algorithms.

Interesting thing, I found a "bug" in Stars. Stars keeps population in terms of kilotons (100 people per kiloton). When your population grows, you often generate some fraction of a kiloton of people (0..99 people). We weren't previously storing or calculating with this. When I added it, I noticed a difference between our calculations and Stars (the Stars.xls sheet has been invaluable).

So, should the fraction of a kiloton of people contribute to population growth? I thought so, but apparently, the fraction is kept on the side and added in after growth is calculated. I have implemented "bug compatibility", although the other way is commented in the code.