Game Discussions Star Citizen Discussion Thread v12

They could just continue what they were doing last?

Yes, you could let that happen, but then it leaves NPCs open to client side manipulation. As we understand, CIG have too much at the moment that is client side, which is why its relatively easy to make hacks for SC. If it goes live in this state, then hackers will be all over it. They need to shift more to the server side, but the servers can't handle it.

But let's stick with client side NPC actions, extrapolating from what they think they should be doing (rather than obeying instructions from the server). It certainly has some advantages, but it can also result in different clients seeing different things. It could result, for example, in one person being in combat with an NPC while another doesn't see that, the NPC is just sitting down.

Again, we can also come to client side manipulation, where a hacker causes an NPC to attack another player. That client then sends data to the server that player B has taken damage. Player B doesn't see that but they see their health dropping. To avoid this, you've got to put in server side checks to see if a client is sending information it should be authorized to send. Again, putting extra load server side.

And remember, this game is meant to have a 10 to 1 NPC to player ratio! That's going to be a lot of NPCs for all clients to be talking to once you get a lot of players in an area (of course, this whole 10 to 1 ratio was a load of rubbish to start with, because they won't dynamically adjust NPC numbers based on the number of players playing. Imagine if you did get 100 players all on Stanton... you're suddently going to get 1000 NPCs all spawning there?).
 
Yes, you could let that happen, but then it leaves NPCs open to client side manipulation. As we understand, CIG have too much at the moment that is client side, which is why its relatively easy to make hacks for SC. If it goes live in this state, then hackers will be all over it. They need to shift more to the server side, but the servers can't handle it.

But let's stick with client side NPC actions, extrapolating from what they think they should be doing (rather than obeying instructions from the server). It certainly has some advantages, but it can also result in different clients seeing different things. It could result, for example, in one person being in combat with an NPC while another doesn't see that, the NPC is just sitting down.

Again, we can also come to client side manipulation, where a hacker causes an NPC to attack another player. That client then sends data to the server that player B has taken damage. Player B doesn't see that but they see their health dropping. To avoid this, you've got to put in server side checks to see if a client is sending information it should be authorized to send. Again, putting extra load server side.

And remember, this game is meant to have a 10 to 1 NPC to player ratio! That's going to be a lot of NPCs for all clients to be talking to once you get a lot of players in an area (of course, this whole 10 to 1 ratio was a load of rubbish to start with, because they won't dynamically adjust NPC numbers based on the number of players playing. Imagine if you did get 100 players all on Stanton... you're suddently going to get 1000 NPCs all spawning there?).
You can keep location and inventory / item server controlled. There is no reason a server needs to authorise some bloody animations. What are you gonna cheat there? Make nude actors? Big cheat. Not sure it'd break the game.
 
As i said, get the NPC to fire on another player (or another NPC).
What you're describing isn't animation, though.
As a general issue with letting all NPC activity be controlled client-side, sure, but that's a very different thing.

The worst you'd end up with is if you forced a different animation to play for you than it did for everyone else, so you'd for instance end up not noticing that all the NPCs around you are flinching from the incoming fire. You end up fooling yourself, and little more.
 
Last edited:
They just had said they have time synchronization difficulties between 2 servers, nothing more.
Nope. They are having trouble getting the servers to share session state. It's not just a matter of time sync.
"It's quite tricky it's quite um detailed work... Now um hopefully that will be done soon and then yeah we're also looking at getting two servers talking to each other... ...the fundamental problem there is that the engine's based on the assumption that um a server thinks it owns the game session... "
 
We're talking about braindead NPCs sitting on chair or going occasionally from A to B. Even if they can't implement mundane unconsequential behaviour, I wonder how a magic tech will, and how they plan to make what they promised.

Also: if iCache is hiding Redis or Kafka, I assume 1) CIG lies when they say they invent never before tech, 2) they're not good at clicking on install.exe.
 
Last edited:
We're talking about braindead NPCs sitting on chair or going occasionally from A to B. Even if they can't implement mundane unconsequential behaviour, I wonder how a magic tech will.

Also: if iCache hides Redis or Kafka, I assume 1) CIG lies when they say they invent never before tech, 2) they're not good at clicking on install.exe.

