[ BETA ] Mobility Update v2.12.7-beta

[Tyunge]

ACF MOBILITY UPDATE V1.0.0-beta

This update brings new logic to ACF3 mobility. This update will NOT affect existing dupes that are using the legacy mobility components. Updated components must be spawned new as they do not share the same class as legacy components.

Legacy components cannot be auto updated by using the ACF spawner tool to use the new mobility logic. THEY MUST BE SPAWNED NEW

Legacy Components CANNOT be linked to updated components and vice-versa.

Please view the Other Changes sections for how to enable/disable this update, and to spawn updated components.

**this update is experimental and may have adverse effects to your health **please be patient as bugs may increase in prevalence to its stage of development

Engine Component Changes

• Engine Feedback - engine rpm is matched to gearbox rpm
• Engine Braking - braking torque is applied to wheels in the absence of throttle input
• Engine Over-rev - engines are no longer limited to their redline
• Improved Flywheel Response - flywheel mass has an improved response to sudden load
• Idle Throttle - engines will roll in gear

Gearbox Component Changes

• Gear Ratios Use Realistic Ratios - gear ratios no longer follow a 0 ...1 format
• Improved Clutch Simulation
• Gearboxes Have RPM - rpm is retrieved from connected wheels relative to gear ratio
• Differentials are Open - differentials are no longer limited slip
• Ratio Converter -Converts old ratios to new ratios and vice-versa
• Past Data -Ability to paste data from the copy tool to gearbox ratios

Other Changes

• New Server Setting - server setting to allow client spawning of new engine components - New Client Setting - client setting to spawn updated components - New Client CMD _- acfmobilityupdate can be used to enabled/disable this update - Update Eligibility - notification description added to all engines and gearboxes. !

Future Updates

• [ ] Limit slip slider added to differentials
• [ ] Automatic Gearbox Update
• [ ] CVT Gearbox Update
• [ ] Double Differential Update
• [ ] Auto Clutch
• [ ] Engine Over Rev Damage
• [ ] Clutch Slip Due to Over Torque
• [ ] Clutch Damage

For Developers

Creating Eligible Components To create or update existing engine addons, all engines must have the following variables in their registry:

• Displacement
• FlywheelMassUpdate

Important Info Updated mobility components are NOT acf_engine acf_gearbox classes. Updated mobility components are acf_engine_update acf_gearbox_update classes. The reason for this was to create a separation of legacy and updated mobility components to maintain a stable mobility components as changes are made to the mobility update. The legacy components should be considered depreciated.

[Tyunge]

I notice the calcMass test is failing for KEShove, I was told that it was caused from an unrelated change to KEShove. Is there something I need to update or change for this pull request?

[thecraftianman]

Merge the latest commit from dev and the tests should be good now

[thecraftianman]

Do you plan to move the new functionality into the existing acf_engine/gearbox classes? I assume the separation is to allow this to be used on servers in the meantime, but if this is intended to be the long-term implementation I'm not really sure why it's necessary. Same thing with the FlywheelMassUpdate variable for engines; this should just be moved into FlywheelMass in the end (adding fully new ones like Displacement is fine, but we may want to have a default value for existing addons that do not get updated)

Also for everyone's future reference, this appears to close #250 (feel free to correct me on this if not or tag any other applicable issues)

[Tyunge]

Yes, the end goal is to replace the logic of current acf_engine and acf_gearbox classes. You're correct that the separation, duplicate variables, and server settings are there to make it usable on servers, without forcing a change to existing contraptions that are using the old logic.

The reason I'm approaching the change in this way is to catch any major issues and to get feedback before it becomes the main system. The differences between the new logic and the old logic are great enough that it's a better idea to implement and test along side the old system in the dev branch until it reaches a stable release.

The goal is create an accurate simulation of mobility components which includes engine feedback, engine braking, clutch slip, over rev damage, engine stalling, variable slip rates for differentials, accurate gear ratios, etc.

Displacement is used to simulate engine braking and should be the only new variable introduced. This could possibly be defaulted to 0 for older addons.

[CheezusChrust]

This would also close https://github.com/ACF-Team/ACF-3/issues/134 and https://github.com/ACF-Team/ACF-3/issues/309, one of the most annoying long-standing issues in all versions of ACF

[Tyunge]

This also closes #136 & #103 bug and suggestion

[TwistedTail]

I have a couple of suggestions but I wasn't entirely sure with bringing them up because they could certainly end up being controversial.

One of the topics that has been brought up in the discord when it comes to mobility components is the inconsistency on the units used by them:

• Clutches use 0-1
• Throttle uses 0-100
• Brakes use 0-100 unless you need more then it goes all the way up to 5000 (iirc)

Which makes me think, would it be possible to standarize all these inputs to use a single unit? Changing Throttle and Brake to work with 0-1 would certainly make everything much simpler for the end user, but it'd also break every single old contraption prior this change.

[Tyunge]

Yeah I could make them all use a 0-1 value and for brakes to use 0-50 to keep it relative. The input manager for throttle converts 0-100 to a 0-1 value immediately anyways so that would make the code a lot more simple.

Not sure how the manager for brake converts but i assume it’s the same. I could make a maximum brake force slider for gearboxes so that the brake input could also default to 0-1.

It wouldn’t necessarily break old contraptions, but if they did use say 50 throttle it would be similar to using 100% throttle since the value would be clamped to 1 as a maximum.

I do like this update because it would allow users to use nothing but a chair and a wire POD controller for mobility if they don’t have access to ecu codes