I would like to have a laser weapon and it should be an endless one. Well at least a battle ground length so it looks like an endless one. I use sim-eth-es as a base. Several issues popped in my mind:
How would you do ray intersection with sphere like objects (currently everything has a sphere like collision shape to keep things simple)? Do jme have such logical shapes without graphical representation?
How could I handle the zone issue as the laser starts in ine zone and crosses in my case at least two zones?
Jme’s ray hit calculation is fast enough to be done on meshes without any performance loss if you do it sparingly in my experience.
If you want a Ray → BoundingSphere collision which isn’t supported by default I think then you’ll have to adapt this reference. Have done it myself and can confirm the code piece works perfectly.
but ray do work on spatials and nodes, no? so on server side I don’t have that, at least that is not the plan. Aha maybe that BoundingSphere… I’ll check that.
The other problem is that ships in a zone don’t see updates from ships outside that zone, and if a ship outside that zone fires a laser beam it will not reach my zone as my zone does have no clue. Does it make sense?
Lasers are not physics objects and so should probably not be handled by sim-eth… use regular components probably.
Do your own sphere intersection on the server. Ray->sphere intersection is not hard and you can use BoundingSphere or copy the code from it that does the ray->sphere check.
Ok that sounds then not that hard but how to do the update on client? I mean on server I have 60 updates per second but only 20 toward the client. For physics I have that buffer, I would probably need something similar for the laser beam…
I mean this laser is connected to a ship and that ship can turn around. The turn around changes for that laser will be updated only 20 times per second and that might look not ver fluently. I would need to store it similar like physics do with that position buffer.
EDIT: The laser will last a few seconds, else it would be a completely over powered weapon, but during those, let’s say 3-5 seconds it should be fluently move with my ship across the zones…
Yes that ship might be far enough away so that I never will see that ship, exactly.
Yes I think I will need to interpolate like the rest, I’ll see how it is done for physics objects in detail (I never cared till know as this simply works in your example ).
Maybe I will have one or the other question for this interpolation I’ll see.
A movement of a player is thought of as more of a question to the server, and the responses are un-guessable really until you get them back: however you have a time and a velocity and a position now. The beginnings of your thought process into this (and it can be a huge area of expertise if you want to be anal) can be seen in chasecam. It smooths out sharp coordinates into a more natural flow.
Regarding your issue of never ending lasers, you can really narrow down the list of potential targets before you even throw it at anything else more advanced. Which targets have zero chance (behind you) for example - and try to put as little stress on the physics/scene/heavy hitters as much as you can - if at all (iterative search as the laser moves, or areas cleared). If one area per frame is sufficient, do that. Your server will calculate that 3x more by your timings.
I currently do not bother much about the server, I mean there it should be relatively easy to iterate through possible targets (still below 100 or so, I have small battle grounds) and due the other answers it seems ray sphere hits are easy.
I bother more about visible stuff on client side and it’s interpolation (as the updates are 3 times fewer than server side)
to save network traffic I guess. It looks 100ms in the passt and stores some samples in a position buffer which then is used to interpolate it on client side. I have to study this part as I can not do the laser thing with the simple physics system I have in place…
oh maybe I was not clear of course the visual update on client is also 50-60 (depends on the screen and if vsync or not and so on), but the update the client gets from server is only 20 times per second.
It is still not 100% clear to me how to use that BodyPosition? I would need one so that that laser follows my ship and ships rotation (I want that Luftrausers laser ). So I guess I have to update the BodyPosition on every Frame, without add a new one, right? But isn’t that a bit against ECS?!
What I do at the moment is implement a FollowSystem, where an entity follows a physical entity, so I just look to what my Laser entity is linked (entityId) and then get the current position/orientation of that from the physics system and add a new transition to the BodyPosition and I keep a history of 20 of them. I’m not totally sure if I understood that idea correctly, but I will give it a try.
Yes. You have to know the rules in order to break the rules.
If you update a component’s internal values directly then you bypass the ES’s ability to provide thread safety, change notification, etc… in this case, that’s exactly what we want. We WANT to do our own threading and we WANT to bypass change notification.
I wasn’t suggesting the you actually use BodyPosition. Just suggesting that you interpolate values. You can still do that within the confines of normal components. You just send regular laser position updates through component updates and let your laser-visual-display-thingy interpolate from last to current. In the end it really depends on how accurate you want to be… but if you are sending regular component updates you are already TCP-behind the UDP object updates. But again… the ship firing the laser is really far away in this case.
You should try to handle the case where the laser is attached to a ship that is visible differently than the case where the laser is attached to a ship super far away.
In the end, you may decide that ‘infinite lasers’ is not worth all of the trouble. Switch to limited lasers and increase your zone sizes and I suspect you will practically get nearly the effect you want without all of the trouble.
Ok, I also already thought of limit lasers and the battle ground normally avoids it that a laser beam can really get infinit. So let’s say I would do it inside a visible zone, I could then do that by pass similar to SimplePhysicsSystem, right? Doing it via Zone updates and a body position publisher (I didn’t yet got the idea of that body position publisher tbh, but I think it is for the server side part).
I fear if I’m not doing nearly the same as the ship I will look jumpy or strange. Ok the visual part I could do by just know which laser beam follows which ship on the client, but it still can lead to strange things, like get damage from a laser which is visual not where you are and so on.
The good part now is, afterwards I also understand that part of your example
EDIT: For interpolation, what kind of math do you use for that? I found in the math for dummy a linear interpolation, maybe enough, but for rotation? I mean JME maths
Regarding the laser, you could treat it as a component of the ship. “Lasers On”. A laser collision system would use the ships location/rotation to decide if the laser was hitting something.
A laser visual system on the client would just attach the laser visual to the ship model.
I think this is the solution for limit laser beam, sounds doable. I go with that and save me all the trouble I would have with unlimited laser beams (I anyway plan to have small battle grounds and about 20 ships, so I can make the zone bigger). Thx for help me tinker that topic
). So I guess I have to update the BodyPosition on every Frame, without add a new one, right? But isn’t that a bit against ECS?!