Model displays correctly in my map editor, but not in-game.

[Enjay]

That's what I was trying and failing to do last night. Any chance you could set up this tree model to work using this kind of setup so that I can learn from it?

[Enjay]

OK, I got it!

The main problem was that the model is scaled to be ENORMOUS! It is so big that when I was spawning it, I couldn't see it. Eventually I made a giant custom map to house it. Voila!



Attached is a pk3 with the model, skins, definitions and test map.

I also made a second version with a scale value of 1.0 instead of 25 and it is also in the map just because it helped me figure stuff out. (Same model, just scaled to a sane size in MODELDEF.)

tree_testNJ.pk3

(123.61 KiB) Downloaded 74 times

[edit]BTW, you might notice that I changed the mass in your DECORATE to "Mass 0x7FFFFFFF". That is the biggest number supported. A tree with that mass will definitely not move. I also noticed that your tree is set to be shootable. As a result, it can be killed if you fire enough rockets at it or use the MDK cheat on it etc. I didn't change this but if you don't want your trees to just vanish if they have been hit by enough damage, set them to be invulnerable or something (assuming that you set them to be shootable so that they would block shots).[/edit]

[RazurBlazur]

Yeah the scale was probably screwed up because of previous attempts to scale the model in Blender, and then not changing the Modeldef to account for it when I was changing its base scale. Great to have an example for that method on hand to work off of, I already got a bridge model set up with the multi-model method but this'll save me some time ahead for sure, thanks!

[Enjay]

So the thing that made me think what I was doing wasn't working (the huge scale) wasn't even intended. I just assumed you were going for a giant tree.

I'd summoned the actor many times and I just couldn't see anything, but I knew that the actor was there because I could bump into it (the actor itself has a reasonably normal size and so was fitting completely inside the model). So I concluded that what I was doing wasn't working - despite the fact that I wasn't getting any error messages. As it turned out, I just couldn't see the model because it was so big that it was much bigger than the room where I was summoning it. So I was completely inside the model and so were the alls of the room that I was standing in. It just so happened that one time I went into an area that was a bit bigger and I could see a little bit of the model. That was the clue that I needed.

[WARCHILD_89]

NOTE:

The model does not need to be scaled in modeldef if
- you scale the model properly in Blender. It should by no means get bigger than the grid frame in Blender. It is better to have the model small and scale it up in Modeldef or, even better, in Doombuilder directly.

you scale the model down via command line when exporting in noesis model viewer. Noesis also notifies you that the model is too big for md3.

models can be scaled directly in doombuilder if the maps are in UDMF format. If the tree inherits the "invisible bridge" actor in Gzdoom, you can also set its radius and Height directly in Doombuilder. This way you don´t need to set the scale in decorate.
Makes most sense when you have hundreds of models and you want to save time.

[Enjay]

NOTE:
If the tree inherits the "invisible bridge" actor in Gzdoom, you can also set its radius and Height directly in Doombuilder.

Why have I never thought about that?
Most of the time I wouldn't need it, but on the occasions where I would it would be incredibly useful. Thanks for the tip.

[WARCHILD_89]

NOTE:
If the tree inherits the "invisible bridge" actor in Gzdoom, you can also set its radius and Height directly in Doombuilder.

Why have I never thought about that?
Most of the time I wouldn't need it, but on the occasions where I would it would be incredibly useful. Thanks for the tip.

No Problem. But keep in mind that you can shoot through bridges, therefore hitscans won´t be blocked by the models. Only Missiles/Projectiles will be blocked. To me it is not an issue because my mod is intended to avoid hitscans anyway and replace them with 3d modeled bullet tracers combined with Damage types.

[Enjay]

Would giving the inherited actor +SHOOTABLE +INVULNERABLE work around that issue?

[WARCHILD_89]

Would giving the inherited actor +SHOOTABLE +INVULNERABLE work around that issue?

This is a very good question you ask. I guess I finally found a solution for this:

Actor invisiblebridge_solid : invisiblebridge replaces invisiblebridge // This actor is used in areas of the 3d model the bounding box of the actor cannot reach.
{
+solid //you cannot shoot through it in any way
+shootable // Hitscan would go through otherwise
+invulnerable //cannot be killed
+NOBLOOD //does not bleed
+nogravity //not subject to gravity
+dontthrust //cannot be thrust in any way
+NEVERTARGET //not targeted by monsters
+CANTSEEK //not targeted by seeker missiles
+NOTAUTOAIMED //autoaim wont work and actor does not get targeted by BFG blasts
}


