Proto commits in RPTools/maptool

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-07-01

Fulfills #5966, this is a broader approach mention in #1762, #1909, #2002

The documentation is generated from this commit.

2026-05-21

Fulfills #5966, this is a broader approach mention in #1762, #1909, #2002

The documentation is generated from this commit.

2025-12-02

Deprecate Zone#drawBoard This is not really part of the model, but is just a means for the export screenshot dialog to temporary disable board rendering. As such, the flag has been moved into `ZoneRenderer`. Remove the corresponding `draw_board` field from `ZoneDto`.`

2025-12-01

Clean up various board-related logic In `Zone`, put all the board getters & setters together. Rename `setBoard(Point)` to `setBoardPosition(Point)` to avoid confusion with the more general `setBoard(MD5Key, Point)`. Modify `setBoard(MD5Key, Point)` to be the one-true-place to update board settings, with this method firing a `BoardChanged` event and the other board-related setters delegating to it. Include the x/y scale in with the other board parameters. Include it in the `BoardChanged` event and `SetBoardMsg` DTO. Deprecate `Zone#boardChanged` in favour of the renderer keeping track of this information. Remove the corresponding `boardChanged` from `ZoneDto`. Since this is a serialized field, it has not been removed.

Include image scale in SetBoardMsg

2025-11-07

Encapsulate Pen using readResolve() and writeReplace() `Pen` now has a simple invariant: the foreground mode is transparent if and only if the foreground paint is null, and the background mode is transparent if and only if the background paint is null. `Pen#readResolve()` guarantees this invariant holds when loading legacy pens, and `Pen#writeReplace()` guarantees that serialized pens will have the same properties and can be properly handled by a subsequent `Pen#readResolve()`. Callers are also no longer able to check or modify the foreground and background modes, instead only setting the desired paints. When loading legacy pens, a non-positive opacity is replaced with `1`. Callers thus no longer need to check for an opacity of zero. Legacy colors are no longer publicly accessible. Callers can just use the modern paints.

2025-11-05

Address further feedback, correct nonnull Halodto.

2025-11-04

Address review feedback, add new FACING/FLIP/INNER halo properties, resolve dto bugs.

2025-10-22

Merge branch 'develop' into feature/5786-token-halos-in-campaign-properties

Sync quadrant for dot states

Refactor the boolean token overlay hierarchy Classes in the hierarchy are either abstract or final, so there is no deep nesting anymore. The only real inheritance that is used now is when several types share a common structure, so can be handled in identical ways during rendering, persisting, etc. This makes the leaf classes generally quite simple, and in general it's easier to follow the rendering process for each implementation. The DTOs for overlays have been reworked to match the new inheritance tree. `BooleanTokenOverlayDto` no longer supplies all possible fields for all overlay implementations, but supplies only the common fields and a union of messages, one for each unique overlay structure. This is the new hierarchy: - `BooleanTokenOverlay` - `AbstractShapeTokenOverlay` - `CrossTokenOverlay` - `DiamondTokenOverlay` - `OTokenOverlay` - `TriangleTokenOverlay` - `XTokenOverlay` - `YieldTokenOverlay` - `AbstractFlowShapeTokenOverlay` - `FlowColorDotTokenOverlay` - `FlowColorSquareTokenOverlay` - `FlowDiamondTokenOverlay` - `FlowTriangleTokenOverlay` - `FlowYieldTokenOverlay` - `ColorDotTokenOverlay` - `CornerImageTokenOverlay` - `FlowImageTokenOverlay` - `ImageTokenOverlay` - `ShadedTokenOverlay` Compare with the old hierarchy: - `BooleanTokenOverlay` - `ImageTokenOverlay` - `CornerImageTokenOverlay` - `FlowImageTokenOverlay` - `ShadedTokenOverlay` - `XTokenOverlay` - `ColorDotTokenOverlay` - `CrossTokenOverlay` - `DiamondTokenOverlay` - `FlowColorDotTokenOverlay` - `FlowColorSquareTokenOverlay` - `FlowDiamondTokenOverlay` - `FlowTriangleTokenOverlay` - `FlowYieldTokenOverlay` - `OTokenOverlay` - `TriangleTokenOverlay` - `YieldTokenOverlay`

2025-10-19

Merge branch 'develop' into feature/5786-token-halos-in-campaign-properties

Halo shapes panoply

2025-10-17

