8689 replies to this topic

[Judith]

Evey time I try to use blend blend mode with heat haze program, the shader ignores that stage, so everything looks like a predator camo. Is that a known shader limitation or a bug?

 

Edit: nevermind, I forgot blend blend works best as a last stage.

Edited by Judith, 24 January 2019 - 03:20 AM.

[Destined]

I finally found the time to try out the "button" solution and it works quite well. The only problem is that now the rope can be destroyed by water arrows (these are also able to activate buttons). I don't suppose that there is a way to negate that? If there isn't, I will still keep the setup as it is, because at least it works. If I come up with another solution, I will try it, but for now it should suffice.

 

And another question: How do Slow Matches work? I thought that they would emit a fire stim, when used. However, when I try to use them on an extinguished wall torch, they blink red and nothing happens... Just to be sure, I additionally gave the torch the response "fire: light _SELF" (which it should have anyway, as it can be lit with a fire arrow), but still no luck. Thus, I concluded that the matches have to work in some other way.

Edited by Destined, 28 January 2019 - 02:12 AM.

[Obsttorte]

You don't "use" the matches. You drop them into your hand and move them around so that the glowing end is close enough to the extinguished fire source.

[Destined]

Ah, ok, that works. Thanks! I think I will add that to the Wiki page about player tools. I could not find any description on how to use them.

[ERH+]

I've just started working on my laptop with darkradiant and suddenly loading big map almost choke completely whole system. I remember working on large maps on this computer in the past and it never happened. DR eats almost all ram and only filtering func_statics make it barely usable. It have FPS count almost like when I noclip in-game and all visportals are off - but it happens in DR. Any solutions? ("cubic clip the camera view" don't resolve it at all). Older version of DR work the same way, what could have made such drastic change?

Edited by ERH+, 30 January 2019 - 03:18 AM.

[Bienie]

Something weird happened to my DR or TDM, not sure which...

 

When I was dmapping the other day my computer died mid-process, and restarted itself. When I came back in and redid the dmap it suddenly took 10 minutes to complete instead of the normal 30-60 seconds (what I mean is that in console it said ~600 seconds for dmap instead of 30-60). And to my dismay it has kept taking 10 minutes to dmap ever since, which is really annoying when you are doing it to check up on small changing while building. If I try to dmap another map file (my first mission) it once again takes ~30 seconds. What could be the cause of this, and how would I fix it? I already tried to delete the proc file and others that are created in the dmap process, but no change.

Finally, I had just added a new area to the map. Is it possible that there is some glitch that is causing this exponential increase in time to dmap, rather than some damage caused by the crash? If so, what do I look for?

[Obsttorte]

