It would be useful in scenarios to be able to change content (levels, vehicles, etc) on a scenario-by-scenario basis. In my opinion the most straightforward way to do that is to mount a root level directory from inside the scenarios directory. For example, say we have a level named example-level and it contains a scenario called scenario-01. That level would mount in content/levels/example-level/ as normal. Normally that level would include a /scenarios/ directory which would contain files such as scenario-01.json and potentially scenario-01.html as well as typically a preview image such as scenario-01.jpg (but of course that and any prefabs are defined in the json file). What I'm proposing is adding a directory at content/levels/example-level/scenarios/scenario-01/ which will mount with the highest priority and follow the same mounting rules used for mounting from /mods/whatever.zip (using the same rules is not really necessary, but it should make things very easy on mod authors with the relaxed folder structure). This should allow for several easy-to-implement things: Removing static objects which are in the way somehow or do not fit the scenario. This could mean clearing a path through the trees (content/levels/example-level/scenarios/scenario-01/content/levels/example-level/example-level.forest). A similar scenario is a prop which would be different in the scenario. Maybe in your scenario a house has burned down. Simple, replace the .mis file with one which swaps out that house with a burned down house. Replacing static objects (TSStatic & etc) with vehicle objects (BeamNGVehicle). For example, replacing a section of guardrail which was either a TSStatic or mesh-road-generated or whatever with a vehicle object guardrail so that it can be crashed through/over. Adding .pc files for prefabs to load from. These configurations do not need to dirty up the normal sub-vehicle selector menu, so they may as well load with scenarios. This is just a nicety for mod-creators; of course we can already make a super-ugly prefab to load specific parts when spawning a vehicle. I am aware that as far as #3 goes, the long-term goal is to implement a sleep system where objects which are not being interacted with do not require time on the physics system, but until (or maybe beyond) then I think that this would be a good workaround as far as scenarios are concerned.
Every use-case described in your post is already possible. Any level objects or data needed for the scenario can simply be included in the mod .zip and referenced as normal. Any deletions of or changes to objects that exist in the level normally can be achieved by adding a levelObjects attribute to the scenario .json. What I'm trying to say is closely related to what you ended your post on: (I assume that) eventually most of these systems will be replaced by far superior systems, but for now, a working solution exists. EDIT: Forgot to explain: your PC file issue can be solved by simply giving your custom PC file a different extension. That way the save/load config menu won't detect it, but it's still perfectly possible to use it for a scenario.
After looking at how levelObjects is used on JRI and Hirochi Raceway, I'm not sure that I understand how levelObjects facilitates deletions. Do we simply overwrite objects with blank ones? I don't see how that would work for deleting the average static object - many are spawned without unique names. Let's take a "bump" in Gridmap for example... if I wanted the bump at position = "40.0064 64.3397 -0.270741" to go away, how would I do that? Another thing my proposal is intended to help deal with is "instancing" of stuff borrowed from other mod authors. For example, let's say that I got permission from B25Mitch to include that explosive propane tank in a scenario, and then I went and got permission from Darren9 to use the DW Rock Bouncer. Copying those resources into my scenario would be ideal since the user wouldn't need to be separately install both of them for my scenario to function. I can do that now, but then there is the potential collision of files from the actual DW Rock Bouncer (for example) and the one included in my scenario. I could painstakingly rename everything, but that isn't really great either. I forgot to write about any of that when writing the OP.
Deletions can be achieved slightly hackishly, by setting hidden to true, and its position somewhere far off. You can reference non-named objects with their id. So to get rid of that bump in Gridmap, something like this should work: Code: "levelObjects": { 4370 : { "hidden": true, "position": "0 0 -1000" }, } As far as using other people's mods goes: I'm not a fan of including their stuff in your own mods. Just tell people to download those mods too, that way A) those mod's authors get the traffic they deserve and B) you don't have to spend time and effort keeping your included version up to date.
For some reason I assumed that I would not be able to reference non-named objects by ID since the ID isn't saved in the .mis file. I suppose that the ID is generated consistently enough during load that I can do that though? (eg just use the ID as it appears in the editor, right?) I'll give it a try. Regarding the "other people's mods" thing: sometimes it's just best that way. Various hacky things may be done with these mods for a scenario (I don't know what. Maybe attaching a strap to an axle and a fixed-position node so that the axle gets ripped out as the vehicle drives away.) In those cases I figure it's good and easy to have the custom, hacky resources loaded only for the scenario. As long as the mod and scenario still operate with the current game, there's little need to bother keeping the pack-in up to date. (especially if the improvements are not relevant for the scenario or negatively impact the scenario) As far as giving credit / downloads -> of course it's polite to link to the author's page for the mod in the listing for the scenario/level/whatever. That might often be a condition that goes along with permission from the author. In the case of my suggestion: since the mod would only be present in that particular scenario I think it's fair to say that anyone who liked it and wanted to play with it more would go get the mod from the original author. That's part of the appeal here IMO! If I pack in DW Rock Bouncer to a level's .zip with the current system it will (unfortunately) appear in the normal vehicle selector and fail to get updated as Darren9 releases improvements... both things you wish to avoid by not including pack-ins. I think my suggestion addresses that particular problem pretty well! Anyway I think you see my point (as I see yours). My suggestion is out, as well as a reasonable rationale. If it's trivially easy to implement I don't see a major downside. Since the devs are loading lots of different locations into their virtual filesystem anyway, maybe one more location loaded on a conditional basis is easy enough. If not, the devs will wisely spend their time on more important things.
