Dragofer

Ah, then it's not wholly as laborious as I remembered, though still there are plenty of numbers between 0 and 1 involved. Almost all of the existing tables are geared towards flickering candle light (more like pulsating tbh), so if some tables for electrical flickers were made that could be a useful addition i.e. for making lit windows for industrial buildings.

The standard way to make a flame light is to assign the flame particle as the light's model. This takes up the light's model slot, so you have to connect it to the lamp via def_attach which means the light's colour won't affect the lamp's colour. It also means you can't easily edit the light's properties in DR, so def_attach is only really used for lights that need a particle. His desired result contains a flickering sound shader, so that was my assumption yes, though I skimmed through the not too concise post. Creating new versions of materials which use tables would let him avoid exporting his brush as a model, but last I checked there weren't any tables made for electrical lights. I got pretty good results in my map using the thunderstorm tables, but that was for very dysfunctional lamps. Creating a light table from scratch seems a bit much since you'd have to define intensity frame-by-frame, while you could just sync it to one of the flickering sound shaders. Can set volume to -60 if you don't want to hear the sound. Tbh I think a lot of Mircea's problems could be solved by exporting that brush as a model first before dropping it into an existing flickering electrical lamp. Might need to set up lit and unlit skins too.

The process peter_spy describes is mainly suited for making a lamp with a flame, since it doesn't let the light affect the lamp model too much. For a flickering electrical light, you'll need to start with a light entity and change its model spawnarg to your lamp or filament model, change its texture spawnarg to one that ends in _snd, assign a flickering soundshader, and inherit from one of the existing sound-emitting electrical lamps. I doubt you can assign a brush as a model, so you'll have to export it as one first. The surface textures need to be a texture that uses colorme. You'll probably also need to define new skins to override the inherited ones. Since you can only assign a light one model, it'd be much more convenient to combine the lamp and filament into one model.

It's been a fairly longstanding bug that patches exported in DR as .lwo's lose smooth shading and therefore look clunky. The workarounds are to export as .ase or fix it in Blender by removing doubles on a material-by-material basis. .lwo is a compressed numeric format while .ase is an uncompressed text based format. They have the same size when they're compressed into a .zip or when they're ue.npacked ingame, so it's mostly a matter of storage space on your harddrive. I think it's fine to use multiple smaller patches for more complex shapes.

You'd need to: - make black&white versions of the flame diffusemaps so they can be recoloured better - use the "colored" keyword in their material definitions, see existing colorme textures for examples - enable "use entity colour" in the particle editor - this gives you a recolourable flame entity. Since it's def_attached to a lamp fixture, you need to use the spawnarg "set _color on flame" on the fixture to change the colour. More initial work this way than cloning existing entities with different fixed colours, but you'd get a much more versatile entity and the entity list would remain more navigable.

Grats on the (semi-beta, as you said) release! The map's now available for download ingame.

@STRUNK I don't think there's any way around AIs using md5meshes as models, so you'll need to find a working combination of Blender and md5 importer/exporter script plugins to downscale the model. Since there are no animations, though, you can probably get away with making the AI invisible via a skin and binding a small static model (export the elemental as a model inside DR). @Geep There's the setName script command. But if it's like a change of clothes, then wouldn't setSkin be a better fit in this case?

That sounds like the path_anim isn't being targeted by what should be the previous path node, causing the path to end.

This is actually a bug with scriptobjects which set up their own S/R the way you've done in your init. I was stumped on this for ages, wondering why the variables don't carry over between functions (always 0), until it occurred to me to use a different method to call the script object i.e. via the frob_action_script spawnarg.

Seems I had that problem in 2010: Thread: DefTokeniser: no more tokens

Other venues towards making ragdolls invisible would be: - set the "AIuse" spawnarg to something like "-" - use actual ragdoll entities instead of killing AIs - or show the ragdolls to the undead in a blue room so they can freak out there without being seen, give them time to relax before teleporting them to the playable area For making the lute music stop, only thing that comes to mind now is to make an invisible objective that checks whether the AI is dead or alerted to level 3+, and triggers the speaker once.

You could disable the visual stims emitted by those AIs, in the same script that kills / knocks them out. $name_of_ai.StimEnable(14, 0); 14 is the ID# of visual stims (found in script/tdm_stim_response.script), 0 is to disable. (If they start ragdolled at map start you can just disable the visual stim in the S/R Editor). One method is to encase him in a brush of nodrawsolid and apply health 1000. If you want to go further you could make a looping script that refreshes his health every few seconds. For never becoming alert, you can set all his acuities to 0.