Improve server syncs for lookup tables Instead of syncing the complete campaign properties via `ServerCommand#updateCampaign(CampaignProperties)`, we now have two other commands with more narrow protobuf message behind them: 1. `ServerCommand#putLookupTable(LookupTable)` which adds the lookup table to the campaign and syncs it to the server. Any existing table with that name will be overwritten. 2. `ServerCommand#deleteLookupTable(String)` which deletes the named lookup table from the campaign and sync it to the server. These are put to use both in `LookupTableFunctions` and in `LookupTablePanel`. An additional improvement in `LookupTableFunctions` is to only send sync the lookup table in cases where a change has actually occurred. If the state nothing has changed, we can save some overhead.

2025-07-19

Added translation light keys. Removed i18n from dto Removed null checks in LightSource removed redundant light-source xml

2025-07-15

i18n of Basic Campaign token type and property strings. Added i18nKey field to LightSource. Generated new default lights xml

2025-07-14

Move protobuf messages into messages project

2025-07-10

Move grid footprint definitions into code This was more involved than it seemed it should be: - The TokenFootprintCreator was out of date and did not have entries for all footprints. Had to add these manually. - Footprints must accept a GUID so that it can be stable across campaign saves. Previously, this could only be accomplished via XStream setting the `id` field during loading, but code had no way of doing the same. - Similar story for translations, it relied on a flag that could only be set via XML. This one is actually worse, since Java could well do constant folding and ignore our translations if it felt like it. Now constructors take an explicit `localizedName` parameter, and the footprint has a transient `localizedName` field that is also present in the DTO. TODO What is the raw name even used for? Could we get rid of it? TokenFootprint was also due for a bit of cleanup, e.g., making the public default constructor (which _is_ used in one place) actually initialize the object.

2025-04-18

Removed property token image rotation and associated references. Fixed problem with slider not updating in SpinnerSliderPaired with mouse wheel event

2025-04-09

Merge branch 'develop' into TokenLayout

2025-01-31

Added Drawing shapes; ArcDto,CubicCurveDto,LineDto,PolygonShapeDto,QuadCurveDto,RoundRectangleDto,Rectangle2DDto

2025-01-28

Merge branch 'RPTools:develop' into TokenLayout

2024-12-24

Add direction to walls Each wall can have a main direction (`Left`, `Right`) or be bidirectional (`Both`). Relative to the main direction, specific uses (`Sight`, `Light`, `Aura`) can be configured to respect the main direction (`SameDirection`), work in the opposite direction (`ReverseDirection`), ignore directionality and be bidirectional (`ForceBoth`) or ignore the wall entirely (`Disabled`). Movement also supports the `ForceBoth` and `Disabled` cases, but does not support direction itself and so does not have the `SameDirection` and `ReverseDirection` cases. Internally, the representation of walls got more complicated, but a future change will work to reduce that again. `WallInternal` now sports a mutable `WallData` that is capable of being overwritten and merged with `WallData` from other walls. Individual walls can have their data be updated through the new `UpdateWallMessage` message. The `WallData` is what carries the directional information for the wall. A new control panel gives access to changing wall properties. The currently selected wall will have its state reflected in the control panel, and modifying the values there will update the wall. When drawing a new wall, the current values from the control panel will be applied. The XML for walls has been extended to store the wall's direction and modifiers as child elements.

2024-12-11

Many things coming together

Updated TokenDto to handle refactored property names and new property imageRotation

2024-11-26

Add WallTopology to Zone This includes adding extending `ZoneDto` to include `WallTopologyDto`.

Mark legacy masks as masks, including in server commands As time goes on, we will rely less and less on masks and more and more on walls. Still, walls cannot completely replace masks and so masks need to remain a support, if separate, type into the future.

Introduce new topology types `MaskTopology` represents legacy masks as polygons. This is used in lighting and pathfinding algorithms, though the original `Area` is maintained and serialized in the model for the sake of existing tools and macros. `WallTopology` is a new form of topology, made of thin walls that form a graph. Edge wall (edge) blocks both vision and movement from any direction. The plan is to extend this in the future to control vision and movement separately, and to add directionality to the wall, but for now only the basic option is available. `WallTopologyConverter` ensures that `WallTopology` can be serialized without exposing the implementation details, and to make the XML look reasonable.

2024-11-22

