Use cases for the countdown clock

[Decksmeck]

At stations when doing something wrong, a count down clock appears allowing the player time to make corrections.

Other use cases for this mechanic exist.

Use case 1:
Deploying hardpoints during an interdiction by security forces.

Use case 2:
NPC pirates request the jettison of cargo.

Question:
Can the countdown timer be reprogrammed to be used by one player on another as a consise way to communicate a demand?

Player creates a timed event from a template by writing or choosing a message and selecting a time period.

Use cases similar to the way it can be used by NPCs.

Use case 1:
Player pirates another player by issuing a timed event which was previously setup. It delivers a message and starts a countdown timer visible to both players.

 

[Tiili]

Would be awesome to have something like this, typing the same message thousands of times or having autohotkey send it to the wrong channel is starting to get quite old

The only timer that's relevant for piracy right now is the logout timer, and the only way to make sure people aren't waiting for it is to ask them to spam the chat every couple seconds with nonsense. Would be cool to have some UI element telling us if the other commander is playing or in the menu as well.

 

[Decksmeck]

What if upon disconnection, the computer just complies with the request. Like it jettisons the cargo. Then despawns.

Or if that doesn't work technically, when you issue the demand, maybe the computer can, somehow behind the scene, place the cargo in a jointly owned container between pirate and victim. If anyone disconnects, their claim is relinquished. Not sure how to make that work knowing little about the programming.

 

[varonica]

What if upon disconnection, the computer just complies with the request. Like it jettisons the cargo. Then despawns.

1) That's not really how P2P works, 2) I could manipulate the mechanic by making all my targets appear to disconnect by DOS'ing their IP address, thus forcing them to drop cargo whether they wanted to fight or not, easy pickings.

 

[Decksmeck]

1) That's not really how P2P works, 2) I could manipulate the mechanic by making all my targets appear to disconnect by DOS'ing their IP address, thus forcing them to drop cargo whether they wanted to fight or not, easy pickings.

I don't know how their P2P model works.

 

[varonica]

I don't know how their P2P model works.

Peer 2 Peer, there's not much else to know, the data in a P2P setup, in this case combat between two players, is transferred directly between each player, so I can use any one of hundreds of pieces commonly used software to find out your IP address, attack you, fire up a DOS attack that will effectively disconnect you from the internet by flooding your inbound port and as far as the game is concerned you disconnected in the middle of combat, therefore I get your stuff.

 

[Decksmeck]

Yeah P2P seems kind of exploitable. They need to have a different configuration to connect peers. Though a middle man is going to introduce latency. P2P2P. The middle P is a peer that hosts an instance that doesn't involve him. The middle P is in turn the left or right P in another peer relationship.

The middle P performs exchanges of data between his sub branches. A DOS against him would disconnect pirate and victim.

Though this wouldn't stop plain griefing where the middle P launches a DOS against a branch.

 

[Decksmeck]

Also, maybe P2P2P2P2P in a circle where the first and last P are the same P. Then network traffic is in a circle. Then the two middle Ps are linked as well. These 2 middle Ps are servers.

Don't know. Would need a computer science expert to work it out.

Edit: had to add P.

 

[Decksmeck]

Latency aside, because the following introduces 2 additional hops. Imagine P2P2P as a triangle. This inner triangle is a peer host network.

Client peers are connected to 2 nodes of the 3 nodes in the triangle. A DOS against these 2 nodes disables them and hisself. The last host node remains connected and would broadcast across the peer network the need for additional host nodes.

Actually you don't need 3 host nodes for 2 clients. However, every time a new peer enters the instance he gets a surrogate. So 10 clients are connected to a peer host network of 10 surrogates. The surrogates know about each other.

 

[varonica]

There are no servers, this is all done in the cloud, fdev don't even own the nodes it's running on.

 

[Decksmeck]

There are no servers, this is all done in the cloud, fdev don't even own the nodes it's running on.

Fdev has to be doing some kind of match making or how are peers ever introduced.

I see this net work structure as a form of P2P though.

Need a master host in the middle. Fdev must be doing this, I guess. If a surrogate disconnects the orphaned client needs to ask the master host for a replacement. Then the master host broadcasts the need to the surrogate network in the instance. The surrogates pass it along through their own client connections and so on until one is found.

Every surrogate is also a client. So every sorrogate has two connections to the peer network.

It is just theory.

 

[Decksmeck]

Nah. There is no way to terminate the broadcast even after a new surrogate is found.

 

[Decksmeck]

I think you create a broadcast message that has a number indicating number of hops remaining. Each recipient first checks that the number of remaining hops is within parameters. Handle it, if outside parameters. Since the master host has access to all connected computers it can send limited broadcasts as needed.

Once an open surrogate responds it matchmakes the surrogate with the orphaned client and back into the instance. Excess potential surrogates can be put into a queue for later use.

But if that is not feasible then perhaps the master host can keep track of open surrogates.

 

[Decksmeck]

Or you just let the broadcast message propagate indefinitely and the master host continually adds open surrogates to a queue and that is how the open surrogate queue is maintained.

Maybe someone finds reading this interesting.