USS appreciation society

I can get on board with both of these ideas. In fact, let me "lock on" to any signal source received via. comms be it a distress call, or just some friendly banter between traders.

IMO USSs need to be ...

1) persistent: as in they come into being for everyone to potentially see, and exist for a set time appropriate to their type (see 3).
2) relevant: should make sense in terms of location and system economic, political and military disposition.
3) discrete situation types: e.g. distress calls, hazard signals, ad hoc small outposts (e.g. pirate lairs, trading posts, black marketeers), telemetry (black boxes/ship wrecks)
4) interactive: any action you take in the USS (such as destroying faction assets) should be fed back into the background sim, which may in turn influence future USS generation (see 2).

However I consider even this to be a stop gap measure. Eventually such generated events should at least in part be replaced by real events i.e. a "distress signal" comes about from an actual pirating incident involving persistent NPCs (and players or course), ditto for ship wrecks.
 
Last edited:
IMO USSs need to be ...

1) persistent: as in they come into being for everyone to potentially see, and exist for a set time appropriate to their type (see 3).
2) relevant: should make sense in terms of location and system economic, political and military disposition.
3) discrete situation types: e.g. distress calls, hazard signals, ad hoc small outposts (e.g. pirate lairs, trading posts, black marketeers), telemetry (black boxes/ship wrecks)
4) interactive: any action you take in the USS (such as destroying faction assets) should be fed back into the background sim, which may in turn influence future USS generation (see 2).

However I consider even this to be a stop gap measure. Eventually such generated events should at least in part be replaced by real events i.e. a "distress signal" comes about from an actual pirating incident involving persistent NPCs (and players or course), ditto for ship wrecks.

Another thing that would be great to add to #4 would be USSes can convert to other types. For example, you go to a USS to find a ship you decide to pirate. You destroy the ship, but leave a bunch of cargo that won't fit in your hold. When you leave, that USS is now that cargo.
 
Another thing that would be great to add to #4 would be USSes can convert to other types. For example, you go to a USS to find a ship you decide to pirate. You destroy the ship, but leave a bunch of cargo that won't fit in your hold. When you leave, that USS is now that cargo.

Nice idea and persistence would be great, however unless FD decided to change the server / hosting scheme it's unlikely to ever work and the storage requirements for a lot of persistent USS instances would quickly grow to insane levels. Why? These game construct crutches are generated locally (no possibility of exploits there of course) and distributed P2P, therefore when you leave an area the USS instances disappear as well.

However just having the annoying things persistent within one system for the duration that you're in the system would be an enormous leap in immersion and common sense.
 
I agree completely!

And I also think...

Beyond just having a marker (representing where a ship has come out of SC and got into a fight/destroyed/dropped cargo/gone for a stroll etc...) it would also show the path the ship took to reach it...

These trails would give you clues as the nature of the USS:

--Traders would tend to be flying from nav beacon to station
--Explorers would be flying all over the system
--Pirates would tend to be buzzing around the traders, but not going neatly from station to station
-- Police ships would be patrolling between stations
--A whole load of trails ending in one USS would probably indicate an ongoing battle.
--A USS with trails entering and LEAVING would probably indicate a ship has been destroyed.
--A USS with no trail would indicate something has been there for a long time

This sort of thing:
View attachment 15919

Apart from all the info that might be gleaned, it would look pretty cool and give a sense of the life within a system.

Furthermore, it could all be procedurally generated using the stuff they already have.

Despise the lazy design and immersion killer of the current USS. Love this idea!
 
Despise the lazy design and immersion killer of the current USS. Love this idea!

This is the problem and it may only be perception but the current design comes across as lazy and is definitely an immersion killer.

Plenty of people have come up with viable ways to change things that wouldn't take that much of a change and would work with instances. Other games manage to make instances interesting, FDev need to get a grip and steal, beg or borrow those ideas. If FDev don't have the skills or talent then get some people in who do.

That sounds really negative but the game does some things gloriously well but when it comes to content and coherence of vision they are abysmally failing.
 
Nice idea and persistence would be great, however unless FD decided to change the server / hosting scheme it's unlikely to ever work and the storage requirements for a lot of persistent USS instances would quickly grow to insane levels.

I dont think its a problem, the contents of a persistent USS would not require much storage space. Lets be really generous and say each one requires 1k - one GB would hold a million of them.
 
I dont think its a problem, the contents of a persistent USS would not require much storage space. Lets be really generous and say each one requires 1k - one GB would hold a million of them.

The USS only really have to be persistent for you and people in the same instance at system level. This can't be that hard to do can it ?
The only thing that I can see that would need to be persistent above this would be things like the market, Galnet.

Things like community goals to build a station the only thing your instance needs to know is the percentage completed which is a triviality, the engine should then be able to render a station that is partially completed to the relevant extent. I know this isn't in game currently for community goals but it should be.

If it isn't possible to get this level of persistence with the core design then FDev have a hard road ahead.
 
For a single USS, the storage requirements shouldn't too high. Particularly as they are so limited in scope and depth at the moment, but even taking into account sub-type status tracking such as "1 of the 4 black boxes has been picked up, only 3 left". However for a system to have any form of immersion there would have to be dozens of USS, some in more remote locations, some more on the standard routes between star and stations. Taking an arbitrary number of 50 USS in an average system, multiplying this by an equally arbitrary number of actively visited systems (2000), we have 100,000 USS to track and this excludes all the random out of the way stuff on rarely accessed systems, so assuming the typical long-tail distribution we could just double the amount to 200,000 USS to track persistently. While 200,000 objects isn't a particuarly difficult storage problem the database server also needs to handle every group play and solo instance... and its from there that we immediately have insane storage requirements for a central server system. While this can be alleviated by shoving all solo storage back onto the client system however that adds a lot of extra complexity and data security and integrity issues to deal with (exploits and corruption) and would require non-trivial development resources to create and, more critically, to support in the long term and this costs a lot for a game with no subscription income.
 
Back
Top Bottom