Outdated Heavy Delivery Pack:Utah 0.4.1

The Gas Station submitted a new resource:

Heavy Delivery Pack:Utah - 4 different scenarios, with different vehicles delivering heavy cargo all around Utah

Read more about this resource...

 

what lost brakes i didnt feel any difference

 

Nice scenarios! I had a good time with 'em. The ones with the pickup and the Pigeon were an exercise in precise steering in order to avoid flipping over, haha.

Unfortunately, you seem to have missed some spots in the second Heavy Cargo scenario--you've left a few of the T65's brake parts in the config you made, so it's still able to brake fairly well. Without them, I'm sure it'll be a lot more challenging!

 

I agree with Skirmisher so far: fun, imaginative, and fresh. So far I've only played "Topsy Turvy" and "Heavy Cargo".

• How would you feel about swapping out the contents of the dry van trailer with several weights on the dry van trailer vehicle? That should increase performance a lot since the game currently must have a separate physics thread for each vehicle (so your scenario currently has 5! Most scenarios stick to 1/2).
• Was your intention to leave brakepad_R installed? I'm waiting to play the scenario until you let us know. ;-)
• BTW, what did you have in mind for a LUA? Something that causes brake fade, random failures, or what?

 

how do you attach the trailer?

 

Press the "L" key on your keyboard. See here for a demonstration:

 

I had a mod that was preventing this feature from working properly but thank you for the help. Great mod by the way!

 

Well you're all correct- I did leave them on. But I have an excuse- the front brakes are there because reversing to connect the trailer would be very annoying w/o brakes. I tried it, and it was very annoying. I know this isn't optimal, but since I can't manage to use .lua, I had to find a middle-gound.

That's exactly the plan. I want the brakes to break down when you hit the first downhill section (3rd checkpoint I believe)- that way you'll have the brakes for the trailer connection at first, but then loose them when beggining to go downhill (the front ones as well). Basically- loose all brakes when reached 3rd checkpoint,

 

I think I've looked into this before, but I looked into it again. The brakes are not members of breakgroups, so they can't be broken that way. I'm not certain, but I think the solution might be to create a small loop which iterates through the contents of v.data and finds every instance of brakeTorque and sets it to zero. That's at least one level of nested arrays. I dumped v.data to a file and there are thousands of brakeTorque variables (all largely identical).

I might piddle with it some more, but there are definitely other modders here who are better qualified. I'm not even certain that the approach I mentioned is the 'best' way or whether it would work correctly. It would be much better if the game exposed some sort of interface for changing the brake values but I don't think it does.

 

you can still connect the trailer if you use manual and slam it in reverse to brake or in forward to stop from driving reverse and after the trailer is connected just go to arcade or whatever you want to use

 

So I've heard people complaining Topsy-turvy is impossible... There is no such thing as impossible. There's only extremely hard and nerveracking.

10:07. That's right.

 

Shoot for 3:27... :-D (I purposefully tipped the black one off after I completed the race.)

 

Wow that's unbelievably fast

EDIT:
(keyboard)

 

I'll try and post a quick video.
--- Post updated ---

 

@The Gas Station - I've been looking into fixing "Heavy Cargo B", it's definitely going to be doable. I PM'd a dev and was directed to look in the each vehicle's drivetrain like so:

Code:

for a,b in pairs(drivetrain.wheels) do
    drivetrain.wheels[a].brakeTorqe =
end

Later I was gratified to realize that this is very similar to what I was suggesting above. I just didn't know the correct data structure to loop through. In addition to the variable above we also must set parkingTorque to prevent the use of the parking brake. I also investigated melting the brakes using brakeCoreTemperature and brakeSurfaceTemperature - this works as well.

While working on the scenario one thing I've noticed is that you aren't actually loading your config files at all... when they load it's quite noticeable because the brakes are physically missing so there's a gap between the rims and the axles. ;-) I've attached a screenshot demonstrating that. In your prefab you call out the config in the format of "t65_brakes" but the name of the actual config is t65_brakes.pc - this is not the same thing. In this case it's actually good to omit the ".pc" from the config name - that way it won't show up in the config list outside of your scenario. In other words, the best solution is to rename the configs by removing the ".pc" from their names (and leave the names in the prefab file as they are). The failures to load are also visible in the log.

With that said, adding the brakes back is best since they're needed for hookup etc. Breaking the brakes is going to be pretty straightforward.

I've also constructed a set of simple weights which should weigh 12,000kg total. They don't have a mesh, just a jbeam. This can replace the 3 vehicles you've got loaded into the dryvan currently and results in (a) much better performance plus (b) eliminates all the crazy/annoying noises that constantly happened during the existing scenario. (eg popping tires, constant weird suspension noises, etc) The weights don't shift much currently but a pendulum could easily be added to make them tend to shift more if desired.

 