Did you create small details out of tiny brushes or patches. Lots of intersections can increase dmapping time and even cause crashes. Back in the day when I was working on my first mission I created a girder out of brushes (didn't knew about alpha-testing at that time). A simple 32x32 doom units sized girder caused the dmapping time to increase from around 10 seconds to more then five minutes.

[Destined]

If the area you have added has a lot of areas that are accessible by AI, this may also increase dmap time as the AAS has to include all areas. I am not sure if the increase is exponentially, but I think it is at least not linear. However, there are other people here that know that better than I. You could try to block off the transition between the two areas. That way sou should see, if the new area is the cause.

[Obsttorte]

That would then increase aas creation time, which is an additional step after dmapping. Mappers would clearly see whether the additional time is taken by the dmap or aas creation step. In addition, one can dmap with the noaas command (dmap noaas mapname) to see whether it makes a difference. I also doubt that aas creation raises exponentially with the amount of aas areas to be created, but you are right that it is probably non-linear (very few algorithm are).

 

I guess hte general advice to keep dmapping times low is to avoid detailed stuff to stay worldspawn. Convert it to func_static and avoid brushes and patches with lots of vertices to intersect with each other if they are worldspawn or belong to the same func_static. Exporting detailed stuff as models and use those instead should also help.

 

Monsterclipping should be done a bit generously, as it is better to have few big areas instead of lots of tiny ones. This should also help in avoiding strange pathfinding behaviour, like ai swirling around.

[Bienie]

That would then increase aas creation time, which is an additional step after dmapping. Mappers would clearly see whether the additional time is taken by the dmap or aas creation step. In addition, one can dmap with the noaas command (dmap noaas mapname) to see whether it makes a difference. I also doubt that aas creation raises exponentially with the amount of aas areas to be created, but you are right that it is probably non-linear (very few algorithm are).

 

I guess hte general advice to keep dmapping times low is to avoid detailed stuff to stay worldspawn. Convert it to func_static and avoid brushes and patches with lots of vertices to intersect with each other if they are worldspawn or belong to the same func_static. Exporting detailed stuff as models and use those instead should also help.

 

Monsterclipping should be done a bit generously, as it is better to have few big areas instead of lots of tiny ones. This should also help in avoiding strange pathfinding behaviour, like ai swirling around.

 

Thanks! That was the problem. I thought making my complex barn wall into a func_static would be enough, but when I exported it as a model the dmapping went back down to 35 seconds!

I introduced another boo-boo by doing that though... Now the origin of the models are far away from the thing, and they were causing leaks. I guess the model export thing left the origin of the model at 0 0 0 when exporting. So after cloning it and rotating it they are all over the place out in the void. Is there any way to change the origin after the fact? The thing is that I replaced the original func_static when I exported and then saved it over. I don't have any other save where they are made either so I would have to either remake everything from scratch or change the origin place somehow. Or just leave it as is with little caulk band-aids in the void where the origins are now?

[grayman]

One thing you could try is to add the spawnarg "noflood/1" to your far-flung origin models.

 

This tells dmap to ignore the fact that the model origin is out in the void.

 

I know it works for fog lights, but I never tried it on models or func_statics.

[RPGista]

Biernie - I dont remember if you can manipulate the origin inside dr, but if you cant, a simple solution would be to select the model, find the origin point wherever it is and create a brush block around it. Another solution would be to open it in blender and change the origin placement there, then re export it. But Im not sure if that would break the uvs and force you to work on that as well...

Edited by RPGista, 10 February 2019 - 11:06 AM.

[R Soul]

It won't break UVs.

[Obsttorte]

@Biene: There is a 'use entity origin as export origin' setting in the objects exporter which you should activate. This only works if you only have one entity selected for exporting, but provides the highest control over where the origin will end up. In regards to the performance boost note that each brushs and patchs surface contained in one func_static will split up each other which does not happen when exported as a model. This can lead to high tris counts on detail func_static and therefore impact performance. Turning things into func_static only avoids them to split up and be split up by other nearby geometry.

 

The noflood spawnarg works on all sort of entities. It possibly won't work on ai, but definetely does work for func_static.

 

It won't break UVs.

I would second that. I'm no modeler but imho the uv maps don't rely on origin placement, but is stored on a per vertex base.

[Bienie]

Thanks for all the answers! I take it then that my caulk band-aids in the void over the origins is an acceptable solution. I will try to remember to click in the "use entity origin" box in the future. I always get confused with those options. I know in the past I have just moved the func_static to the map's origin point before exporting before, but that if that option in the export window works then that is a lot more convenient!

[teh_saccade]

Regarding models and baking stuff...

(This is me rubber ducking something again - I think it might be better to change the idea... But in case anyone has a clue, it's about making a pendulum swing for a brush. I can't find the right function to script a mover to do that)

Spoiler

After exporting a bunch of bruses as an .ase to put back in the game as one thing, rather than bind a bunch of things together - I've found a crash in DR when trying to stick a collision mesh over some things.
It's not such a big deal, as the material files for stock media provides the same thing.

What I'm trying to achieve is a simple pendulum motion for an anchor-shaped thingy that swings across a pathway.
Have considered using the Indiana Jones style saw blade that whirs along just over crouch height, however this is used in the first chapter of T2X if I recall.

Thinking how it might be worked, I've tried using a corridor with large, thin recesses for the pendulum to move in a large circle and sweep across the corridor - however this isn't a swing, it's more like a series of single fan-blades (which isn't as nice).
Looking at other pendulum things - like The Swing map (which kinda isn't right) - the pendulums from clocks seem decent. They are using animated static models.
http://wiki.thedarkm..._static_objects

This seems like a lot of stuff in order to get a simple brush working.
I'm trying to avoid putting using anything that's not stock or can't be made using only DR (except audio assets, perhaps a typeface or decal or two).

So, looking at some script to get the motion - I've come across
scriptEvent void bob(speed, phase, vector); perhaps with a waitfor to stagger the series of swinging damage things, so that the player can time their run and jump and stuff, get to the end and mantle on a mover (or mis-time and get sliced, or fall off the edge if rushed).
but this doesn't really explain how to plot the vector along which the mover will travel back and forth.

 

Also, I think this will only make it bob like a boat rather than increase the velocity as a mover reaches the apex of its swing and decrease as it loses inertia.
Plus there's the problem of fixing it to swing from its joint, rather than float along.

I'm unsure how to get a func_mover (whether a single brush or a baked ase reverted) to have the swinging motion as a clock's pendulum, back and forth, with the same kind of rhythm...

There's a few more simple ways, such as doing the Skyrim-style, fan-blades from the side that chop across, but that doesn't swing - it rotates into the corridor from slits at the side in one direction or back and forward in a steady motion.
There's the idea of having a series of opening and closing walls or bear-trap kinda things, but that's might not be as cool as the mechanical clanks and grinding of metal slicing across the path. Or maybe, it is... idk.
There's also a series of circular saws that descend from the ceiling and/or travel at strange angles, which gives lateral slice (which is easy with rotation) and some horizontal or diagonal times as well, which might be a more interesting obstacle than the basic "crouch and walk under stuff" traps of T2X and a billion other things...

Hmm... maybe it's easier to combine a bunch of those things into the corridor... plus it would make it more challenging and interesting to get through, also.
Plus it could still have all the mechanical workings and noises and stuff. Perhaps that's a good option that is actually possible without messing with changing velocities.

But it'd still be nice to have a pointer in the right direction of how a pendulum swing might be achieved for a brush in TDM, if anyone reads this and knows off their head an example or which function is the right one to look at.

Cheers.

 

 

[VanishedOne]

Any reason you can't use func_pendulum?

 

(If memory serves it needs a brush-based model for some reason, but it's possible to make a brush textured with nodraw, convert it to a func_pendulum entity, and bind a func_static model to it.)

[teh_saccade]

Thanks, VanishedOne.

When I looked at the func descriptions, it explains how to rotate the model, but it doesn't explain how the swing speed / frequency might be tampered with (I've tried a "frequency", plus a few synonyms, arg, but no go - idk if there's a list somewhere of these kinds of things, or where to look for them in the game files).. It'd be nice to be able to stagger the pendulums or adjust the timings for velocity at different swing states, without having to resize the model - so it's more like a clockwork or motorised swing, a contraption, rather than a realistic swing based upon the constraints of physics..:

"Pendulums always swing north / south on unrotated models. Add an angles field to the model to allow rotation in other directions. Pendulum frequency is a physical constant based on the length of the beam and gravity."

[ from http://wiki.thedarkm...Entity_Database - func section]
 

Edited by teh_saccade, 13 February 2019 - 05:06 PM.

[VanishedOne]

You can get a reasonably comprehensive list of spawnargs for an entity class in Entity -> Entity Class Tree, although in it the descriptions are grouped under editor_* types. Apparently there's a "freq" spawnarg that 'forces a specific frequency', and "speed" to determine 'the number of degrees each way the pendulum swings'. (I haven't tested these.)

[Judith]

I want an AI to remain hidden, or at least stationary, until player hits the trigger_once brush. So I linked the trigger to AI, set Hide to 1, but for some reason the AI isn't hidden. What is weird though, when I set Hide to 1 for an AI that isn't targeted by a trigger, it works correctly. What am I doing wrong?

 

Edit: never mind, I just found out the waitfortrigger node Although this behavior is kinda weird, as this simple triggering works for other objects.

Edited by Judith, 14 February 2019 - 07:47 AM.

[teh_saccade]

That's something I didn't think of, widening the arc of the swing - that might work and make for some interesting staggered rhythms. Thanks very much!
I reckon that would work and also gives a bunch of stuff to play with in future when experimenting with weird things without scripts.

I wonder if it's worth tabulating the spawnargs to make another massive list of stuff for quick reference and search, like the script list, file structure and entity stuff.
Might do that as going through stuff, as it'd be useful in future to be able to search for keywords. I've never found that list of args before. Useful:)

[stumpy]

wait for trigger is there, else it gets triggered when map loads into the engine.

it might be because they also have a delay option and its set to 0 seconds.

so it triggers after a delay of zero seconds, unless its told to wait to be triggered.

Edited by stumpy, 16 February 2019 - 09:46 PM.

[ERH+]

Is there a fm with ghosts going through closed doors and other obstacles? I see "fleshy" arg in builder guard ghost AI, and "ignore_obstacles", but AI seems to bash into things. solid=0 is not helping either.

[AluminumHaste]

Mother Rose

 

EDIT: http://www.thedarkmo...details/?id=106

[Destined]

Is there a fm with ghosts going through closed doors and other obstacles? I see "fleshy" arg in builder guard ghost AI, and "ignore_obstacles", but AI seems to bash into things. solid=0 is not helping either.

I have experimented with ghosts some time ago and found that the most effective way for me was to give the AI acollision box (and AAS) with only 0.5 units height. That way, you can leave an extremely small gap below walls and doors for them to walk through and controll that way, where the AI can walk to. It is even possible for the player to walk through them (although there is always a small "bump" over which the player walks.