|
IL-2 Sturmovik The famous combat flight simulator. |
|
Thread Tools | Display Modes |
#1
|
||||
|
||||
New server controller - any input?
I've been writing a server controller, mainly because I wanted a controller that offered a simple way of running a DCG campaign for just a few people, but also as an exercise to introduce myself to writing programs in Java, and later in Clojure. I actually wrote a lot more functionality in pure Java before I became frustrated with the awkward multithreading features and started rewriting the whole thing from scratch a few days ago. This is what is working so far:
Things that were tested in the Java-only branch and shouldn't take me too long to restore:
Planned features:
Features I'm not planning to write:
Anybody have any suggestions/input/comments? Last edited by TheGrunch; 12-25-2013 at 05:03 AM. |
#2
|
|||
|
|||
Sounds pretty good
Do you intend to implement any target features like target circle percentage or target counts (x cars, x tanks, x static aircraft, etc.). FBDj development seems to have ended and a new daemon to take its place some day might be nice. Not to freak you out
__________________
Find my missions and much more at Mission4Today.com |
#3
|
||||
|
||||
Not initially, as parsing the eventlog is a much bigger job than just chat and the server console due to the variety of different event types, but I wouldn't rule it out!
Sent from my ST23i using Tapatalk |
#4
|
||||
|
||||
Things are going well, mission state is now parsed from the server console output and the UI is updated to suit the current state:
An .ini configuration file is now generated and parsed back into the controller. Next on the list:
|
#5
|
||||
|
||||
Still putting a few hours into this every couple of days. I don't outwardly have anything much to show for it though, other than silent loading & saving of properties when the program is closed & opened.
Recent changes have involved migrating to a different packaging method (JavaFX Ant tasks instead of JavaFX Maven plugin) a different build tool (Leiningen instead of Maven), adopting a license (the Eclipse Public License), performance improvements by the use of a lot of type hinting to eliminate uses of the Reflection API at runtime, and a lot of refactoring as I've learnt more about Clojure in general. I've also eliminated a lot of niggles in the way I was manipulating the difficulty settings table control. Hopefully I can get back to making a mess of my code with new features now that I've spent a couple of weeks tidying it up! |
#6
|
||||
|
||||
IceFire, on this topic, and on the more general topic of dealing with in-mission events, what would you say is the most important list of capabilities for a server controller that reacts to events so that I have some idea of where this could go?
|
#7
|
||||
|
||||
Still chipping away at this when I can. As part of optimising the program I managed to remove all outstanding text parsing bugs that I was experiencing and reduce memory usage by nearly 100% from nearly 200MB to under 100MB!
I have also substantially decoupled the JavaFX interface from the application logic and documented the program thoroughly. It's now potentially possible for someone to write (for example) an Android app which makes use of this application's logic but which provides a different UI with extremely minimal alterations to the existing code. Now I really do need to stop messing about and get it to actually load missions! |
#8
|
||||
|
||||
I've made a lot of progress, but the last week and a half has been eaten up struggling with a really aggravating bug:
Mission paths from the text field work 100% of the time, first time, every time. Mission paths from the file chooser fail the first time, every time, and work after that. I have actually gone as far as booting up Wireshark to take a look at what is actually being sent via TCP, and the data sent in both cases is identical, right down to the line ending characters. Completely baffled! |
#9
|
||||
|
||||
As mentioned in the Daidalos team subforum, I have now solved the problem above (turned out to be network share configuration rather than a code defect).
Now working on the mission cycle scheduler! |
|
|