A bit of fairness, pls. To sit on a chair they have to have basic balance system lest they don't fall off the other side. Same with A B autolocator locomotion. We wouldn't want them to fall down all the time when the joint&muscular actuator engine is not calibrated correctly.
 
What you're describing isn't animation, though.
As a general issue with letting all NPC activity be controlled client-side, sure, but that's a very different thing.

The worst you'd end up with is if you forced a different animation to play for you than it did for everyone else, so you'd for instance end up not noticing that all the NPCs around you are flinching from the incoming fire. You end up fooling yourself, and little more.

I was just extrapolating further than just beyond basic animations. If the idea is to allow NPCs to behave like they should when the server is not communicating (or lagging) then at that point you have to allow them to do behave like they should. So, if they can potentionally open fire on a player (for example, one who shoots at them first) then you also allow that to happen client side.
 
The animations deals no damage. The action does. Animation is just illustration. What an actor does, moves, is - that's something for verification.

Ahem, are you forgetting we are talking about CIG here?

Client A reports Client B is taking damage.

Server reports to Client B their avatar is taking damage.

Yes, if we were talking about a different developer it would be laughable to suggest something like that could happen. But this is CIG, for whom nothing exists unless they invented it first.
 
Come to think of it, wasn't that pretty much what one of the early hacks did?
Just send a bunch of “I damaged [client X]” messages to the server for it it accept on faith and propagate to everyone connected? :D
 
The animations deals no damage. The action does. Animation is just illustration. What an actor does, moves, is - that's something for verification.
"Animation is just illustration". No.
If you use ragdoll client side when a ship crash in another ship and project bodies few meters away, the server have to know where all bodies will be after all ragdoll animations. The bodies are not dead and will not vanish, everyone will have to get up from their position. Ragdoll animations finish point client side can't be predicted by the server (for what I know)...
Technically, I don't see how CIG can use real ragdoll animation. Client side, the server doesn't know where the body is at the end of animation and server side, it uses too many resources and bandwith. Pre-calculated animations can be a good solution.
 
Last edited:
Last edited:
"Animation is just illustration". Not for SC.
If you use ragdoll client side when a ship crash in another ship and project bodies few meters away, the server have to know where all bodies will be after all ragdoll animations. The bodies are not dead and will not vanish, everyone will have to get up from their position. Ragdoll animations finish point client side can't be predicted by the server (for what I know)...
Technically, I don't see how CIG can use real ragdoll animation. Client side, the server doesn't know where the body is at the end of animation and server side, it uses too many resources and bandwith. Pre-calculated animations can be a good solution.
Yeah, finish point should be fine for this purpose. The client can make a spectacular ragdoll with these parameters.
 
Not putting everything on the roadmap doesn't make it a lie. The actual roadmap is short/mid term cards with approx ETA. No ETA = no card.
Dear sir, not putting something on roadmap while working on it does indeed make roadmap a lie.
Definition of actual roadmap:
a detailed plan to guide progress toward a goal
As one can see, it doesn't have any references to cards or ETA, but it does have reference to details. Major features that are required to fulfill a goal (i.e. deliver the game) are omitted from roadmap. The game can't be delivered without processing those features. Following only the pathetic excuse for a roadmap CI-G had given to us without those omitted features will not deliver us to the game release.
Therefore it is not a roadmap, but a lie. Or CI-G's goal is not the delivery of the game. Either way, dear sir, CI-G had lied to backers, again.
 
"Animation is just illustration". No.
Yes.
Animation is a transition from one state to another. Only the two end points matter. Anything that happens between the two can be handled by the client. This isn't even a question of ragdoll vs. canned — it holds true regardless. Even with canned animations, the server isn't stepping through animation frames to continuously control every last vertex of the model. It just says “play animation X at position Y [implied: end up in position Z]”. The exact same thing can be said to a ragdoll animation system, and for the exact same reason, the server does not need any fine control over every frame.

If what you said was true, canned animations would yield the exact same problems and require the exact same pointless server load. Bit it isn't so they aren't and they don't, and neither do ragdolls.

Ragdoll animations finish point client side can't be predicted by the server (for what I know).
Incorrect and irrelevant. The finish point can be determined by the server and fed to the client.

Technically, I don't see how CIG can use real ragdoll animation.
They already are.
 
Back
Top Bottom