rich_is_bored

You can use ROQ videos as a cube map. Here's the relevant information copy/pasted from a cached version of modwiki... { blend add texgen skybox videoMap loop video/mysky.roq } The video can be no larger than 256x1536 pixels. Each of the 6 sides of the cubemap are stacked from top to bottom like so... PX NX PY NY PZ NZ [*]The PX and NX sides must be rotated so the orientation is the same as if it were a cubemap

I think it's called textures/common/cushion.

It could be vertex normals with a length of zero. The engine ignores smoothing groups. It's also worth noting that this problem only seems to appear when exporting patches. My main point of contention with patches is that they are an abstraction layer above the geometry produced by the engine. You can't build everything out of squares. Sometimes you need a triangle. What's happening in the background when you stack a series of control points on top of each other? Is this optimized and cleaned up geometry the same data made available to the exporter?

You can do some pretty amazing things with shaders now days. http://www.youtube.com/watch?v=QCYM_h3OEno But since TDM isn't up to that you'll have to fake it as best as you can. A model with intentionally distorted UV coordinates and some subtle texture scrolling/oscillation could work. Vertex colors or blending might help too. But Id Tech 4 is a fickle bitch that refuses to do what she's told. She doesn't like image sequences or ROQ movies being fed in as normal maps.

That's a really clunky way of working around a missing entity declaration. All the data we need is already available. entityDef atdm:env_ragdoll_horse { "inherit" "atdm:env_ragdoll_base" "editor_displayFolder" "Ragdolls/Bodies" "editor_ragdoll" "1" "editor_usage" "Ragdoll for horse" "bleed" "1" "sleep" "1" "smoke_wound_flesh" "bloodwound.smoke" "model" "horse_tame1" "articulatedFigure" "tdm_horse1" "snd_bounce" "bodyparts" } Copy this text. Save it to a .def file with a name of your choosing. Create a def folder where your FM is being worked on. Put this .def file in that folder. Put a atdm:env_ragdoll_horse in your map. With the next update this entity can be included.

Are you asking me this question because you are genuinely unable to come up with a solution or because you don't like the suggestion to begin with and are looking for a reason to shoot it down?

The problem here isn't that the player can move backwards too quickly but that the AI doesn't move enough or do so strategically. AI positioning and directed attacks could be used to inform player movement; unknowingly guiding players into corners or towards other guards. Instead all AI seem to do is run directly toward the player and then swing repeatedly when in range. This same issue was the cause for concern over fatal headshots to alerted guards. A drawn bow should be cue for AI to stay at a distance, break line of sight, crouch to become a smaller target, and advance only when the player no longer has an arrow knocked. But TDM opted for the quick fix that made the challenge of landing a single fatal shot to an alerted guard impossible rather than just making it really hard.

I wouldn't mind seeing that changed now that we have the ability to. The image textures to be used for ambient lighting are already specified elsewhere in a material declaration. By cutting out the manual copy paste work you'd reduce the length of nearly every TDM material shader to one third it's size and they'd be less intimidating for newcomers to work with.

It should look something like this... textures/example { // first set { blend bumpmap map bump_1.tga scale 0.2, 0.2 inverseVertexColor } { blend diffusemap map diff_1.tga scale 0.2, 0.2 inverseVertexColor } { blend specularmap map spec_1.tga scale 0.2, 0.2 inverseVertexColor } // second set { blend bumpmap map bump_2.tga scale 0.2, 0.2 VertexColor } { blend diffusemap map diff_2.tga scale 0.2, 0.2 VertexColor } { blend specularmap map spec_2.tga scale 0.2, 0.2 VertexColor } } If it were me however, I'd forego editing the material shader. Just open the model in Blender and scale the UV coordinates up. One change versus a fair amount of text editing.

Hosting and spreading the word is trivial when the intent is to service a small group of people who are missing out on some missions. And with the goal simply being to make missions playable in another language, conflicts and updates aren't much different. Mission updates are a luxury since playable missions, no matter the age, are better than those unavailable in your native language. Game updates are too rare to be of much concern. Even less so when backwards compatibility with existing maps is a priority. I don't see where conflicts would arise but then I'm a native speaker and the issue isn't mine to solve. I'm content allowing foreign speakers to hammer out the details.

For the record, I agree with you about the spyglass reference made in the archery section. There is a preferred order you are expected to visit each section from the hub. I don't believe the entire level needs restructured but there are things that could be done to guide the player along and avoid confusion. For instance, including a spyglass in both locations and removing the remainder upon retrieval is an option. I don't believe linear design and hand holding are inherently bad. I have more to say on this but my thoughts aren't organized so I'll leave it at that for now.

To clarify, I'm not arguing that you should host unsanctioned translations. I'm simply pointing out that there is nothing that can be done to stop others from creating and distributing them. You can't even inconvenience people given how easy it would be to produce a modified game executable that downloads content from a different set of mirrors.

You don't have to support it in an official capacity. The game is open source.

What language offers the best experience is of no consequence to people who can't read it. And permission is of no consequence to those who have no respect for it. TDM is too open and unrestrictive to leave the matter to temptation. There will be those who see the lack of a translation as a call to action. It's best to entrust the task to someone who at least respects you enough to ask. If an officially sanctioned translation exists, there is no reason to seek one out or create one yourself.

Actually that link works if you correct it to ".pk4" instead of ".pk".

That's a minor detail that's probably best left for someone with a Oculus Rift development kit to address. It's just guesswork without it.

Just because something can be done on a per map basis doesn't mean it should be. Scripting is a blessing and a curse. Case in point, knocking AI out with heavy objects and AI noticing open doors. These could both be single use scripted events but the combination of these two seemingly mundane abilities anywhere in any map makes it possible to setup traps that knock NPCs out. I love that this kind of emergent game play is possible and I wish TDM had more of it.

That's simple. If they are the only game in town, they get all the FMs.

That's a pretty ambitious project that will require almost every trick in the book. I can sort of envision how you might use fences, skyboxes, and archways to assist with compartmentalization but overall it's a giant technical exercise. You will have to make compromises.

Sure there's a chance albeit slim if you counting on existing contributors. But the code is available. If someone capable wants it enough they can do it.

They don't need no stinkin daggers. They've got rocks.

You don't have to be brave. Just smart. Create a virtual machine using VirtualBox. Download and "play it" from inside the sandbox you've crafted. If it's indeed a virus, no damage done. Delete.

Yeah that suggestion is irrelevant now. Rapture 3D was openAL based and I've since learned that openAL support in TDM 2.0 seems to be broken.

Through OpenAL Soft, a software based implementation of the OpenAL API. You can download binaries here. You don't have to do a full blown install to test it. Just make a copy of soft_oal.dll from the respective Win32 or Win64 directories, rename it OpenAL32.dll, and plop it into the same working directory as the executable you intend to run. Doing this, I can enable OpenAL in TDM. But I get the same error message you have posted on the bug tracker when trying to start an FM.

I bought the exact same headset from Woot a few years ago but I guess it was a refurbished item because I don't have the little USB dongle. If you insist on using the dongle, there's a program called Virtual Audio Cable that may work. I have no personal experience with it but from what I understand you are able to create virtual audio devices and then route and mix sounds however you please. And if TDM correctly identifies this virtual device you should be able to route 7.1 audio to the USB dongle. Alternatively you can bypass the USB dongle entirely like I have and buy a copy of Rapture 3D. I tested this software in an older version of TDM so things may have changed but I did record a video at the time... http://www.youtube.com/watch?v=uJNr7IzcMR4 I don't use my headset that often but if there's interest I can track down the software and report back on if it works with TDM 2.0.