[SOURCE] Prevent Your Maps from Crashing and/or Fix Them — “Bad Inline Model” Errors

[Mozartkugeln]

I'm sure you've experienced these errors at one point or another. They're incredibly annoying and make your game crash instantly. They cause entire servers to empty out if an affected map comes on, and they're hell to troubleshoot.

How can I prevent my map from being affected?

The cause of bad inline model errors is the presence of static content (decals) on dynamic brush entities (doors, moving platforms, breakable glass panes, rotating parts and so on). This is what the number in the errors represents — the index of the inline (brush) model causing problems.

All you have to do is be careful where you stick your decals: make sure they aren't placed over any brush you've tied to an entity, either partially or in their entirety. This, for example, is bad:

Even though the button doesn't move when pressed, the lambda decal on it still causes an error. In a perfect world, the compile tools would report this to you, or even fix it for you, but you'll just have to keep an eye out yourself.

In summation, tread carefully when decorating your map, and keep decals away from moving parts! This includes, but is not limited to, the following entities:

• func_breakable
  
• func_breakable_surf
  
• func_brush
  
• func_button
  
• func_clip_vphysics
  
• func_conveyor
  
• func_door
  
• func_door_rotating
  
• func_extinguishercharger
  
• func_guntarget
  
• func_healthcharger
  
• func_illusionary
  
• func_ladder
  
• func_lod
  
• func_lookdoor
  
• func_monitor
  
• func_movelinear
  
• func_physbox
  
• func_physbox_multiplayer
  
• func_platrot
  
• func_recharge
  
• func_reflective_glass
  
• func_rot_button
  
• func_rotating
  
• func_tank
  
• func_tankairboatgun
  
• func_tankapcrocket
  
• func_tanklaser
  
• func_tankmortar
  
• func_tankphyscannister
  
• func_tankpulselaser
  
• func_tankrocket
  
• func_tanktrain
  
• func_trackautochange
  
• func_trackchange
  
• func_tracktrain
  
• func_traincontrols
  
• func_wall
  
• func_wall_toggle
  
• momentary_rot_button
  

Need a quick way to check your map or even fix already existing maps?

Look no further than the Sassilization Inline Patcher.

The Sassilization Inline Patcher is a utility application which fixes “bad inline model number #, worldmodel not yet setup” errors in Source engine BSP files. These errors are very common and cause many people to crash on certain maps, regardless of game or gamemode. Valve recently made an attempt to fix them, but the problem remains.

Theoretically, the patcher supports virtually any Source game and BSP version. It was created in Java by Mozartkugeln and Sonic5039.

If you're unsure whether you've misplaced any decals in your map, a quick way to check is to compile it and run the BSP through this application. The thorough logging system will inform you what the problematic decals are (their texture paths) and where they're located (underlying brush model, class and targetname).

Likewise, if you're a server owner and would like to spare your players the discomfort of crashing to desktop, run any map you get complaints about through the patcher, and then upload the fixed version to your servers.

