Package net.sf.colossus.server
Class History
java.lang.Object
net.sf.colossus.server.History
Stores game history as XML.
- Author:
- David Ripton
-
Field Summary
FieldsModifier and TypeFieldDescriptionprivate boolean
private final org.jdom.Element
private boolean
Set to true during the processing offireEventsFromXML(Server)
to avoid triggering events we just restored again.private static final Logger
private final List
<org.jdom.Element> History elements/events that happened since the last commit/"snapshot".private final org.jdom.Element
History: events that happened before last commit point -
Constructor Summary
ConstructorsConstructorDescriptionHistory()
Stores the surviving legions (this variable is not needed any more) While the history should contain all information to reproduce the game state, the last set of legions is currently still loaded upfront since they contain the battle-specific information.History
(org.jdom.Element loadGameRoot) Constructor used by "LoadGame" -
Method Summary
Modifier and TypeMethodDescription(package private) void
addCreatureEvent
(AddCreatureAction event, int turn, String reason) TODO reconsider name TODO decide if we should move it all into one big handleEvent(GameEvent) method(package private) void
fireEventFromElement
(Server server, org.jdom.Element el) (package private) void
fireEventsFromXML
(Server server) (package private) void
Reached a commit point: append all recent events to the history, clear list of recent events; caller should do this together with creating the next snapshot.(package private) org.jdom.Element
getCopy()
All events before last commit(package private) org.jdom.Element
(package private) void
legionMoveEvent
(Legion legion, MasterHex newHex, EntrySide entrySide, boolean teleport, CreatureType lord) (package private) void
legionUndoMoveEvent
(Legion legion) (package private) void
mergeEvent
(String splitoffId, String survivorId, int turn) (package private) void
movementRollEvent
(Player player, int roll) (package private) void
playerElimEvent
(Player player, Player slayer, int turn) (package private) void
processRedoLog
(Server server) Fire all events from redoLog.(package private) void
recruitEvent
(Legion legion, CreatureType recruit, CreatureType recruiter) (package private) void
relocateLegionEvent
(Legion legion) (package private) void
removeCreatureEvent
(Legion legion, CreatureType creature, int turn, String reason) (package private) void
revealEvent
(boolean allPlayers, List<Player> players, Legion legion, List<CreatureType> creatures, int turn, String reason) (package private) void
splitEvent
(Legion parent, Legion child, List<CreatureType> splitoffs, int turn) (package private) void
undoRecruitEvent
(Legion legion)
-
Field Details
-
LOGGER
-
root
private final org.jdom.Element rootHistory: events that happened before last commit point -
recentEvents
History elements/events that happened since the last commit/"snapshot". -
loading
private boolean loadingSet to true during the processing offireEventsFromXML(Server)
to avoid triggering events we just restored again. -
loadedRedoLog
private final org.jdom.Element loadedRedoLog -
isRedo
private boolean isRedo
-
-
Constructor Details
-
History
public History()Stores the surviving legions (this variable is not needed any more) While the history should contain all information to reproduce the game state, the last set of legions is currently still loaded upfront since they contain the battle-specific information. This collides with replaying the game from history... Now, since 08/2008, they are not stored as "survivorlegions" any more. Instead, they are backed up internally (done inside PlayerServerSide), all the history is replayed. This creates proper split prediction data in all clients. After that, backup data is compared with result of replay. E.g. Legion count, their content, players eliminated must be in sync. Then the replayed ones are discarded and the backedup ones restored - which have the right legion state (moved, donor, summoned, ...) TODO align the history replay more with the original gameplay so we don't need this anymore; 08/2008:==> this is now to some part done. Still replay events could be closer to original events (split, summon, acquire, teleport, ...) , not just the "result" of that event (reveal,add,remove effects). TODO instead: model the actual events instead of just result, or at least add relevant info to history elements, so that all replayed events carry all needed data so that they could also be processed by event viewer (currently EV does not process anything during replay). -
History
public History(org.jdom.Element loadGameRoot) Constructor used by "LoadGame"
-
-
Method Details
-
getCopy
org.jdom.Element getCopy()All events before last commit -
flushRecentToRoot
void flushRecentToRoot()Reached a commit point: append all recent events to the history, clear list of recent events; caller should do this together with creating the next snapshot. -
getNewRedoLogElement
org.jdom.Element getNewRedoLogElement()- Returns:
- A Redo Element, containing all events since last commit i.e. which need to be REDOne on top of last commit point/snapshot
-
addCreatureEvent
TODO reconsider name TODO decide if we should move it all into one big handleEvent(GameEvent) method -
removeCreatureEvent
-
relocateLegionEvent
-
splitEvent
-
mergeEvent
-
revealEvent
-
playerElimEvent
-
movementRollEvent
-
legionMoveEvent
void legionMoveEvent(Legion legion, MasterHex newHex, EntrySide entrySide, boolean teleport, CreatureType lord) -
legionUndoMoveEvent
-
recruitEvent
-
undoRecruitEvent
-
processRedoLog
Fire all events from redoLog. Elements from RedoLog are processed one by one and the corresponding method is called on the Server object, pretty much as if a ClientHandler would call it when receiving such a request from Client. Note that in some cases overriding the processingCH is necessary (because technically, this all currently happens while still the connecting of last joining player is processed, so processingCH is set to his ClientHandler). Note that "loading" is not set to true, so they DO GET ADDED to the recentEvents list again.- Parameters:
server
- The server on which to call all the actions to be redone
-
fireEventsFromXML
-
fireEventFromElement
-