peter_spy

But that was kind of the point. You were an engineer, not some bloody Isaac Clarke. Alien was the cat, you were the mouse. Both humans and synthetics had shitty attitude towards you. Gunplay was supposed to be messy. And everything you managed to repair was just a glimmer of hope before another thing got broken, or situation went even more downhill. That was brillianty executed, along with all interface elements. Even stuff like saving added to tension. Comparing this to a cripple of a game that is Thief 4 is insane. A:I is 10x above T4 in terms of quality of... everything.

Yes: http://forums.thedarkmod.com/topic/19294-how-to-use-the-mission-beta-testing-forum/

Haahahahahaha... No. A: I is much, much better game than Thief 4. I finished it on hard, and it was very well designed, and felt meaningful for what it wanted to do. And yes, as most AAA games it was designed with controller in mind, and that's how I played it. One thing I didn't like was the pacing towards the end. I think the game was too long. Seems like devs were so in love with their Alien that they prolonged the last section by a few hours, just to give players more content.

Now, that's more like winter I like. -2°C, lots of snow. Looks like a snowstorm now, but during the day it's perfect weather for relaxing winter walks.

And another cool bank mission, I played it so long ago that I forgot about it. This is kind of dev walkthrough, but much more relaxed and off the record:

This is not a version-related problem, more like DR works from the beginning, but I think it's worth mentioning. It's very weird an unusual that you can select brushes and meshes based on their faces in 2D views. And, you can't select them or move them, if their faces are turned backwards in relation to any given 2D view, which happens with planes and models without faces on the back, like wall panels. Every other game editor and modeling software I know selects geometry based on its wireframe in 2D views. I filed an issue in the bugtracker just in case: http://bugs.thedarkmod.com/view.php?id=4735

In the video it's pre-recorded, so eveyone will hear it. The question is whether you can hear it in-game. Both Volta 1 and 2 support EFX, so you can try them out.

It might be so. If you don't hear enhanced audio, like in the video below, then it doesn't work. It will work in 2.06, regardless of your audio solution. Note that not many missions have EFX set up. You can open PK4 packages with programs like 7-Zip, if you see a folder named "efxs", then it supports enhanced audio.

Depends on your sound card and OS. I don't have a Creative card anymore, and the EFX is the software solution, so it works with any sound card. EAX works only with Creative cards and on windows 7 it requires Creative ALchemy to work.

Or you could just try it with current 2.06 beta. It was stable enough for the mission to be playable in beta testing stage, and it supports EFX from the get-go.

It's not how you do proper emissive/glow materials for game engines. Diffuse needs to be slightly less contrasty and without overblown highlights or deep dark shadows, as in the original version, to allow for brightness, gamma, and postprocess settings to work correctly on most monitors. You need to supply a separate emissive/glow texture. Also, the material you're using contains outdated code: http://wiki.thedarkmod.com/index.php?title=Material_Files

Yup, cubemap skybox isn't a bad idea. If you want something more flexible, you can download UDK and see how their example day/night maps were made. Typically their skies consist of skydome, cloud dome, height fog, and sun or moon paired with light entity. That said, it might be a bit hard to have something like in this T2 mission, since we can have either some translucent clouds or jaggy 1-bit alpha ones. Will try to tweak some stuff later.

LOL

"It takes 10 days to make a chair." Now I feel a bit better now with my average output of 2-3 models per month

Actually it's possible to have much better clouds than just diffuse texture. Experiment with Render -> Clouds -> Solid noise in Gimp, and make it tileable. Use the result as a mask on white image, and also paste it to nJob or use Normalmap filter in Gimp. Now you can put it in alphatest material, then put it on a plane or dome in your skybox. If you have a moon light in your skybox, it will affect your clouds as well, and it should look cool. Other cool trick, if you don't want to use transparency, is to make opaque clouds and put them on a larger dome or sphere. Just remember to give diffuse texture some dark blueish tint. Also make a normalmap for this one. Now to have something more than clouds, you can use spot light and put image of stars as a projection texture. Add glowing moon with its own light as well. Obviously, you can make those materials pan in both cases. I actually did something like that in my Cabal mission for Deadly Shadows, and it worked pretty well.

