New server controller - any input?

[TheGrunch]

http://www.youtube.com/watch?v=yLqR5khwDcU
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:

Written in Java/Clojure so very portable - DCG features will only work on Windows though.
Direct access to the remote server console via a TCP socket connection to view output and enter commands.
Intelligent parsing of console output - at present difficulty settings are parsed from the server at runtime before they are loaded into the table in the Settings page. This means that I won't have to rewrite the program every time DT add a difficulty setting.


Things that were tested in the Java-only branch and shouldn't take me too long to restore:

Local mission selection - when you are running the server on the local machine, you can simply select the server .exe and the .mis file and you will be able to load the selected mission.
Remote mission loading using direct path entry - when you are using the server remotely you can enter a path for the mission to load.
DCG integration - the Next button generates a new DCG mission and when complete, loads the mission. This can only be done when the server is running locally or when the server directory is accessible over a network share.
Easily editable .ini configuration file.


Planned features:

Mission cycle configuration.
In-game control via chat - enter commands on chat to control the server.
Simple pilot management. I don't envisage this being extremely detailed.


Features I'm not planning to write:

Statistics.


Anybody have any suggestions/input/comments?

[IceFire]

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 :D

[TheGrunch]

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

[TheGrunch]

Things are going well, mission state is now parsed from the server console output and the UI is updated to suit the current state:
http://www.youtube.com/watch?v=y7oi_53AbHE
An .ini configuration file is now generated and parsed back into the controller.

http://img.photobucket.com/albums/v218/TheGrunch/IL-2%20Sturmovik%201946/2013-12-2716_58_40-il2ssdini-Notepad_zpsdbb0f3d0.png

Next on the list:
to design and implement the mission loading UIs for single, cycle and DCG modes
to make the controller actually do something with the bit of information that it gets back:
[:file [:mission [:setting Mode single]]
[:server [:setting Port 21003] [:setting IP 192.168.1.254]]]

[TheGrunch]

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!

[TheGrunch]

Do you intend to implement any target features like target circle percentage or target counts (x cars, x tanks, x static aircraft, etc.).

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?

[TheGrunch]

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!

[TheGrunch]

I've made a lot of progress, but the last week and a half has been eaten up struggling with a really aggravating bug:
Il-2 Simple Server Daemon early work 3 (http://www.youtube.com/watch?v=MW-zBFU03-U)
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!

[TheGrunch]

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! :grin: