CurrentPlans

v1.9

DPforge solved issues and enhancements

• New blind options: TROJAN, GREEK. These are actually combinations of more primitive blind options, determining what units scs can see, what units units can see and what scs can be seen.
• See ownership of all neighbobyring SCs by default.
• Most host parameters should have sensible default parameters set in DPjudge/__init__.ps, but it should be possible to overwrite any of them, hence the need to check whether a parameter is initialized or not. Background: On the one hand, a shorter host.py is a noble goal, headed toward the "host.py is created by an installer" goal. So the only things in host.py should be truly unique among different installs. Not identical this = that + '/web' lines, hence the need for default values. On the other hand, you should allow for some directories (like games) to be moved to different servers, hence the need for conditional checks.
• Homes in power objects instead of map.
• Roll back one phase.
• Roll forward.
• Master can't see waived builds in blind games.
• Ghost units in blind games after disbands.
• Dummies make the game wait until the deadline because of improper CD handling.
• In games with yellow and fake press, no player could press the submit button to send an anonymous broadcast, while e-mail broadcasts work. Fixed.
• A mail option to only send to a specific address instead of to all pluayers and the GM is a must for debugging active production games on the test server. Solved with the tester parameter, which is both a host (applying to all games) and a status (only applying to that game) parameter. If tester is empty, no e-mail is sent at all.
• Resigning and dummifying powers in Firefox.
• Improved toggling behavior of press recipients on web page: Any recipients below ALL (like JUDGEKEEPER) gets toggled off when ALL is toggled; in case of PRESS_MASTER, MASTER is moved below ALL to exclude it from broadcasts; you no longer need to select a second recipient besides JUDGEKEEPER (or another one below ALL) to be able to send a message to the latter.
• For fake press, remove the ALL claim-to option on the Press web page if the master is not included; in combination with PRESS_MASTER, either remove Master or remove ALL. Also let the GM know the real recipients that are getting the message and send the same header to omniscient observers.
• A trials folder to dump maps that are being tested. Use TRIAL instead of MAP when creating a game. The JK gets a message each time such a game gets created.
• Forbid processing inactive games. Apparently when no player has joined yet and the game is still forming, sending a process command will start the game and run forever.
• Column width for retreat orders is too small. The unit caption is split over two lines, as in 'F' on one line, 'NWY' on the second (Chrome browser). Solved by replacing the space with a non-breaking space.
• A REVIVE master command to reinstate dismissed players. Parameters: Power [Password]. If no password is given, it will be randomly generated. The player receives a mail telling him the new password and how to change it. If someone else took over in the meantime and resigns in the same turn, his credentials are removed from the player line so that the former player can be renounced as usual. Also unchecking the Resigned checkbox on the master page for that power will revive the player, giving him a random password.
• Save CD orders in status file before processing, so that a replay (rollback - rollforward) will execute the same orders.
• Replay script on active production games.
• Forcing a refresh of pdf files even when the browse setting is to never check for updates.
• Alternative home centers. If both a normal hc and an alt sc are open and owned, the player can choose to build in the alternative center instead of a home center. In other words the maximum number of builds equals the number of normal owned and open home centers, while the build options include both those normal build centers and the alternative build centers. See CAL in Zeus.
• Hidden builds. A home center marked with a "~" will not reveal what was built until the next (Spring) turn gets processed. See CAL-NYO at game start in Zeus.
• Following up on that, HIDE_BUILDS, HIDE_REMOVES, HIDE_RETREATS could be added to delay revealing minor phase actions for ALL players. Kind of a mini-XtallBall.
• The Zeus map.
• Making TORN_ALLEGIANCE a rule.
• An email link to the current judgekeeper on the DPjudge home page.
• Loading the home page should not fail if host.dppd is None.
• Put power variable assignments for inspect in a method in a separate class (called Inspector), so it can be called at any time. Executing inspect.load('gameName') will load the game and create global variables for the game and any power in it, while executing inspect.loadDb() will initialize the global variables dppd and db, the latter pointing to dppd.db.
• The map FLAGS option can have several directories to search from. Renamed powers inherit the flag of the original power.
• Messages to the judgekeeper now have the GM's email address in the From field.
• A TEAM_VICTORY rule making a controlled power's supply count count towards the controlling player's victory count. Automatically included with VASSAL_DUMMIES. Useful when players control one or more dummy powers from start to finish.
• Back up the dpjudge database, replacing the dpforge database with it, on a monthly basis. Script backup in folder /home/dpforge/bin created for this purpose.
• A judgekeeper password, allowing access to all games and the whole DPPD. Should not show up in game access files. Save in host.py. Renew from time to time.
• Weekly reminders on forming and waiting games to the GM, instead of daily. The message informs on the number of open positions or the powers that are to be taken over.
• ALL and ALL EXCEPT versions for DUMMY and UNPLAYED map rules.