Add support in the model for unique light sources - Methods on `Token` to add or delete unique light sources and look them up. - Support in `AttachedLightSource` to resolve against a `Token` in addition to a `Campaign`. - Support in `TokenDto` to transfer unique light sources. Attaching (turning on) a unique light source works exactly as for a campaign light source: the ID is added to the list. The only difference in behaviour between unique and campaign light sources is where the definition lives.

2024-11-19

Add support for landing maps Each `Campaign` now stores the ID of its landing map, if one is set. The user sets one using from the app menu, _Map > Set as landing map_. When a player client connects and the campaign has a landing map set, the client will look up that landing map to display first. This does not apply to GM clients. Also, the local client will prefer to stay on the current map if possible when starting and stopping a server.

2024-11-12

Remove the topology type set and related DTO

2024-10-24

Deprecate now-unused drawing types `Oval`, `Rectangle`, and `Cross` no longer serve a purpose and so have been deprecated. It is possible for existing campaigns to have these serialized in them, so we are keeping the structure around. However, each one will `readResolve()` itself into a modern type. Also be clear about the set of supported types in `ShapeDrawable`. The new `ShapeDrawable#getShapeTypeName()` outputs one of `"Rectangle"`, `"Oval"`, `"Polygon"`, `"Area"`, or `"Unknown"`, which callers can use to make meaningful decisions about the general type of shape wrapped in the drawable. This matters especially for ellipses, where several places refers to the simple name of `Ellipse2D.Float`, which is just `"Float"`. Now they refer to `"Oval"`, or use proper type checks where needed.

Increase number of shapes supported by protobuf `Path2D` is now transferable in addition to to `Area`, with the latter now being implemented on top fo the former. All `Ellipse2D` are now transferable, whereas previously only `Ellipse2D.Float` was allowed. We always use double precision for ellipses.

Perform zone topology edits through server commands The `ServerCommand.addTopology()` and `removeTopology()` have been merged into a single `updateTopology()` that handles both drawing and erasing. It also applies the changes to the local client so caller's don't have to remember to do that. All callers were already well-behaved here, but this change just cleans them all up and avoids the repetition conditions.

2024-06-11

Mark Grid fields as transient The movement keys, zone, and cell shape have no business being serialized. The cell shape was also removed from the DTO to match this.

Fix edge projection for stretched hex grids The edge projection was not always recalculated when the dimensions change. On top of that, it is not always half the edge length - that's only for regular hexagons. Now we always recalculate edge projection and edge length together, and relate them to the diameter propertly. There was one place where edge length was used where the diameter should have been used. Also remove a bunch of unused and commented out code, and caches for things that don't need to be cached.

2024-05-31

Revert "Merge branch 'develop' into release-1.15" This reverts commit cf937dab7f2c186164ef7929fa566988365b51ee, reversing changes made to 4ac15e49b074261fa54c1fb290525997f120c563.

2024-04-16

Remove zone ID from templates Now that zones are passed via methods, the templates don't use the zone ID for any real functionality anymore. Removing it cleans up a bunch of code, and avoids the need to make sure that templates have their zone IDs updated in various case.

2024-04-15

Rework LineCellTemplate path and bounds `calcPath()` has been simplified to essentially Bressenham's algorithm. It only calculates and returns a path, while `getPath()` (previously unused) will call it if needed. `getBounds()` now correctly accounts for the path's quadrant and the position of the first vertex to produce a correctly located and sized bounding box. This method was also simplified to only look at the two endpoints rather than iterating over the entire line. All fields except `pathVertex` are now marked as `transient` since they can be recovered from only `getVertex()` and `pathVertex`. Correspondingly, the quadrant is not longer part of the DTO, and the serialized XML is much smaller. With the above changes in, it was natural to simplify `LineCellTemplateTool` to avoid a lot of case work, especially in not relying on mutations of `getPathVertex()`.

Remove unused mouse slope state from LineCellTemplate

2024-02-03

Merge branch 'develop' into better-labels-dev-merge

2024-02-02

Add border width, colour, arc to text ui

added label border width/color

2024-02-01

Remove the unique light sources feature The refactorings that went along with the feature are still in place as they are good on their own. But unique light sources themselves have been removed along with the DTOs, UI, and I18N changes.

2024-01-12

Update labels

2023-12-30

Standardised around "ignores-vbl" and added additional required function updates. Removed Ignores VBL from SightSyntax.java as not wanted.

2023-12-26

Merge branch 'develop' into pass-through-lights

