Epifire

While it seems like the next step at pushing boundaries, (which is what HL games tend to try and do) they intentionally didn't do this with HL3. I see this as a creative reintroduction to the series and my hopes are that we finally get some kind of EP2 sequel in the not so far future. As a major HL2 fan (that being the game that kept me in modding btw) still has me really stoked. That will however leave me very stoked and broke for the next couple months. ?

Thanks! It happened to be the only map I had to test with water and a working cubemap already setup. However one day when I'm ready to get back to work on it, I'm hoping to reshape it into a neat FM.

A new Gondola for Neon's project. (NOTE the background map isn't related to it). Still kinda swamped with stuff to do (and other requests!) but least to say the Epi is still cranking models here and there.

Ahhh my bad, I thought the camera tutorial was just for the one that buzzes the alarm if it spots something. Yeah that looks to be the reference material I was needing. Just kinda wanting to reverse engineer some template so I think this will work.

Yeah it's not working now on my end either. Trying to figure out why the hell we keep having so many outages in recent.

Currently mission downloader is dead again. Where are we at with this? We've had several months and we're still running on a stand in forum, no bug tracker and I still haven't heard any news on what's being done to remedy this? I understand things take time but we're starting to lose more functionality rather than see things fixed. And it feels like we've had overall less traffic on the site because of it.

Hey quick question, how do you get a camera position to be rendered in real time to a material surface? Wanting to create a neat effect but I'm having a hard time tracking down documentation on the matter.

Yeah I think I messaged around asking anybody at one point if I could look at the current resources for it. A lot more busy just trying to wrap up current requests and getting back to the portfolio but I'd still like to help out on that again if I ever get the chance. Had talked to Kingsal at one point about what adding my own NPC's would take. So while I'm busy af right now, I'm still really keen on working with animations (especially since I'm now learning Maya). ? I just wish id4 had more broad plugin support with other, more modern modeling apps.

It will probably have to change for me in the future but I hate drawing myself my own concept. It's a strange thing but I feel a lot more comfortable (usually) just hammering it out in the editor rather than going through a ton of concept. I do the thing where I take down notes that I toss on my desktop and usually refer to online references of the real thing I'm trying to attain the look of. But that's also from a modeler's standpoint where I do a lot of blocking and going over the design in the early stages of it anyways. However. Having very rarely been given 1:1 concept art, I will say knowing the shape and color pallet to something before even starting it blows my mind. I think drawing your own concept really depends on your workflow because I used to do it in the past but dropped it because it somehow gave me tunnel vision on the scope of the project right off the bat.

I brought it up originally just to hear our coder's thoughts on the concept. As mentioned in the status, I'm a big advocate for implementing (or improving) tech already very well associated to other idtech branches rather than trying to overhaul it's core architecture. We can improve things within a certain degree but at present, even if you had new tech to run TDM on; you'd have to patch the majority of our assets just to render it correctly. What I really would like to see added to TDM follows as... -Parallax corrected cubemaps with batch node building and macro-asset assignment (possibly my most asked/requested feature). -Optional lightmap system for BSP brushwork. -Vertex paint mode for displacements/patches in DR. I rant all the time in the TDM chat about cubemaps because it's such a powerful yet underused feature in TDM. A: it's barely accessible and B: it's current projection method limits it's practical usage. Current cubemaps do not shift via the player's spacial coordinates and they're really a damned pain to create for them to be feasible. Source Engine cubemaps weren't a great deal better in the projection side of things but the build method was 50x better than what we've got. Bare in mind it still uses player position to take the six sided snapshots but it treats the cubemap nodes (placed by the mapper) as player coordinate data to batch build all cubemaps from a single console command. Would stringing together entity positions in a batch automation be that difficult to create in our instance? Lastly I bring up the cubemap assignment/usage. Probably the most painful part of our current system is it requires you to painstakingly create a new material definition for each time you want a new cubemap for a new asset position. My proposition before was to have a generic default block running a kind of if statement. Exactly as our param syntax can look for code additions, my idea was to have this generic block (in a cubemap optional material) look for a cubemap keyname. That if referenced in the model via spawnarg, the material would modify the expected path and fill in the cubemap keyname. This would mean you could have 10+ cubemaps all being based off the same parent material. No more custom MTRs for each! All the mapper would have to do then is drop in a cubemap node, match that node's keyname to a spawnarg on said model needing reflections; then build cubemaps via console command. A fair bit of additional framework I can imagine but that is the ideal situation I could see us benefiting from as a whole. Just improving what we already have, without needing Nvidia specific hardware.

Just got the alternate, "smart" paths worked out; bug free! Thanks again all, I'm sure I'll be back this way when I get some more gameplay nonsense to work out!

Thanks for the responses everyone! Interesting glitch I run into with stims. The stim method works great until I introduce another trigger targeting the NPC with an additional path. Currently I have them making an NPC either walk left or right depending on what trigger the player walks through. What's odd is that the right trigger works without a hitch and NPC walks on the right path upon triggered. However if I place an additional (left) trigger into the mix just labeling a different path, the right trigger breaks. Instead the NPC will always walk left as long as the left trigger volume is present. If I delete it, the right trigger works no problem again. So the entity method Jack posted does work (even if it's a couple more steps) but I just wanted to figure out one last thing. What command can target the other trigger to kill it (kill and remove from stim don't actually work)? As of right now, left or right trigger are set to active at the same time. This introduces the problem that the NPC getting teleported in, gets re-teleported since the other trigger once is active. My goal was to issue a kill/remove command to the adjacent trigger volume to negate that problem. I only tried this method with stims so my question is what's a manual method for externally targeting a volume for deactivation/removal? My only guess is it's a stims bug (or possibly my lack in understanding) so I'm needing more options.

Hey I had a question. So I have a scenario where I have an NPC being teleported from black box into the map. However depending on what trigger_once the player uses, I need it to modify the starting path the NPC starts to patrol on. Still getting the hang of this method as my brain still works in Source Engine I/O direct entity events. So yeah to recap I just need to be able to assign a different path depending on what trigger is targeting the NPC. Thanks!

Well lets put it this way, I was in my teens when I started here (2013). I'm 23 now so I feel like I'm probably one of the youngest members here.

Okay, I just did a couple tiny edits to the mesh and general smoothing. In other words I finally took the time to actually hit upload So here it is! I didn't end up doing the glass shader (still a possibility) but to be done right it would have needed a secondary mask. The mirror also would have seemed strange in contrast to the lens getting a cool shader and the mirror being left opaque, so I just left it as is to not get too noisy. Kinda woulda been overkill in the materials for something so small I think. http://www.mediafire.com/file/mf1hyfgavli1c6y/microscope_001.zip/file