GoldSource error - model stuck in wall Created 4 years ago2020-08-12 23:19:22 UTC by WalterBennet

Hello !

I've been importing my model in my most recent map, but I can't seem to make it work without the in-game error "Monster monster_generic stuck in wall--level design" error showing up.

The model is of course not in the ground or anything, I tried to lift it up from a few units and even move it around but it just keep showing this error.
The only time the error didn't appear was when it was flying in the middle of a room.

So, I'm wondering if there is any solution to that problem, like for example, to disable this warning (cause the model load just fine, it's just surrounded with weird yellow spore). Any help would be appreciated !

Hope you all have a nice day !

Try using a cycler_sprite instead. Despite its name, it can also be used to render models, and it won't be solid when used that way.

It's also possible to use models with a few brush-based entities, such as func_train. On top of my head: create a point entity, change its classname to func_train, add a 'model' attribute and set it to the path of the model you want to use. If it's a model that's not normally precached, then you also need to add a monster_generic or cycler_sprite entity to your map that references the same model. That entity can be killed after the level has started, its only purpose is to force the game to load that model. A bit of a hack, but it works.

Yeah just remembered of the cycler_sprite like 2 hours ago lmao. Anyway thanks for the hack, I bet it'll be useful !

Hey, upping this thread cause I don't want to make a new one, but I encountered a new problem with cycler_sprite.

Basically, when the map load, the models are here, but if I do a quicksave and then a quickload, the models disappear and the only way to make them re-appear is to restart the map.

Any idea why this is happening ? Here's some screens for an illustration :

Before :After :Hope you all have a nice day !

Why does nobody use monster_furniture...

Why does nobody use monster_furniture...

That's... a good question! Time to update the entity guide?

I did a little bit of testing, and after loading a savegame:

• cycler_sprites are not restored correctly. That probably wasn't implemented because it's just a sprite-viewer test entity after all.
• monster_furnitures are restored correctly. They're also seen as targets by the auto-aiming system, and bleed a little when hurt by explosives.
• trigger_autos that did not remove themselves after firing are triggered again.

More test results:

• cycler_sprites do precache their model after reloading, so that is not what's causing them to disappear.
• the brush-based entity 'hack' does not suffer from the reloading problem (tested with func_wall and func_illusionary). However, this requires another entity to precache the model, and that precaching must be done before the brush-based entity is initialized, otherwise HL with hang or crash while loading the map. This depends on the order in which the entities are stored in the .bsp file.
• J.A.C.K. does not handle brush-based entities without brushes well - in some cases it crashes, in other cases it puts them at (0, 0, 0).
• monster_furnitures are dropped to the ground after spawning.
• env_sprite seems to work just as well as cycler_sprite, without the reloading problem.

So I now think that env_sprite is the best way to go. The only downside is that, because halflife.fgd marks its 'model' attribute as 'sprite' instead of 'studio', J.A.C.K. does not display the model (and Hammer just crashes when loading such map files).

One way to solve that is to add a custom entity (let's call it env_model) to the fgd, with a 'model(studio)' attribute. That would give you proper editor support. Then you'd need a custom compilation step that renames all 'env_model' entities in the .map file to 'env_sprite', before the other compile tools start processing the .map file.