@torsion Wow man, thanks a lot! That is real nice, and I'll try to figure it out. But I don't really know how the syntax for the .lua commands should look like. would this work if I put in .lua file something like this:

Code:

local function onRaceWaypoint(data)
    if data.waypointName == 'waypoint3' then
        brakeCoreTemperature=0
    end
end

? How will it know to disable the trailer's brakes too?

About the weights: are they like a trailer part or a brand new vehicle? The slot in the .jbeam is "slotType" : "trailer_mod"? The trailer doesn't have a trailer_mod slot.
I am still rather new to modding in Beamng, so I'm sorry if the answers to my questions are obvious.

 

You're welcome. BTW, you certainly realize this, but your mod is a featured mod right now.

Regarding the weights: Go ahead and place the JBEAM file I provided in the correct path (vehicles/dryvan/whatever.jbeam) and fire up the game. The slot is present - it's simply not shown when there are no parts which fit into it. With the file in place you'll see the slot and be able to install the weights. Note that they are invisible unless you turn on node or beam view in the debugging.

The code I posted is a "loop". It means "for each item in whatever do this" - it will find all of the wheels in the vehicle it's run in (one by one) and do the stuff in the "do" section. What you've posted omits both the loop and the correct name to set brakeCoreTemp (should be drivetrain.brakeCoreTemperature). We'll do a second loop for the other vehicle to set it's temps as well. The advantage of destroying the brakes with temperature instead of just eliminating their torque is that it shows in the GUI that the brakes have stopped functioning. Also note that setting the temp to zero won't help... instead I recommend setting the temp to something like 2000 (assuming you do core and surface at the same time).

I'm still playing with some things, I'll post more shortly.

 

Code:

scenetree.findObject("trailer"):queueLuaCommand('for a,b in pairs(drivetrain.wheels) do drivetrain.wheels[a].brakeCoreTemperature = 10000 drivetrain.wheels[a].brakeSurfaceTemperature = 10000 end')
scenetree.findObject("scenario_player0"):queueLuaCommand('for a,b in pairs(drivetrain.wheels) do drivetrain.wheels[a].brakeCoreTemperature = 10000 drivetrain.wheels[a].brakeSurfaceTemperature = 10000 end')

scenetree.findObject("scenario_player0"):queueLuaCommand("obj:queueGameEngineLua('heavy_cargo_v2.brakingTorque = ('..obj:getWheel(1).brakingTorque..')')")

scenetree.findObject("scenario_player0"):queueLuaCommand('sounds.playSoundOnceAtNode("TurboBovSound", 1, 1); sounds.playSoundOnceAtNode("TireBurstSound", 1, 0.20)')

For now here's my scratchpad, see above for the commands I've scratched together. All of these work already.

