Dragofer

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?

You can spawn entities, and you'd probably need to set a model too, like this: entity spawned_entity = sys.spawn("func_static"); spawned_entity.setModel("models/darkmod/..."); spawned_entity.setOrigin('0 0 0');

It's very probable the 0.0160 is just a rounding down of 0.01666666. The most precise expression of a frame is 1/60 of a second. sys.wait is less precise than sys.waitFrame because the engine checks every frame how much time has passed. So it checks after 0.0167s, 0.0333s, 0.0500s etc. If you tell it to wait 0.02s it actually waits 0.0333s because that's the first frame where time elapsed is greater than 0.02. I really don't think there can be less than 1/60 of a second between scripted events, so you'd have to adjust the distance moved.

I think the game clock runs independently of how fast your PC is producing frames. If you run the game at 20fps, the game clock advances by 3 frames even though you've only seen one frame in that time. The shortest possible waiting duration is 1/60 of a frame, so 0.0167s. As Obsttorte pointed out once, if you use wait commands the engine checks every frame whether a greater or equal amount of time has passed. So if you specify 0.0200s, the engine will wait 2 frames, 0.0333s.