This would assist in heading to teammates or targets that are very far away. It would also be useful in storms or any area with few or no reference points. It serves a purpose in both for solo and cooperative efforts.

Basic idea: A small (toggleable?) HUD element that displays your bearing on both axes of rotation in degrees from 0-359, horizontal followed by vertical. A 3D compass, basically. For example, if you and a teammate are near each other and see something or someone far out, one of you could call out a bearing (e.g. "270x-090y" for a target above and to the left if you're looking "north" in the sector) and you could both head that direction. If you have to maneuver or look around and lose the target, you can just point yourself to that bearing again and be on the right track.

You could also implement this into the target window on the HUD, so you can see a target's bearing in real time if you're close enough to select it.

+0.

Personally, I think the existing radar & targeting systems are sufficient as-is, you can already see your teammates/guildmembers/whoever's locations anywhere in a sector so long as you are in a group with said person(s) not to mention you can just target X person and have a very clear line of sight, so long as they are within radar range.

although, I wouldn't be upset at more technical means of doing so, as I enjoy technical data/situations but I don't see a necessity for anything further than what we have currently.

-1

As useful as this would be, and as obvious as it might seem, the fact remains that this really is all we as players are missing for bot automation. I don't think it's worth those problems for what value we might get out of it.

/displayshippos used to be a thing, was removed for a good reason, and it wasn't just a joke...

+1

To arfs issues: Just make it work only in storms and fogged sectors.

I’d like it to work in all sectors, personally. Maybe you could reduce the polling rate, or even make it a command that works only every minute or 30 seconds. You could reset the coordinates for sectors at a short rate that shouldn’t impede minute to minute gameplay (hourly?), mitigating automated trading ships. I see a lot of ways to impede automation without throwing out the proverbial baby.

The HUD data and bearing calculation could be completely outside the sandbox of plugin access, to reduce the automation concern.

There would still be the possibility of automation, through either direct memory-hacking of the client, or doing OCR-style text recognition and processing of the rendered HUD graphics in real-time. But, both of those are a bit arduous. And I think if one is willing to go that far, one could probably already build pretty complex automation.

But, to limit the system the way I'm describing, there would also be no automation to informing group members or anything. Once you start automation of shared data, then you instantly have a problem.

You could "manually" share the data, however, in terms of reading it and repeating it over voice chat, or typing it in yourself.

I would be completely in favor of limiting plug-in access to the data if it meant this feature could be implemented.

I've tended to butt against Incarnate's vision on these types of topics.. but now and then something is brought up that I can't resist commenting on.

On the issue of using your 3D position for automation purposes which is something incarnate has vehemently opposed and taken great effort to circumvent. It should be noted that this can still be achieved using the available distance to target functionality on stationary objects in any given sector. A skilled person could take the distance to any 4 objects and construct arbitrary mathematical planes by assigning some arbitrary distance between the objects (an estimate is all that is necessary). Then your 3D position could be calculated so long as those objects are within detection distance. There are functions exposed to lua to simplify these 3D calculations.

Any game can be hacked or cheated by someone with enough skill, will, and time. The best that can be done is to make it such that the skill level required is high enough that it would be a rare occurrence.

I believe that the suggestion and response from Incarnate reflect a strong enough level of difficulty that this would pose little threat to game integrity but could be helpful for general gameplay. Of course, I'm also one of those guys who take the stance that if some hack prevention represents enough work to implement, it is worth considering opening it to everyone freely through built-in game mechanics rather than investing time and money in circumvention. I take this stance with data sharing, having suggested before a built-in mechanism for sharing data that is commonly shared with plugins and TCP. This could allow the same functionality without giving TCP/UDP access to plugin developers at all. Subsequently putting the dev team in complete control of data flow... but I digress.

I think the suggestion is a really good one and as someone who has invested time into creating hacks for games in the past, I can say that the implementation possibilities mentioned by incarnate would make it not worth the effort to abuse.

On the issue of using your 3D position for automation purposes which is something incarnate has vehemently opposed and taken great effort to circumvent.

What? All we did was disable "displayshippos". I'm not sure what "great effort" your referencing.

A lot of players didn't like the "displayshippos" era automation, as it negated the value of their dedicated play-time and efforts. All we did was formally decide to make games for people to play with one another, as opposed to making games for computers to play with one another.

It should be noted that this can still be achieved using the available distance to target functionality on stationary objects in any given sector.

We are aware of what data is presented by our Lua API. But if it's abused, we'll turn off those functions. That won't require any more effort than disabling "displayshippos". About a minute of time.

I was specifically referencing the potential "exploitability" of this new data presented by this new suggested system.

I believe that the suggestion and response from Incarnate reflect a strong enough level of difficulty that this would pose little threat to game integrity but could be helpful for general gameplay.

Well.. great then? You could probably just have stated the one sentence above? Most of the rest seemed pretty off-topic. We aren't discussing networking or data-exchange protocols here.

"Well.. great then? You could probably just have stated the one sentence above? Most of the rest seemed pretty off-topic. We aren't discussing networking or data-exchange protocols here."

but you did mention it here:

"But, to limit the system the way I'm describing, there would also be no automation to informing group members or anything. Once you start automation of shared data, then you instantly have a problem."

I was acknowledging what I perceived to be the problem with this statement.. that automation is most easily accomplished due to the ability to share data via the methods you provided (TCP/UDP). Which allows for communication with the OS and therefore any positional data that is available to the plugin system is moveable to the OS where mouse/keyboard/joystick events are generated. This is relevant to the discussion of the exploitability of the suggestion because the suggestion is about positional data and how it is made available.

"What? All we did was disable "displayshippos". I'm not sure what "great effort" your referencing."

Also the ability to control ship movement via plugins.

"A lot of players didn't like the "displayshippos" era automation, as it negated the value of their dedicated play-time and efforts. All we did was formally decide to make games for people to play with one another, as opposed to making games for computers to play with one another."

I don't like it either..

I was acknowledging what I perceived to be the problem with this statement.. that automation is most easily accomplished due to the ability to share data via the methods you provided (TCP/UDP).

What..? No, I was saying the game wouldn't allow "automation to informing group members". Ie, an in-game feature that messages the people in your group to automatically tell them a particular bearing of a target when you press a button, or something along those lines.

For instance, we have automated notifications of when another player comes within a particular range. It does not require a discussion of "TCP/UDP" or the availability of networking APIs to the plugin architecture. You're really reaching here to try and expand this conversation into something it wasn't, that you seemingly wanted to talk about.

The discussion point here has nothing to do with networking. It's just the relative inconvenience of having to manually enter "bearing" data subverts any trivial automation. Regardless of whether that automation would be implemented on a single client (aiding single-client autopiloting) or broadcast to others.

"What? All we did was disable "displayshippos". I'm not sure what "great effort" your referencing."

Also the ability to control ship movement via plugins.

Okay. I'm sure that took an extra minute to disable (it is a "sandbox", you realize). Again, you stated that we expended "great effort to circumvent" automated flight. Evidence suggests it was more like "almost zero effort".

"A lot of players didn't like the "displayshippos" era automation.."

I don't like it either..

Well, great, then I guess you're also "vehemently opposed" to it, per your characterization of me.

It emerged as a problem, people didn't like it, we disabled it and moved on. It was not actually very dramatic at all. I've spent far more time posting on this thread, than we invested in making technical changes around this historical issue.

Glad we're all on the same page. Let's move forward now with the OP discussion that has nothing to do with "TCP" or "UDP".