Inline Patcher can be downloaded here or, if you want the test builds, from my Dropbox. Provided as an attachment is a ZIP of the latest release version as of this posting (0.9.:

inlinepatcher_0.9.8.zip

Inline Patcher requires Java 7 or higher. For more information on how to use the application and how to get the most out of it, check the Usage section or this Facepunch thread.

Thanks for reading.

Any comments, requests or criticism are welcome.

Edited February 6, 2013 by Mozartkugeln

[⌐■_■]

tested it and it works without problems for me would be cool to implement even more solutions to common compile issues, but then again i'm not a programmer so i have no idea how that would work.

Edited January 20, 2013 by killertomato

[Mozartkugeln]

Thanks for the feedback!

would be cool to implement even more solutions to common compile issues, but then again i'm not a programmer so i have no idea how that would work.

Could you list some of those issues? I'll see what I can do.

[⌐■_■]

Sure

• I was thinking about a lightmap check, where as all faces are checked to see if they have a legit lightmap number assigned since I've had my lightmaps somehow automatically change after a compile (even into uneven numbers) which has caused me to give up on some of my maps.
  

• Something that would automatically destroy incorrect displacement faces or marks them with a recognizable texture (i.e. if a world brush has one or more displacement faces).
  

• A feature that automatically deletes invalid microbrushes and devides surfaces too large to have any valid lightmap values into chucks that can be lit properly.
  

I know that for most compile related problems there is a workaround, but it would be nice if there'd be some application to ''clean your map up'' before your last compile or just as something as a last resort for newer mappers with compile problems.

Again, I'm no programmer so I have no idea if these features would be easily realised or simply impossible. One thing that I do know tho, is that the source engine is quite old, and if you're aspiring to be hired within the games industry it might be a better idea to invest your energy into a newer engine.

Anyway, good luck! Personally I'm happy to see you putting all these effort into something I might use myself so I'll be following this

Edited January 21, 2013 by killertomato

[Mozartkugeln]

Thanks for the kind words!

The first two are definitely possible, and there's already something for #3 (kind of): VertAlert.

I'm busy with coursework at the moment, and my community is soon re-releasing its flagship gamemode that 60k+ people have been waiting on for several years, so I have very little time for side projects. The first one would be fairly simple to implement, though, so I'll definitely keep that one in mind.

Edited January 21, 2013 by Mozartkugeln

[⌐■_■]

You're welcome. Thanks for putting in all this effort! Any info on the flagship game mode you were talking about?

[Mozartkugeln]

It's called Sassilization, and it's a real-time strategy gamemode for Garry's Mod that was hugely popular some years ago. One of the engine updates broke it, however, and it's been in (re)development ever since. We're scheduled to release within a month or so.

If you're interested, you can follow the blog or the Steam group here.

I'll have some free time in the coming days, so I'll get to that lightmap thing you mentioned.

Edited January 23, 2013 by Mozartkugeln

[Mozartkugeln]

I finally found some time to work on the lightmap tool. The GitHub repo can be found here.

So far, I plan on including a feature to fix lightmap scales that aren't a power of two, as well as a feature to clamp lightmap scales to min and max values specified by the user. I might also make it possible to force all lightmaps that are above and below the default scale of 16 to a certain value, respectively.

Do you have any other suggestions?

[⌐■_■]

Hah, that's awesome As far as the lightmaps are concerned, I think the options you plan to implement are quite complete already. I tried it though and I found that there's no executable to select at step 4. Am I overlooking something?

Thanks again!

Also, how come I am the only one posting here? I'm sure I'm not the only one who could possibly benefit from these improvements?

Edited February 3, 2013 by killertomato

[Mozartkugeln]

Oh haha, I haven't actually started working on the code yet; only got around to setting up the website, writing the setup file for cx_Freeze and the readme for the application. I'll most likely start coding tomorrow.

Anyway, thanks for the feedback! If you think of any other features the lightmap app could use, be sure to let me know!

[⌐■_■]

Will definitely let you know when anything new comes to mind!

[Mozartkugeln]

Well, after looking into the issue itself further, I realized it's not very likely for lightmap scales to just change like that. Could you maybe tell me how/when it affected your maps?

Edited February 4, 2013 by Mozartkugeln

[⌐■_■]

Sure

I've had this issue a few times now (about 4 times I think). It happens mostly when my maps reach the last fase of completion. After I compile the map, it looks like there's a leak, but there really isn't. I've done extensive searching after trying to find the non-existent pointfile. Then, when I begin checking my lightmap scales, some faces have values like 9 (mostly 9, though I've had faces with a lightmap scale of 11 assigned to them).

After this, no matter what I change in lightmap scale settings, my map will not compile like it should: the map still looks like there's a leak (although it differs a little bit in how it looks: lighting is fine, there's just alot of the map that doesn't render, or only renders when you look at the faces in a certain angle).

I must honestly say that I, with my limited knowledge, can't be sure what the source of this problem is. But what I see is a badly rendered level, no apparent compile log errors and weird lightmap scale values being assigned to random brushfaces.

Edited February 5, 2013 by killertomato

[Mozartkugeln]

Sounds reasonable enough. Do you by any chance still have a VMF of one of these maps laying around?

[⌐■_■]

PM