Epifire

It's much easier to generate normal from a heightmap (same as bumpmap) than the opposite. The major difference being that normals data is dealt to convey edge details, whereas the B&W bumpmap is just used to calculate low to high areas. I wish we could use alphas for more than just opacity. As far as I know, the engine doesn't support much else for alpha masks. Otherwise I would have been packing my speculars with my normals this whole time. If the system could be modified that would be a different story. But I highly doubt it's as easy as copying and pasting new code in.

Does that count for multiple movers (such as wheels or doors) being bound (bind) to the single tram mover? It would be more involving but I had initially wanted to have other embedded movers via script to provide a solid visual representation. Not that I plan on ever running more than one tram, it's good to know there's a method for running two spline paths. Also, what of this physics problem? I'm debating some kind of player attachment method if the physics continue to be faulty for proper collision. I'm not using .disableSplineAngles now since that pretty well defeats my purpose to use a spline to begin with. But when removed I think that's when I started finding this lack in proper collision. If this acts as a vehicle (really similar to HL2 usable vehicles) would just lock the player position (or seat) until the tram has come to it's destination, in which case would kick the player out of the vehicle. The quality of ensuring the ride is clean and smooth is the greatest benefit in that regard. It also gives me the opportunity to sidestep the always upright issue of the player node... The player pitch (hopefully) could match that of the orientation of the tram. The goal of a player attachment is that foot movement would be locked in but you'd be able to look around. This would have to look for the tram script running, because if you could exit this, "vehicle" prior to it's stop you'd just fall through it. Otherwise I don't feel like I have a lot of options left. EDIT: Well I fixed my collision issue. Something a bit more refined that's bugging me is the .disableSplineAngles line. I need rotation and pitch but I wish I could remove roll axis from the mover. That's the unpredictable part I can't predict with track meshes so the variable rocking (and rolling) that occurs on sharper turns gets kinda funky. Also is there a list of available mover functions somewhere that I can use for reference?

Wai.. wait, hold up a second. This guy managed to copy shadow information into cubemaps?! That's freakin brilliant. I always had been a fan of pre-baking shadows into single channel, lightmap textures. The problem had always been that foreground elements (the proposed shadow caster) being covered by the baked shadow map. Only solution there was having the shadow casted (projected lightmap texture) and then a second fast light to illuminate the front of the actual object in question. That ended up being how I did these soft shadows... But again, that's TWO lights to accomplish one instance of soft shadowing. It only is worth while for really moody shots that are secluded. So the usefulness of that method is how much do you want certain lighting scenarios to pop? Honestly though nbohr1more, I'm very curious about that new lighting method you brought up. Not asking if it's ongoing, but what are the possibilities you see in that being adapted to the engine personally? EDIT: Also that parallax mapping would be dope considering how much time I spend on highpolys and heightmaps.

My thoughts exactly. In that same vein of thinking, I'm a big fan of using the same naming convention for parts designed as a set. I'm usually that guy who just arrow keys around in a set to find something, so it's really handy when all the intended assets are all in a bunch.

I'm running through Grayman's article on camera movement now. http://wiki.thedarkmod.com/index.php?title=Cutscenes_Part_2:_Splines_and_Camera_Movement I hadn't realized that the spline data needed to be saved into the func_splinemover. Stumpy notes having to list the spline name in the script, but all I'm able to declare is the spawnarg property name (curve_Nurbs). Grayman shows this method of embedding the spline to the mover but that also complicates the method of multiple tracks, or direction reversal. EDIT: Aight nevermind what I said there. I failed to realize that the spline mover was just a storage for the spline path (and still needed an additional func_mover). Though one thing I'm having some troubles with is the player keeps falling through the mesh when it follows the mover it's bound to. I can walk forward to stay on it otherwise it's like the collision mesh doesn't exist if I stand still.

I hadn't really used scripts before all of this so pardon my lack in understanding the object setup. I hadn't seen any articles covering spline usage so I'm assuming I should be utilizing a func_splinemover for this? Currently I'm getting console errors each time I try and activate the mover. It's stating, "Thread 'spline_mover': Function 'time' not supported on entity 'mover_object" It's repeating that same error along every function added within the script. I wasn't sure how to interpret that whole section so I just added in the first bunch stumpy listed within brackets. void spline_mover() { $mover_object.time(20); //how long object take to move along spline $mover_object.accelTime(0.5); //time mover takes to accelerate to full speed range 0.0 to not more than time to travel spline $mover_object.decelTime(0.5); //time mover takes to decelerate to a stop range as above $mover_object.disableSplineAngles(); //disables spline angles $mover_object.startSpline($the_fine_spline_line); //starts mover moving along spline sys.waitFor($mover_object); //wait for func_mover to finish moving along spline before doing anything else } Are there additional spawnargs the func_splinemover should be using? I just have a mover button pointed to that, with a (state_change_callback) set for the script. Not sure if I'm doing any of this right so I figured I'd just mention all of it for good measure.

So I've been hard at work on my very own FM that's a bit more akin to my industrial tastes for detailing. That being said I decided to add in a tram system for a section of the map that requires transportation. In addition, this tram I'm designing goes up and down inclines. My primary concern has been that the tram's pitch orientation would match the path it's traversing. Hence the spline method. This was pretty simple to rig up back when I was doing HL2 mods but I've never touched the movers in id4. Has anyone used a mover script to take pitch orientation into account?