2023-12-23

Redone around the saner language of "ignore-vbl". Corrected some unnecessary calls and null checks. Updated Language for GB and AU.

2023-12-22

First attempt at lights-through-walls option.

2023-12-16

Change BEAM lights and sights to accept width instead of arc Width is measure in map units, so works the same as ranges.

2023-11-22

Refactored LINE to BEAM Undid unnecessary changes to LightSourceCreator Added BEAM to getShapedArea in IsometricGrid Removed commenting on some code in Grid Fixed issue with BEAM not being parsed for sight in Campaign Properties.

2023-11-21

All this in order to introduce ShapeType.LINE

2023-11-15

Simplify drawable management in Zone Rather than maintain separate fields for each layer, the fields `drawables`, `gmDrawables`, `objectDrawables`, and `backgroundDrawables` now packaged into a single map so that the required list can be looked up according to layer. Serialization backwards compatibility requires the original fields to still be maintained, but at runtime only the new `drawablesByLayer` is relied on, even for DTO conversions. Some other simplifications were done in this area, such as: - The fields can be `@NonNull` by ensuring the initializer and `readResolve()` set them. - The copying of the lists in the copy constructor can use the `LinkedList` constructor rather than `Collections.copy()` (`Collections.copy()` does not copy the elements themselves despite what the comments seemed to suggest). A bug fix was applied where zone IDs were only being consistently set for token-layer templates, and not for the others. We also now have `Zone.getDrawnElements(Zone.Layer)` that provides external access to the drawing by layer, rather than keeping four separate methods that require hardcoded layer names due to the method naming. This increased flexibility enabled a similar refactoring in `ZoneRenderer` so that the serparate drawable renderer fields could be handled uniformly in a single map as well.

2023-11-03

Implement light sources on tokens It is now possible for tokens to carry light source definitions, much like campaigns can. These new light sources are called "unique lights" as they are only available to the token that defines them. If any unique light source are defined on a token, they can be accessed like any other lights via the right-click menu, under the special category "Unique". In order to support lookup of such light sources, `AttachedLightSource#resolve()` now also accepts a `Token` for context, in addition to the `Campaign`. The token is checked first for a matching light source, then the campaign is checked as a fallback. For networking, the `TokenPropertyValueDto.lightSource` field was added back in because creating a unique light source now requires the complete definition to be passed. This commit does not add any way for a user to add any light sources to token. That will come later.

Simplify existing light source system The protocol for adding and removing lights was streamlined: since the light source GUID is the only piece needed for this functionality, that is now all that gets passed around via protobuf. Previously the entire light source definition was passed around for these operations. `AttachedLightSource` is now more encapsulated so that resolving `LightSource` from `GUID` is easier. Callers no longer need to bother with grabbing the `GUID` from the `AttachedLightSource`, nor do they have to know where to use it. Instead they can just ask the `AttachedLightSource` to do the lookup, providing only the `Campaign` for context. This will enable future changes to how light sources can looked up. `AttachedLightSource` has also been made immutable by finalizing the class and `lightSourceId` field.

2023-09-28

Beginnings of Cover VBL implementation.

2023-09-23

Beginnings of Cover VBL implementation.

2023-08-16

Descirptions for aliases

2023-08-03

Add display name to token property type and dto

2023-05-23

Add default property

2023-05-20

store stat sheet properties not just id

2023-05-18

Add Stat Sheets to tokens

update property type stat sheet

2023-05-14

move stat sheet to seperate config file

2023-05-13

Merge branch 'develop' of https://github.com/RPTools/maptool into feature-statsheet-overlay

2023-05-10

Fixes for Hero Lab tokens

2023-05-07

Add stat sheet to add-ons

2023-04-24

Merge pull request #3894 from sauliuskarmanovas/Issue-3890-MsgPlayerFinishedLoadingZone Show player loading status

2023-04-21

Merge branch 'develop' into Issue-3890-MsgPlayerFinishedLoadingZone

2023-04-19

Add lighting style to the ZoneDTO

2023-04-13

Handle nullabilty when converting LookupTable to DTO Each reference field in `LookupTable` and `LookupEntry` is marked as `@Nullable` or `@Nonnull` for clarity. `@Nonnull` is enforced for deserialized fields in `readResolve()`, with corresponding `null` checks in accessors being removed. Several `Boolean` accessors have been changed to `boolean` since nullability for these fields in an internal detail. In `toDto()`/`fromDto()`, all `@Nullable` fields are checked first whether a value exists prior to converting. The `visible` and `allowLookup` flags are now included in the copy constructor so that copied tables have the same flags set.

