@kazeshiro ROFL, looking for the actual valve documents I found this. You didn’t get very far in 3 months, did you xD Maybe you should just have read the docs as we suggested then you’d pose better questions by now and were not trying to apply your preconceived ideas on how stuff should be done ^^
“Manually computing physics” “for each object” all this shows that you have no idea how the physics actually works. You can easily step the physics space differently/manually and as said thats even commented on in the MonkeyZone code. But as you seem to completely avoid doing your homework I DO NOT WANT TO TALK TO YOU ANYWAY, so don’t worry about any annoyance through me, gl finding a fool to help you.
Was I clear? Thanks.
@normen
AHAHAAHAH
Your attitude shows that I am in right!!!
AHAHAHAHAHAHh
In last 3 months I have spent my time studying for the OCPJP certification and 2 university exams while working 10 hours per day. I don’t know what you do in your life, but Jmonkey is not my only thought.
I have made several researches about multiplayer FPS architecture and i am sure that MonkeyZone is not a good demo that solves the problems of a WAN environment. If you read the blog i posted the link to, you can notice that it is very well explained how to build a networked physics architecture.
I made this but it was physicsless. Like the title post say i was looking for a method to something like the pseudo code i posted. Why can’t you help me in finding this way instead of say “read valve documentation” and “MonkeyZone”!!!
And to finish, if you posted classes or some clues to help me finding where MZ made what you say, you wuold save a lot of time and words. I’m sure you documented enough MonkeyZone but reading all the javadoc is not a solution in terms of time, right?!?! So simply say “MonkeyZone does manual physics here” was so difficult!!?!?!?!?!??!!!?!?!?
Every time i asked something about multiplayer games you told me to read valve documentation and watch MZ.
Do you know what = “How to update physics manually” means!??!?!’!
What the hell is has to do with valve documentation?!?!?!?!?!
MonkeyZone does not implement client side prediction and entity interpolation like the way those are meant to be!!! And delaying user input is not client side prediction!!!
So it is usefulness see how monkeyzone does this!!!
Prove me the opposite! :evil:
However, can you tell me where i went wrong with you?
Really, i wonna know where
I am not mad at you, you are mad at me ^^ You know, before writing this post you really should have read the docs this time, then you might have had a slight chance to “own” me in any way if thats what you are about. Its not like I am / we were (3 months ago) suggesting this to you to annoy you, its because it would be best if you actually did that. If 3 months are not enough to read the monkey zone code or the valve docs then except you have some reading disability I don’t know how much would be. Everything you say and everything you seem to grasp about what somebody says (also in this thread) points to the fact that you need to educate yourself using the mentioned material. Its explained in the monkey zone code, since everything is physics the physics itself is the prediction, all you have to do to avoid the “snapping” (I can’t believe I say this the 5th time) is ramping the tpf for the physics space. If you would have looked at the code you would know what I mean by this, thats what I am saying, thats also what I meant with my snappy comment about “i don’t want to…”.
I am mad at you because you comment my posts in this way:
@normen said:
If 3 months are not enough to read the monkey zone code or the valve docs then except you have some reading disability I don't know how much would be.
Are really nedded this comments!!??! I think not, in fact are absolutly non sense and let you to not answare my question or to comment my point of view. And if you didn't read i repeat that in last 3 months i have done many things for my private life. JME i'ts not a religion is a hobby and if you want help me in investing as well as possible my time i'll thak you.
I've done what you say:
Read monkeyzone code,
read valve doc,
read doc about unreal networking,
read doc about quake 3 networking
and many other docs!!!!
Now that i know where i want to go, i ask you to help founding a solution that can implement the architecture i know with jME.
Why can't you simply help me instead of say read MonkeyZone and comment my private last 3 months!?!?!?
Answer to this plese
To ensure you have understood what i mean :
If i ask to you something about multiplayer games you tell me to see MonkeyZone code.
But monkeyZone
(I can’t believe I say this the 5th time)does not implement prediction and interpolation!!!
If you don't know how this stuff is done it's not my problem.
What monkeyzone does is to extrapolate server side the state of players adding an offset at the physics simulation time.
IMHO this is NOT what a multiplayer architecture needs to run well in a WAN, or is not however a solution that apply to my architecture
(the same as the doc of Q3 for example XD ).
What do you don't understand of what i say!?!?!?!?
Surely you are not stupid ( instead of what you think of me basing you assumption on nothing!!!!) becase jME is a real complex stuff and your are one of the major contributor, but this is not a good thing because it highlights that you don't WANT to u nderstand what i say simply because you think that MZ is better than what i have done.
Answer to this please
Dude, the entities position is sent only every 500ms, if it was not interpolated by the physics you would see it jump around which you don’t, do you? So THERE IS CLIENT-SIDE INTERPOLATION THROUGH THE PHYSICS!! Thats what interpolation is, computing the values in between that are not sent via the network, no matter if its a physics system or some other system doing that.
And since you simply refuse to look at the code and the docs you will never get what I mean by “ramping tpf”, doing a gradual adaption of changes in the delay instead of snapping which THEN WORKS ON A WAN! Maybe someone will bow down and simply post all the contents of the valve documents in a thread bit for bit until you understand it xD
And I still think 3 months is enough to read the document unless you have a reading disability. If you didn’t have the time to read them because of private things or w/e then simply post in the forum after you did so ^^ Again, its not like we want to annoy you or derive great pleasure from your posts, its just that the docs we point you at contain the info you ask for.
I will have to contain myself but I will stop answering now. Your silly “you are too dumb to explain it to me” attitude is just turning me off. Good luck in 3 months when you will still have zero idea about networking games and ask people to explain it to you ^^
what i want to explain to you and you still DON’T WANT TO UNDERSTAND IS THAT YOU CONTINUE TO TELL ME WHAT I AM LOOKING FOR!!!
I don’t want to copy the multiplayer architecture that MZ implements!!!
I wann o do another architecture that is welle explained in other documents then MZ!!!
I ask to you how to do another thing!!! Not how to implement multiplayer architecture!!!
AND IF YOU ARE NOT IN GRADE TO UNDERSTAND WHAT I HAVE WRITE IS NOT MY PROBLEM (i am concius that my english is bad but if you can comment what i say you can understand my english but you don’t want)
I HAVE READ SOOOOO MANY DOCS!!!
I HAVE READ MZ CODE AND DOCS AND AS I SAY I DON’T WANT TO DO THIS STUFF IN THIS WAY!!!
IS YOU THAT THINK YOU HAVE TO EXPLAIN MULTIPLAYER TO ME BUT
IT
IS
NOT
WHAT
I
REQUESTED
TO
YOU!!!
Well you get what you pay for I guess ^^ Anyway I answered your questions in the first three posts, the fact that you don’t understand the answers is what makes me point at the monkey zone code and valve docs again, thats what you don’t understand.
Ok normen,
i rephrase the question as well as i can:
There is a way to update the physics state of a single object on demand and many consecutively times?
If the answere requires you to point me some code in MZ, ok, very well. If you can point me directly at the interesting code (class, method??)
you can save a lot of time to me try to find what i am looking for instead of search in the entire MZ project.
But please, PLEASE, stop pointing me valve docs!!!
It is really non sense!!!
Ok survivor, i think that my english doesn’t help me in this.
Can you tell me what is not clear to you? 
@normen
hi, i have understood the entire MonkeyZone architecture. I swear XD i read all the classes of this project and i have to admit that this was helpfull. I have re-read another time this document that is the same written in valve site.
You told me to see the monkeyzone code and read the valve doc and now i have done it all.I’ve undestood how MZ implement this kind of architecture and sincerely… I don’t like it. Possibly i’m wrong…it’s just an opinion. Accept this please and help me …
I know that i’m a newbi near you but i wanna only do the things in another way…
So please can you help me? i’ll acccept all insults and don’t mind those XD
So, if you have an opinion about the monkey zone code (which is fine, I was mostly urging you to read it again so we can talk on even ground / you don’t keep making wrong statements about the code) what exactly is it that you want to change/do different? The valve doc pretty much contains the ideal version of networking which is used by about every game out there and the monkey zone code only really differs slightly in the approach as it uses a full physics simulation on both sides for the interpolation and motion. (and as said misses the client-side local applying / time warping) Start writing the code that would in your opinion be better and then come here with the problems/findings you made doing that.
Start writing the code that would in your opinion be better and then come here with the problems/findings you made doing that.
Ok there is only a problem that i encountered using bullet physics that is client side prediction.
As i said the problem is that i can't rewind a rigid body state to a certain moment and the reapply all inputs beetween the moment of the correct state and the moment of the client simulation...
So i can't write some code before i have found a solution to this....
One thing that for example i don't like is the broadcasting of every physics sync message that arrives to the server
[java]
PhysicsSyncManager.messageReceived(Object source, final Message message) {
...
...
} else if (server != null) {
app.enqueue(new Callable<Void>() {
public Void call() throws Exception {
for (Iterator<SyncMessageValidator> it = validators.iterator(); it.hasNext();) {
SyncMessageValidator syncMessageValidator = it.next();
if (!syncMessageValidator.checkMessage((PhysicsSyncMessage) message)) {
return null;
}
}
broadcast((PhysicsSyncMessage) message); <-- Here
doMessage((PhysicsSyncMessage) message);
return null;
}
});
}
}
[/java]
and that those messages are sent every time a user does an input command
NetworkedManualControl
[java] public void steerX(float amount) {
if (client != null && amount != lastSteerX) {
lastSteerX = amount;
sendMoveSync();
}
}
public void steerY(float amount) {
if (client != null && amount != lastSteerY) {
lastSteerY = amount;
sendMoveSync();
}
}
public void moveX(float amount) {
if (client != null && amount != lastMoveX) {
lastMoveX = amount;
sendMoveSync();
}
}
public void moveY(float amount) {
if (client != null && amount != lastMoveY) {
lastMoveY = amount;
sendMoveSync();
}
}
public void moveZ(float amount) {
if (client != null && amount != lastMoveZ) {
lastMoveZ = amount;
sendMoveSync();
}
}[/java]
What i wanna do about client side prediction is something like this:
When a user type a button i put on a flag (up = true for example)
In the update method (in a control) i store the time in an input message where i calculate the viewDirection and walkDirection basing the flags (up - down - ...) like the TestWalkingCharacter does.
Those input messages are sent to server and stored in a PredictionControl attached to the local player spatial
When the server sends an UpdateGameStateMessage the client get the local controlled player informations.
Those informations contain the player correct state in the past that is a start point to compute the actual player state and it is done in such a way:
Pseudo - code
[java]
serverPlayerState = player state sent by the server taht refers to a correct state in the past;
TimedInputList.removeOldInput(playerState.time); // removes all input too old
correctPlayerState = serverPlayerState;
While(!TimedInputList.isEmpty()) {
correctPlayerState = computePhysics(correctPlayerState, inputList.next()); // compute the new more accurate physics state
}
MyCharacterControl.setCorrectState(correctPlayerState); // This is the control that update to the correct state smoothly
[/java]
The only problem is the compute physics step because like you said it is not a good practice to call CharacterControl.update method.
Can you help me looking for a solution to this problem please?
As said, the physics space is one, you cannot just update single objects in it and thats also not what you want to do. You can either remove physics from the client and replace it with simple value interpolation (which is easy for the character, it has no real physics) similar to how valve does it or you just care for having a consistent physics on the server that the client tries to sync to as closely as possible by ramping the physics space stepping like its laid out in MZ. You can also combine both, using the MZ way for physics and an adapted way to move characters.
But the goal of client side prediction is to give an illusion of instant responsiveness and interpolating the movements adding another offset beetween the input and the response doesn’t it risk to produce a bad feeling?
A delay between player input and corresponding visual feedback creates a strange, unnatural feeling and makes it hard to move or aim precisely.
And , correct me if i am wrong, MZ doesn't check the movement on client side because the cleint calculate the delta movments and apply it instantly and the server check in a second moment those informations.
It is true that the game state is sent back to clients but it is delayed and all clients share the same offset which result in a interpolation that is the opposite of what client side prediction want to do.
Yeah, exactly. The first thing is what I was talking about “warping time” etc. or using a valve-similar user movement interpolation that just hides the problems differently (hence the warnings in every game “the gaming experience might be different when playing online”). The second thing is something I never denied, there is no local time decoupling in MZ atm.
Mmmm…
So there isn’t a possibility to do a “real” (with real i mean the manner i told before of rewind and reapply inputs ) of doing client side prediction with bullet?
Like I outlined in the beginning, you’d have to send the messages “back in time” in terms of the global server time. If you have two physics spaces the point is in syncing them as physics means something, you cannot just move stuff around like you want to. Unless you mix up physics and collision detection. If you don’t have physics (e.g. all objects are kinematic) then you can do what you want.
But i need physics for many porposes…
However in you opinion entity interpolation is enough to do a good networking model?