Newbie DarkRadiant Questions

[Obsttorte]

The visportal is created on the plane that has the visportal texture on it (marked with red in the picture).

 

The boundaries of the visportal either have to touch other visportal boundaries or worldspawn brushes.

 

In your case, the vp is just hanging in the air, thus having no effect and gets discarded by the engine.

 

Moving it a bit more downwards so it is surrounded by brushes will solve your problem.

[Goldwell]

Thanks Obs, it's all sorted now

[Obsttorte]

It seems that the concept of visportals is a bit confusing to a lot of people (although it is actually pretty simple, but I didn't said that loud ).

 

But the understanding of this concept is crucial for mission design imho. My fingers itching for another poll

[Goldwell]

It seems that the concept of visportals is a bit confusing to a lot of people (although it is actually pretty simple, but I didn't said that loud ).

 

But the understanding of this concept is crucial for mission design imho. My fingers itching for another poll

 

I have vis portals throughout my whole map that work great, in addition the old version of the toilet had a working vis portal. I just couldn't figure out why it wasn't working when I rebuilt it. It was mostly a Gedankenfurz on my part

Edited August 29, 2014 by Goldwell

[Obsttorte]

Gedankenfurz

Another word you've learned from your girlfriend

 

Btw.: In german all nouns are written with capital letters.

[Goldwell]

This is my first time playing with trigger_facing entities and i've got everything set up correctly and technically its working however it doesn't work quite the way I Want it to.

 

I want it so that when the player looks into a certain corner it gets triggered however I find I have to get really close up and look in the direction of the corner to work.. if I get far away (but still within the trigger_facing entity) and look into the same corner it doesn't work.

 

Any ideas? or is there a better way to do something similar to trigger_facing?

 

edit: I just tried again and it seems to only work if I stand in the middle of the entity and face the direction. I can't stand say on the left hand side and face the corner because that would be a 90 degree angle instead of say a 45 degree angle.

 

I wonder if you can do this better with scripting? or just trigger it so that whenever the player looks at an entity it triggers

Edited August 31, 2014 by Goldwell

[SteveL]

This is my first time playing with trigger_facing entities and i've got everything set up correctly and technically its working however it doesn't work quite the way I Want it to.

 

I want it so that when the player looks into a certain corner it gets triggered however I find I have to get really close up and look in the direction of the corner to work.. if I get far away (but still within the trigger_facing entity) and look into the same corner it doesn't work.

 

Any ideas? or is there a better way to do something similar to trigger_facing?

 

edit: I just tried again and it seems to only work if I stand in the middle of the entity and face the direction. I can't stand say on the left hand side and face the corner because that would be a 90 degree angle instead of say a 45 degree angle.

 

I wonder if you can do this better with scripting? or just trigger it so that whenever the player looks at an entity it triggers

 

You might need a wider angle. I just had a look under the hood, and a trigger_facing is just a trigger_multi that checks what compass direction the player is facing before firing.

 

One point: the notes on the DR spawnargs give both "angle" and "angleLimit" as the spawnargs to set. But the game code uses only "angleLimit". It defaults to 30 degrees.

 

If you have a big trigger_facing, then the angle could end up working out wrong. The angleLimit is relative to the world, it's not related to the size or shape of the trigger. In other words, it worries about only the player's compass direction, not whether he or she is facing a specific entity. So for example, if you want the trigger to fire when the player is facing the northern edge of the trigger, you might enter 270 as the angleLimit (=North, I think). When the player is standing in the middle of the trigger, that means he/she is looking at the middle of the northern edge. But if they are at the western edge of the trigger, it'll still fire when they are facing North, so when they are looking at the northwest corner of the trigger. It looks like trigger_facing is designed to be used with a view target that's well outside the trigger: that way, the player will genuinely be facing the target area when it fires.

 

I guess there are alternative designs available that wouldn't mess up existing maps using trigger_facings, so it's definitely worth discussing. One example off the top of my head: a trigger_facing could have an optional spawnarg "facing_target" which names another entity. Then it could fire when the player is inside the trigger and facing that specific entity, ignoring the compass direction.

[Obsttorte]

This is my first time playing with trigger_facing entities and i've got everything set up correctly and technically its working however it doesn't work quite the way I Want it to.

 

I want it so that when the player looks into a certain corner it gets triggered however I find I have to get really close up and look in the direction of the corner to work.. if I get far away (but still within the trigger_facing entity) and look into the same corner it doesn't work.

 

Any ideas? or is there a better way to do something similar to trigger_facing?

 

edit: I just tried again and it seems to only work if I stand in the middle of the entity and face the direction. I can't stand say on the left hand side and face the corner because that would be a 90 degree angle instead of say a 45 degree angle.

 

I wonder if you can do this better with scripting? or just trigger it so that whenever the player looks at an entity it triggers

http://wiki.thedarkmod.com/index.php?title=Triggering_events_when_looking_at_something

[SteveL]

I should have guessed that Obs would have a pre-canned solution to hand

 

Correction to my last post: both "angle" and "angleLimit" are important in the current setup. The angle (rotation) of the trigger gives the compass direction, and angleLimit sets the tolerance.

 

How about incorporating that functionality into trigger_facing though, using the optional spawnarg? Is that worth a thread? Existing setups would be unchanged - they wouldn't have the facing_target spawnarg set -- but for new maps that do supply that spawnarg an angleLimit of 30 (the default) would mean "in the trigger and facing within 30 degrees of the target" instead of "in the trigger and facing within 30 degrees of the trigger's world orientation". That way, trigger_facing could be used with nearby viewtargets too, including those that are inside the trigger volume itself.

[Obsttorte]

Note that trigger_facing and my scriptobject linked above does work differently.

 

Trigger_facing only checks the view direction of the player, and if it is in a tolerance to the given angle on the entity.

 

My scriptobject compares the view direction of the player with the direction from the player towards the entity the scriptobject is assigned to. This means, that in difference to the trigger_facing the direction the players view direction is compared against depends on how the player is positioned compared to the object he should look at.

 

The reason for me to write this scriptobjcet was exactly the fact, that a trigger_facing does not provide such a functionality. The latter basically works like my scriptobject, as if it would be used on an entity infinite far away.

[SteveL]

Note that trigger_facing and my scriptobject linked above does work differently.

 

Trigger_facing only checks the view direction of the player, and if it is in a tolerance to the given angle on the entity.

 

My scriptobject compares the view direction of the player with the direction from the player towards the entity the scriptobject is assigned to. This means, that in difference to the trigger_facing the direction the players view direction is compared against depends on how the player is positioned compared to the object he should look at.

 

The reason for me to write this scriptobjcet was exactly the fact, that a trigger_facing does not provide such a functionality. The latter basically works like my scriptobject, as if it would be used on an entity infinite far away.

 

Agreed. So is it worth adding that functionality to trigger_facing? It would be only a couple of extra lines of code.

[Goldwell]

I think it should be added. I just setup the script and it works perfectly.

[Obsttorte]

We could do this. Personally I would prefer a spawnarg called "ent". If this contains the name of an entity in the map, the trigger_facing behaves like the scriptobject, so that it fires when the player faces the entity specified there. If it is not set or the entity specified there doesn't exist, it behaves like now.

 

"angleLimit" would apply in both cases.

 

This appears the easiest to use approach.

 

Regarding enhancing the code, I would ask Grayman, as I consider him the "official" chief of programming here. (Could we give him this name, sounds funny )

 

EDIT:

I think it should be added. I just setup the script and it works perfectly.

 

So the wiki page is understandable?

[Goldwell]

So the wiki page is understandable?

 

Yeah it's pretty straight forward. You add the script then you add that spawnarg then when the player looks at that entity with that spawnarg any targets it has is triggered.

 

Sehr einfach!

[buck28]

Ok. So I am outside in my map, and I walk through an opening in a wall (gate), that has a working Visportal (or so it shows as working), but when I get inside the wall (gate) by one or two steps, the Skybox turns, black or brown, or greenish, until I take another step or two further? Then it comes back to normal? Could this be a bad Visportal, or something else? Everything is good elsewhere outside. Note: this new area was a new add. (0ne of the Last things newly added before dmap.

Edited September 12, 2014 by buck28

[SteveL]

Hmm, so it's just the skybox not the entire map the far side of the VP. The skybox going opaque might mean the the player's origin (bottom of feet) has got the wrong side of a surface. Check if you have an awkward bit of brushwork on the floor at that spot, that could be making the player's feet sink in a bit. Is it a single visportal involved?

 

Please keep a copy or send me the glitching map. Renderer errors are precious Your glitching bedroom wall taught me loads of useful stuff!

[buck28]

@SteveL

 

Will do. Yes only one VP affected.

I do have a small brush at that approximate spot, .25 thick (height) that might be the issue? It has a sand texture. When I get home I will check it out. If it doesn't fix it will send you a short pm.

Thanks

[SteveL]

Thanks. 0.25 thick should be fine. dmap "should" only choke on brush slices less than 0.1000 thick (a good reason for min grid size in DR being 0.125), so even if removing that brush cures it I'd still very much like to see it.

By the way, the issue I mentioned where the skybox can vanish if the player's feet get tangled with a brush, that'll be fixed in the next release.

[buck28]

@SteveL

 

Sent you a PM.

[Goldwell]

I just inserted the printing_press prefab into my map however whenever I compile it gives me the following error and the printing press doesn't seem to work

 

WARNING: file def/tdm_mover_mechanical.def, line 17: 'editor_DisplayFolder' already defined

 

Can anyone else get the printing press working via the prefab?

[demagogue]

I think a .25 brush can break the rendering, and the description you gave is pretty much a textbook case for 'black walls of death' that I opened this thread with. I think it's even one of the most common bugs if not the most common one mentioned here.

 

It's not that it's too thin. It's that brush slivers break the rendering and create black walls. Brushes should be flush, and that's the first way I'd try to fix it. Generally, cleaning up brushwork is the first thing to try fixing problems like this.

[Obsttorte]

I just inserted the printing_press prefab into my map however whenever I compile it gives me the following error and the printing press doesn't seem to work

 

 

 

Can anyone else get the printing press working via the prefab?

The error states exactly what's wrong.

   "editor_displayFolder"        "Movers/Mechanical"

   "editor_color"                "0 .5 .8"
   "editor_mins"                "?"
   "editor_maxs"                "?"
   "editor_mover"                "1"
   "editor_DisplayFolder"        "Internal"

As you can see the editor_DisplayFolder is defined twice. Although it's strange the error only comes up once you place the prefab.

 

Extract the file from the tdm_defs01.pk4 and place it in the def folder of you fm folder. Than delete the second editor_Displayfolder spawnarg. This should get it to work. If another such error comes up, check the def file for double definitions like this.

[Moonbo]

Hey guys, I've have two questions (which just might be bugs for SteveL):

 

1) I finally got frob_simple to work. This means when I look at one object, both linked objects properly highlight. However, once I pick up the highlighted object, the linked objects stop highlighting. I think this is the same problem with heads un-highlighting after you grab ragdolls to move them around. For my FM, it's going to look very weird if I can't fix this problem. Is this something than can be corrected in 2.03?

 

2) Scrolling around in DR, I noticed that there's a really nice-looking texture titled "tdm_bannerlong_banner_black_floral" which looks like it should be an alternate skin for the banners, however there's no skin in the game that utilizes it. In my FM I'm using it as a carpet texture, but I was wondering if there was some reason why it's not in-game.

 

Thanks!

[Obsttorte]

1.) What exactly do you mean with linked? Is object 1 bound to object 2. If only the first one is frobable, and frobbing it removes it from game, than it is not surprising that the second object stops highlighting.

 

2.) You can create skins yourself.

skin myskin // the name of your skin
{
 model blabla // list of models were the skin should show up under 'matching skins'
 texturename1 texturename2  //replace the first texture with the second one
}

Each skin can be used on several models, and can also be used on models not listed in the skin file. You can replace several textures with one skin. The code above needs to go into a textfile with skin-ending. Create a folder skins in your fm folder and place it there.

[Moonbo]

Hey Obs, regarding #1, I have two objects that are bound to each other and are connected via "frob_simple". This means if one highlights, then the other highlights. However, if I pick up and start moving one object around (it's a moveable) the second object stops highlighting. To see this bug in action in a more common situation, note that with a ragdolled corpse, both the body and the head highlight. However once you grab the body, the head will no longer highlight. This is what I'm talking about. I would like it so that both objects connected by "frob_simple" continue to highlight after one of them is selected (i.e. the head would remain highlighted on a ragdoll after the body is selected). Is it possible to do this?