ACTOR Custombridge_solid : Custombridge replaces Custombridge //because the built-in bridge lets hitscans pass through, I have to tweak and override its behavior.
{
+solid
+shootable
+invulnerable
+NOBLOOD
+nogravity
+dontthrust
+NEVERTARGET
+CANTSEEK
+NOTAUTOAIMED
}

ACTOR CSS_dummy : Custombridge_solid // All actors inherit this to have same basic decorate code.
{
//$Category CSS
Radius 16
Height 20
States
{
Spawn:
PLAY K -1
Stop
}
}

[Enjay]

Yup, that looks like it would do a good job, and includes some of the flags that I always forget about in this kind of situation. Useful stuff. Thanks.

[WARCHILD_89]

I encountered that after a while the bridges will be broken for unknown reason, the actors are not found in doombuilder and radius and height can´t be set in doombuilder anymore.

To fix this erm...bug (?) it will be absolutely necessary, to give both bridges a TID. And not replace them.


Here is the corrected code:

Actor invisiblebridge_solid : invisiblebridge replaces invisiblebridge 9990 //replacing is optional, TID is necessary. But take another number than 9990 as its already used by the original bridge that´s being replaced
{
+solid //you cannot shoot through it in any way
+shootable // Hitscan would go through otherwise
+invulnerable //cannot be killed
+NOBLOOD //does not bleed
+nogravity //not subject to gravity
+dontthrust //cannot be thrust in any way
+NEVERTARGET //not targetes by monsters
+CANTSEEK //not targeted by seeker missiles
+NOTAUTOAIMED //autoaim wont work and actor does not get targeted by BFG blasts
}


ACTOR Custombridge_solid : Custombridge replaces Custombridge 9991 //replacing is optional, TID is necessary. But take another number than 9991 as its already used by the original bridge that´s being replaced
{
+solid
+shootable
+invulnerable
+NOBLOOD
+nogravity
+dontthrust
+NEVERTARGET
+CANTSEEK
+NOTAUTOAIMED
}

[WARCHILD_89]

I just made a video on that. There is also a file to download.

https://www.youtube.com/watch?v=bkPctjRNQFE

[Enjay]

invisiblebridge replaces invisiblebridge 9990 //replacing is optional, TID is necessary. But take another number than 9990 as its already used by the original bridge that´s being replaced

I'm a little confused by what you mean here.

It could be the way I'm reading what you wrote, but there seems to be confusion between the terms tid and the editor number.

A tid is a thing id. This was a long-established name but for whatever reason, DoomBuilder refers to them as thing tags. Tids/thing tags are allocated to items in the map editor.

9990 is the editor number (or sometimes the more ugly DoomEdNum). Editor numbers are allocated to things in their DECORATE or in MAPINFO.

So, when you say "TID is necessary" are we actually referring to a tid/thing tag (which is allocated to individual items when editing the map) or are we referring to the editor number (i.e. the number used to place the correct thing type in the map (after which the thing may then be given a tid as well))?

[WARCHILD_89]

invisiblebridge replaces invisiblebridge 9990 //replacing is optional, TID is necessary. But take another number than 9990 as its already used by the original bridge that´s being replaced

I'm a little confused by what you mean here.

It could be the way I'm reading what you wrote, but there seems to be confusion between the terms tid and the editor number.

A tid is a thing id. This was a long-established name but for whatever reason, DoomBuilder refers to them as thing tags. Tids/thing tags are allocated to items in the map editor.

9990 is the editor number (or sometimes the more ugly DoomEdNum). Editor numbers are allocated to things in their DECORATE or in MAPINFO.

So, when you say "TID is necessary" are we actually referring to a tid/thing tag (which is allocated to individual items when editing the map) or are we referring to the editor number (i.e. the number used to place the correct thing type in the map (after which the thing may then be given a tid as well))?

my bad, yes I mean the DoomEdnums, the file you can download in the video description should have it right. actually the video is older than the updated pk3 in the link

[Enjay]

Cool. I figured that was probably the case but I couldn't check the video or the file at the time, so I just made my post.