Light of Nova

I finally found a Stars-like that people are playing (and it was even on Facebook!)

The mechanics are pretty straightforward (build, build, build), and politics plays a pretty important part.  There is even a story that is not entirely terrible.

And I've got a spreadsheet!

Software Updates

A NewStars update!

Surprise, surprise, the first executable didn't work (at all). The second executable mostly worked, the third executable should work (haven't heard any complaints!)

Each executable is about 3 MB, which takes several minutes to upload (no FIOS for me right now).

But, there is a way to update a Starkit piecemeal! Just make a list of files to check for updates, then foreach s in that list:

if {[file exists $s]} {
file rename -force $s [file join $starkit::topdir $s]
}

So, I can update one file and just drop it in the runtime directory, and it will slurp it into the archive.

Of course, Windows becomes extremely angry if you try and update an exe while it is running!

This is going to require me to drop from a Starpack back to a Starkit and ship Tclkit. I'll also need a batch file to couple everything together.

Irritating, but worth it to reduce update sizes.

A Starkit of Stars

I just sent out the first user-ready version of NewStars!

The main concern I had with using Tcl was that when it came time to distribute, every player would need to install Tcl.

However, there is a handy technology called "Star kit" (or in this case, "Star Package").

There are three components:

1. Tclkit
2. Starkit
3. Star package

Tclkit is the program that does all the work. It is a single file Tcl/Tk interpreter.

A "Star kit" is a single file archive (like a jar) which contains all the Tcl files and DLL's needed, in whatever directory structure you like.

The Star package is a star kit, with tclkit wrapped in with self-extraction and execution.

I had used Freewrap before (which is another single file Tcl interpreter), but couldn't make it work.

Tclkit is very easy.

Starting from the base stars.tcl (in a scratch area):

sdx wrap stars.tcl
This creates a skeleton kit, with just the main script.

sdx unwrap stars.kit
Expand the kit virtual directory structure into a real directory structure - which we are going to populate and experiment with.

tclkit stars.vfs/main.tcl
Try and run from the real directory structure (for testing)

sdx wrap stars.kit
All done, make the kit (can test the kit with tclkit stars.kit).

sdx wrap stars -runtime tclkit
Bundle Tclkit into the Stars star kit, making a star package - which is executable on its own.

Mail out the executable!

NewStars Status

Whew, been a while... I have been putting off work on NewStars. I was afraid of "GUI load/unload", that is, the shuffling of cargo using the GUI. These orders have a separate order type from "Waypoint 0" (both happen before move). I was worried I would need to evaluate these orders in order to show the current levels on planets and in ships. Then, I would need to hide the orders in the order box, yet update the orders when the GUI instructs.

I figured out a way around all that. I left the GUI orders in place (visible and not evaluated) for loading/unloading to a planet. For ship-to-ship, I edit the XML (the reconciler handles edits in the XML).

The basic GUI is now ready:

Here we can see a transfer between the medium freighter and colony ship for player 1. The orders are executed when the window closes (I should add Cancel and Ok buttons...)

With that, everything needed to play is in the GUI!

NewStars Status

Cool little bug managed to waste a week of John's time...

I had noticed a difference in surface minerals for player 1 in 2401. Examining the mining code indicated it was probably due to scrapping the JOAT remote miner.

The code which calculates ship cost and scrap value is pretty complicated, so it seemed natural the bug would be there.

After digging into it, it became apparent that the bug was due to the miner being on a destroyer hull!

This is due to a copy/paste bug in the code which gives players their initial fleets:
In function makeInitialJoatMiner (copied from the make destroyer code)
Ship *design = new Ship(*(pd->gd_->hullList[destroyer_hull]));

Oops.

NewStars Status

Turn 2!

Here we can see some problems, although nothing earth shattering.

There is some difference in mining or scrapping (the JOAT miner was scapped on turn 1). But the pop growth looks good, as well as resource calculation, and production. I've also checked the resources going into research, and they match.

The x resources out of y is a known Tcl bug. I just put "x of x", and don't bother to include the research tax...

There should be a WM scout visible, but I need to create the P2 orders to make that happen...

New Stars Status

Another day, another bug!

This time, it looks like a bug (or bizarre algorithm) in Stars!

John was kind enough to fix the previous bug.

Now, our Long Range Scout has picked up a ly in the X direction.

The relevant X,Y pairs are:
Finale 78, 80
New Stars 101, 108
Stars 100, 108

The distances are 36.24 ly for New Stars, and 35.61 for Stars. It's really not clear why Stars didn't give up that last ly...

I'm tempted to call "Will Not Fix".

How can our lock step hope to succeed with bizarre bugs like this :(

HTML Canvas

Interesting development. The guys behind FreeCiv have developed a client using the HTML 5 canvas.

I remember looking at a proposal for canvas a while back. It was sorely lacking from the Tcl canvas (if only Tcl had made it as a web standard!).

But, if you can implement FreeCiv in it, maybe it has gotten better (or maybe FreeCiv doesn't use circles...).

Probably worth looking into. A NewStars web client would be nice.

New Stars Status

Hopefully things will pick up...

Here we have our first turn gen, and our first bug!
Our move code has place the destroyer and the probe in the same location, while Stars has them one light year apart. Bizarro. Must be a rounding problem...

I also had to fix the recent file LRU yet again. Hopefully it is correct now.

New Stars Status

Not exactly a blitz, but moving along...

Here is player 2. Note, I have fixed the title bar. I did the Stars turn by hand, but the New Stars turn was generated from Tcl!

$ cat orders_P2_2400.tcl
set owd [pwd]
cd ../../../gui/tcl
load ./nstclgui.so
source nsCli.tcl

set nsGui::playerNum [newStars $::ns_open $owd/tiny_sparse_P2_Y2400.xml]
buildMyPlanetMap
set hwPID $nsGui::myPlanetMap(0)

set fid [findFleetByName "Armed Probe #2443026239740"]
sendFleetToPlanet "Armed Probe #2443026239740" [findPlanetByName Pervo]
sendFleetToPlanet "Armed Probe #2443026239740"
sendFleetToPlanet "Armed Probe #2443026239740"

# get a useful scout
newStars $::ns_design $::ns_loadPre scout "Smaugarian Peeping Tom"
newStars $::ns_design $::ns_save

# build it
newStars $::ns_planet $hwPID $::ns_addAtIndex 0 0 1 $::designMap(3)

# set orders for max growth
for {set i 0} {$i < 100} {incr i} {
newStars $::ns_planet $hwPID $::ns_addAtIndex 1 1 3
newStars $::ns_planet $hwPID $::ns_addAtIndex 2 1 4
}

newStars $::ns_save $owd/tiny_sparse_P2_Y2400.xml

Pasting Tcl code is so much easier than C++, a lot fewer < and >!

I had to override the logic for "sendFleetToPlanet" auto-pick. It picks the closest planet, but I wanted to send the Armed Probe on a one-way trip to cover a specific set of planets. The Smaug will cover closer planets.

I had to adjust the speed of the probe in Stars, but the New Stars auto-pick got the speed I wanted, very nice!

New Stars does not show what will finish, that is a very hard problem. I will have to address it at some point, though...

New Stars Status

Let me start by saying the gcc maintainers are jerks.

I have heard this accusation often on comp.arch, but I was skeptical. Now I know it's true.

If you doubt, read this.

That was back in October, there is still no solution for Cygwin (as far as I can tell). My latest updates pulled down the latest versions, and now I can no longer build NewStars.

I had to back rev to gcc-3 (as mentioned in the post).

Which brings us:


Ahh yeah! Stars versus New Stars, head to head!

Turn 1, player 1 of the test game.

Obvious differences:

1. Stars and New Stars have the origin of their graphics inverted. This creates a "mirror" effect when looking at the universe (not going to fix)
2. Stars puts some useful info in the title bar (will fix ASAP)
3. I am missing the planetary mineral concentrations (will fix, eventually)

More soon!

P.S. Interesting factoids

1. Stars adds 1000 to x and y
2. I used Tcl to verify the structure of the master xml

package require tdom
set doc [dom parse -channel [open tiny_sparse.xml]]
set root [$doc documentElement root]

set univP [$root selectNodes //UNIVERSE_PLANET_LIST/PLANET]
set playP [$root selectNodes //PLANET_LIST/PLANET]
puts "#\tX\tY\tName"
foreach p $univP {
set name [$p selectNodes string(NAME/text())]
set id [$p selectNodes string(OBJECTID/text())]
set x [$p selectNodes string(X_COORD/text())]
set y [$p selectNodes string(Y_COORD/text())]

incr x 1000
incr y 1000
puts "$id\t$x\t$y\t$name"
}

That creates the "Universe Definition File" (Report->Dump To Text File->Universe Definition). I have a longer version which checks the integrity of the player maps against the global map.

New Stars Status

Well, looky here!



Here is the "Merge Fleets" dialog! (I know the spacing is off) It works! You can merge ships between fleets. I still don't have "Split All" and "Merge All", but they are basically macros that should be easy. All the core functionality is done.

I also fixed the "Goto" button in the "Other Fleets" area. It was really bugging me...

We are now ready to play! (except for fleet to fleet cargo transfer, but who ever does that :)

New Stars Status

So close now!

It's been a while since we had a Windows screen shot. See, it still looks the same! :)

I had to scp over the turn file from Linux for debugging, because I don't have a split case on Windows, and debugging through VNC can be a pain...

This looks like the normal split case, but look carefully...

The original fleet id is 234806..., now the fleet id is different. I did a split, where all the ships move into the new fleet (and the old fleet gets deleted). That was to test the fleet deletion code, which is needed for merge to be useful.

Now I can do merging.

New Stars Status

Oh Frabjous Day! Calooh! Callay!

Here we can see the fleet split dialog in action. The cool thing about Tcl, is the whole dialog and the logic behind it is 90 lines of code...

Here's the bulk of it:
for {set i 0} {$i < $numDesigns} {incr i} {
pack [frame .tSplitter.fTop.fRow$i] -side top

set shipName [newStars $::ns_planet $fid $::ns_design $i $::ns_getName]
pack [label .tSplitter.fTop.fRow$i.lL -text $shipName] -side left

set shipCt [newStars $::ns_planet $fid $::ns_design $i $::ns_getNumFleets]
pack [label .tSplitter.fTop.fRow$i.lLC -text $shipCt] -side left

pack [button .tSplitter.fTop.fRow$i.bL -text "<" -command "adjustSplitRes $i -1"] -side left
pack [button .tSplitter.fTop.fRow$i.bR -text ">" -command "adjustSplitRes $i 1"] -side left

pack [label .tSplitter.fTop.fRow$i.lRC -text 0] -side left

lappend ::splitRes [list $shipCt 0]
}
Hardly any < or >!

In English, it says:
foreach ship design in the fleet do
create a new frame (invisible GUI packing object)
pull the ship name via the C++ bridge, and make a text widget for it
pull the ship count via same, and make a widget for it
make 2 buttons, one < and one > which will call adjustSplitRes (described later)
make a text widget with "0"
append a list to the global variable splitRes (which holds the split counts for each design)

Like 9 or 10 lines of specific English, roughly the same in Tcl (plus whitespace)
Here's adjustSplitRes in its entirety:
proc adjustSplitRes {row val} {
set left [.tSplitter.fTop.fRow$row.lLC cget -text]
set rght [.tSplitter.fTop.fRow$row.lRC cget -text]

if {$left < $val} {return}
if {$rght < -$val} {return}

set left [expr $left - $val]
set rght [expr $rght + $val]

lset ::splitRes $row 0 $left
lset ::splitRes $row 1 $rght

.tSplitter.fTop.fRow$row.lLC configure -text $left
.tSplitter.fTop.fRow$row.lRC configure -text $rght
}

This pulls the text labels for the left and right, checks for underflow, then applies the new count (for now, we only support moving up or down 1, but I should be able to bind shift and control click to move more). I then update the splitRes list, and the GUI text.

The C++ bridge does not handle deleting the old fleet... that will probably need to be fixed, although we should have new tools for handling chaff mine sweeping, which was the main reason for shedding old fleet nums (otherwise, you never need to move out the last ship from a fleet).

I should be able to use much of this logic to build the fleet merge dialog.

Split all and Merge all should be easy, and aren't strictly needed for playing (merge fleets is needed).

Almost there!

New Stars Status

I hacked in a simple fix for the case I can check. I will need more code once I can check more cases...


Now we can build multiple ships, and split them out one by one. The Tcl/C++ interface has everything we need (I created this case from the command line). I need to update the GUI to present it nicely.

New Stars Status

This is a particularly tricky set of code. I need to split off individual ships into a new fleet, and make sure the fuel and cargo are transferred proportionately.

Here we can see the 2 Toms have been split, but the fuel was left behind (as would the cargo)...

New Stars Status

I've been doing more work on the Linux side, as bugs come in and because I don't trust my XP regression (without comparing it to Vista).

This means I get my first Linux screen shot! (Which confused me for a second, I thought I would need to scp it back!)


Twm rulez!

The other advantage of working on Linux is that I need a new regression. That means I can use a disposable game, where everyone is not acting optimally.

Here, I have changed player two to build two scouts, instead of one.

That allows me to update the build logic to group new ships into fleets by design, rather than putting every ship in its own fleet.

This will allow me to work on the split fleet code.

Fun With Excel

(Actually its the Open Office Excel clone, but I can't even remember it's name...)

Saturday night I got my development environment under Windows XP in workable shape (I won't say it is totally working, because there still seem to be some oddities).

I then started to look into the regression.

I am trying to run the regression like a real game, which means all the micro-management entailed in a new game (part of the reason for NewStars was the hope of eventually automating the micro-management).

I have a spreadsheet (the famous STARS!.xls), which allows for colony planning.

The spreadsheet is incredible, and is invaluable for checking the server code.

I found a bug regarding partial completion. Imagine a factory built 1 resource at a time, over 10 turns. The factory costs 4 germ. How do you subtract the 4 G, and not 0 or 10. Our code was subtracting 0...

After I fixed that, I found a (what I think is) a bug in the spreadsheet!

So, I spent all day looking at spreadsheets, and ending up starting a new spreadsheet.

Fun! Fun!

New Stars Status

Wow! A long time with no updates!

Real life has interfered with development, hampered by some irritating 64 bit problems. Apparently, the C runtime in Windows Vista accepts %ll for printf. The same cannot be said for Windows XP.

I had been doing most of my development on a Windows Vista machine, but lately have had to fall back to Windows XP. That's when I noticed the regression doesn't pass.

I tried to track down the printf's and replace them with ostringstreams (finally a case where C++ is better than C!), but there are just too many of them. I ended up doing:
vi `grep -l '%ll' *.cpp`
And
%s/%ll/%I64

Ahh, saved by vi.

The regression is now somewhat passing, but there are some oddities... need to check against Vista...

New Stars Status

Getting close!



I added the "Other Fleets Here" GUI element. I also implemented the functions to populate the list.

As soon as I implement the functionality for split/merge and cargo, we will be ready for a developer test game!