Part is spawning behind character in live server, but doesn't in Play Solo

Help and Feedback Scripting Support
#1

I have an attack system I built. The core idea to it is that by clicking on any point on the screen, a ball will be fired towards that position. It produces an effect similar to the Superball tool.

The problem is that when I go into a live server, the ball doesn’t spawn where it’s supposed to. I thought at first it was probably a network latency issue, but after making some changes in an effort to combat that, I’m not sure it is.

I’ve created a game with all the scripts necessary for my system:

The main two are in ServerScriptService > AttackSystem (and its children) & ReplicatedFirst > AttackLocal (and its children). The process works such that:

Once the player clicks a button, they will fire off a RemoteEvent (this is from AttackLocal).
The RemoteEvent is detected on the server, the server converts this direction into a target position and this is used to spawn a ball (this is AttackSystem & AttackSystem.Attack).
The ball spawns at the player’s head & goes towards the direction specified.

I’ve been looking at it for weeks now and I’m completely lost as to what could be causing it. If anyone has any suggestions as to what I can do, that’d be really helpful. Thanks!

3 Likes
#2

One of the most common reasons for things working in play solo and not in a real server is because of how play solo works.

Play solo makes your computer act as both the server and the client and also modifies things to make it better for just one player.

So, this means that the value of Players.LocalPlayer, for example, is available on the server, but only in play solo.

Have a double check that you haven’t used any client-only values in your server scripts.

I haven’t actually checked your source yet for this, but I will in a little while (I’ll post again if I find anything).

But, in the meantime, have a check for this.

Also, maybe even check the source code for the superball tool. It might help you to see what you could do/do better.

1 Like
#3

That was my first thought here - but I’ve looked through and haven’t seen anything. I’m doing all the calculations, the player positioning and everything from the server… Only thing it needs locally is the direction, which I’m passing through to the event.

Another source I’m thinking of could be that the player moves & it’s displayed locally, but maybe it’s not replicated to the server in the same instance that I’m clicking - so they’re further ahead locally than they would be from the server’s view? I did some printing out with that & I’m getting different values for positioning. I’m gonna experiment with that.

That’s a good point on the Superball. I’ll look into that. Thanks!

#4

Are you definitely using the first parameter of the server event handler as the player? I know this changes in play solo. So, for example:

event.OnServerEvent:Connect(function(anything, anything2)
    print(anything)
    print(anything2)
end)

Regardless of what you fire to the server on the client, in this case, anything will always be a reference to the player who fired the event.

I see people slip up a lot with this, as I don’t think this happens in play solo.

EDIT: I checked, and this stays the same in play solo, so you can ignore this.

1 Like
#5

Yep, I’ve got that part of it - I have some server logging & stuff too to make sure it’s all working and that’s fine. All the values, at least from what I can tell, seem correct.

I was doing some testing with Superball & I’m seeing the same problem with it… which is interesting. I should also add that I sped my characters up for the game - so instead of the standard 16 walkspeed, they’re going at 70. So that could be at least part of it - but even so, the issue isn’t replicating. That’s what I find weird about it.

Thanks again for the help. I’m gonna keep looking into it and hopefully I find something

#6

Wait one second. Is the part spawning correctly in Play Solo, but not in the live server or the other way around?

If it’s just a problem in Play Solo, then it shouldn’t be a problem ingame.

Is that a typo or is that correct?

1 Like
#8

Play Solo makes the server and the client act as a single entity. It is also being deprecated (and removed) in the future. Please do conduct all future testing using Accurate Play Solo so you avoid circumstances where “it works in Studio but not in-game”.

I only seem to be experiencing your supposed spawn position discrepancy once my character starts moving - when I’m standing still, there’s no issue in terms of where the ball is spawning. I’m thinking that your conversions are being done later than expected, but I’m still looking through the repro so that may not exactly be the situation.

1 Like
#9

I might have had that backwards, sorry - it’s an issue in the servers (so if I’m actually playing the game), but when I’m in play solo, it’s fine. Otherwise yeah, I wouldn’t worry about it lol

1 Like
#10

@colbert2677 Although not strictly on topic, where can you enable accurate play solo? I couldn’t seem to find anything to do with it.

1 Like
#11

Accurate Play Solo should be enabled by default. It’s an opt-out feature, not an opt-in.

image
image784×497 68.6 KB

2 Likes
#12

Okay, I didn’t disable it, so I guess I’m fine. Thanks

1 Like
#13

Yeah, it’s only a problem when the player’s moving. It becomes a big thing in the case of my game though - basically the players will be running around constantly, so I need that part of it to work.

And yep - didn’t notice Accurate Play Solo was disabled & I enabled it. Now it’s replicating.

I thought at first it would be something to do with where I’m spawning it, but I’m not sure where the problem would be with that. I’m getting the position & spawning the ball in the same step, so it shouldn’t be anything delayed with that. I’m still looking though, might be something else that I forgot about?

#14

Was playing around with it and I think I found the root cause of it. The player’s position locally is updating ahead of the server, so if I switch the spawn position to the player’s local position, it spawns much more accurately (within about half a stud).

The problem with doing that is it’d be a security concern… But I can validate the value on the server to see if it’s “close enough”. I think if it’s within about ten studs, then it should be fine.

So anyway. I think I got it. Don’t like it, but it’ll work. Thanks for all the help everyone!

EDIT: I ended up finding a formula for the difference here. It seems to be that for every increase by 7 in the Humanoid’s WalkSpeed, the distance will go up by 1 (so, if you’re moving at 7, then it’ll be an offset of magnitude 1; if you’re 70, it’s 10; if you’re 35, it’s 5; if you’re 700, it’s 100). By using that and humanoid.MoveDirection, I was able to come up with:

local distanceCovered = self._human.MoveDirection * (self._human.WalkSpeed/7 + 1);

And that formula centers it - so no matter how fast I’m moving, when I fire, it will spawn with the player. By applying a slight offset (something like + direction.unit * 2), I’m able to spawn the ball in front.

4 Likes
#15

Keep it up, man! Nice work finding your own formula.

1 Like
#16

Have in mind that the set value you found might just work for you and people with similar ping as you. If someone with a different ping plays your game the calculation might be off

1 Like
#17

This was from accurate play solo but true, I have no idea how that simulates it … I’ve tried it in two locations / WiFi networks so far at least and it seems to work (both accurate play solo & online).

Any suggestions for how else I could do it? I guess I could do some calculations to see but I’d rather avoid that as it seems open to exploitation.