• The first two lines are used to melt the brakes on both vehicles.
• The third line is used along with a module (I'm still learning about this but have it working) to retrieve the value of brakingTorque from one wheel. brakingTorque above (for example) 10 tells us that somehow the brakes are being applies - regular footbrake, emergency brake, whatever. Even if the AI was activating the brakes I suppose...
• The fourth line is used to play two sounds together at different volumes from an arbitrary node on the semi.
• All of the above lines are convoluted and hard to read due to the need to shuffle commands and data around between the game's multiple Lua VM's. That's what the stuff like queueLuaCommand() and queueGameEngineLua() is doing.
• onRaceTick and onRaceWaypoint will be used along with some other stuff.

The concept for how to use these things together is like so:

1. player starts scenario
2. player hitches up and proceeds through WP1/WP2
3. WP3 triggers two things: a timer (say several seconds) and a watchdog for brakingTorque
4. When we detect the brakes being used we wait about 1/4s to 1/2s and then kill the brakes (and play our sound). This should give the player time to see the brakes start to work and then fail with a noticeable lurch forward and sound.
5. If the player tries to avoid using the brakes to prolong things and our timer runs out we change our strategy. Now we kill the brakes and play the sound the moment we detect brakingTorque.

I think that this makes for a more dramatic scenario. Without going to look, it may be useful to move WP3 very slightly closer to WP2 for the most effective experience.

I'm open to suggestions about exactly how to time the failure - how to make it seem as natural and dramatic as possible. I plan to do some more thinking about that myself. I think that it would be reasonable to try to get the brakes to fail while the player is 'riding' them, I think that this is probably a typical behavior just before the sharp turn at the bottom of the first steep slope (after WP3). If they try something tricky like pulsing the brakes all the way down the hill to avoid triggering the failure that's fine... we can still switch to the backup mode where the next 'tap' will cause a failure.

 

OK, while I certainly haven't done all of the things I mentioned above... I have both written some code and done some thinking.

After some investigation I found that brakeTorque bounces around a good bit. I set the threshold for "braking vs not braking" at >500 units. Remember, brakeTorque is something like the torque between the calipers and disks, so even in a vehicle sitting immobile holding the brakes there will be a high brakeTorque! We may still need to zero the parking brake right from the start because it's not part of brakingTorque. Or just add them up. Probably just add them up, I haven't looked into it yet.

In order to try and get a slightly more useful number than "how many seconds has the player been braking" I decided to do a rough version of "how much brakeTorque has the player delivered to the brakes?". Every race tick should be 0.25s I believe, but regardless the number is passed to the onRaceTick() function like onRaceTick(0.25) so we get that as a value. If we find that brakeTorque > 500 then we multiply brakeTorque by our tick time and add that to a variable (brakingSum). This is a very crude measurement at best, but less crude than some alternatives!

After getting that working I made this calibration Lua script. I've attached it to this post. Put it in the scenarios folder alongside the relevant scenario and it should work the next time you load/reset the scenario. For approximately every 5k that is put into brakingSum it will display the value on the screen. I think that's a reasonably granular way to look at it. Generally speaking I see that braking for a single turn typically adds up to between 5 and 20 thousand units. Braking for a sharp turn at speed is typically 15k for me in this scenario. Note that the console contains some additional info printed from this Lua script.

My plan is to implement the concepts I mentioned above, but maybe using the brakingSum value rather than braking time. Really I suspect that players probably won't be able to tell the difference anyway.

 

IMO a damage goal should be added to the trailer vehicle.
--- Post updated ---
I've noticed a problem with the scenario which I believe is a bug in the game: http://beamng.com/threads/v0-6-1-dry-van-trailer-scenario-restart-issue.30647/
--- Post updated ---
I'm attaching a working scenario. As long as the zip file is not renamed this one should automatically take priority over the one included in this pack if they are installed side-by-side.

Changes to included files:

• Modified scenario JSON to add damage goal to trailer. Modified failure message for both vehicles to be more ambiguous about what the player damaged since the game might fail on either vehicle first during a crash which clearly destroyed both: "You wrecked the equipment."
• Fixed WP1's wayPointMessage not displaying to the player.
• Removed "cargo" vehicles from prefab.
• Updated vehicle configs to include brakes and have matching names to the prefab strings.
• Updated trailer config to include weights.
• Removed unused "cargo" vehicles from scenario JSON.
• Changed the scenario description to include the words "(Lua Test)" so that it's clear whether you've loaded the correct scenario for testing!

New Stuff:

• Added weights part for dry van trailer.
  
• Added Lua for scenario.

Lua / Scenario notes:

• There are tuning options at the top of the Lua. Not everything is tuneable, I probably should have done more.
• Keeps track of your braking total as discussed above. If your total braking before WP2 (eg getting hooked up) is >30k then the script penalizes you later.

• WP2 resets the total braking counter (brakingSum) to either zero or 5000 depending on how much you braked before WP2.

• WP2 triggers the ability for the brakes to fail.

• WP2 reduces your brakes' effectiveness by a factor of 4 (so you have to mash the pedal to the floor to get the vehicle to stop!)

• Once the failureEnabled flag is set to 1 (by passing through WP2) we start checking to see if the player has held the brake for >1s and the brakingSum is already >9000. If so we break the brakes and play a little noise.

• If the player never holds the brakes for that long it's OK. First of all they probably wrecked since the brakes are really weak after WP2. Secondly we have a backup of 18000 - once the total reaches that much the brakes will also fail.

• So far I haven't been able to measure the torque from applying the parking brake. For this reason we're currently just completely zeroing out the parking brake at the beginning of the scenario. The method used could eventually cause problems with other scenarios depending on how the devs optimize moving from one scenario to another within the same level. For now I think it's OK.

I think that's about it. There's probably a fair amount of tuning that could be done, possibly including the penalty (maybe reduce it into the 3-4k range instead of 5k - that's a holdover from earlier when the whole thing was using bigger numbers!). Remember that the console (press ~) includes debug output - including brake totals. This is good info for tuning.

I've actually been testing the scenario without the weights since I forgot to add them into the config file until the last minute! They certainly change the situation. I'm not sure if any values need to be tweaked now that the weights are there - the weight significantly reduces your top speed on the initial straight from WP2 to WP3, and I think it makes the trailer a lot more top heavy around the corners. Interesting stuff, plenty to play with.
--- Post updated ---
It seems that I missed something - it may be a limitation of the current scenarios system. Resetting only works correctly from the "Failed" screen. If you try to reset during normal gameplay then the brakes will be messed up (weak). EDIT: see next post for the fixed version