Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
MarkBell

Avatar / Picture

Administrator
Registered:
Posts: 1,955
Reply with quote  #1 
With the release of 2.7.5, please put all development suggestions in this thread.
__________________
Note - this is in no way intended to be an official position of Thom or Artemis, as I am not an official representative of the creator or game.
DrProid

Registered:
Posts: 2
Reply with quote  #2 

Please can you add more engineering keybinds? This has been on many peoples wish list for years. I know its a lot of binds but it would open up the possibility to create incredible physical interfaces. Currently the only method for making interfaces for engineering is the macro cycling method using 'ENG_NEXT_SYSTEM' and 'ENG_PREV_SYSTEM' which is kind of hacky.

Ideally, we need both analog control over the power and incremental control over coolant for each individual engineering system.

An example of the analog binds that could be added:
ANALOG_ENG_BEAM
ANALOG_ENG_TORPEDO
ANALOG_ENG_SENSOR
ANALOG_ENG_MANEUVER
ANALOG_ENG_IMPULSE
ANALOG_ENG_WARP
ANALOG_ENG_F_SHIELD
ANALOG_ENG_R_SHIELD

An example of system selection and coolant key binds:
ENG_SELECT_BEAM
ENG_SELECT_TORPEDO
ENG_SELECT_SENSOR
ENG_SELECT_MANEUVER
ENG_SELECT_IMPULSE
ENG_SELECT_WARP
ENG_SELECT_F_SHIELD
ENG_SELECT_R_SHIELD
ENG_SET_COOLANT_0
ENG_SET_COOLANT_1
ENG_SET_COOLANT_2
ENG_SET_COOLANT_3
ENG_SET_COOLANT_4
ENG_SET_COOLANT_5
ENG_SET_COOLANT_6
ENG_SET_COOLANT_7
ENG_SET_COOLANT_8


I know this is a lot to ask, but if you did this it would really mean a lot to the community.

(Edit: I improved my example)

NoseyNick

Avatar / Picture

Registered:
Posts: 105
Reply with quote  #3 
Quote:
Ideally, we need both analog control over the power and incremental control over coolant for each individual engineering system.


Can I recommend that instead of USB HID, you consider talking the TCP protocol to the server?

If you want, you could send https://artemis-nerds.github.io/protocol-docs/#udp-server-discovery to find servers, but it's probably easier if you know the server's IP address in advance.

You'd need to connect to the server, on TCP port 2010.

You need to understand https://artemis-nerds.github.io/protocol-docs/#packet-structure to wrap the rest of the packets in:

You'd need to send https://artemis-nerds.github.io/protocol-docs/#setshippacket to say which ship you'd like to be on.

You DO NOT need to https://artemis-nerds.github.io/protocol-docs/#setconsolepacket - a "real" client would do so, to "claim" the engineering console, but if you did that, then you couldn't use it on your "real" client. Despite NOT claiming Engineering, you can still send...

https://artemis-nerds.github.io/protocol-docs/#engsetcoolantpacket to set the coolant of any system, 0-8

https://artemis-nerds.github.io/protocol-docs/#engsetenergypacket to set the energy level of any system, 0-300% (actually 0.0 to 1.0)

Apart from "how numbers are encoded" that's almost all you need, but let us know if you need any help.

DrProid

Registered:
Posts: 2
Reply with quote  #4 
Quote:
Originally Posted by NoseyNick
Can I recommend that instead of USB HID, you consider talking the TCP protocol to the server?


I didn't know this was possible. Thank you so much. This changes everything.
NoseyNick

Avatar / Picture

Registered:
Posts: 105
Reply with quote  #5 
Quote:
I didn't know this was possible. Thank you so much. This changes everything.


It's certainly not very OFFICIAL, but it does allow you to be able to do everything a real client could do AND POSSIBLY MORE. An example I've seen is a single self-destruct button which will set red alert, come to a halt, take shields down, set all coolants to zero and all eng energy levels to 300%, and send a distress/farewell message to all player ships. I guess you COULD do this manually by switching back and forth between the relevant consoles, but not if someone else already had engineering or helm "taken", and certainly not all so quickly within a second   [cool]

If you want to learn how to decode the RECEIVED packets, that's quite a bit more complicated, but can enable all sorts of other fun stuff too. See for example the big LED damage display on the RHS of https://photos.app.goo.gl/FsF9w2feMBLmLnM86 - it's not currently showing damage, but is showing a ship plan and the locations of repair crews. When the ship takes damage, red squares appear, and you can see the green-ish repair crews head off toward those sectors of the ship and perform repairs. This is pretty much the same damage info you'd see in Engineering, but mapped onto a big 12x12 grid of LEDs.

