abrindam / artemisengineeringclient Goto Github PK

There seems to be a thread leak with the audio code. A new thread is created every time a sound is played and never goes away.

Looks like we need to explicitly close the clip (thanks Java):
http://stackoverflow.com/questions/2792977/do-i-need-to-close-an-audio-clip

The engineering console options shows three visualization options and one "off" setting. Not sure what they do.

So people have some idea of what it actually looks like!

Some video would be awesome too.

There are several places in the code where we do getPlayerShip(0). This probably will break in a game with multiple ships.

Current development has been against a much older version of Artemis. We should support the latest, 2.4.0, to get all the good stuff that's been added!

As part of this, we will need to upgrade from ArtClientLib to IAN (Interface for Artemis Networking)

If the server drops us, or a proxied client drops, need to handle cleanly, including sending a clean disconnect to the other side if proxying.

If the user quits our client, we need to send a clean disconnect to the server (and the proxied client if proxied).

If we can support all features of the vanilla client, we don't need it. Do we keep it anyways? Do we support it in the meantime?

Parity: master volume

Enhancement: different audio levels for different events e.g. damage, DAMCON comms, beeps and bleeps, etc.

Would provide a much more immersive experience.

See font offset sizing being different on Windows (is that hardcoded or one of the ones we measured?). Also see that font with background color behind it looks awful.

If safety mode is enabled, energy and coolant will be incremented together in increments of coolant units. Increasing beyond amount of available coolant will not work.

An override modifier (such as shift) could permit having energy exceed coolant.

We need to determine which of the DXS files in Artemis\dat correspond to which ships.

In #20 we updated from ArtClientLib to IAN, but had to build our own version as an official build was not yet available.

Per https://github.com/rjwut/ian/releases there are now official releases available. The latest is 3.1.1. We should use that.

The vanilla engineering console displays some stats that are not specific to engineering such as shield levels, etc.

Something like a small white triangle pointing at the current power level would be nice. Maybe one for coolant on the other side too.

Display historical energy consumption to help engineer monitor what's happening. Over last 5 min perhaps?

People won't want to launch the client with command line arguments. Need an initial splash screen to collect server info. Also implies allowing connect/disconnect/reconnect without having to relaunch client.

In ConnectPanel

On Windows, or at least at 1920x1080, the shield bar icons look awful.

Options:
-Do better scaling?
-Create pre-sized icons?
-Other?

If preset titles are too long, they'll run off the right edge of the screen. We should truncate them once now, and if we get more dynamic layout later, do it dynamically.

Something with a stylized placement of "AEC" could work.

Reproduction:
-Host game
-Start game
-End simulation
-Connect client
-End game
-Start game
-Observe stack trace and game over message after timeout

Exception in thread "Thread-10" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
    at com.walkertribe.ian.iface.ListenerMethod.offer(ListenerMethod.java:106)
    at com.walkertribe.ian.iface.ParseResult.fireListeners(ParseResult.java:84)
    at com.walkertribe.ian.iface.ThreadedArtemisNetworkInterface$ReceiverThread.run(ThreadedArtemisNetworkInterface.java:336)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.walkertribe.ian.iface.ListenerMethod.offer(ListenerMethod.java:100)
    ... 2 more
Caused by: java.lang.NullPointerException
    at com.brindyblitz.artemis.engconsole.RealEngineeringConsoleManager.lambda$14(RealEngineeringConsoleManager.java:309)
    at com.brindyblitz.artemis.utils.newton.DerivedProperty.doUpdate(DerivedProperty.java:22)
    at com.brindyblitz.artemis.utils.newton.DerivedProperty.lambda$0(DerivedProperty.java:15)
    at com.brindyblitz.artemis.utils.EventEmitter.lambda$0(EventEmitter.java:33)
    at com.brindyblitz.artemis.utils.EventEmitter.emit(EventEmitter.java:18)
    at com.brindyblitz.artemis.utils.newton.ObservableAdapter.triggerChange(ObservableAdapter.java:13)
    at com.brindyblitz.artemis.engconsole.RealEngineeringConsoleManager.lambda$20(RealEngineeringConsoleManager.java:59)
    at com.brindyblitz.artemis.utils.EventEmitter.lambda$0(EventEmitter.java:33)
    at com.brindyblitz.artemis.utils.EventEmitter.emit(EventEmitter.java:18)
    at com.brindyblitz.artemis.protocol.EnhancedSystemManager.fireChange(EnhancedSystemManager.java:97)
    at com.brindyblitz.artemis.protocol.EnhancedSystemManager.onPacket(EnhancedSystemManager.java:64)
    ... 6 more
Object update timeout
Switch to GameOver

Will require displaying 3D model of ship and allowing user to interact with it.

Let's make reference to which "radio channel" you have selected on your DAMCON comms control panel, e.g. DAMCON Channel or D/C CHAN. That makes much more sense than something like Selected DAMCON Team.

I'm not sure if it's recent changes or just bugs, but the in fake mode, pressing any key causes the UI to redraw all over itself a bunch of different ways.

Also, the font looks atrocious on Windows wherever it's overlaid on top of a colored bar.

See attached:

The client is meant to be heavily keyboard oriented but it wouldn't hurt to support the mouse as well.

We update the damcon UI on every network packet. This is causing close to 200% CPU usage on my computer and is making command not take for minutes at a time.

This manifests itself in two ways:

1. View of ship is inconsistent with display in official clients
2. Orders are reversed - you tell damcon teams to go to the port node and they go starboard.

This should work on a wide variety of resolutions and also hopefully support touchscreen use, which means the UI and window sizing needs to be flexible.

The current version is intended for use with a standard mouse scroll wheel. If you use a trackpad that generates scroll events (e.g. two-finger scrolling on Macbooks), the scroll rate is off.

See UserInterfaceFrame.java: this.setIconImage(new ImageIcon("assets/art/aec_thumbnail.png").getImage());

Don't forget to respect minimum size. Was having issues with JPanel refusing to resize.

When you first load the UI, it doesn't show any damcon teams. If you damage something, they start moving automatically and then appear out of nowhere.

Need to handle knowing where they are initially.

The Robot class can set mouse position and the cursor can be hidden. A quick crack at the first one had some weird results, but this shouldn't be too hard. We may have to write our own version of mouseDragged() to work around this, which is easy.