A place for general chatter about games in progress, games completed, strategy advice, bug reports, or really anything at all that relates in some vague way to RSW.
* New "Advanced Spots" interface in the Preferences window enables
the expression of absurd amounts of data via those little world
spots.
* Multi-position games may no longer be created with an unequal
number of positions per player--all players must sign up for the
same number of positions at the start of the game.
* A player must wait 24 hours before taking over an abandoned
position within a game he or she is already involved in, to allow
others not involved in the game to have a chance to take over the
position first.
* A player may take over no more than one additional position in a
single-position game he is already involved in. More generally,
in a multi-position game where each player controls n positions, a
player may control up to a total of 2*n positions by taking over
abandoned positions.
* Squelched spurious error messages when importing gift and ally
orders from other players.
* Gift orders are now properly listed in the "Final" phase, to be
consistent with when the actual ownership transfer takes place.
* Fixed bug with popup menus on top of popup world/fleet windows.
* Better defense against python errors when saving game data.
* Main window remembers its size and splitter placement across
sessions.
Projected score seems to forget who your current Jihad target is unless you redeclare it on a turn. It assumed to be docking me points for shots fired against my enemy on the prior turn until I readded the Jihad code.
Hmm. You're right. Drat, that will be tricky to fix, since the server doesn't (traditionally) tell the client about its current jihad state. Guess I'll have to deviate from standard FB practices again.
It doesn't seem like server communication is necessary. You can parse prior turns that are already resident on the client for Jihad orders, right?
Along those lines, I'm not seeing where the order is actually stored in the UI. Aside from redeclaring each turn, I'd have to parse prior orders to figure out who my current enemy is (if I've forgotten).
Right, but the server is responsible for telling us the complete state of the game every turn. For instance, it tells us our current list of allies and loaders. For some reason (unless I am mistaken) the standard FB turn report doesn't include information about who your current Jihad target is, so the client would have to infer this information from the set of orders the client has sent.
That's technically possible, but kind of problematic. One of the problems is that all of the past turns aren't loaded at once (this is why it takes half a second to view a previous turn).
The bottom line is, currently the client doesn't know your current Jihad target, because that information doesn't appear on the standard turn report. In order to fix it, I can either (a) add code to load up all of the prior turns and look for Jihad orders, or (b) add this information to the turn report sent by the server.
Option (b) seems more appealing to me, even though it violates the principle I've been trying to follow of making the game 100% compatible with the standard FB turn reports, so that the RSW Client can be used to play a game of official Starweb from FB. (It will still be useful for this, but if you play the game from FB, the client won't be able to track your Jihad status. I think that's acceptable.)
Projected Usable Industry doesn't seem to update properly. In enormous7a I'm dropping 6 metal on my homeworld. The world has 2 mines so metal is 2(8). Usable Industry is somehow at 2(0). The 2(0) should naturally be 2(2) but I would expect 2(10) factoring in the metal drops.
Projected Metal on fleets being transferred ships is also wrong. I'm transferring fleets with loaded metal and the projected metal is zero even with projected ships and projected destination being proper. All ships in the donor fleet HAVE metal and aren't unloading, so there's no chance that there's a mixup there. I guess considering that situation it would also be good to be able to specifically transfer loaded ships versus unloaded ships between fleets.
Usable industry is different from the other properties. Rather than projecting the usable industry at the next turn, the projected value for this property is the usable industry after all of the build orders for this turn have been issued. This is a much more useful value than usable industry next turn: it shows how many units of industry you have not yet ordered to build this turn. So if it reads 2(0), it means there is 2 usable industry this turn, and you have issued orders for both units. If you really want to see the actual projected usable industry for next turn, you'll have to advance the turn and look at the value displayed there.
As to the ship transfers, the projected metal is reading correctly. It will be zero after the transfer. You cannot transfer loaded ships; when you try to transfer a loaded ship, it arrives empty. This is described in the rules on the Transfers page:
Transfers take place after unloading metal, and before loading more metal. If you transfer ships that are carrying metal without unloading the metal first, the metal will not transfer and may be lost.
Though reading that now, I don't know why the language is so vague. It should say "the metal will not transfer and will be lost," not "may be lost."