That section detailing the flying buttresses reminds me of the exterior of the Hammer cathedral in TDS. The precision with the perspective framework is a fantastic added touch. I had made some considerations for creating modular cathedral parts (sometime in the distant future). A 2D breakdown granting technical direction and possible thematic elements would be invaluable for something like that.

This is the core reason I'm not even making a mission based out of the city. Well that and there's just so many city types now, I think it needs to get shook up once in a while.

U'm does he have any unpacked asset folders in the core directory that could be interfering with the ones contained in the PK4? That's honestly the only time I've seen that kind of thing happen.

Once these release it's truly out of my hands at that point as to what people want to do with them, or if they want to kitbash/modifiy them with other existing assets. As for making additional skins, it would be difficult (but still possible) without using Substance Painter. Though I don't recommend it as most the control comes into play with smart masks and real time preview adjustments. I don't give out source assets (highpolys and working files) as a matter of principal, simply to maintain and supply legal grounds as the valid owner (should the need ever arise for it). It's a standard I uphold across all mods I've worked on but to that end I only share the final release versions for that reason. Once these files (among probably a hundred other bits of models) make their debut in a collaboration FM, I'll be seeing to a public release for community use.

Thankyou! Definitely doing a pingpong for themes between that and TDS in my art. Well the source files can definitely be edited to create additional skins later from Substance Painter. At current I had no plans of additional skins but it's still open should there be a valid enough reason in the future.

Aight, well I wasn't planning on showing these till Lord Edgar's Disappearance shipped but we have enough home grown goodies still left in there as a surprise. Made up a safe set to flesh out the mechanics for two different kinds of safes. There's a standing floor version and a wall mounted one. The set is designed specifically for having fully script controlled mover actions. credits to Goldwell for scripting and recording this wonderful gif There are single and dual lock optional doors, with locked and unlocked clasps for scripting as well. So like four optional doors to use for both safe types.

That's really good to know about the difficulty spawnargs. I'll have to write some of this down when I actually do up my own FM (someday?). Something else directly pressing in some recent work I've been trying to do. Long story short, I need a Sub Surface Scattering shader. I feel like it should be possible but I'm not one to judge as I can't make them myself. Does anyone have an existing shader program available that could apply a kind of thickness based highlight from local point lights to said object?

Alright I think we're getting somewhere. So this begs the question what happens when we hit escape during a mission load? Would we insert the regular menu, or maybe have the active player preview blurred into the background of the menu elements? The latter totally being an HL2 trait, but having the option would be cool. I think the code/scripting elements would be comprised in the same method. You'd just be targeting the actual player position when a mission is loaded. Whereas when just the main menu is loaded on startup it could run through one or more entity plotted positions in your startup map. I know I most certainly would use this in my own work if I had the option to do so.

Now this is my kinda menu! A couple things I'm curious about is exactly how this is setup and how far it increased load times? Naturally you'd have a the core level it's taken from gutted and saved out as a menu map. Keeping only the components and key areas that are required to be visible. If you ever wanted to go a bit more in depth, you could have a camera path track like what Unreal Gold's menu used for a flying camera. Maybe a bit of nostalgic flare!

I don't think it's exactly needed that we have a menu rework, but high quality material elements layered in would be badass. I'm a big fan of mission themed menus. I don't think it would work so well with id4 load times but I'd love to setup my own menu maps with an active camera view of the world (yes like HL2 ).

Generally I've noticed ase files tend to store redundant file data whereas a lwo file is usually more slim. My main thing is the plugins I've tried with Blender were pretty buggy for ase, combined with the fact I didn't want to manually have to edit paths afterwards. In my time working with models on the id4, lwo files are just present less headaches as they've been more straightforward.

It looks like those viewport shots are primarily relying on a phong shader. I'd be interested in seeing what he'd do in TDM with proper normal maps applied in the final shots. @freyk If he is interested in getting into any kind of modeling, I'd be more than happy to lend a hand getting him setup with exporters and stuff to use. Or just any general advice if needed!

From where I'm sitting, as long as they are indeed free to use and there are no qualms about it being added to the content base; then I'd suggest a import/export with Blender. Lwo files are even better yet as long as you're able to get decent smoothing on export. They're a fraction in file size compared to ase, which is why I use them so heavily. That and it just happens to be the only plugin that works for finalizing my meshes out of Blender. Shoot me a PM if you want me to take a crack at converting some of those for you.

Some great looking art there. The first one really gives off some original Thief intro movie vibes. Too bad I've got my own FM work on hold right now else I'd jump right on board with any kind of collaboration to offer. Definitely will be keeping you in mind for recommendation as I continue work on other projects here. Also I'd be thrilled to see a personal page with more of your illustrations if you had one available.

Question for all you fellas regarding difficulty options. Is it possible to have variable scenarios and condition states (for script objects in a world) that respond to difficulty settings? I was thinking to myself how it would be to have different doors, and world features that could be enabled (or disabled) depending on if you were playing easy/med/hard, etc. Maybe people do this already and I haven't seen it? It does seem like a less linear way of adding more play through value by changing the actual scenarios based off the difficulty. In this sense you could funnel, or even bottleneck areas to increase the challenge presented to the player. That grate or sewer access could be locked in a harder playthrough, whereas it's open on easier difficulties to provide more options. Or you could take it a step further and have whole environmental changes that are set to be visible or removed. Maybe a pain to setup but the result would be pretty cool.