This attribute is calculated at each update of the boat as prompted by the game state regularly
Removed the lat and lng attribute from the Yacht class and replaced its usage with the GeoPoint object instead
Removed redundant test files and merged GeoUtility and testGeoUtil test classes into one
tags: #story[1124] #pair[hyi25, wmu16]
Big boy merge request. Issue 34. Issue 35.
# This merge request is to fix **Issue 34** and **Issue 35**
*This is will require some further work but is being added to develop as is*
# Changelog
## Mark classes from server now used in client also.
The mark setup client side was poor because all marks were of type AbstractMark but they all had different methods so you had to identify what kind of mark they were anyway. The server side implementation
used the same calls for all Mark types and had the bonus of a GeoPoint class with utilities for distance and calculations.
## Yacht Class now contains observable values
The yacht attributes used by the model are now observable.
## StreamParser now static utils class.
Data no longer needs to be stored in the staticly available thread. Can now be processed in a more direct fashion by classes calling the parsing utils when needed.
## XMLParser now static utils class.
XMLParser now converts XML formatted doc objects and returns the containing data, this removes the need for the class to store multiples kinds of XML data and can instead just return it for use elsewhere.
## Data storage classes added to java/seng302/model/stream/parser
Rather than the StreamParser updating the Model directly it just processes the data into basic data types and shoves it all into objects for processing elsewhere. This avoids the static StreamParser class needing to know about Model objects.
## All static ultilities moved to their own package to make them easier to locate. Any child classes moved to their own files and added to packages in the model package.
## All visualiser code moved to the a new visualiser package
## Grouped all high level logic for the app and data management.
Previously all the high level logic (e.g. when to start a race, what fxml to show, how to process data from the stream) was in a number of classes. Mainly StreamParser, Controller, StartScreenController, RaceViewController, BoatGroup and LobbyController. All of this has been grouped into GameClient.
* This reduces the need to share data between these classes. Previously all the controllers needed references to one another to work so they were essentially the same class anyways.
* This makes it easier to find specific logic.
* Everything is now accessabile from GameClient, or from something GameClient knows about, making it easier to pass information if needed.
## Logic removed from LobbyController. Now only displays information
## Annotation box now a generic case for a rectange containg any number or type of annotation.
This means that if any new annotation needs to be added you don't have to hard code a specific case for it. Just initialize the annotation in the box at anytime.
## GameClient now observes the state of Yacht and Marker classes for position changes and updates them accordingly.
This avoids having to pass data to the GameView and having to poll for changes.
## CanvasController renamed GameView, now only concerned with displaying the race.
Moved all unnecessary logic to GameClient. Also fixed some issues where it polled RaceViewController for data instead of being updated by RaceViewController.
## MarkerObjects now a simple circle bound to the location of a given Mark. To display a gate lines are bound between the circles bound to Marks if a CompoundMark has more than one Mark.
Made all the logic here much more straight forward.
## Replaced most public static data classes with listeners.
Removed a bunch of polling. Made sharing data simplier and more readable.
# Known Issues & Limitaitons
* Pretty much everything that wasn't working at the end of sprint 5.
* Because listeners are triggering stuff on the JavaFX thread you have to use `Platform.runLater(() -> {//Do stuff});` whenever you want to access FX stuff from other threads. You can't just be lazy and put everything in it because then the JavaFX thread goes really slow. This is actually good practice anyways since you want to process data off of them FX thread (so not anything that's not triggered by a controller or an event) to keep JavaFX responsive.
* There is a 100% chance stuff has broken with this refactor that I'm not aware of. Some of it I am aware of.
# Testing
Good joke. I did manual testing though.
# Acceptance criteria
It works more or less.
See merge request !50
- Mark order is read from the generated RaceXML and stored
- Added .getNextMark() to get the next mark in the race
- Added .equals() and .hashCode() for Marks
Tags: #story[1124] (Task 1)
- Race status messages are sent at regular intervals instead of once at race start
- Boat positions are initialised on the Team Position list
- Timer counts up from when host clicks ready
Tags: #story[377]
Zhi You Tan
William Muir
Kusal Ekanayake
Calum
Michael Rausch
Alistair McIntyre
Haoming Yin
Peter Galloway