DPforge issues and enhancements

• Vassal retreats from owner page; vassal names without leading underscores in login dropdown box.
• Vassals separate from dummies.
• VASSAL_DOMINOES for cascading vassal coat turning.
• Late notices to vassals need to go to their controllers, bundled if possible. Reduce the amount of mail.
• Multi-home center vassals should be captured one by one. Partial captures should be stored along with the power's normal home centers, marked with a '*' in front or something, and count towards victory points. Power may be able to issue non-move orders for vassal unit in the city.
• Add total number of victory points for vassal games to center table (After Fall judge results).
• CAPTURE_EARLY rule.
• Dynamic rules and rollback.
• Updating power info, making dummy from master page.
• SHIFT_HOME and HOME_SHIFTS rules (bretwalda).
• SHIFT_POWERS starting rule (shiftright, ...).
• Move logic to powers.
• Merge retreat and adjustment reports into order report. Put B, R, F, L in front of built, retreating, found and lost units.
• Two letter initials for every power, including dummies.
• Void and chaos powers and colors in the info section on every map.
• Roll forward matching units/scs only.
• Rotating in combination with IN phase should be tested. A SKIP or NIL phase could be added; in combination with IFYEARDIV, one could then rotate every n years.
• Provide a separate function for preview, so that Game.process() no longer has to care about it, allowing rollforward to call process() without checking self.preview. An obstacle may be the PREVIEW rule.
• An EXPLORE rule that allows powers to see more and more of the map as a function of what they have explored. Assumes UNITS_SEE_ALL. Power SEES lines need to include non-sc provinces, and don't need to be reset. Mark the province name on the map to show what has been discovered. Optionally restrict to travelled through provinces only, not neighboring locations.
• Changing passwords should automatically change the file names of associated blind maps.
• The numbers calculated for the second portion of the blind map file names should not be negative.
• Player rankings. See the ratings folder in some old backup on usdp for payola and crystal ball. For now we remove the payroll and cbd ratings links in the header sections of the respective variant Index files.
• Better error handling when forbidding processing inactive games. I've added a ProcessGameInactive exception now which will be raised on games where the status is not active, but better error handling can be added for web button presses (disable the button, or show an error dialog) and mail responses.
• Column width for communications is not big enough for long power names like Tsaratutsch.
• Allow players to join and change leagues. See game green24. Also make leagues part of the power info instead of keeping it purely in the map variable. That way at least the master can confirm that everyone is in the correct league.
• DPmap enhancements: Minor phases on separate pages with split parameter. Dislodged unit shown offset on After page. Create method per phase.
• Put encoding in open() call instead of encoding each read()/write() string.
• HTML formatting for messages. E.g. the summary page should be in courier font to display well. 70 character limit can be eliminated. Format may depend on user setting. Chris Babcock suggests using Lynx on the command line for reading and writing html messages.
• A PURGE command for GMs and a forced purge option for judgekeepers.
• User set timezones, on game level and dppd level.
• A setup framework to install the judge, and a README file (John).
• Resignation and/or takeover mails in the messages dropdown.
• Clean up the DPPD web pages, making it SQL-infusion-proof by using the 2 parameter variant for all db.execute() calls. Also distinguish between query parameter page (for html-pages) and data (for sql-queries), e.g. for whois calls, in the latter case not adding banners. Could also be done by assuming that a page name starting with a lower-case letter is a request for data.
• Create a RemoteDPPD class, a subclass of DPPD, to transparently handle remote and local access to the database. Make all sql-queries inside DPPD, while RemoteDPPD implements the same methods by sending URL-queries over the internet. That means that any judge, whether it's hosting its own database or not, can have its own pages run locally. Use a host.remoteDPPD variable to decide on what type it is. When answering queries, assume that the DB has to be local (or error out) to avoid recursively sending URL-queries to yourself.
• Only show the games on the host judge on the user page, and let the judge links on top jump to the user page on the other judges (the one for the current judge doesn't need a link then). Add a button to see finished games.
• Fail soft on SMTP Mail Server error, as when sending results (vaslay S1910M).
• Report changed log files in login message for all users (dpjudge, dpforge, mario).
• Show acceptable error message when connection to DB fails when visiting DPPD home page.
• Multiple signon's (join's, etc.) before the final signoff should be possible.
• Report powers that NMR to GM. (Ed)
• Put a link on the player page to the website that created the flag. A bit of html-code in the flag folder might be sufficient.
• Send a message to the GM telling which players went CD. Include dummies only if they have a controller.
• Add an OMNISCIENT(!) command, so that a GM can make someone omniscient without invoking the help from a JK. Model it after DUMMY if possible (DUMMY is a map command, this would be rather a status command?), with player names listed after the command name, and preceded by '-' if one needs to get removed. Alternatively, add an OMNISCIENT check mark on the master web page in the power box, with a dialog to check whether a '!' should be added or not. Unchecking simply raises an Ok dialog.
• Get rid of either pages/Status or pages/StatusHelp. They seem to have mostly the same contents.
• Put a small html or py file in each flags folder, containing a table with for each flag the power name, file name, web site name and web site url. Use that info to add a link on each player page around the copyright, with the text "Flag from <web site name>". The file name in the table means we don't need to rename the file and can use other image formats than GIF. Manus others PNG.
• In blind games omniscient observers should simply get the master's map and controlled dummies their ceo's. The ps file name should have the game phase encrypted along with the password, so that an observer who is no longer omniscient can't guess the file name of newer phases (real concern?). Old files should be deleted.
• A TEAM_PLAY rule, so that powers in the same team (controlled powers and their ceo) don't capture each other's centers. Home centers are returned to the original power, so resurrection becomes possible. Similar to VASSAL_DUMMIES, but limited to controlled dummies. Disbanding (by one power) and building (by another power in the same team) in the same center in the same turn should be investigated. Also investigate if instead of dummies we can apply this to leagues (powers controlled by actual players).
• Allow game names with letters and punctuation other than alphanumerical and "_", excluding only white-space, "<", ">", "&", ".", "?", "!", "/", "\" and non-latin-1. "-" is not allowed as the first character, so as not to confuse with script flags.
• Weekly reminder to GM for waiting games that are blind, should show the actual unit and supply count for every power.
• Use git to backup games outside of server. Google "use git backup". Used on USAK. Is installed on floc. See mail from Chris Babcock on Jan. 29, 2013.
• In case of FICTIONAL_OK (BLIND games) at least check that the route is possible if fleets would be everywhere along the route.
• New rule CONVOY_LIFT, allowing the start and end part of a convoy route to be open to the convoyed unit only. E.g. in combination with COASTAL_CONVOY this would allow MOS-STP/NC-BAR-NWG-EDI-LVP, and with PORTAGE_CONVOY it would allow BAR-LVN-MOS-SEV-BLA, literally lifting the fleet out of the water and dropping it straight into another sea.

