- Boats now collide with marks
- Added method to MarkOrder to get all marks
- Reduced the frequency at which collisions are detected. This fixed some performance issues
- Added method to bounce the boat off a mark
Tags: #story[1117]
Created and updated methods reading yacht event packet to translate to collision alert on visualiser.
WIP: sending yacht event packet to inform collision
#story[1117]
boats now must pass through the correct way. This works for start in-race and finish gates
Refactored yacht algorithm code for better readability
Logging function added or seeing mark roundings occur
tags: #story[1124] #pair[hyi25, wmu16]
Mark rounding works for whole course (WITH BUGS)
Still some gate logic to work out.
Moved gate function to GeoUtil class
tags: #story[1124] #pair[hyi25, wmu16]
Removed RacePosition class. Instead marks are just grabbed from the mark order class when necessary.
No marks are stored as an attribute in the yacht class but the 'currentMarkSeqID' which is used to get current, and surrounding marks.
Works for all marks in between but not including starting and finishing gate as no angle can be made with them. Still to work out how to implement this
#story[1124]
Created a second prototype function which is more testable compared to the initial design. New function takes in parameters (starting marks, yacht starting position, yacht) and initialise yacht correctly with position.
#story[1117]
Loading mark sequence from RaceXML
# Loading mark sequence from RaceXML
## Change Log
1. Added MarkOrder class
* 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
* NEW: Added RacePosition class to hold players position in the race
* NEW: Fixed issue where the duplicates weren't stored in the mark order
## Testing
* Unit tests in models/MarkOrderTest.java
## Acceptance Criteria
* Use the mark sequence in the raceXML
* Met by change log item (1)
* Store relevant mark details with each participating boat (Last mark, next mark)
* Method in MarkOrder to get next mark, however the last mark and next mark will need to be stored by whoever implements the second task.
See merge request !52
- Re-engineered code to work with the new marks
- Fixed bug where race order wasn't correct (added RacePosition class to fix)
- Rewrote tests to work with new RacePosition class
Tags: #story[1124] (Task 1)
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
William Muir
alistairjmcintyre
Michael Rausch
Calum
Zhi You Tan
Kusal Ekanayake
Zhi You Tan
Haoming Yin