Jump to content
The Dark Mod Forums

VanishedOne

Member
  • Posts

    1235
  • Joined

  • Days Won

    24

Posts posted by VanishedOne

  1. The def in the OP should still be current. There's a test map to go with it here.

    One detail: idDebris is intended to have a 'fuse' like a grenade and be removed from the game world when it runs out (optionally with particle effects, and there seems to be shaderparm support for 'burnaway' effects like D3's dead monsters' too). Whereas flinders like those used by the wine bottles are standard moveables, so they persist and can be grabbed.

    While getting the links to my previous posts I found this one too, which may be of interest re. mappers' control of collision effects.

  2. 4 hours ago, kingsal said:

    Is it still possible to add an impulse to these flinders? Im thinking it would be beneficial in some cases where a mapper might want to give the illusion of an explosion without having to spawn an explosion and then trigger it. 

    Also- Will we be able to add velocity / fall damage to the crate and bottles? So in the case a player throws a bottle or crate hard enough it shatters. 

    Have you looked at idDebris, like I mentioned on the tracker? The powder keg (not your urn, the w.i.p. idExplodingBarrel keg) spawns some as def_debris. Edit: however, just spawning one from the console doesn't 'launch' it. I just had a look for a way to do that at will, and didn't find one.

    (Edit2: by the way, my suggestion for creating 'the illusion of an explosion' would be the FX system: you can tie together sound, lights and particles, and there's even a 'launch' command that's supposed to launch projectiles, though it was unused in D3 and I haven't tested it. Maybe launching debris could be added to that.)

    https://wiki.thedarkmod.com/index.php?title=Breakable_objects#Todo claims that wine bottles break under force, but I've been throwing one around and it didn't break even after I added "max_stress" and "max_torque" spawnargs.

  3. There's a small amount of documentation about ET:QW's occlusion handling at https://wiki.splashdamage.com/index.php/Occlusion_Tests

    Yes, the ET:QW/Q4/Prey SDKs are quite a tease. If we had the full source we could find out how Q4 and ET:QW implemented material maps, for example. (Although the biggest tease is D3's own expansion, since TDM seems to have been built on vanilla gamecode: I hope to see the missing parts of xrayRenderMap ported someday, but after seeing all the changes RoE made to support slow motion I'm not holding my breath for an Arrow Time potion.)

  4. Flinders' spawning with no velocity is an old bug. My comment from #4230: 'A bit of playing with breakables suggests that a single flinder spawns on the ground, 2+ flinders created with flinder_count (as opposed to two separate def_flinders, which can be given unique offsets as seen on the bottles) hover where they spawn.'

    As I say here, it's a bit unclear how the flinder system is supposed to be used, since the example on the wiki actually has "def_flinder" pointing to models, not entity defs. Apparently breakability in TDM is a bit of an old unfinished project: note the w.i.p. warnings on https://wiki.thedarkmod.com/index.php?title=Breakable_objects

    • Like 1
  5. According to this, the reason TDM mines don't have fire stims is that they're intended to be non-incendiary kinetic explosives:

    Quote

    Basically, the main effect of a mine is an explosion. If you blow up some powder, you won't get nearby objects on fire.

    So where does this leave powder kegs: incendiary or non-incendiary?

    I've been trying to research gunpowder blasts, but while there are loads of sites explaining deflagration versus detonation, trying to find out about e.g. the possibility of secondary ignition caused by sparks from a powder blast has probably just got me on government watch lists. I did find a couple of assertions about fires arising from explosions:

    Quote
    Quote

    So I'm not certain black powder is non-incendiary (if you want an explanation for non-incendiary mines, maybe they use some form of high explosive). Anyway, powder kegs: with the current set-up they have a 'burn' phase prior to the actual explosion, perhaps implying the wooden keg has caught fire first, and hence that they chuck embers (def_debris) around as well. Do we want them setting flammable things on fire?

    • Like 1
    • Haha 1
  6. I remember being surprised when I noticed in DR's AI tab that lanternbots weren't KO-immune, but thinking it made some sense given the spindly look that they'd have some delicate external machinery that could be disabled with a precise whack.

    I'm not familiar with the workings of the soundprop defs, but at a glance the relevant ones seem to be sprgs_blackjack_hit_hard ("alert_factor" "0.55", "vol" "40") and sprgs_sword_hit_hard ("vol" "48"). So my guess is that as things stand the sword is noisier.

  7. Welcome to the 'people who've tried writing Pagan lines' club. :-P

    If this AI is meant to be 'poorly educated and rural', as quoted, then I like the animal/venery motifs, but I don't think he comes across as poorly educated. Bits like 'I do not fear your cowardly barbs' sound to me as though they're coming from someone who's trying to play the role of a heroic warrior out of literature, rather than someone who's authentically down-to-earth. 'Educated class pagan sympathiser' is a viable role of course, even one I find interesting, but a bit of a niche I'd have thought.

    On 12/18/2019 at 4:05 PM, Dragofer said:

    @chakkmanresponding to your suggestion to include more references to nature and mystical beings, my original 2010 draft featured numerous lines referencing trolls, a dark lady, deities, a spirit wolf etc. Some years later they seemed to me to be too high fantasy and intrusive for what should be a believable human in TDM's setting, so I toned them down/cut them/gave them to the shaman subset, but I'm flexible in this decision. If the community considers these a good addition I can bring them back.

    Maybe not those exactly ('dark lady' makes me think of Shakespeare's sonnets), but I much prefer that approach to the number of times 'spirits' appear in the OP. The trouble with that kind of generic animism is that the stereotypes it fits are so broad, it can bring e.g. a North American Fallout 2 character to mind.

    • Like 2
  8. On 12/11/2019 at 3:01 PM, Dragofer said:

    Would be most realistic if stuff inside the chest could only be frobbed if you have a clear line of sight to it. On the other hand there'd be a lot of quality of life to gained if we didn't have to worry about the chest body getting in the way.

    That reminds me of this problem: being able to frob e.g. light switches in the next room through the wall unless prevented by mapper precautions. Presumably the default frob trace behaviour is too firmly established to change, but I wonder whether entities could be given a spawnarg that disables frobbing them through solids.

  9. Necro'ing because I think I've got somewhere with this:

    hanged_ragdoll.jpg.395f68c9376a9a9731d9d63aea118a21.jpg

    The way the noose looks isn't ideal: I had to scale it in DR in the first place, since the original obviously wasn't designed to go with the AI necks, and before I set the noose nonsolid the ragdoll would twitch around for a bit and then settle without a nicely drooping look. So you might want to continue using Sotha's anim (especially if you want a swinging-in-wind effect like in PD2, which this method won't allow). If you'd like a hanged ragdoll, though, this seems viable. Basically you take the modified AF below, save it as af/guard_base_newskel_hanged.af, and give the ragdoll an "articulatedFigure" "guard_base_newskel_hanged" spawnarg. This causes the head to be bound to the world, so it stays in position, but the rest of the body still has ragdoll physics (I also made it solid to the player).

    
    
    /*
    	Generated by the Articulated Figure Editor.
    	Do not edit directly but launch the game and type 'editAFs' on the console.
    */
    
    articulatedFigure guard_base_newskel_hanged {
    
    settings {
    	model "tdm_ai_citywatch"
    	skin ""
    	friction 0.09, 0.09, 0.45  //friction 0.01, 0.01, 0.15   // old values made AI slide down stairs or ramps
    	suspendSpeed 20, 30, 40, 60
    	noMoveTime 1
    	noMoveTranslation 1
    	noMoveRotation 1
    	minMoveTime -1
    	maxMoveTime 15
    	totalMass 100
    	//contents corpse
    	//clipMask solid, corpse
    	contents corpse, playerclip
    	clipMask solid, body, corpse
    	selfCollision 1
    }
    
    body "waist" 
    {
    	joint "origin"
    	mod orientation
    	model box( ( -5.5, -6.5, -8 ), ( 5.5, 6.5, 3 ) )
    	origin bonecenter( "Hips", "Spine1" )
    	density 0.2
    	friction 0.01, 0.01, 0.25
    	selfCollision 1
    	containedJoints "*origin  -*spine1 -*leftupleg  -*rightupleg"
    }
    
    body "chest" 
    {
    	joint "Spine1"
    	mod orientation
    	model box( ( -5.5, -7, -9.5 ), ( 5.5, 7, 6 ) )
    	origin bonecenter( "Spine", "Head" )
    	density 0.2
    	friction 0.01, 0.01, 0.25
    	selfCollision 1
    	containedJoints "*spine1 -*neck -*leftarm -*rightarm"
    }
    
    body "head" 
    {
    	// joint "Head"
    	joint "Spine2"
    	mod orientation
    	model box( ( -4, -3, -6 ), ( 4, 3, 3.5 ) )
    	origin ( -2, 0, 75 )
    	density 0.4
    	selfCollision 1
    	containedJoints "*neck"
    }
    
    body "rupleg" {
    	joint "RightUpLeg"
    	mod orientation
    	model bone( joint( "RightUpLeg" ), joint( "RightLeg" ), 6 )
    	origin bonecenter( "RightUpLeg", "RightLeg" )
    	density 1
    	selfCollision 1
    	containedJoints "*rightupleg -*rightleg"
    }
    
    body "rloleg" {
    	joint "RightLeg"
    	mod orientation
    	model cone( ( -6.5, -4, -9 ), ( 6.5, 4, 12.5 ), 3 )
    	origin joint( "RightLeg" )
    	density 1
    	friction 0.05, 0.05, 0.17
    	selfCollision 1
    	containedJoints "*rightleg"
    }
    
    body "ruparm" {
    	joint "RightArm"
    	mod orientation
    	model bone( joint( "RightArm" ), joint( "RightForeArm" ), 10 )
    	origin bonecenter( "RightArm", "RightForeArm" )
    	density 1
    	selfCollision 1
    	containedJoints "*rightarm -*rightforearm"
    }
    
    body "rlowarm" {
    	joint "RightForeArm"
    	mod orientation
    	model bone( joint( "RightForeArm" ), joint( "RightHandRing3" ), 8 )
    	origin bonecenter( "RightForeArm", "RightHandRing3" )
    	density 1
    	selfCollision 1
    	containedJoints "*rightforearm"
    }
    
    body "Lupleg" {
    	joint "LeftUpLeg"
    	mod orientation
    	model bone( joint( "LeftUpLeg" ), joint( "LeftLeg" ), 6 )
    	origin bonecenter( "LeftUpLeg", "LeftLeg" )
    	density 1
    	selfCollision 1
    	containedJoints "*leftupleg  -*leftleg"
    }
    
    body "Llowleg" {
    	joint "LeftLeg"
    	mod orientation
    	model cone( ( -6.5, -4, -9), ( 6.5, 4, 12.5 ), 3 )
    	origin joint( "LeftLeg" )
    	density 1
    	friction 0.05, 0.05, 0.17
    	selfCollision 1
    	containedJoints "*leftleg"
    }
    
    body "Luparm" {
    	joint "LeftArm"
    	mod orientation
    	model bone( joint( "LeftArm" ), joint( "LeftForeArm" ), 10 )
    	origin bonecenter( "LeftArm", "LeftForeArm" )
    	density 1
    	selfCollision 1
    	containedJoints "*leftarm -*leftforearm"
    }
    
    body "Llowarm" {
    	joint "LeftForeArm"
    	mod orientation
    	model bone( joint( "LeftForeArm" ), joint( "LeftHandRing3" ), 8 )
    	origin bonecenter( "LeftForeArm", "LeftHandRing3" )
    	density 1
    	selfCollision 1
    	containedJoints "*leftforearm"
    }
    
    /*
    fixed "waist" {
    	body1 "waist"
    	body2 "chest"
    }
    */
    
    universalJoint "head" {
    	body1 "head"
    	body2 "chest"
    	// anchor joint( "Neck" )
    	anchor joint( "Spine2" )	
    	shafts ( 0.0000001629, 0, 1 ), ( 0.0000004888, 0, -1 )
    	friction 0.5
    	coneLimit ( -0.0000001629, 0, 1 ), 60
    }
    
    universalJoint "rupleg" {
    	body1 "rupleg"
    	body2 "waist"
    	anchor joint( "RightUpLeg" )
    	shafts ( 0.0000004888, 0, -1 ), ( 0.0000001629, 0, 1 )
    	friction 0.3
    	coneLimit ( 0.3535537422, -0.3535535038, -0.8660252094 ), 40
    }
    
    hinge "rloleg" {
    	body1 "rloleg"
    	body2 "rupleg"
    	anchor joint( "RightLeg" )
    	axis ( 0.0000004888, -1, 0 )
    	friction 0.15
    	limit 130, 70, 90
    }
    
    universalJoint "ruparm" {
    	body1 "ruparm"
    	body2 "chest"
    	anchor joint( "RightArm" )
    	shafts ( 0.0000004888, -1, 0 ), ( -0.0000001629, 1, 0 )
    	friction 0.35
    	coneLimit ( 0.0000004813, -0.9848078489, -0.173647508 ), 140
    }
    
    universalJoint "rlowarm" {
    	body1 "rlowarm"
    	body2 "ruparm"
    	anchor joint( "RightForeArm" )
    	shafts bonedir( "RightForeArm", "RightHand" ), bonedir( "RightHand", "RightForeArm" )
    	friction 0.25
    	coneLimit ( 0.6427878737, -0.7660441995, 0 ), 80
    }
    
    universalJoint "Lupleg" {
    	body1 "Lupleg"
    	body2 "waist"
    	anchor joint( "LeftUpLeg" )
    	shafts ( 0.0000004888, 0, -1 ), ( 0.0000001629, 0, 1 )
    	friction 0.3
    	coneLimit ( 0.3535535932, 0.3535536528, -0.8660252094 ), 40
    }
    
    hinge "Llowleg" {
    	body1 "Llowleg"
    	body2 "Lupleg"
    	anchor joint( "LeftLeg" )
    	axis ( 0.0000004888, -1, 0 )
    	friction 0.15
    	limit 130, 70, 90
    }
    
    universalJoint "Luparm" {
    	body1 "Luparm"
    	body2 "chest"
    	anchor joint( "LeftArm" )
    	shafts ( -0.0000001629, 1, 0 ), ( 0.0000004888, -1, 0 )
    	friction 0.35
    	coneLimit ( -0.0000001604, 0.9848078489, -0.173647508 ), 140
    }
    
    universalJoint "Llowarm" {
    	body1 "Llowarm"
    	body2 "Luparm"
    	anchor joint( "LeftForeArm" )
    	shafts bonedir( "LeftForeArm", "LeftHand" ), bonedir( "LeftHand", "LeftForeArm" )
    	friction 0.25
    	coneLimit ( 0.6427875757, 0.7660444975, 0 ), 90
    }
    
    universalJoint "chest" {
    	body1 "chest"
    //	body2 "head"
    	body2 "waist"
    	anchor joint( "Spine1" )
    	shafts bonedir( "Hips", "Head" ), bonedir( "Head", "Hips" )
    	friction 0.5
    	coneLimit bonedir( "Spine1", "Head" ), 30
    }
    
    fixed "headnoose" {
    	body1 "head"
    	body2 "world"
    }
    
    }

    • Like 1
  10. It looks as though Move To Position is for use with AI.

    The response effects are implemented via script functions, so you can find out what they do internally by looking at script/tdm_response_effects.script inside tdm_base01.pk4. effect_move_to_position_action() appears to invoke a script event called moveToPosition(), which according to http://wiki.thedarkmod.com/index.php?title=TDM_Script_Reference/2.06 is specific to the idAI spawnclass. (A touch confusingly, idMover has one called moveToPos().)

    Edit: on removing particles, I'm guessing these ones were spawned via the Spawn Particle effect? From a glance at the scripting there's no obvious way to get the name of the emitter it spawns, so depending on what you want to do, the best thing might be to place your own func_emitter and trigger it on/off as desired.

    • Thanks 1
  11. 22 hours ago, Dragofer said:

    Another idea is to adapt a script fragment from Obsttorte to fade the fog's density over time as the player changes between locations. But it doesn't seem like fog entities respond to their shaderParm3 getting changed, unfortunately, so this wouldn't work. Had a test map where I just flat out called $fog.setShaderParm(3,10000); on a dense foglight.

    
    void fade_fog(entity location_name)		//reduces the density of a foglight with the name 'fog' by increasing shaderParm3 when entering a location with the name 'location_name'
    {
        float i;
        for (i=0;i<100;i++)				//for the next 100 frames (i = iteration)...
        {
            $fog.setShaderParm(3,1000+(i*10));	//add 10 to shaderParm3, from a starting value of 1000
            sys.waitFrame();			//repeat next frame
        }
    }
    
    //this is a start - would require variants to increase & reduce density and be called by moving to specific locations                       
                         

     

    It just occurred to me: did your test map use delta1_fog by any chance? It has alpha explicitly set to 0.5 (values of 1 or less are treated as an instruction to use a 'default' fog distance of 500 units), which might explain why the shaderparm wasn't working.

    • Like 1
  12. 5 hours ago, VanishedOne said:

    I'm not even sure whether id Tech 4 foglights work the way id intended to make them work: there's a Doom 3 file with a lengthy comment indicating they can be manipulated via the light texture's alpha channel, but my experiments got nowhere.

    I misremembered this somewhat; here's what it actually says:

    // If you replace the default internal fog projection image with your own
    // texture, make sure that the alpha starts at 0 in the center, reaches
    // 255 at the borders, and is generally radially symetrical.
    // The color channel can be left solid white, or it can have additional
    // color changes with position.

    I messed about with both RGB and alpha channels to no apparent effect. I think I tried the same on the falloff image too.

  13. 5 hours ago, Dragofer said:

    IIRC there's a spawnarg relating to boundaries of fog. I don't remember how it goes, though, and whether it achieves what you're looking for.

    noFogBoundary stops foglights painting on the boundaries of their volumes, but they'll still paint on geometry inside the volume, so I'm pessimistic about its being a complete solution in this case.

    3 hours ago, duzenko said:

    It's time to revisit our fog implementation. It looks like ad-hoc, last-ditch effort by id to create an effect they never really cared about. It's non-linear in Z-direction and is plain unnatural.

     

    I'm not even sure whether id Tech 4 foglights work the way id intended to make them work: there's a Doom 3 file with a lengthy comment indicating they can be manipulated via the light texture's alpha channel, but my experiments got nowhere.

  14. In the simplest case: frobbing already is a stim, so give the switch a response to STIM_FROB (that is, the Frob stim type).

    The catch here is that S/R alone doesn't give you a way to do one thing when a switch is frobbed 'on' and another when it's frobbed 'off'. The dining room in ITB has switches that fade the lights but I just used two switches.

    • Thanks 1
  15. 10 hours ago, joebarnin said:

    krrg - thanks for you comments.

    D'oh! Good catch. If I ever do version 2, I'll fix that.

    If you do, take a look at the brushwork around the back door too: there's a visible gap.

    Solid sneaking apart from that detail! Though after the

     

    'reset' on purifying the Heart, it ended with me spawning in a load of gas arrows to knock everyone back out, because I'd already done it properly the first time around. Someone noticed the open display case too and began a search, so it all ended in complete chaos with bodies piled up in the nave.?

    • Like 1
  16. From a glance at func_rotating, "invert_on_trigger" "0" should stop the direction reversing.

    Try a negative value for "speed" to make them rotate in the opposite direction.

    I'm not sure from the diagram whether you want a mover that moves from A to B or B to A when triggered (isn't that a regular binary mover, like a sliding door?) or whether you want one that cycles back and forth (func_bobbing?).

    • Like 1
×
×
  • Create New...