I can be wrong, but if I remember right there is no correct formula for the fuel, as the the fuel consumption differs from car to car. The usual trick is to multiply the track length with 13, for my track (is a bit longer) 14 did the trick. But there will always be a small or bigger difference, depending on what car is used. For a correct fuel calculation you'll need to drive the car and read out the fuel used with a plugin. Even with identical cars and setups, the fuel use can differ up to 0,3 liter per lap depending the driver and it's style... So no chance to define this with a value in a track file. Have a look in the AIW and you'll find these values. lap_length=5521.599121 * 13 = FuelUse=71325.835938
forgot to mention: the result FuelUse=71325.835938 is used from the AIs to calculate their fuel use and you'll get this as readout in the garage screen (for sure calculated with the fuel use entered in the engine.ini of the car)
Also to consider are elevation changes. I've got a half km elevation change on my long track... four times (think: like a bidirectional, dual Pikes Peak). Presently, for other aiw file tasks, I have the inclination / declination.... as well as likely turning angles at each waypoint (5m separation)... which could easily be interpolated to each meter.... Thanks for the * 13, A13.... ( i trust no bias was involved..). Sounds like a good starting point. edit: cool.... I'll look at that ini file another edit: Yea... the FuelUse variable is the one I am interested in mathing about. I already calculate the fast line length in the script's fast structure... where the incline and corner angles are also collected to help in generating the fast line. Kinda hoping to not have to go the trial and error route.
Ok... a little progress. I looked at wiki for f1 cars and read that the V8's used fuel at about 75 liters per 100 km traveled (~1.3km / liter). So.. using rF2 f1 (like) car & Toban in rf2: track length = tl = 4.017km (toban_long.aiw) fuel usage = fu = 58471 (toban_long.aiw) fuel consumption = fc = 3.1e-5 (engine,ini) fuel estimate = fe = 1.745 (engine.ini) then: fu * fe * fc = liters per lap = ~3.163 and: (liters per lap) / track length (in km) = liters per km = 3.163 / 4.017 = ~0.787.. or: track length / (liters per lap) = km / liter = ~1.27 km / liter ... both sound alot like what I read on the f1 wiki page for the car milage. In rF2 (toban long) these figures check out when adjusting starting fuel values (same with rF2 Trainer values). Needed will be a way to calculate a "liters per lap" value for the recommended rF fuel sim vehicle... based on track topography. After that, algebra gives the aiw file "FuelUse" parameter. If anyone has the engine.ini file for the car that isi recommends to do fuel testing with... please post it here. I bet the "fuel estimate" figure in that .ini file will be 1.0 [Just guessing on all this at the moment ... so if any (or all) of this is garbage... please post a suitably snarky response.]
To me, it seems like you're going to a lot of trouble for what is ultimately an estimate. Wouldn't it be better to put 10-20 liters in several different ISI cars and drive them to see when they run dry? That will work out to some constant value and you take the conservative one (highest fuel usage). The thing is that some tracks, like Thruxton, Watkins Glen, and ovals, you're full throttle much of the time. Other tracks, with lots of left/right long sweepers, you're only running a maintenance throttle.
You're absolutely right.... but I look at it as going through a lot of fun. Presently, the script creates an aiw file in 3dsMax... in about 5 miniutes. "FuelUse" is the only meaningful parameter that I can't make (..yet). So.. this one parameter will need a simulation. It will be for the "base" car that rF uses for it's fuel calculation. When fed the waypoint, and curve structures (generated anyhow while making aiw file), it will output the "Liters per Lap"... which yields the "FuelUse" parameter. It doesn't have to run in real time, be drivable, display anything, or sound like anything.... and should be able to complete a lap in sevral seconds (maxScript can be slow). Whether it's fed Watkins Glen, or Monaco should not matter.... It will already "know": -- the 'fast line' at the track, -- length, angles & inclinations for straights & corners, -- test vehicle acceleration, deceleration, & cornering speeds, -- test vehicle fuel consumption at various loads, etc.... It seems like it should only take a month or so .... which means it will probably take 3 or 4 months to write. Thereafter, it will only take seconds. And you're right... it will only be an estimate, just like ISI's (a simulation); an "in the ballpark" figure that works well enough for teams to work their fuel strategy around in-game. -------------------------------------------------------------------------- Oregon.... eh... Ever been tubing on the Willamette?
> You're absolutely right.... but I look at it as going through a lot of fun. LOL, I can appreciate that! > Oregon.... eh... Ever been tubing on the Willamette? Tubing only on the Sandy River and I've also kayaked the Marys River by Corvallis. Fished a fair amount of the Willamette above Eugene, too.
After googling yesterday, it turns out that the "fuel consumption" value in engine.ini is liters per radian (of crank shaft rotation). That's why 'fuel consumption' for an f1 car in the .ini file is 3.1e-5 (so... 31 micro liters / radian). Knowing that doesn't help to make the f1 leaf blowers interesting this year, but it helps answer some of the fuel flow questions. [Notice how when the cars stop, they bring a bunch of other leaf blowers over so the 'power unit' doesn't get lonely?] FuelUse param will have to wait though.. making a test aiw file for Mario's Laguna a few weeks ago highlighted some deficiencies in my spline editor. It's much better now... you can select butloads of spline knots if you want (rather than only one), and move them in any direction with "terrain following". Working on 'snapping' collision corridor spline knots to walls today. The last spline editor function will be "auto-vect": If you're moving a selection of inside corridor or cut corner spline knots to the inside of a curb or wherever.. ..it would be nice if their In & Out vector handles automatically adjusted themselves to the smaller radius. -------------------------------------------------------------------------------------------------------------------- Yea, Emery.. nice river you got there... (In Holland, they let you speed-skate on their rivers). View attachment 13338
thanks jka... and thanks to jka also... (I suppose you guys can do twice the testing that other ISI Testers do). In the image below: The numbered rollouts are controlled by a 'state machine' to guide you through the building process. Rollouts are opened for you, and the next button you need to use is enabled... when the previous step has been completed. A button's "tool tip" tells you what you need to do (select edges, wp, spline knot, whatever...) before pressing the button: 1. Select the edges along the center line of your track. 2. Press this button ...which is pretty fast and easy to do if you know where Max's "Loop" edge select button is. If you forget to select any edges, or too few... a message box tells you about it. Recently re-wrote a bunch of things so that 'ai objects' in max are time-stamped... when made, edited, and / or measured (as is the case with wp <--> spline offsets for driving lines, corridors, etc..). So... the script always "knows" everything that has been made for the ai, anything that is missing, and if any offsets need re-measuring before updating the file. All of that data is stored in the ai objects, so it gets re-read when the script 'wakes-up' thereafter. The :::Edit Ai::: rollout displays what (if anything) needs doing before updating the file... so you don't have to guess..... (...feature that). View attachment 13345
@MM... It's being written by one... does that qualify? Most of this is to learn some of the technology that your generation has developed; another thing to study in my retirement. As a kid, the only monitor I had was on an oscilloscope, and state-of-the-art storage media was paper. Having never played a video game, I'm still a noob to this technology, and have tried to design the controls on aiw~thing so that it's easy for other noobs. A couple decades ago, I designed a film synchronizer for 70mm stuff that was too complex for it's intended users (vfx directors). The result was that I had to follow it around, wherever used.. babysitting it... which was lucrative, but boring. (Some of it wasn't so bad... one of the films that used it involved a spy who was, evidently, shagged.) Since then, I've made an effort to design things that are easier to use. Presently, the aiw~thing code is locked into "guide me" mode. Been thinking about ideas for 'raikkonen radio-buttons' at the top of the script... one being the existing "guide me (mode)"... and the other being a "leave me alone...(mode)". Either way... "visual aiw" is still much easier then what's currently available. @Rik... Grazie... Now, if we could just solve some of the problems at Maranello.....
This (image) is the second of what will be some of the most boring tracks ever built. It is for testing fuel usage, acceleration & braking distances. Length is 4km in each direction (which may change as needed). On the side with pits, the fastline will zig-zag all the way to warm the tires (except in front of the pits). The far side will be for testing accel / decel fuel usage. A telemetry plug-in will gather the data. Eventually, clones of this track will be made at various inclinations so we know rates for hills. A number of circular tracks of varying radius' & banking will also be needed (with appropriate tire warming stretches). The data will be used to build up a "base fuel usage model" for the car.. as well as a "performance model". Look-up table interpolation would probably be the easiest ... but I have a fuzzy c compiler I might use (for an algorithimic approach). The trick will be to distill the (plug-in) data gathered on the test tracks into a "rulebase" in maxScript that eats aiw data, and yields a FuelUse figure for the aiw file. View attachment 13433
