I Love Tcl

So, I have been grinding through a lot of GUI code (NewStars update coming soon!)...

In the process, I have been shifting code from C++ to direct XML access. Part of this involves something called "XPath" (which I had never heard of before).

The key is, you can query an XML document like a database (including wildcard and logical test patterns). So, if I want the node with the planet with object id stored in variable 'pid', I can do:

set n [$nsGui::turnRoot selectNodes //PLANET_LIST/PLANET\[OBJECTID=$pid\]]

'//' means a relative search (not necessarily from the root). I need "PLANET_LIST" because there is another list of planets, called "UNIVERSE_PLANET_LIST". The outer square bracked "[]" are part of Tcl (execute this part, and resolve it to the string that is returned). The inner (escaped) brackets are part of XPath (return nodes which satisfy "[logical_condition]").

Of course, any language can support XPath. But, in Tcl, I can open a console session, source the stars.tcl, and start issuing XPath commands against the turn file. That allows me to rapidly tune my request to get the results I want (eliminating the compile/re-run steps). Especially since the W3C XPath docs are unreadable...

Then, once I have the planet node, I can pick off attributes:
set concs [$n selectNodes string(MINERALCONCENTRATIONS/text())]

That replaces:
set planXML [xml2list [newStars $::ns_planet $id $::ns_getXML]]
set mainXML [lindex $planXML 2]
set cargoXML [findXMLbyTag "CARGOMANIFEST" $mainXML 2]
set tuple [lindex $cargoXML 1]

Especially since that used "xml2list", which can't always parse some XML...

Const Fail

I only recently discovered an oddity in the C++ "const" feature. Consider this code:

class Foo
{
 int *i;

 void foo(void) const
 {
    *i = 4;
 }
};

(I've left out some boiler plate)

Anyone see it? A const function is changing the state of the object!

Oops, turns out C++ const is not "transitive" (the D docs call it "head const").

This bit me big time on my previous project. To the point that I developed a "const pointer" class to wrap all my pointers (only got partially deployed into the project).

D 1.0 lacks const (because it is hard to get right, witness C++). D 2.0 wants const done right.

Also, there is a great slam on Java and const. (I can't help myself when it comes to slams on Java! :) Yea, no const for you Java-kins!

New Stars Status

I've been struggling with whether to extend the regression, or to get things into shape for a pre-Beta test. I like the regression (being repeatable and all), but it takes as much work as playing the game (more, since I have to play both players).

Of course, shaping things up for a live test requires different sorts of GUI programming...


Here we can see the major changes:

• I added the icons for two of the planet views (ship view - mostly implemented, and planet value view - next to be implemented)
• Lots of production queue stuff...
• Shift and control with Add/Remove (10 and 100 respectively, 1000 together). 889 = 1000 - 100 - 10 - 1
• Added "End of queue" (add is "add before", so we need end - original Stars uses "add after", oops!)
• Fixed quirks in selection (previously, I deleted the queue and reconstructed it from the current orders - now the C++ code communicates queue changes and the GUI selectively rebuilds the view)
• Added a binding to the "q" key
• Fixed a bug related to pressing "Change" queue button multiple times

Fixes that can't be seen here:

• Fixed a bug in the max usable factories calculation (population was divided by 1000 instead of 10,000 before multiplying by race factory operation factor)
• Fixed a typo in the component map for Interspace 10. This caused a Tcl error when opening the Ship Design Wizard for players with that access to that component.
• Fixed key bindings for '-' and '+' on the numeric keypad (linked to zoom) for Linux. On Windows, <plus> and <minus> catches both versions. On Linux, the keypad keys generate <KP_Add> and <KP_Subtract>. May be an X server thing...
• Fixed transport amount carrying over between different fleets (and players!). The most confusing thing was - a player could order a load 2500 colonists, save and load another turn, and see that load 2500! Except, the order wasn't given, so they'd launch with no colonists! Ops!
  
• Unlinked open file command from "Find" operations (it was intended as a place holder, I find "" makes a better one!)
  

I'm pretty sure there is a bug in "Remove" multiple, when there are not enough to satisfy the remove (for example, remove 1000 - when there are only 999). The remove will probably remove more stuff, until the count is satisfied! I will fix that...

I also need to implement the hab view.

And fleet split/merge. Fleet numbers. Fleet (friendly and other) and planet list.

Stuff I've read lately

"The Sovereign Grace of God In Salvation" (John Roden) - Reviewed on my faith blog.

New Stars Status

BOOM!



Further work on the battle VCR.

First, I ran through this battle in the original Stars, and noticed that the Warmonger Armed Probe should be crossing the board faster. I found that the Warmonger did not have his +.5 move bonus. Fixed.

That gave me a test case for a "FIRE" token in the battle report (missles still not supported).

I also updated the selection logic, so that changing the current event (next and previous buttons) selects the acting token.

Stuff I've read lately

"Murder in the Solid State" (Wil McCarthy) - Interesting pun. When you think of "solid state" you think of "state of the art" and "cutting edge". But, in the age of nanotech (full of tiny machines and their moving parts), "solid state" is the failure mode (your tiny machines have jammed)!

This book is a murder mystery. Things go pretty well (very suspenseful) for the most part. Although, the ending was a little confusing and unsatisfying.

Stuff I've read lately

"The Sky Road" (Ken Macleod) - Wikipedia says that this book presents an alternate time-line in the "Stone Canal", "Cassini Division" series. I'm not so sure. It's certainly not obvious. One character, "Ellen May" seemed younger than I remember, but I can't be sure. The "Sheenisov" are still marching across the earth, and the "tinker" society seems a believable precursor to the communes in "Cassini". Overall, ok. I still like "Cassini" the best.

"Why I am So Wise" (Friedrich Nietzsche) - Reviewed on my faith blog.

Aluminum + 1000 resources

= Space Elevator! (thank you Civ 4). Of course, if you build in in the city with the Iron Works (excellent Texas barbecue results in double resource output!), it's only 500 resources; a good city can do that in ten or eleven years.

I've been following discussions on building a space elevator for some time now. I was surprised to see CNN discussing it!

There are two primary challenges connected with building a space elevator:

1. The cable (or tether) - Spans 100,000 kilometers from the surface of the earth, up past geosynchronous orbit (the center of mass is at the geosynch point)
   
• This cable need not be one single piece. This is a confusion many people have ("We can't build a carbon nanotube that long!!111eleven!").
• The cable need not be of super materials (100% carbon nanotubes, positronium, etc.) You can make it out of bubble gum, although you'd probably need enough to alter the center of mass of the earth-moon system :)
• Better materials translate into less mass for the initial tether. That means fewer rockets to get all the materials into space.
• Once the initial tether is up, the first cargo can be more tether, to increase the capacity of your elevator (and build new ones).
  
2. The cars (or climbers)
• The tether does not move, instead, the cars pull themselves up or down.
• The climbers are actually the hard problem!
• They must travel the hundred miles or so into the edge of space, and possibly, the 36,000 km to geosync orbit (especially if they are going to be used to add on to the tether).
• It is unlikely we will want to carry enough fuel for a 36,000 km journey (at 200 mph, that's about a five day trip - one way).
• That means we need a means of power distribution to generate power on the ground, and get it to the climbers (most likely lasers and solar panels).
  

The dangers of the space elevator (terrorist attacks on the base, the tether, or the geosync station) are largely exaggerated. Breaking the tether would cause pieces of it to burn up or fall to earth. It is relatively small, and would do little damage. If the base were destroyed, the tether would slowly rise (there is slight pressure up, to keep the tether tight).

The hazard to lower orbiting satellites is more than offset by the increased launch efficiency. (There would need to be a workforce assigned to pushing satellites out of the way, or a way to shift the tether around them - such a shift might even be useful in dodging meteors or terrorist suicide attacks).

The good news is that the space elevator used to be considered a tech level 9 or 10 achievement. It appears, it will be completed easily within the tech 8 time frame.