Also, I was a bit worried that in stronger lighting this frob will be less visible, which often happens with standard frob. But, instead of making material instances for different situations, you can just add parm3 to the alpha value and then set it in the model. So the base alpha value in the material can be, e.g. for models lit only with ambient_world (with shaderparm3 = 0). And if you need stronger outline for frob, e.g. in well lit room, you increase shaderparm3 value. For example: Shaderparm3 = 0 Shaderparm = 0.5 Code: // Frobable object outline { maskcolor map makealpha (texture) alpha .2 + parm3 // modify it as you wish, set shaderparm3 in the model to at least 0! } { blend gl_dst_alpha, gl_one maskalpha cameraCubeMap fake_fresnel_cubemap texgen reflect } // Better frob { if ( parm11 > 0 ) maskcolor map makealpha (texture) alpha .4 + parm3 // modify it as you wish, set shaderparm3 in the model to at least 0! } { if ( parm11 > 0 ) blend gl_dst_alpha, gl_one maskalpha cameraCubeMap fake_fresnel_cubemap texgen reflect }

You asked for more tangible example, so here it is: This is a bit refined version, although it's probably not that much visible in the video. This material actually uses the same cubemap twice: first stage uses specular texture as alpha to give the grate a subtle shimmer to indicate it's interactive. It's not very pronounced, as lights make the cubemap more dim. But, it's very useful for finding objects in darker scenes. Second stage is actual frob and it uses diffuse texture as alpha, so it's a bit more pronounced.

I tried frob_peer with clip and player_clip, and it doesn't work. I assumed frob needs player collision to work properly and it looks like I was right. I just tried it with caulk block set to solid 0 and it doesn't work. It works with solid 1.

The same goes for collision mesh. You have to disable collision in your main material, otherwise the model will have 2 overlapping collisions.

Thanks Obs, this might come in handy. For now, I decided to have this little box in the middle, so when player looks at the center of the grate, frobing wil be a bit easier. If during playtests people will report problems with shooting stuff through the grate, I'll change it so it doesn't allow any object through.

To clarify, maybe this is a rare problem, only related to "see-through" models like iron gates, as I can't think of anything else right now. Anyway, frob detection needs surfaces that player can collide with. In this particular case it means stuff like arrows or other small stuff will be stopped by the collision model. Not sure if we can have a material that is non-solid and works with frob detection (right now we can't). Is there a point to write that kind of functionality, if only for cases like this one? I'm not sure. That is a question for our lovely coders out there

Yup, that's why I wrote it. By the way, with modelling it's easier just to create a collision model and export it with the mesh, instead of binding brushes and using frob_peer. Game will use your collision model for frob detection.

Grayman, I know how to use the frob_peer spawngarg, I wrote that in the first post.

You mean nondrawsolid. That is sure a kind of workaround, although the main problem is lack of contact surface in the center, as that's how players will approach the grate. I might put a small cube there, but it will block any items or projectiles. I hope that's a minor thing, since it will be easier to just open the grate and throw or shoot. Ensuring consistent and error-free frobing is more important. Imagine player fleeing from a guard and having problems with opening this

I created an iron grate that will be frobable, and just like Wiki says, the frob box shape is the shape of my model. The problem is that it will be pretty hard for the players to highlight it, because of the distance between the bars. Basically it looks like this: https://www.dropbox.com/s/au0k3mcvs03jspf/GrateFrob.mp4 Adjusting frob box size doesn't help much in this case. I've tried other options like frob_peer, which works as intended, but the main problem is that even if I use a brush or model to propagate frob to my grate, it still needs to be solid for the frob raytrace to detect it. Materials like nodraw, clip or playerclip don't work, and that grate looks like it should let players shoot and throw stuff through it. I think I had similar problem while playing Biker's WIP, while with frobing an iron gate, so this is a common problem with more complex interactive models. Am I missing something or it seems like we need some sort of special non-solid material like nodraw that will let everything through but collide with frob detection?