That sounds like your Windows user-specific configuration for DR might be glitched, would be worth going to /name of your user/AppData/Roaming/DarkRadiant/ and deleting or submitting your user.xml as part of a bug report.

When attaching entities to AIs, the entities sometimes need to be rotated by putting spawnargs into their entity defs which specify their rotation and offset compared to a specific joint (in this case: something attached to the joint "velvetcap_1"). "angles_velvetcap_1" "90 90 0" "origin_velvetcap_1" "3 1.2 .2" I think if you specify a name_attach5 in addition to the def_attach5, for example "lute", then you can skip modifying the entity def and instead apply a spawnarg like "set angles_velvetcap_1 on lute" "90 90 0". This is why you sometimes have "wearable" versions of props for attaching to AIs. Maybe there's one already for the lute? Can check Goldwell's missions for an existing example, I believe Northdale 2 is the one with a skeleton bard playing a lute.

You need to copy from a brush's surface onto a patch, and the brush surface has to be on the same plane as the patch. This is a 2D projection, so it'll work best for flat patches.

If the statue should just be in the default position you could export it as an .ase model. No need for the extra complexity of a ragdoll underneath the hood. The entity's name is atdm_env_ragdoll_werebeast_steele_1, but it doesn't look rotation-hacked and doesn't have special settings otherwise.

Obsttorte wrote a script based on the player's view angles (statues that only move when the player's not looking at them): object statue_look { void init(); void loopLook(); vector viewDir; vector direction; float cosine; float tolerance; }; void statue_look::init() { thread loopLook(); } void statue_look::loopLook() { while(1) { if (distanceTo($player1)<1024) { viewDir=sys.angToForward($player1.getViewAngles()); direction=getOrigin()-$player1.getOrigin(); cosine=viewDir*direction/sys.vecLength(direction); direction_z=0; if (cosine<sys.cos($player1.getFov()/2+30)) { setAngles(sys.VecToAngles(-direction)+'0 90 0'); } } sys.waitFrame(); } }

I've checked beforehand, quake 4 seems to use idtech4 so it should be comparable?

There is this From this thread in 2014. Looks like the creator doesn't respond to messages though, at least back in 2014.

Expanding on this, you can: 1) Create a patch with a generous number of rows and columns 2) Open the Patch Inspector (shift s), enable fixed subdivisions and set to i.e. horizontal 5 and vertical 5. 2) At the top, Patch > Bulge Patch. This randomly deforms the patch. May need to manually drag down some of the vertices again to avoid knife edges. If you keep posting into this thread Id suggest renaming it to i.e. mattmkb's Mapping Thread.

I'm not aware of a tutorial, but the mission Exhumed has a more open skybox that gives the illusion of extending the landscape into the horizon beyond the map's boundaries.

For punctual information, I find wiki.thedarkmod.com to be most helpful, for example when wanting to find everything about how to setup various doors and behaviours related to them. The DR userguide is more for learning about using the program's interface. For broader intros to mapping, it's definitely recommended to look at the video mapping workshops by veteran mappers (I know that those by Springheel or Sotha are detailed and up to date), which walk the viewer through the creation of a small mission. There's also a text-based tutorial on the wiki by Fidcal, but it's very old by now and multiple procedures in it have become much easier nowadays.

There are a few options: type in testmap mapname into the console, which combines dmap and then map. This is risky when you're only beginning to make maps because the map will load even if there's a leak without any warning. create a custom shortcut that starts TDM and automatically loads or compiles a map bind the console commands to dmap/map/testmap your map to hotkeys by typing for example this into the console: bind "p" "map mapname". This works only if you're already loaded into the map. as of 2.09, which is slated for entering beta at the end of 2020, there'll be integration between DarkRadiant and TDM that allows you to update individual entities ingame, after changing them in DR, without having to reload the map. IIRC it'll also allow for functionality like Dromed's alt-g/alt-e.

You need to have a darkmod.txt and startingmap.txt in your fm so that it shows up in your mission list in TDM, then you need to install your FM in TDM. This is the same as what you do everytime you switch to playing a new mission.

Maybe you've already tried to load the slimmed down version of the mission (in the sense of a large secret area), which can be manually downloaded from here?