currently you need to modify the source code for that.
we are planning to add some setter functions to allow modifying individual wheels in the following releases.
Thank you. Thank you very much.
I want to change the height of the suspension on the left and right to create a unique movement. 
:rolleyes:
This is something that I really need as well. Iām making a car combat game and when a wheel/tire is damaged, I need the properties of each wheel to be able to change depending on its damage state. Looking forward to this for sure.
Do you have a Discord channel / means to chat?
i use telegram but i do not prefer it for support, e-mail is more convenient for me. i have a full time job so i can not always chat with customers.
I think Fgear is still a framerate dependent solution, regardless of your custom update rate implementation. For example, when i change the fps to 5 the car barely move forward. Once i enable physics substepping the acceleration will be calculated properly, but then it starts this annoying bouncing effect and cannot be kept on the road.
The settings of my example project are unchanged, so you should be able to reproduce these problems.
Here, when i force fps 30 this bike will start acting crazy. I have 60hz update rate set in the fgear/general settings, tho it doesnt matter. I have also test this with physx substepping enabled (on 0.016 max delta), but it has no effect on the problem either.
Maybe the calculations are off and causing the wheel to penetrate the floor perhaps. For example, in UFGearWheel::myFixedUpdate you will update suspension only once per actor tick, and not use substepping which is strange. You maybe just overlook something in the calculations and not apply the sim coef or substep deltas when required. Could you please verify them?
When you test networked game with dedicated server, you may want to untick the single process mode, so it will allow the dedicated server run on the default 30fps clock instead. That way you can see the problems with gameplay immediately. By manually force the server to run on 60fps the problems are obviously gone, but this is not the desired solution, since the server is designed to run on 30fps clock, which is not compatible with fgearās custom simulation atm.
The current server authorative solution (at v1.1) is slugish to control when play online with any latency. You want client side prediction and correction that allows true client side simulation and just apply corrections based on server replicated body data instead. Epicās physics replication may be slightly better, but far from playable.
You will repeatedly answer many questions multiple times, that shouldnt be very convinient for you at all. Discord is the prefered solution for many, since we can not only ask but search previous conversations when looking for answers.
hi, thanks for the feedback.
its true that fgear is frame dependent(physics slows down when frame rate is low, custom update makes the calculations more precise) yet we made our tests for minumum 20-25 fps and it mostly behaves well over 30fps. generally game physics start to behave badly under 50hz and vehicle physics requires much more precision. fgear uses fixedupdates in unity but unreal has no such feature. we have tried the substepping callbacks of unreal but the raycasts does not seem to be synched with the regular frame updates so the raycast results seem to be incorrect(substepping is an experimental feature may be thats why). frame dependency is a known issue, we will try to address this problem for the next release.
fixing the first problem should also solve this.
yes the controls are always relayed from the server or it will be like a local control which feels nice especially for low latencies but conflicts with the corrections from server and seems ugly as the latency increases. we had a lot headaches because of the unreals physics replication issues so this is the best what we could achieve for the first iteration. we will reiterate it regardless(probably not for the next release).
we will consider it.
about the frame dependency issue, we have successfully implemented substepping support and it is not mandatory, the code detects if substepping is enabled and update accordingly.
Candescent Games is using fgear for their Lacuna Passage project. you can check the developer logto see some awesome pictures and gifs. they have modified the source for their specific needs and we constantly exchange ideas to make it better. i wish them good luck with their project.
Thanks for the reply.
Is this a feature for next release? When can we expect it to be uploaded?
Do you plan to include those improvements in base code?
Probably just a couple of ideas for cosmetics, but turning the getters to **BlueprintPure **would be helping with better organizing BPs. Vehicle classās components are not marked for blueprint access but you can use meta prioerties to solve this problem with privates. Example:
UPROPERTY(VisibleDefaultsOnly, Category = "FGearVehicle", DisplayName = "Mesh", **BlueprintReadOnly, meta=(AllowPrivateAccess = "true")**)
UFGearSkeletalMeshComponent* mMesh;
This change would potentitally deprecate some of those dummy getters. Also, controllerās rotation is not replicated to server. For instance in Character you can see they pass the 3 axes along with the rest of the movement values, and using a byte packing to minimize load. On that note, just noticed you are replicating individual values for movement, whereas a struct would probably be just as suitable for this purpose and made easier to extending on.
Additionally, many components of vehicle should not be mandatory, instead allow us to setup arbitrary vehicle configurations, eg change on the number of wheels without ādisableā any. It is nice to have a 4 wheeled vehicle class predefined, but that shouldnāt be the only base class i suppose. It would be easier to setup different kind of vehicles with or without wheels. In fact wheel components could be replaced with other phyiscs forces. Think of boats, bikes and so on!
Naturally. Everybody does who try networked physics. But we can take a closer look at **FPhysicsReplication::ApplyRigidBodyState() **for epicās approximation. Tho i understand you have ran into issues with syncing, but that could be a mere version specific issue. Also it appears to gets continously updated which is quite exciting to see, they now include ping in the calculations, and by extending it further itās possible to get a playable solution out of this.
Then i have to do it, but merging will be difficult. It would be ideal to strip the replication code in such a way that allows easy modification without refactoring big portions of the code.
yes, v1.2 is planned to be released this month, we are in testing phase.
some of them are included but we avoid structural and game specific changes.
those getters will be needed for c++ users anyway, am i right?
we only replicate inputs in FGearReplicatedInputs struct, the remaining replication is the regular pawn replication + interpolation. which parts of the code are you referring to?
arbitrary vehicle configurations sound nice but not planned for near future. the structure started with a 4-wheel vehicle sim and evolved around that. even multi axle setups are not fully supported, some of the features are directly developed for 4-wheels. you can fake bikes but motorcycle physics are very different if you want realism so we do not want to enter that region.
replication will be reiterated in the future releases, we also hope there will be improvements in the epics replication.
actually replication related code is minimal and it should be pretty easy to strip it. if you have the v1.0 sources you can easily see the difference, if not drop me a mail.
thanks.
the latest sandbox demo(there is an additional rc car sample) is available here.
here is a preview of the upcoming v1.2, video showcasing a couple of new features:
Great Job!!!
Do you have release notes?
I want to know if I can change individual wheel settings.
i will post the full release notes when its released.
yes you will be able to modify individual wheel settings, not recommended though.
fixed downloaded the example and was able to get it to work. Thank you so much ! Great plugin by the way. Cleanly coded and runs fantastic
How well would this perform with 30 cars in multiplayer on a dedicated server? Is there client side prediction? Every other vehicle solution Iāve tried is jittery in MP.
How do the cars react to physics interaction? If I were to put a car on top of a large physics object (e.g. transport helicopter) would the car be moved smoothly or would things glitch out?
to be honest i am not confident about the multiplayer part yet because we have recently added and it feels a bit laggy at the moment. we built it on top of regular pawn replication + relaying inputs from server + client side interpolation. unreals pawn replication had problems with rotation updates at that moment so we had to use interpolation to make sure the transform is correct but it added an extra small delay. the physics interaction feels nice and natural between vehicles(at least at low ping) but we have not tried that kind of(putting on top of a large physical object) interaction yet. our focus will be on replication for the next release(after v1.2) and we also plan to put a multiplayer demo too.
In serverUpdateState() just submit the FGearReplicatedInputs struct instead, not the individual values. The second part was about sending controller rotation of autonomous to server, since playercontroller wontā do it. You can find example of this in UCharacterMovementComp.
The problem always is with merging local changes to marketplace entry updates. Fewer the customizations the better for us, users.
In bluemanās plugin you can find an experiment of implementing a rewind feature for client-side prediction. Itās crashing a lot, not resource firendly at all, and not compatible with certain vehicle configurations but itās one interesting approach anyways, you can perhaps derive a finished version. Iām trying an alternative solution by extending on epicās rigidbody replication instead, and resolve some of the jittering/stuttering issues mentioned above.
it sounds like the lag compensation approach of source engine but i am not sure if it would be useful in a racing game where things move too fast. today we made some tests and our current replication fails miserably(in some cases) in 4.24 but fine with 4.22. i think it will be wiser to develop an implementation that does not depend on epics replication.
In which cases? Could you be a bit more specific?
I think in FGear 1.1 the clientInterpolation() method going to dismiss what FPhysicsReplication have achieved, since it will calculate a new world transform for the body using the replicated (very old) value. I have this method disabled but the body seems to be replicated fine, since epics replication takes care of it already. Tho it still feels slugish to drive, since no client simulation for the vehicles allowed either way.
They refactor this replication logic since 4.18 and itās looking different now. Earlier it was enough to simply override a few methods in pawn, but now itās probably a bit more complicated to use, tho essentially the idea remain same. I donāt see much changes in 4.24 to FPhysicsReplication, perhaps the issue you see is coming from this change which was supposed to be a fix for UE-75150.
Hi, We are creating a multiplayer racer and Iāve been following this for a while now as we have tried all sorts for the last few years to have āsmooth non jitteryā clients.
I am hoping that you find some form of working state for multiplayer replication as Iām sure itās not just me who wants to see this but many others and I will happily purchase this. Currently we are developing using BlueMan which seems to be the most viable at current but I have high hopes for FGear.
Please do keep us updated.