sektor2111 wrote:Comparing my posts with bullshit posted by some members "addicted" here I think I'm posting 100 times more properly and exactly - no offense just reality.
Yes, yes, you're better than everyone else, got it.
sektor2111 wrote:
Except that "Super.Tick" thing probably your code will help - this is what I want to see not "explanations" as long as maps posted by Barbie are not added on my playground and they will never be there - there are things with no single net code which have no place ON-Line, yeah, trash out
. Else, because we have ROLE_DumbProxy we don't need simulated functions here, those are part of ROLE_SimulatedProxy. About Net stuff probably I don't have any concern, collisions are SERVER's job and "meshed" actors are replicated as said by server not by client. Yesterday I could see what RemoteRole does toward simulated/non-simulated functions while I was playing with some "dynamic lightning" mapping related problem - it will be time for showing something in the right moment not in this stage.
Yes, I am aware that you don't need it to be simulated considering that its current remote role is DumbProxy, however when I posted that code with simulated it was to imply that these functions should run in the client rather than the server, with a SimulatedProxy and perhaps a few other changes depending on how the rest of the class is set up (which I didn't really look at).
Having that said, most of the workload of anything should be put on the client rather than the server, whenever possible.
The server should only run the things which are actually authoritative and have a direct impact in the entire state of the game at any given moment. Relying on the server to replicate everything without a care in the world leads to a great waste of both bandwidth (not major in current connections, it's more about the limits of the engine itself) and CPU (there's a good amount of processing being done by the engine just to know what changed and what to replicate, to whom, and to even compress some of it to spare bandwidth).
Being a mesh, or having collision, or anything else, tells absolutely nothing about whether or not an actor should run on the client or the server, it all depends on what the actor actually does and represents in the game.
In this case, the only thing you "fix" here is a visual detail which is only relevant to the clients themselves, for the server it has no relevance whatsoever, thus the PrePivot should be changed and updated over time in the client alone.
Furthermore, PrePivot is a vector, and as such is compressed and looses precision, which might or not make a difference, so you would either have to send each axis as a float separately, or you simply update from the client.
In the case of Pawns however, it seems that the only problem is generally the offset in the Z axis, and Pawns generally never pitch or roll, they only yaw, so for these I guess it's OK to let the server set up the PrePivot and replicate it once per spawn, or just set it as a default in a subclass, as it doesn't need to get updated over time.
But extending and customizing the actor directly isn't the only way of doing it, you could also build some sort of manager which would update things by itself, which would be easier and more flexible, as you would only need to hold a list of stuff to fix, and it could just far more efficiently iterate over them, but it's tricky since you would have to always guarantee that the tick of the manager is always the last one to be called in some way, to avoid an update unsynced with the actual updates on the other actors themselves, causing visual lag in terms of positions or rotations.
The most basic trick is to simply spawn a tracking actor after the pawn, and let it send the events to the manager, and then let the manager handle the pawn that the tracking actor is referencing, due to the order by which Tick is called in each actor (actors added last are called last, I don't remember if there's a use-case where this isn't the case).
This manager would exist in both the server and the client (due to the first replication, and since new clients joining must become aware of it from the server), but the rest would be handled fully client-side (including the tracking actors).
sektor2111 wrote:
For the rest of fire offset problems I'm still curious to see a solution not explanations about "why that wheel it's a square" because it looks ridiculous, and explanations are making things to be more ridiculous. In each map which I do I'm writing some personal stuff and this is the reason for doing/speaking about some fixes - I need them.
Again, if you just wanted fixes, your very opening post would be far different, as well as the rest of your posts.
But let's focus on the fixin' then: starting with the simple case of the Slith, there isn't much that can be done there since the value is hardcoded.
However, you have 2 possible solutions:
1 - The simplest, is to extend the class and override the ShootTarget function and set a property instead with the correct value by default. Cons: replacing the pawn class in existing maps may break stuff up.
2 - Another one would be to detect the moment the projectile is spawned (SpawnNotify perhaps), check if its owner is a Slith, and move it a bit ahead accordingly.
Since, from your description, the problem is only when they are moving, but the engine is single threaded so only one thing runs at a time, so the projectile itself should be able to spawn without touching the Slith at all, and you should be able to move it to where you find to be the best offset, and you're done. Replication and stuff only happen at the end of the tick, so by changing locations at this point is not a problem.
SC]-[WARTZ_{HoF} wrote:I really love this conversation Nels. I actually skim through this forum to read your and Higor's posts mainly. Otherwise I just mark forum read on most everything else. I have enough knowledge to know who here actually knows what they are talking about.
I don't think you do. I think you're more latching on someone you know over the fact that you don't actually understand anything they are talking about, making others wrong to you by default.
If I am wrong, feel free to contribute to this discussion in an actual meaningful way.