2023-04-04

Show players current zone and loading status in connections window

2023-03-23

add *notestype to protobuf and fill them

2023-02-16

Add a lumens overlay and make lights environmental The new lumens overlay is a visualization of the light strength at each point of a map. The strength of the light is determined by its lumens and - as always - darkness obscures light of equal or lesser lumens. The lumens overlay treats lumens less than zero as darkness and renders dark areas as black. On the other end, lumens of 100 or greater are treated as bright areas, and are rendered as a nearly transparent white. The final special case is lumens equal to zero, which is a representation of daylight and is not included in the lumens overlay. Any other lumens values are drawn as shades of grey, with low levels being nearly black, and with higher levels being closer to white. The environmental lights are an improvement to the aesthetics of lights. Lights now blend with one another "additively" (technically according to the Screen blend mode) so that they get brighter when they overlap. After blending the lights, the results are blended with the map using a blend operation that brightens the map while preserving details (similar to overlay blend mode and soft lighting). This make lights look more like they illuminate the map rather than sit on top of it. Both of these features can be toggled in the *View* menu depending on user preferences and game requirements. The lumens overlay can also have its opacity configured in the Preferences dialog, and the older light and darkness opacities have been removed. Lights no longer have an opacity congiguration since they are conceptually part of the map and not a layer rendered on top. In order to make the lumens overlay as useful as possible, the lumens values are now atached to individual light ranges rather than to entire light sources. Existing campaigns will have their light sources' lumens values copied to each range. The **Campaign Properties** dialog's _Light_ tab represents per-range lumens as by appending the lumens after the optional range color. So these are now valid ranges: ``` r#ff0000+100 r#aa0000+50 r+100 ``` These define, respectively, a saturated red range at 100 lumens, a desaturated red range at 50 lumens, and a colourless range at 100 lumens.

2023-01-10

Remove Direction enum since it is always CENTRE anyways

2022-12-09

reintegrate net/rptools/lib ressources

2022-10-13

Merge branch 'RPTools:develop' into develop

add data to assetDto

2022-10-07

Fix for NPE when using removeTokenFacing() Rather than try to pass a null through the DTO process, added new update type for removeFacing that doesn't take a parameter.

2022-09-09

Retain GM macros accross server start

2022-07-13

initialise CampaignProperties with default values only when wanted

2022-06-14

Most of HeroLabData's (String) fields are able to be null

2022-06-08

Explicitly initialize some more Token fields to avoid nulls The `Token` class expects to have a non-null shape, type and layer. Up until now, the fields could be `null`, although the accessors for these fields would detect this and return a real value (`readResolve()` does similar). This change makes it so that the Token class' initializer also sets these fields to their default values, so that all constructors will respect the defaults as well. This also means there is no more worry about these fields being null, which means the accessors can be simplified some and `toDto()` does not also have to handle `null`s. In a similar vein, we can infer from the `readResolve()` logic and usage that `name` and `exposedAreaGUID` do not need to support a `null` value either, and so this change also updates these fields to be initialized to real values.

2022-06-03

Add Hill VBL, Pit VBL and MBL to tokens New features --- - Macro functions for manipulating token topology - `getTokenHillVBL` - `getTokenPitVBL` - `getTokenMBL` - `setTokenHillVBL` - `setTokenPitVBL` - `setTokenMBL` - `transferHillVBL` - `transferPitVBL` - `transferMBL` - Token topology is rendered in distinct colours for each topology type. - Color sensitivity for auto-generated topology is remembered per topology type. Internal changes / refactorings --- - Token model now has fields for Hill VBL, Pit VBL and MBL in addition to the existing Wall VBL. - Token model update command `setVBL` has been replaced by `setTopology` which requires a topology type to be sent as well as the area. - Protobuf Token DTO has been extended to support the new fields. - The macro function code under `Topology_Functions` was refactored so that each kind of function is handled by a separate method rather than keeping all that code in a single method under an if/else chain. - `Zone` and `ZoneView` only expose topology via `TopologyType` rather than having distinct methods for each kind of topology. - Topology caching in `ZoneView` has been revamped. - `ZoneView` no longer caches the token topology `Area`s and instead just caches the total topology of the map plus tokens. - `ZoneView` now caches the topology `Area`s for each topology type instead of just the `AreaTree`s. This benefits the A* walker because it needs the `Area`s but previously had to rely on the expensive `AreaTree`s. - The cached `AreaTree`s are now only needed internally to `ZoneView`, for passing to the FoW calculations. - Most methods with the term "VBL" in the name now use "topology" to make clear that they are more general. Bug fixes --- - Subtle issue in A* algorithm to only subtract token topology from total topology of the same type. Previously a token's Wall VBL would be subtracted from all topologies. VBL => topology