v2.0

• Make the DPjudge a backbone processor for other game interfaces by abstracting in- and output in the Game class.
• Alternative web pages for smartphones (using Zope, Python's SOAP library).
• Community features: Integrated forum (see pyForum.org based on Python, or PunBB based on PHP), tournament listings, search page, ...
• A Wiki for creating pages. May be extended to the Diplomatic Pouch in general.
• A SHROUD directive to hide units in certain locations from view. Requires a public map apart from private player maps. DROP SHROUD clears the shroud.
• A CLOAK rule to exploit shrouds. After Fall retreat, every unit on the board creates a shroud in the province it is in. If however there was a shroud in place from another player, the shroud gets dropped instead. Requires to remember shroud extents per player, instead of relying on unit positions and scs.
• Results in an intermediate format

This would be a great thing to have for generating output in all kinds of languages. There's a prototype that I (woelpad) developed earlier that could be directly interpreted by PostScript (by adding some fancy code of course). Here's a short fragment:

% Season

(Devonshire2) 1902 Spring

% Centers

FRANCE

BRE ^
MAR ^
PAR ^
MUN $
VEN $
BEL $

...


% Orders

FRANCE

F BEL H ~
A VEN S MUN TYR !
A MUN TYR !
F BEL R *

...

This shows France with 3 home centers and 3 supply centers. Its unit in Belgium held, but was dislodged. Its unit in Munich moved to Tyrolia with Venice's support. Finally its dislodged unit retreated off the board. In short, orders are ended by a character that tells its result: '!' for success, '~' for dislodged, '|' for bounce or cut, '*' for destroyed, etc. Supply centers are marked with '^' for build centers (for that power) and '$' for normal supply centers.