Devel/Mapper Mod

(MadJack) #1

I was thinking if there was some modifications that could be done so that some of the invisible things we insert in a map like triggers, clip, etc are visible or at least get some kind of idea where they are? Some outline perhaps?

I know that it would help me sometimes. Like clipping for exemple or script_mover, splines etc.

I’m sure there would be some more suggestions from other mappers.

(SCDS_reyalP) #2

well, for testing you could just change the shaders to they have an image stage.

(MadJack) #3

Some can’t be changed like target_script_trigger or trigger, target_speaker and others. As for the rest, yeah some could be changed but it’s not convenient. I’d prefer using /db_debugInvisibles 1 than to change the map itself…

(Rain) #4

As far as I know, there’s no easy way for the gamecode to get enough information about brushes to draw them, so you’re stuck with a couple of options:

  • [li]Read the .bsp yourself and extract the data you need (probably not too difficult, but not trivial, either…)[*]Get very basic brush info for brush ents (and no other brushes) with the existing code and build an approximation of the real brush shape with a lot of traces.

[/li]For very simple bmodels, the engine will encode the mins/maxs into ent->s.solid when the entity is linked (search for ‘encoded bbox’ in cg_predict.c), but this information is useless for anything more complex than the encoding there can handle. There’s already some code (#define VISIBLE_TRIGGERS in cg_predicts.c) to draw the bounding boxes for triggers whose bounding boxes are sent in es.solid.

A debugging feature of this sort would indeed be quite useful (to the point where I’ve considered adding it myself using the read-from-bsp method), but I haven’t had the enthusiasm to do it yet.

(dime1622) #5

make an identical brush in the same place, but make it non-colliding.

(SCDS_reyalP) #6

You could show triggers, and all the other brush based stuff. The simple way to do it would be just to have an alternate common.shader, and switch them for debug compiles. ET has a built in speaker editor.

For other stuff, probably the best way to do this would be a compiler option. The compiler could add polygons for the various invisible entities Q3map2 already has some debug stuff that works in a similar way.

You still wouldn’t be able to turn it on/off in gameplay, but it could be easier to code.

(MadJack) #7

@ dime1622, what if I want to debug something in a moving vehicle? It’ll become invisible if I add a model2, I know, I tried it and if I dont’ add a model2, the heading won’t be the same because a script_mover with a model2 will orient itself from the model2 origin… They will all connect to the same point but their facing will (most likely) be different.

@ Player, yeah, I think ydnar’s q3map2 would be the best tool to do that kind of thing but I don’t know if it could be used with movable stuff… attachtotag… etc.

Huh… Why mention the speaker editor? I don’t get what you mean :smiley: I could make some modifications to the brush based shaders but that’s only last resort.

@ rain, well, if I were a coder I’d probably find a way to do those but unfortunately I’m not anymore. I can read code but that’s as far as I can go and even then… :slight_smile:

Thanks for the feedback though :smiley: