For an impounded vehicle, will it be possible to pay a fee to get it back later, or is it just gone forever?
Right now it only removes vehicles from the garage like pink slip races, but I like the idea. It would make sense to be able get back impounded cars by paying the ticket price at a later time. I guess there should also be a certain amount of in time to pay the ticket until the car is gone for good, and the time limit could be tweaked as a difficulty setting.
Quick update on the impound mechanic, I found a simple way to have the suggested fee to get back an impounded car. I initially thought I'd have to create a new file structure for impounded vehicles but noticed it would be much better to be keeping the car in the player garage and simply mark it as impounded until the cost of the ticket is paid. The button to pay the outstanding ticket replaces the "Use" option in the garage menu for impounded vehicles. Beamstate, mechanical damage and the gas tank value are saved before despawning as if the player had just garaged the vehicle. It would still work great if down the line a different "police station" area is added to get back impounded vehicles, I'd just remove the button from the player garage and add it to a new UI that shows up at this new area. Overall I think it's better gameplay on top of being more realistic to have a chance to get back impounded vehicles. Here's a summary of the change to show how it works:
Here is the latest round of updates to the BeamLR WIP, this time the showcase focuses on the updated race system and part edit UI. The dynamic race system now works with multi lap, multi checkpoint races and has features present in typical scenario races like sound effects when crossing checkpoints, winning or losing and both the current and the next checkpoints are shown in different colors. Data like checkpoint list, AI waypoints and lap count is stored in race files and the system works seamlessly for drag races by using a single checkpoint and single lap. The AI can have some trouble getting through tight corners without crashing, and due to the way the AI will head to the next waypoint after crossing checkpoints if the current waypoint is too close to the checkpoint trigger the AI will slow down which can cause problems. I've experimented with a different flowgraph node which allows for the AI to take in a list of waypoints as a race path and this seems to fix that particular problem. Since I've already made the new race system using the "AI Arrive" node it would be easier if I found a way to force the AI to not slow down at waypoints but this is something I haven't found anything about even though I looked into it a bit. If anyone knows how this might be possible please let me know, I think setting the AI to "race mode" might have something to do with it but I didn't look too deep into the core AI scripts to see what makes them slow down (or not) at waypoints. The part edit UI has also been updated in multiple ways, the biggest update being a category sorting system to help navigate through lists of parts. By only looking to match universal part names like "bumper" and "radiator" the system should work on most cars and car parts. Parts missing a proper category will still be shown in the "All" category. I've been thinking for a bit about the best way to go around doing this without having to manually give a category to each individual part and this seems to be the best way to do it as far as I know. I tried looking into how the car config menu sorts parts into the categories we see in that menu, however didn't find what I was looking for after a while so I decided to try out this method which seems to work great for most cases. Other problem I've fixed with this UI was the inventory changes not immediately updating and the way the orbit camera becomes misaligned after changing parts. Also the part edit UI now has checks to ensure the player vehicle isn't damaged before edits are allowed, this is done for consistency purposes as BeamNG will always fix a vehicle when editing parts, and restoring Beamstates after part edits is not currently possible. This forces the player to repair a vehicle before editing parts and prevents free repairs by swapping car parts. Gas values are also now properly restored after part edits.
Just an idea. How about adding a unique odometer to the car you are using, so that when you sell it, the price increases or decreases based on the mileage? It would also be interesting to add a random mileage to each used car and relate it to the purchase price. Alternatively, one might determine the mileage based on the damage to the used car. It also would be nice to have a playful element to the game, such as disguising the mileage when modifying one's car. I think it would be interesting to see one where if one's car is found to be faking it when it is impounded, one is subject to a hefty fine. The probability of being found out in the game is difficult because it is a factor that determines the player's choice of whether or not to fake the mileage, but personally, I think a 30% chance of not being found out would be thrilling. Also, it might be nice if it simply ends up being impounded. imo, even if the same car has the same modifications, I believe that if each car has its own unique status (in this case, mileage), I can find inherent value in my car and become attached to it. I think this element is important in a career mode game like this, it makes the gameplay more fun, and also makes the car you have more special, with its own unique element, which is difficult to create anew. (Especially in games, as I believe this is what makes it to play with) I also think that this element makes you hardcore, as it makes you more careful in your driving. Sorry for my long reply.
That's a great idea and actually something I've had in the back of my mind for a while because while dealing with restoring mechanical damage I noticed this function: Which as you can see has integrity and odometer values to be set for particular parts. Looks like pretty much every mechanical system has an implementation. I've tested a few of them and it does seem to reduce the performance of parts, although the odometer value isn't used in every implementation of the function. For instance "electricBattery" is only affected by the integrity value which decreases total capacity, which makes sense since a battery isn't technically affected by distance like engine parts. For "combustionEngine" the odometer value is used and it seems to add friction to the engine reducing output torque. From what I can see, the linearScale function shows that the odometer is counting in meters, capped between 30,000 KM and 100,000 KM for friction and 500,000 KM for the other value. The odometer value of a vehicle is easy enough to access using electrics.values.odometer, meanwhile the integrity value of parts is obtained with getPartCondition() so they're both possible to save and restore for garaged and purchased vehicles. Faking the odometer value for police could be accomplished using a small feature I have planned which is a basic item inventory for things like emergency gas tanks, first aid kit and other "consumables". So possibly this odometer faker could be purchased and applied to a vehicle and like you said cops could have a chance of noticing and fine you for it. Overall this is something I wish to add at some point to the mod and from what I can tell adding it should be simple enough.
Back again to show off the latest additions to the BeamLR WIP, this time the update focuses on the suggested Odometer, Race Clubs & Leagues, Tuning UI and Modular Triggers. I added the suggested odometer and part integrity values to vehicle persistence. Vehicles now have a true odometer value that decreases part performance over time. Vehicles sold at the used car shop also use this system and so can race opponents. This system will likely be connected to the part edit system so that swapping key parts restores their underlying integrity and odometer values. Up to this point triggers worked in a "hardcoded" way and in order to allow this flowgraph project to easily port on different maps a modular trigger system was implemented where triggers added to a map are linked to universal categories, and all triggers of a set category will share UI and underlying systems while still being able to access trigger specific data. For instance, different car shops need different spawn points and camera transforms to show the stock. The stock itself could also be different from shop to shop. Gas stations may offer different gas prices using this system. Most importantly it makes it so porting the project to other maps is possible without having to go through and change hardcoded trigger names. While working on this system I looked into detecting various game parameters like current map which made me think about the "Unit" UI setting to add support for both Imperial and Metric units in the stats UI. Race Leagues have been implemented as a way to add progression or opponent performance classes to the race system. Player has to complete all races from a league to move to the next one. Simple but effective. This feature was added in combination with Race Clubs which are essentially different starting points, allowing for different races and opponents. This feature ties into the modular trigger system explained above, basically the race area trigger points to a data table that contains the correct race club league folders & progress file to use as well as the opponent and player starting positions. Finally I've added a WIP Tuning UI to the custom UI app. What seemed like a simple single session task ended up taking me a couple days of chasing bugs and fighting with AngularJS. Mostly my own fault for trying to figure things out myself instead of looking at existing UI app code but there's also the lack of existing documentation on what should and should not be done when building those UI apps. Long story short I wanted to add both sliders and numeric fields like the official tuning UI but the numeric fields kept causing issues I didn't manage to track down before giving up and only using sliders. This still works fine as they can be precisely stepped using the arrow keys. Just like part edits the vehicle must be fully repaired to be tuned as tuning vars change involves a reset. Gas and odometer are both restored after tuning just like part edits and repairs. Another thing I figured out the hard way is that tuning data passed to partmgmt has to be formatted differently to work than the config variables table obtained from a vehicle which contains a data table detailing data such as display min/max/step for each variable. It's a more simple key=val format using the variable name as key and updated values as val.
Small update, a bit boring so no screenshots or video. Today I found some time to replace my existing AI Waypoint node based race system with a custom lua node that uses the ai.driveUsingPath function. This fixes the previously showcased issue with AI vehicles slowing down for waypoints during multi checkpoint races. It works by telling the AI to enter "race" mode which can only be set by giving the AI a looping waypoint path with more than one lap. I'd already mentioned this as a potential fix but at the time I was too focused on building up other aspects of the mod to try adding it to the race system. As far as I tested it this node works great with multi lap multi checkpoint, multi checkpoint single lap and drag races. To get the AI into "race" mode even with a single lap race, a higher lap count is given to the AI while the race system still knows the correct amount of laps and checkpoints remaining and will stop the AI when the race is completed. I've also had time to test out the modular trigger implementations for race areas and car shops by adding one new area of each type to the Utah map, using a simple utility function I've wrote to dump the current vehicle & camera's rotation and position to a file which makes the process of adding slots for car shop stock and race opponent spawning much easier. The new race area focuses on dirt road races while the added car shop will be selling brand new more expensive vehicles. Among other things I also added a simple search function to the parts list in the custom UI, walk mode detection for the UI (to disallow part edits on the "unicycle") and two new options to the Options menu: a field to rename vehicles and a button for manual career reset. Also fixed a bunch of smaller bugs and issues I found, most notably a problem that happened with tuning values causing the vehicle to take damage as it was pulled out of the garage is now being handled with a system that detects such "unfair" damage to vehicles. Basically if a vehicle is placed in the garage with 0 damage, the scenario will expect the vehicle to still be at 0 damage when pulled out. In the event that damage is taken on a pristine vehicle during the process it will be repaired for free. This issue seems to happen during the beamstate loading process so sadly this workaround is the only fix I can think of. Perhaps updates to the core beamstate system will eventually fix the real cause of this problem and the workaround won't be necessary anymore.
Just uploaded a quick showoff video I made after finding something I thought was interesting. The avoidance parameter for AI vehicles seems to be affected by the "race" mode value mentioned in the previous post. Not only does it prevent the AI from slowing down at waypoints but after testing it out I also noticed the AI was much more competitive and seems to swerve rather than brake to avoid other vehicles. Paired with the new "simplified" traffic added in BeamNG version 0.26 allowing for double the amount of traffic while keeping performance decent, this more competitive AI still has some quirks that can make for some interesting race moments! It is however much better than the previous AI which is shown as comparison at the start of the video. Overall I'm quite satisfied with the current dynamic race system and AI behavior despite some weirdness remaining, at least I think it's as good as it can get without reworking the actual AI behavior code. I've also added the last remaining implementation of modular triggers, being the mission giver system, so that I could now begin working on East Coast USA which is the next map I want to support. However I think I'll probably wait until I've released a first WIP version of the mod before working on other maps.
Here is a quick screencap of what I've been working on, basically just a simple UI to repaint vehicles taking code directly from the config screen UI to show color pickers with all the other sliders for metallic & clearcoat settings. I've already tied this system up to the garage system by updating the old paint format to include all 3 palettes that can be set on a vehicle, when the apply button of this UI is pressed the paint is applied to the vehicle and saved to the garage file for that car. It's pretty simple and seems to be working well! The rest of this post concerns BeamNG as a whole, it's about some new feature I believe I've found while working on the paint system. While working on bugs related to vehicle paint I managed to find something quite interesting. I believe this is new to the 0.26 version of BeamNG but someone correct me if I'm wrong. Put simply: we now have the ability to paint individual body panels. Before I explain what led me to find this here is how you can do it. Spawn a new vehicle. I'm using the etk800 because that's the one I used in testing so I remember all the correct body panel names but this worked with all vehicles I tested. Then using the LUA console send this command to the vehicle : partCondition.initConditions(nil, 10000, 1, 1, 1) The values of 1 being sent are fallback integrity values while the second parameter is the odometer value in meters. The "nil" is supposed to be a list of detailed part integrities but it's not needed in this case. From what I can tell, this line will force the vehicle to use a paint system that the new partIntegrity script uses to show worn out versions of paints. From that point forward you can repaint individual panels for that vehicle with: partCondition.setPartMeshColor("etk800_hood", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) The hard part is finding the correct body panel names to send as the first parameter but once you find the correct names for your vehicle it should work. So basically you need to be replace the "etk800_hood" string with whatever panel you want to paint, and all the number values after that represent R,G,B,A values for the three color palettes the vehicle is using. I haven't tested if the palettes are working properly but the main color does change according to the first 4 number values. It appears to want values from 1 to 255 for color channels, anything beyond that range seems to fall back to preset colors. The paint will stick through resets. Only a hard (CTRL+R) reset will restore the vehicle to the previous paint system. You also can't edit the paint for that vehicle using config menu or world editor until hard reset. I found this feature after figuring out that the part integrity system was causing me issues while testing out the paint edit UI I made. I thought the issue was related to vehicle configs until I commented out the line of custom lua code I use to set the odometer values on vehicles. As it turns out, after using the initConditions line the vehicle paint is no longer editable using the configuration UI or the world edit menus. It seems that from that point forward the vehicle paint is completely under the control of partIntegrity. Unfortunately since 0.26 initConditions is the only way to set the odometer value for a vehicle so this means that vehicles must be repainted using this method if they're using custom odometer values. It's not a big problem for me since this is a decent workaround that comes with a surprising new feature. However it is a bit annoying when systems that take control of important behaviors are impossible to avoid, in this case the partIntegrity system having no way to just set odometer values that don't influence the look and performance of a car. Still not sure if this is a new feature but I'd personally never seen it in action before and it kinda blew my mind so I wanted to share this. I searched a bit about previous ways to paint individual panels and all the answers I found seem to indicate that it wasn't previously possible.
Idea : Get parts as rewards for racing. The system works that if players win a race and receive a reward, the parts they have already purchased will be added to their purchases. It would be fun to have parts that can only be received as rewards. Some other ideas... 1.Vehicle inspection and license plate (inspired by My Summer Car lol) 2.Official legal races held at racetracks and other (these races may require vehicle inspections and license plates, and also have many regulations and restrictions on modified vehicles.) 3.Used cars are serviced, restored and sold (this may not be a gameplay element, but simply a means of making money. BTW, this idea came to me because I remembered that there used to be a WIP mod on a SLRR-related forum that specialized in restoring and selling. I don't think that mod was ever released after all.) 4.1vs1 race events that randomly appear on highways, mountain passes, and other roads (Ideas from Tokyo Xtreme Racer: Rivals, Wanderer) I will post more details on these ideas when I have a better idea of what I am talking about. Anyway, keep it up!
Good idea, I've been meaning to add to the race reward system in preparation for the reputation points as SLRR had those rep only races. Randomizing rewards & opponents is also needed to have the final endless stage of race leagues feel less repetitive so I'm probably gonna do all of this in one go by revamping the way race files are parsed. I'm not sure I'm gonna be adding the rest of those ideas myself since I want to focus on the core aspects, but I know they're all possible to implement so my hope is that other modders will create their own more complex branches. That being said I do want to have the endgame races eventually take place at actual race tracks so that's one I'm likely to add at some point.
By improving the race system as mentioned in my previous post I managed to add the suggested part rewards as well as rep rewards. A bunch of parameters can now be randomized including all the reward values but also opponent AI model and config, opponent AI risk and the amount of laps in a race. Although making the races in starter leagues too random could make for unfair progression the randomness is crucial for the endless stage of race clubs otherwise they become repetitive fast. Also some race paths don't work well with multiple laps so it's a bad idea to have random laps for paths that aren't looping unless you want the race to involve a 180 degree turn to drive back to the first checkpoint. As you can see below the randomness works as expected to generate different race conditions using the same file. I haven't really shown the inner workings of the race file system yet knowing it would likely change but now that I feel it's getting quite stable and complete here is a sample of the more important parameters relating to the latest update with some details about each one. The opponent model and config randomness for instance will share a random roll index so it's important to place the configs in the same order as models otherwise the game will attempt to apply a wrong config for the chosen model. During some testing on the Nurburgring map to make sure flowgraph missions work properly on modded maps (except for some minor issues they do) I got to play around with some nodes I had not touched on yet, one of them being the node use to set the time for the timer app on the upper right corner of the screen in Scenario UI. I added it to show time of day with a 24h format. Works just like a regular clock except that it shows tenths of a second due to the amount of digits. The seconds flip back to 0 when reaching 60 as expected from a clock it's just the extra tenth of a second digit that's usually not there since that part of the UI is supposed to show milliseconds during races. Speaking of Nurburgring, the small flowgraph mission I built as a test is another idea I had to introduce some basic progression to the map with time attack challenges on the Nord. Basically by setting a good time with the current vehicle you move on to the next vehicle. Each vehicle has time targets listed as "medals" inspired by trackmania so bronze,silver,gold and "author". Medal times to beat are listed in millisecond precision values with the vehicle model and config to use. Since it contains a very simple persistent progression file system that's similar to my main project I will likely be releasing this small test project this week (hopefully) as a way to see if players experience issues. From what I can tell the way a zipped mod works when using custom files is that they will initially be loaded from the zip and any edits (progress) made will be stored directly in the userfolder so given userfolder content seems to take priority over zipped mod content in the internal filestructure it should all work fine.
I've just uploaded the previously mentioned test scenario I built for the Nurburgring map to my github. Link below for those interested! Keep in mind that the default configs may not be the best, I tuned them for my gamepad so I have no idea how they drive with a wheel. I encourage you to replace them with your own configs. Currently the three stages are Vivace, Scintilla then Bolide. The medal times are basically just there as suggestion and some may be impossible to beat, so once again feel free to change them to more reasonable values if you plan on playing this scenario seriously, potentially using times posted on the thread for that map or by taking times from youtuber runs. https://github.com/r3eckon/BNG-NordschleifeRaceWeek Note: I'm mainly using this as a way to dip my toes in the mod release process so that I can see what's missing, if anything, and know what problems to expect for my main project. Feedback is appreciated, especially if things are not working properly. About BeamLR, I'm likely to only be working on two remaining features before testing and then releasing the initial version: Random challenges and user settings. My ideas for challenges: Speed trap, must be going a certain speed while hitting a checkpoint. Jumps, simply hitting the trigger to complete the challenge. Trying to avoid damage to break even with the reward. Rock crawl , traversing difficult paths. Same as the jump challenge must be avoiding damage otherwise repair costs eats the reward. Police "Trolling", need to keep a chase going for a certain amount of time or until you hit a certain pursuit level. Drift, need to score some drift points in a set area. Not sure about this but I noticed a "drift information" flowgraph node so this could be interesting. I'm probably not gonna add all of them at first and just lay the foundation for that system. More challenges can be added later. As always suggestions are welcome!
This is a new showoff video for some features I discussed in the previous posts as well as other additions I've made since the last video. It includes stuff I've mentioned previously but had not yet shown in video form. Daredevil challenges have been added as a new way to make money in BeamLR. They are risky challenges where the player must wager some amount of money like dynamic races and to win the wager the challenge must be completed. Only two types of challenges are added so far: Jump and Speed Trap. Jump challenges involve risky jumps where to profit the player must avoid taking damage. Speed Trap challenges involve driving through a checkpoint while going above a certain speed. Speed check done using airspeed. Risk of speed trap challenge comes from traffic and police, also just crashing a vehicle that isn't built to go as fast as the challenge demands. Dynamic races have been updated to allow different rewards as well as random parameters. Most parameters can be randomized including Lap Count, Rewards, AI Model, AI Config and AI Risk. This makes it so all the end game races offered by areas are less repetitive. Randomizing the AI risk is a great way to make the AI feel different between runs. I've also tested the modular trigger implementation for race areas by adding a new "offroad" themed race area to Utah. After noticing this feature as a suggestion in MuYe's latest video, I decided to quickly add some preview images to the part edit and part shop UIs. This is a simple addition that makes the UI feel more user friendly. The system will automatically look for part names in a folder storing the preview images and if no image is found will default back to a "no image" preview. The options menu has also been populated with various settings including vehicle renaming, career reset and traffic density. Traffic density can be set both for civilian and police traffic. This option is a must for players using lower end hardware as traffic can be very CPU intensive. Vehicle renaming is a setting which will be immediately reflected in game but traffic density is only applied on scenario start or whenever a race with disabled traffic is ended which reloads the traffic system. As stated in the last post from this point forward I'm likely to start focusing on testing the various features in depth instead of adding new content to make sure they're stable enough for initial release. Right now I've only been fixing bigger bugs and whatever problem came up while adding new features so there's likely to be a ton of smaller bugs remaining. Not giving an ETA yet but I'm very close to the point where I feel comfortable releasing a first version.
