People have shown a lot of interest in learning how my custom hybrid system works, and I'd love to share what I've written so far. I have the source code for all my mods here: https://bitbucket.org/ArcanoxDragon/beamng-mods/src/master/ I used to be a huge fan of Rigs of Rods, and a lot of the concepts are the same between that and BeamNG, so I was able to deep-dive pretty quickly into Beam's modding system. I also have plenty of Lua experience thanks to Garry's Mod, Minecraft, and Dovetail's Train Simulator, which definitely helped when I was combing through BeamNG.drive's source files. My desire to create a hybrid powertrain comes from my general fascination with alternative-fuel vehicles, and the fact that most of the cars I've driven regularly have been hybrids. I first learned to drive on a '06 Highlander Hybrid, drove an MKZ Hybrid for a couple years, and now own a '16 Volt. Because of this, I'm very familiar with how hybrids operate, and BeamNG seemed like the perfect sandbox to try and recreate the systems I'm familiar with myself! NOTE: MOST OF THE INFORMATION IN THIS THREAD IS OUT OF DATE. I'm working on creating a new documentation wiki for the hybrid system now that I've released Version 6. The Version 6 update included a massive rewrite/restructure of the hybrid system that renders most of the technical information in this thread obsolete. The general principles still apply, but until the new documentation is ready, the info in this thread is not reliable. So, onto the powertrain itself. As with most things in BeamNG, the hybrid powertrain is modular, however most of the logic is in the transmission "unit" itself (powertrain device + controller in BeamNG), as is the case with a lot of popular hybrid vehicles (Toyota, Chevy, Ford, etc). For example, on the Chevy Volt, the entirety of the hybrid drivetrain except for the battery is in one self-contained drive unit (the transmission), including all electronics/computers. In BeamNG, my hybrid transmission is composed of a custom "eCVT" gearbox and a fairly complex Lua controller to manage the drivetrain as a whole. Transmission The transmission component of my hybrid system is referred to as an "eCVT" (electric continuously variable transmission), borrowing terminology used by Toyota and Ford who both use the same hybrid system and who both refer to the transmission as such. The term "eCVT" is somewhat misleading, as a typical CVT uses a series of belts and pulleys to constantly adjust the torque ratio of the engine to the wheels, whereas an eCVT operates at fixed gear ratios with no way of adjusting them. Despite using fixed gear ratios, the dual-motor system made popular by Toyota allows the engine to transmit constant torque at a constant RPM regardless of the speed of the vehicle. An excellent explanation of this transmission can be found here and here. I simulate two electric motors (known as MG1, which is the starter-generator, and MG2, which is the drive motor and also handles regenerative braking) using real induction motor torque equations, but I'll admit that I cheat a bit with the math since there are way more variables in a real induction motor's operation than I care to simulate. On a real dual-motor eCVT, the top speed of the vehicle is limited by the maximum RPM of the two electric motors. At high RPMs, the motors tend to vibrate which can damage the transmission. This also means that above a certain speed, the engine must be spinning to slow down the rotation speed of MG1 (see the two sites linked above to understand why). In newer eCVT transaxles, the design of the motors and gears has been optimized such that the maximum RPM is quite high, so this becomes a non-issue except at very high vehicle speeds. My custom gearbox is written in a manner which allows it to be isolated from the hybrid powertrain logic. If another controller was written which was aware of my gearbox's inputs/outputs, my gearbox could be reused separately from my hybrid logic. Hybrid Controller All of the actual hybrid system logic is contained in the hybrid controller file, called hybridArcanox.lua. This controller is referenced by the transmission JBeam component and configured there as well. Both the transmission and the hybrid controller have a great number of configurable JBeam properties that control essentially every aspect of their functions. This amount of flexibility is what allowed me to copy-paste the hybrid system from the ETK800 to the City Bus without changing any code at all, and still allow both vehicles to handle as would be expected for their vehicle class. I will explain function-by-function how the controller works at a fairly high-level. The code is in the repository linked above for those who are familiar with Lua and who want to learn more. I have included a debug UI app as part of my Hybrid UI Apps mod. Simply choose the "Hybrid Debug" app in the UI app customization screen and place it on your dashboard. The app shows a large table with dozens of values used by the hybrid system for simulating the various components. Now, I’ll do an in-depth walkthrough of the system code, file-by-file and function-by-function. I’ll start with the top-level “lua” folder found at the root of each mod archive. This is the “utility” code used in several places. debugutil.lua This file provides functions to utilize my “Arcanox Debug” UI app. The file exports a single function which is then called with a “tag” and an “enable” flag, and it returns an object representing a particular debug instance. For example, the hybridArcanox.lua file has the following line: local debugutil = require("debugutil")("hybrid", true) The “debugutil” variable now holds an object which can be used to send values to the UI app like so: debugutil.putValue("State", state) This will put a value called “State” on the UI app showing the value of the “state” variable. engineUtil.lua This file provides some wrapper functions for getting data about engines. There isn’t much to note here. It exports three simple functions. getBestRpmForTorque returns the lowest RPM at which the engine can provide the specified torque output. getAchievableEngineTorque gets the maximum torque the engine can provide at its current RPM, adjusted for friction. getInstantMaxEngineTorque is the same as the previous function except that it accounts for the presence of a turbo or supercharger. latch.lua This file exports constructors for two classes representing logical “latches”. newTimedLatch(timeToLatch, immediateLatchOnTrue, immediateLatchOnFalse) This is the constructor for the "timedLatch" class. The “timeToLatch” parameter determines the time in seconds that the latch’s input must remain steady in order for the output to flip to that value. Either of the “immediate” flags can be set to “true” to ignore the timer for that value. For example, if the latch is constructed with “newTimedLatch(1.0, true, false)”, the latch will immediately output “true” for any “true” input, but the input will need to remain “false” for a full second before the output will go false. This returns a “timedLatch” object with two functions: timedLatch:test(value, dt) This is intended to be called every game tick. It accepts a “test value” and the “dt” value passed into the updateGFX function by the game. This function will update the latch’s internal timer and return the latch’s current value. If the “test value” flips from false to true, the latch will remain “false” until its timeToLatch time lapses, and vice-verse if the value flips from “true” to “false”. If either of the “immediate” flags was passed to the constructor, the timer is ignored for that value-change. timedLatch:reset(value) Immediately resets the latch to the provided value (or false if omitted), ignoring any time constraints. Resets the internal timer as well. newThresholdLatch(thresholdOn, thresholdOff, initialState) This is the constructor for the "thresholdLatch" class. This returns a “thresholdLatch” object with one function, “thresholdLatch:test(value)”. This function accepts a scalar value and returns either true or false depending on the latch’s internal state. The input value must become equal or greater than thresholdOn in order for the latch to flip to true, and once it is true, the input must become less than thresholdOff for the latch to flip false again. mathutil.lua This file exports several mathematical helper functions: round(value, precision) This function rounds the provided value to the provided number of decimal places. For example, round(1.2468, 2) would return “1.25”. sign(value) Returns the sign of the provided value. If the value is exactly zero, returns zero. If it is greater than zero, returns 1. If it is less than zero, returns -1. maxall(…) Accepts any number of numerical arguments and returns the largest of them all. minall(…) Accepts any number of numerical arguments and returns the smallest of them all. clamp(value, min, max) Returns the provided value clamped to the provided bounds. I.e., if “value” is between “min” and “max”, it returns “value”. If it is smaller than “min”, returns “min”. If it is larger than “max”, returns “max”. maprange(value, srcMin, srcMax, dstMin?, dstMax?, clamp?) A simple linear-interpolation (lerp) function. Maps the provided input value from the source range to the destination range, or to [0, 1] if no destination range is provided. Clamps the value to the destination range by default, but “false” can be passed as the final parameter to allow the value to follow the slope of the range outside the destination range. blend(value1, value2, factor) A linear mix function. Returns “value1” if “factor” is 0, “value2” if “factor” is 1, and a linear interpolation between “value1” and “value2” using “factor” as the time parameter otherwise. kwToTorque(kw, av) Returns the torque produced (Nm) by a certain amount of power (kw, or kilowatts) at the specified “av” (angular velocity, rads/s). torqueToKw(torque, av) Returns the amount of power (kw, kilowatts) required to produce the specified “torque” (Nm) at the specified “av” (angular velocity, rads/s). pid.lua This file exports a constructor for one class implementing a standard PID controller. See https://en.wikipedia.org/wiki/PID_controller for a description of such a device. simplecurve.lua Exports a constructor for a “simpleCurve” class, which simplifies creating a curve out of a header table like the combustionEngine device does with its torqueCurve. The “headerTable” parameter is a JBeam header table with two columns, the names of which should be passed to the “xAxisName” and “yAxisName” parameters respectively. An optional default header table can be provided if it is possible for the input table to be null. The object returned from this function has one function, “simplecurve:get(x)”, which returns the y-value of the curve at the provided x-value. The simpleCurve object also has “minX” and “maxX” properties as well as a “curve” property representing the raw curve values. Now, in the vehicles/[vehicle]/lua/controllers folder, is the heart of the whole system: hybridArcanox.lua This file is huge and has a ton of complex logic in it. Diving into this file is not for the faint of heart! getProportionalBatteryRatio This function is referenced in several places throughout the rest of the file. It returns a percentage value (from zero to one) representing the current charge level of the battery within the battery's "working range" (which is a smaller range than the battery's actual total capacity). The two values passed in allow this "working range" to be collapsed or expanded, which can be used to vary certain logic based on different ranges in the battery's state of charge. calculateElectricLimits This function is called every game tick and calculates the current electric subsystem limits, such as the available battery power and how much battery power is allocated to “priority” power versus “secondary” power. calculateTorqueStatistics This function is also called every game tick and calculates the instantaneous torque characteristics of the system, taking into account the available battery power (when determining motor torque) and the engine’s maximum output torque. These characteristics are then used to map the throttle pedal input to a “torque to wheels” output so that the feel of the pedal is linear regardless of the current drive mode. requestEngine This function can be called anywhere else in the code to request that the engine be started on the next game tick. This is useful for if a complicated part of the controller logic needs to request that the engine be on, but the logic can’t be determined in isEngineDemandedOn. isEngineDemandedOn This function uses several points of data to determine if the engine should be on or not (the engine can be off while the vehicle is on and driveable, or "Ready" in common hybrid terminology). This function takes a number of different variables into account, such as the throttle/brake pedal positions, coolant temperature, vehicle speed, vehicle pitch, battery level, and gear selector position to decide if the engine should be running or if it can shut off. This function runs every frame of the game. If you've turned debugging on, you'll see the "Engine demand reason" at the top left of the screen explaining why the engine is on, as well as “Engine triggered on by” to reflect the reason the engine actually turned on. The engine can be demanded on for several reasons at once, and these can change while the engine is running, so it’s useful to see not only why the engine is currently running, but also why it started in the first place. updateValues This function is pretty small and self-explanatory. It retrieves a number of pieces of data from various parts of the game engine and stores them in "upvalues", or file-global variables so that they can be easily accessed in other parts of the code. It also handles updating a couple of timers using the "dt" (delta-time) variable passed in by the game engine. updateState This function handles the internal state machine, responsible for handling state-dependent logic and deciding when to switch states. The states include "init" (the starting state), "evmode" which forces the engine off (electric-only operation), "chargemode" which high-idles the engine to charge the battery faster, "running" which is any logic that occurs only when the engine is on, "stopped" which is any logic that occurs only when the engine is off, and "startup" which handles the period of time when the engine is starting and not able to provide torque. The vehicle can only be in one state at a time, which prevents weird things from happening if, for example, the driver tries to enter "EV mode" as the engine is still starting up. The state machine also looks for improper state, such as if the engine dies or runs out of fuel, and attempts to resolve itself as best possible. updateBattery This function is responsible for measuring all current consumption/generation by the transmission and engine and using it to adjust the energy level of the traction battery. The system uses BeamNG's built-in "electricBattery" device to store and track energy, meaning the battery is a component on its own and a vehicle can have multiple battery options each with its own performance characteristics. updateSounds This function is very simple and self-explanatory. It simply controls the volume/pitch of the two hybrid system sounds, being the motor/gearbox noise and the "inverter current" sound (a high pitched sine-wave-like sound when accelerating or braking). updateGUI This little guy just compiles some variables together into a stream object to push to the game's UI (for my EV battery monitor app and the debug app). updateGFX This monstrous function is the main block of logic, called directly from the game engine. It handles calling the other functions as well as most of the hybrid logic that isn't directly state-based. The first large block of logic, inside the "if gearbox and engine and battery" block, handles calculating some value limits based on the battery and engine characteristics. These limits are used to prevent too much current from going out of or into the battery (as I eventually would like to implement battery damage/failure, including overheating and Lithium thermal runaway). The next large block of logic handles regenerative braking calculations when the driver's foot is on the brake pedal; these calculations tend to be very tricky with lots of edge/corner cases so there is a lot of logic involved. The general gist of the logic is that the faster the vehicle goes, the higher the kilowatt power output produced per pound-foot of regenerative braking torque gets. There's a maximum amount of power the battery can handle, so at very high speeds, you'll have less torque and a very high kW output, but additionally, as the vehicle nears zero-speed, so does the regenerative braking torque, so it's a bit like a very lopsided bell curve. The hybrid system will adjust the per-wheel balance of friction braking power so that wheels that are connected to the transmission have less friction braking power when the regenerative braking torque is relatively high. As the vehicle slows down to the point where the regenerative torque begins to fade, the friction brakes increase again on those wheels to cover the loss in braking torque. If any sort of stability/traction control kicks in such as TCS, ABS, ESC, etc, the regenerative braking system is immediately disabled and friction brakes take over for all braking power until traction is regained. Additionally, in the "L" gear, instead of using the engine to slow down the vehicle as a traditional gas-only vehicle would do, the hybrid system instead uses 100% regenerative braking torque with absolutely zero friction braking. This means that coasting down a hill or approaching a stoplight in "L" without touching the brake pedal is capturing as much momentum as is physically possible back into the hybrid battery. The next block of logic occurs when the driver is not braking. It is responsible for directing the throttle pedal input to either positive acceleration or regenerative braking depending on if the gear selector is in "L" or not. The final gigantic block of logic determines how the power should be split between engine and motors. The throttle is mapped to an overall “requestedOutputTorque”, which is the torque that the driver has requested be applied to the eCVT transmission’s final drive. This isn’t necessarily torque-to-wheels; if the differential has a gear reduction, for instance, the torque-to-wheels will be different. Once the overall output torque is determined, a lot of logic comes into play to decide how that torque should be achieved. If the battery is quite full, there is a good bit of “priority electric power” available, so a lot of the requested torque will be distributed to the main drive motor. If the battery is low, or if the driver is requesting more torque than the electric motors can provide, the remainder of the requested torque is distributed to the engine, if possible. This torque is achieved by placing load on the engine using MG1 (either by using MG1 as a generator, or by applying reverse torque to it at high vehicle speeds). This negative MG1 torque, along with the output torque of the engine, induces an “equal-but-opposite” reaction on the Ring gear, which is directly coupled to the final drive, hence applying positive torque to the output shaft. If there is still torque requested that has not been achieved, it is distributed as best possible back to the electric drive motor. This means that if the battery is very low and the driver floors it, the electric motors will still kick in to apply torque if the engine is not able to provide enough on its own. If the battery gets too low, however, this is not possible and the total output torque will be drastically reduced until the battery regains some charge. Finally, in order to keep some reserve power in the battery, the vehicle will apply extra load onto the engine (or in some cases, extra regenerative drag) while cruising to charge up the battery slowly. The closer the battery is to its “happy range” (50% by default), the less powerful this “passive charging” will be. If the battery is above its “happy range”, there will be no passive charging. In fact, if the battery has a significant buffer, the system will perform what I refer to as “engine deload”, meaning that if the engine must be running (i.e. to warm up, or because the vehicle is travelling too fast) but is not actually providing power, the system will use a little bit of the excess battery power to spin the engine using MG1, thus greatly reducing the amount of fuel the engine must consume to idle. One of these days I'll write a summary of the eCVT Lua file. It's not terribly complicated, but it's tricky understanding how torque/speed/inertia flow through the system. Summary There isn't much more to explain without diving deep into the code, so I'll leave the rest to those adventurous enough to check out the source code of the mod. Integration This next section is about integrating this system into other vehicles. Feel free to adapt this system to a vehicle of your choice, but please don't release it as a mod anywhere without asking me first. Fair warning though, applying this to another vehicle is a very demanding task requiring extensive knowledge of JBeam and hybrid cars in general. Spoiler The first step in applying this system to another vehicle is to create a mod folder inside the BeamNG.drive/mods/unpacked directory. This is typically in your Documents folder. To see an example of the required folder structure, just use the "Unpack" option on any of my hybrid mods in the game, and it will extract the mod to the "unpacked" folder. You'll need to recreate the correct vehicle folder structure for whatever vehicle you're modifying, just as with any other vehicle mod. The next step is to copy the hybrid system code into your vehicle folder. The easiest way to get these files is to download my code repo (see above) as a ZIP file and then extract it. Navigate to the "etk800_hybrid" folder (not the citybus, as it has extra Lua files you don't need). First copy the "lua" folder from here into the root of your new mod folder. Then navigate to "vehicles/etk800" and copy the "lua" folder here into your specific vehicle folder. These two "lua" folders must be kept separate. If you want to add the "EV only" and "charge mode" keyboard shortcuts to your vehicle, you'll have to copy the necessary files for those as well. There is info on the official Wiki for writing custom input bindings, so I won't go into detail here. Now that you have the necessary code, you'll need to build JBeam parts for your vehicle. I usually work with two .jbeam files: one for the transmission(s), and one for the battery (or batteries). See the "etk800_hybrid_transmission.jbeam" and "etk800_hybrid_battery.jbeam" files in my code repo for examples. The main points to note for the transmission part are as follows: The gearbox type MUST be "ecvtGearbox", not "automaticGearbox" or any of the other available types. The hybrid system relies on the gearbox being an eCVT. There is a controller attached to the gearbox part that references the "hybridArcanox" Lua controller file. This is what makes this a hybrid gearbox. You need to define a slot for a traction/hybrid battery somewhere. I typically do it in my transmission part so that a hybrid battery cannot be installed on a vehicle without a hybrid transmission. You should add a mainEngine section to the transmission part to adjust some parameters of the ICE (internal combustion engine) when a hybrid system is installed: electricsThrottleName: set this to "iceThrottle". This is how the hybrid system overrides the engine throttle. If this is not set to "iceThrottle", it WILL NOT WORK. idleRPMStartCoef: Set this to 0.0. This value is the additional throttle provided to the engine during startup. Because the hybrid gearbox spins the engine to its idle RPM before turning on the ignition, this is not needed and would simply cause unnecessary revving and lurching. You should also add a vehicleController section with the following parameters: automaticModes: set to "PRNDL" (L gear engages regenerative braking when the throttle pedal is released, without touching the brake pedal). defaultAutomaticMode: set to "P" (not "N", as the engine will never shut off in "N"). The main points to note for the battery part are as follows: You should typically define a variable to adjust the SOC (state of charge) of the hybrid battery in the Tuning window, so players can adjust this manually. The energyStorage type must be "electricBattery" but the device name must be "tractionBattery". There are extra JBeam properties that are supported by the hybrid system that are simply stored on the battery device (even though the default electricBattery device does not know what to do with them) The best way to set up a new vehicle is just to replicate the structure I use for the ETK800 but replace all part/slot names with the correct ones for the vehicle you're working with. Once you've completed this structure, you should be able to load the vehicle in-game and see the hybrid system "working" through the debug app (without any fatal errors), although it may not be driveable right away. The next step is setting up JBeam parameters. There are a plethora of parameters available for the transmission (gearbox), hybrid system, and battery. NOTE: I need to rework the documentation for the JBeam parameters. The parameters and their descriptions that were here before were quite outdated. I’ve removed them until I get a chance to rewrite the documentation. In the mean time, you can look at the source code to see where and how each value is used.
Not sure if this is the correct place to report bugs, but here goes for the citybus: When state of charge is around 80% and you go full throttle, the engine is not used, this could be by design (the electric motor is able to deliver 400hp at the wheels), but when soc (state of charge) is below that (where the engine cuts in) the wheel power is both the motor and the engine. This means that it can exceed 400hp, sometimes even to 600hp. (this is not the UI app lying, it really does move a lot faster than normal in this state). And whilst doing this, there is roughly a net 8kw input to the battery. This means that whilst the motor and the battery are working together (their powers are added) it is also charging. This doesn't happen in the "L" mode. But the power is halved at the engine in L mode (slightly odd, but you said you knew about this in the reply to the review). Also idle citystop is a thing on buses, it does exist in real-life:
Interesting...I didn't know buses existed that had idle stop. I've always heard it was "bad" for diesel engines (probably emmissions-wise) to rapidly stop and restart, but perhaps technology has been developed since I heard that making that irrelevant now. It's a one-line jBeam change to enable auto-stop on the bus (plus a few more lines to remove the starter sound and make it start faster), so it's certainly doable. As per the HP observations you made, it's probably bad calibrations on my part. I haven't done a whole lot of tuning and I honestly forgot that the horsepower UI app existed, so that's probably just a result of some values being a little off and curves not lining up. And yeah, the issue with "L" has to do with incorrect throttle mapping for the engine causing the ICE-electric balance to be thrown off. I'll probably be pushing a new update to fix several things this weekend.
Speaking of bugs, driving in reverse charges the batteries, instead of depleting them . Also, the EV controller doesn't seem to play nice with cruise control.
Huh; I know I've fixed that on my copy but I thought I fixed it before releasing the latest version. Guess not! I've actually never even touched cruise control in BeamNG (and hardly use it IRL either ) so thanks for finding that! I'll look into it this weekend.
It might be conflicting with the old version, it said the file name changed, I went and manually deinstalled the mod and reinstalled it as I had mine just crash the bus, there (vehicle exception error), but a reinstall later and it was good.
I've seen that warning...I kind of assumed the game would handle filename changes but it's possible that's causing a conflict. I'll remove the version from the filename next version to reduce the chance of that
best thing to do is leave it as is now. My game was just misbehaving, isolated issue i think. I did have a weird mixture of subscribed and downloaded .zip mods, i think yours might have been a .zip i downloaded manually (hence why when i subscribed to a new update, it glitched). There was a day or two where the subscribe button didn't work, so i downloaded .zips then. But now i went through the .zips and gone back to the subscribe feature now.
Wow it's perfect now! (i wish the bus mod had a discussion tab so we could talk about that in the right place). Now i can only think of two things to add: Range hold mode: Uses engine and keeps the battery at 90% or so. (i don't know how this would be implemented) But it charges the battery at the same time, like instead of using EV mode it uses the engine and charges the battery at the same time, until it hits 90%, where it will just use engine, until maybe beyond 90% throttle (kickdown power boost). Normal mode (could also be called eco mode): Electricity used, increased to max extent dependant on throttle THEN engine comes in to boost power when the battery can't deliver enough power to satisfy demand. Range hold mode: (could also be called sport mode, would be good on ETK also due to the car's sporty nature) Engine used, increased to max extent dependant on throttle THEN battery comes in to boost power when the engine is maxed at 300hp (to deliver the necessary power). Power limit, i'm not sure if this is appropriate really, maybe limit the power to say 400HP since you could be zooming at say 500HP when at 90% battery, but that deteriorates as the battery decreases. In real world we want power to be constant, ie, when the bus driver puts his foot down, it should do the same thing whatever. (but then we miss out on the increased power available ) Also that compressor noise thing you added in the latest version, that makes such a difference!
Those sound similar to the drive modes my Volt has...I've considered having a separate "operating mode" that acts more like a plug-in hybrid than a normal hybrid (where these modes would be present) but I haven't gotten around to it yet. Not sure if anybody actually drives long enough distances in Beam to utilize that or not
That could be due an almost unlimited number of causes; next time it happens, can you upload your beamng.log file somewhere and link it here? The file is in your Documents\BeamNG.drive folder. That way I'll be able to see the actual error that's thrown. --- Post updated --- Additionally, if you installed the latest game update, you'll have issues until my latest mod update goes live. I'll publish that today.
I'm guessing it's due to the latest game update (Alpha 0.14/the Halloween Update). I have updates to my mods pending approval to fix it. If you want to manually update the mod while the repository version is pending approval, I've attached both the ETK800 and Citybus versions to this post. You'll probably have to unsubscribe in-game before installing the manual versions, and then delete the manual versions and re-subscribe once my updates are approved.
Thanks I got the mod pack but installed it to no due effect, weird but I will give these a shot --- Post updated --- I am impressed with what you have managed thats probably the first EV bus on the forums so far!
@Arcanox I also slightly edited your own code and I added in a 1MWh battery into the bus, all I did was copy the 200kWh battery and swapped out the 200 for a 1000 and it seems to be going well no harm there I wanted to see what it would be like with something that powerful its sorta a "fictional" battery, also can I ask where is the code for the electric motor I would very much like to take a look at it and see how its coded
It's in the gearbox powertrain device; there's a link to my code in the first post of this thread and a paragraph that describes what each file is and where it's located
Thanks I should have realised its the powertrain device I am just adding in my own versions of motors you created but with a twist of my own, totally insane power outputs on them and I may try for a 1MW engine to see if it can be done but I might base most of the numbers off your excellent "Race" version and I will see what happens then and there I mean if its possible you know Also I feel for the ETK856 it may need like a proper "Race" version something with a bit of kick in the ass maybe a full RWD setup so AWD for the standard power but with a Hybrid overdrive to the rear axle only, its just a thought
It's difficult to have two different powertrain chains. Having a separate drive for FWD engine and RWD electric would require significant hacks to the game's powertrain system as it currently exists. Plus, it wouldn't provide much benefit IRL...you get much more benefit having the engine and electric motors working in unison on all wheels (or just front). RWD hybrids don't exist because rear-only braking is incredibly unstable, and regenerative braking only occurs on the driven wheels on a hybrid. The current race configuration that's available in the "Save/Load" menu for my ETK hybrid comes in AWD, and I've clocked it at approximately 2.3 seconds 0-60MPH and I've hit a top speed of about 170 MPH (but it can go faster)