Probably your biggest risk of taking the TCP approach is that if/WHEN Thom changes the protocol, you'll be stuck on version N until the artemis-nerds community have reverse-engineered the new packets / structures / formats (which you might be able to help with, if you have the skills) AND you've had time to implement them into your console code, before you can upgrade to version N+1.

... for example 2.7.5 brought with it a ClientHeartbeat, so it turns out you'll now need to know that too, otherwise your consoles will be kicked/ignored after about 12-15sec. Currently being reverse-engineered in https://github.com/artemis-nerds/protocol-docs/issues/194 - looks fairly easy though.


NoseyNick

Avatar / Picture

Registered:
Posts: 105
Reply with quote  #6 
Quote:
See for example the big LED damage display on the RHS


Ah see also https://photos.app.goo.gl/PR7UDfmnSpikJybT6 - I KNEW there were better pics somewhere   [biggrin]
LawsonThompson

Registered:
Posts: 623
Reply with quote  #7 
Option Persistence: Make the client-side options "stick" between missions. 

There's a thread called "persistent UI states" asking about this one. It's got my vote, since Nov 2018.

Note: It appears 2.7.5 persists the Damage Visibility while the client is running, but no options persist after game exit.

__________________
----
Visit us at http://www.ltebridge.com
EricF

Registered:
Posts: 15
Reply with quote  #8 

Newbie question here: what would folks generally say is the forum etiquette on re-posting suggestions from previous dev threads? With several new versions released recently, a couple of good ideas are drifting their way down the forum now in the suggestion threads for 2.7.4 and 2.7.3: would we prefer to see those stay in their original threads, or is it reasonable to re-post them here in the latest thread if there's still interest in the suggestion?

Xavier Wise

Registered:
Posts: 1,134
Reply with quote  #9 
I'd suggest linking to the single message if it is something that you are "up-voting"/ think is something that should be added, or if there are several ideas, writing a bullet point summary so they are not lost. 

From what I understand, Thom does keep an eye on suggestions, along with Mike S, and they are considered. They might be on a "to-do" list somewhere, or may have even been considered and, for some reason or another, dropped.

__________________
Fleet Captain Xavier Wise - TSN Sabre
Link to TSN RP Community website
HaydenBarca

Registered:
Posts: 136
Reply with quote  #10 
Add "Avoid Black Holes" to the brainstack of monsters and ships, or at least the ones destroyed by them (like Whales).  As it is now, Whales swim blissfully to their deaths.

Additionally, give the option to assign brain stack commands to a monster or ship type instead of just uniquely named ones.  As it is now, if I want to write a mission that includes 24 whales on the map and have them act other than default brain stack (such as to avoid black holes), I need to clear and recreate the brain stack 24 times for each named individual.  It would be much better to be able to do that once for all whales.
Mike Substelny

Avatar / Picture

Administrator
Registered:
Posts: 2,399
Reply with quote  #11 
Quote:
Originally Posted by HaydenBarca
Add "Avoid Black Holes" to the brainstack of monsters and ships, or at least the ones destroyed by them (like Whales).  As it is now, Whales swim blissfully to their deaths.

Additionally, give the option to assign brain stack commands to a monster or ship type instead of just uniquely named ones.  As it is now, if I want to write a mission that includes 24 whales on the map and have them act other than default brain stack (such as to avoid black holes), I need to clear and recreate the brain stack 24 times for each named individual.  It would be much better to be able to do that once for all whales.


I could rationalize that its a good, challenging game mechanic. The players have beacons that can repel whales from black holes. Players who successfully protect whales from committing suicide by singularity can be seen as more successful than those who fail.

__________________
"The Admiralty had demanded six ships; the economists offered four; and we finally compromised on eight."
- Winston Churchill
NoseyNick

Avatar / Picture

Registered:
Posts: 105
Reply with quote  #12 
Need a 64-bit version. Is that as simple as a compile-time flag, or is it way more involved?

MacOS users who upgraded to Catalina lost the ability to run 32-bit apps, even under WINE.
LawsonThompson

Registered:
Posts: 623
Reply with quote  #13 
Quote:
Originally Posted by NoseyNick
Need a 64-bit version. Is that as simple as a compile-time flag, or is it way more involved?

MacOS users who upgraded to Catalina lost the ability to run 32-bit apps, even under WINE.


There's a version of WINE patched for 32-bit Windows on 64-bit MacOS which might work for you:



I'm tempted to try VirtualBox on MacOS running Windows 10. 


__________________
----
Visit us at http://www.ltebridge.com
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.