BeamNG normally loads 'terrain' and 'vehicle' mods on startup, but mods which only contain scenarios show up as 'unknown' in the 'Mod Manager' and do not automatically load. Users can work around this by clicking DEACTIVATE and then ACTIVATE in the Mod Manager every time they launch the game. That's a big pain though, and it does not persist between gaming sessions. Bundling a level in with your scenario pack would work (turning your 'unknown' mod into a 'terrain' mod). Bundling a level won't make any sense for many scenarios though, so that doesn't really help. If you bundle any pre-existing level you risk interfering with that level (this is bad!). The smart money is on tricking the game into reclassifying your mod from 'unknown' to 'terrain' without bundling anyone else's level and without throwing a visible dummy level into the Freeroam selection area. Here's how. Tools needed: Just ensure that you have file name extensions turned on in Windows. Instructions: Prepare your scenario(s) for zipping in the normal fashion. This means you should have a folder structure which includes a top level folder of 'levels' and one or more folders inside of that one. Create a new folder inside the 'levels' folder, call it 'fake_level' Create a new text file inside the 'fake_level' folder, call it '.mis.' Windows may prompt you about changing the filename, say 'Yes'. Note that the resulting file is now actually named '.mis' without the trailing period. This is what we need. Create your scenario ZIP as normal (but include our new folder and file) BeamNG will detect any levels folder which contains a .mis file as a level, but it will not create an entry in the Freeroam selection screen for the level if there is nothing in front of the .mis in the filename. This will cause your mod to be classified as 'terrain' and autoload on game launch like like terrain and vehicles do.
Coincidentally I just reported the bug that causes this. You don't actually need anything other than Windows' zip tool, by creating the .mis file before packing the mod - this is possible by naming the file ".mis.", the last period will be removed when you hit enter.
Ahh, thanks Scepheo. Good thinking on both counts. I will update the instructions in the OP accordingly. Tools needed: ZIP utility such as 7-zip, WinRAR, WinZIP, etc. (The one included with Windows is not sufficient.) Instructions: Prepare your scenario(s) for zipping in the normal fashion. This means you should have a folder structure which includes a top level folder of 'levels' and one or more folders inside of that one. Create a new folder inside the 'levels' folder, call it 'fake_level' Create a new text file inside the 'fake_level' folder, call it 'rename.txt' Create your scenario ZIP as normal (but include our new folder and file) Open the ZIP with your ZIP utility and browse to the 'rename.txt' file Right-click on 'rename.txt' and rename it to '.mis' (this must be renamed to '.mis' specifically) Save the changes to the ZIP if necessary. (the rename is already permanent in 7-Zip for example, so no save is necessary in that case)
Or, you could force it to classify scenarios as terrain my modifying line 108 of BeamNG.drive\lua\t3d\extensions\modmanager.lua so it reads as so Code: elseif v2:find(".mis") or v2:find(".prefab") then
The .mis file can be anywhere inside your levels folder, so putting it next to your scenario .prefab or .json works fine, no need for a fake level folder. You do realize that asking everyone that downloads the mod to alter their game files isn't really an option, right? This is especially true as a workaround exists, which does turn scenario mods into drag-and-drop installs. This is bug that I'm sure will be fixed in a future update, in the meantime, it's a tiny bit more work for mod creators.
Again, good work. I think I'll leave the OP instructions as is for the moment. My thought is that the extra folder should help keep things crystal clear for anyone implementing this. (reinforcing that they are in fact doing something to trick the game)
I do realise this now. I was just trying to make a solution that didn't require modifying the scenario mods.
i clearly f-ed this up XD not sure what i did wrong seing as i folowed this tutorial perfectly ;( so this is what i have, i have the jump_derby.zip in that there ís a levels folder witch contains 2 folders, the one with the scenario and all that stuff and the fake_level one with the one file named just .msi. this is what i have why isnt it working ;c
The file should be called .mis, not .msi. Or wait until the update for Jump Derby is approved and you don't have to fix it yourself anymore.
doing what both you guyes said worked, doing just one didnt fsr, may also have been because i didnt clear the cach lol
BeamNG currently has a tendency to not update the mod entries in db.json when changes are made to a mod. That's why even after you fixed the mistake Scepheo pointed out, you didn't get any improvement. Renaming the zip file to a new name creates a new entry in db.json. (You can also just delete db.json, but it clears out your ACTIVATE/DEACTIVATE status on all mods.)
mumboking, thanks for bringing this up. I didn't realize that so much of this stuff was done in Lua, that's pretty neat. See below for what I think is a more comprehensive / better solution than what you posted. Unlike the game's original code, this code will identify mods in a priority order: if it contains '.mis' it's definitely terrain (even if it also contains .jbeam and .prefab), if it contains '.jbeam' but not a '.mis' it's a vehicle, and if it contains a '.prefab' but not the other two then it's definitely a scenario. Frankly I find my code lacking, but it should be functional and foolproof. Starting at line 94: Code: local terrain = 0 local vehicle = 0 local scenario = 0 for k2, v2 in pairs(filesInZIP) do --local zipHash = 'wip' -- zip:getFileEntryHashByIdx(k2) --local zipPath = v2:gsub("\\","/") --d.files[zipPath] = zipHash --log('D', 'modmanager.updateZIPEntry', " " .. zipPath .. ' = ' .. tostring(zipHash)) if v2:find(".mis") then if not v2:find('levels/') then d.mountPoint = 'levels/' d.oldFolders = true end terrain = 1 elseif v2:find(".jbeam") then if not v2:find('vehicles/') then d.mountPoint = 'vehicles/' d.oldFolders = true end vehicle = 1 elseif v2:find(".prefab")then scenario = 1 end end if terrain == 1 then d.modType = 'terrain' d.compatible = true elseif vehicle == 1 then d.modType = 'vehicle' d.compatible = true elseif scenario == 1 then d.modType = 'scenario' d.compatible = true end
If we're going to do that... This will recognise when there are multiple mod types. I'm sure the devs will come up with something better though.
Yeah, it certainly occurred to me that it was very limiting to just slap those 3 labels on and be done. I'm not a big fan of either result - only 3 labels is containing/misleading... but having a pile of labels reduces their usefulness. For the time being I think it's safe to assume that most authors will only produce one of 4 things: terrain, vehicle(s), scenario, and terrain+scenario(s). It's fairly intuitive that terrain+scenarios simply falls under terrain, assuming that those scenarios pertain to the level they are packaged with. That was my reasoning for limiting the labels to only those 3. I agree in hoping that the devs will come up with a better idea. Possibly such as using tags, little icons, etc.