2022-02-04

Handshake: Change symmetric key algorithm to CBC The "AES" cipher is "AES/ECB/PKCS5Padding". ECB mode ciphers are susceiptible to replay and chosen-plaintext attacks and while there's no known possible vulnerabilities using them some cipher suites may not support ECB mode as a precaution which makes interoperability more difficult. The 16-byte block size already makes a codebook attack impractical, but adding an IV makes it even less so as recorded codes from previous sessions can't be reused.

2022-01-22

protobuf changes (#3348) * start with protobuf stuff * start with protobuf stuff * tested addTopology * changeZoneDisplayName -> protobuf * clearAllDrawings -> protobuf * clearExposedArea -> protobuf * start with draw -> protobuff (Mapping missing) * add more mapping methods * add mapping for Shape. Drawing should work now. Testing needed. * spotless * test and correct draw server call * editToken + putToken -> protobuff TODO: Mapping Token <-> TokenDto * editToken + putToken -> protobuff TODO: Mapping Token <-> TokenDto * add mapping Token -> DTO * fix merge * add mapping for Token and HeroLabData * add mapping for MacroButtonProperties * add mapping for AttachedLightSource and Pathd * putToken + editToken done * execFunction, enforceZoneView, enforceZone, enforceNotification, to protobuf * exposePCArea, exposeFoW, execLink, to protobuf * movePointer, message, hidePointer, hideFoW, heartbeat, getZone, getAsset, to protobuf * putAsset, playerDisconnected, playerConnected, to protobuf * fix merge * putLabel + putZone -> protbuf TODO: Mapping for zone * refactor mappings. Missing Mappings Grid, InitiativeList, Zone(todto) * Mapping for Zone + InitiativeList. Missing Mappings Grid * spotless * Grid mapping * restoreZoneView, renameZone, removeZone, removeTopology, removeTokens, removeToken, removeLabel, removeAsset, to protobuf * fix merge * sendTokenToBack -> protobuf * add dto for Campaign + Tokenoverlays * add a bunch of mapping code. Does not build yet. * all mapping for setCampaign done * convert more message to protobuf * added all protobuf definitions * get rid of Command enum * repaired ServerMethodHandler and rename to ServerMessageHandler * repaired ClientMethodHandler and rename to ClientMessageHandler * repaired all * removed hessian * clean up * clean up * clean up * clean up * clean up * merge develop * fix NPEs * spotless * fix asset transfer * more fixes * more fixes + heartbeat disabled Co-authored-by: Phergus <34379254+Phergus@users.noreply.github.com> Co-authored-by: Craig Wisniewski <craig.wisniewski@gmail.com>

2021-11-25

Readme/License

updates to dialog

2021-11-21

Pending connections is now disabled if not on server, and client gets a better message if denied

2021-11-18

.

2021-11-14

Resolves #2001 and #1104 by adding in three checkboxes on server start. Two use existing server policy entries to stop certain player behaviors on server start and the other stops players from inserting tokens from their own client if the GM does not wish them to. This fix feels a bit gross but maybe I did it correctly? Maybe someone who knows swing better should take a quick look. Merge develop

2021-11-06

add-on onInit functions

2021-11-05

events start

typos

2021-11-03

If I was a better planner I would've done this on two different branches but oh well. Resolves #2001 and #1104 by adding in three checkboxes on server start. Two use existing server policy entries to stop certain player behaviors on server start and the other stops players from inserting tokens from their own client if the GM does not wish them to. Finishing up some testing because my drag and drop on my dev builds seems to be broken but I'm unsure if that is due to any of my changes or something weird with how I'm building/running it.

2021-11-02

add export/import undefined data

send data on connect to server

Sending of game data to clients

2021-11-01

save and load game data

2021-10-31

Merge branch 'develop' of github.com:RPTools/maptool into game-data