Epifire

Because as far as I know of it's the only pathing method that can incorporate pitch control. The track and rail areas needed to be traversed have a lot of vertical height differences. If the normal method could do that easily, I'd just as well chuck splines. From what everyone was telling me though, splines are the only way to accomplish that. What would be the few things to consider?

Currently it's using func_mover_amodel with a state_change_callback on a button. The problem at current, is it doesn't pick up where it left off. It just restarts the spline path rather than resuming course. Baring in mind that the tram doesn't deviate from a single spline path in any given situation, should it really be that difficult to implement? Maybe I'm assuming the script can do more than I'm seeing, or that it simply can't handle complex commands for splines. I was under the impression you could define start and end point entities similar to conventional multistate movers. The only difference being how it converges between those two points being a spline rather than a straight line. Proof of concept that a one way mover does indeed work. https://gyazo.com/964a7b7b660b41c25a882a9ff3320f23

Well so you know, I hear Prey runs a heck of a lot better than Dishonored 2. I'd like to buy it but I'm pretty sore on cash myself.

I'm very new to the methods id4 uses for scripting as well as general implementation of gameplay mechanics. I assume you'd be covering some of that too right?

I meant just the regular method being defined by path nodes. For the spline itself I can imagine there will be a lot of map testing involved to get the desired positioning down. Just in my own side tests I realized just how sharp it will make turns. One thing was bothering me when I had made a static brush bucket to test with. When turning or moving at an angle, the player somehow could block the mover from the inside. I'm hoping that just had to do with using brushwork, so hopefully using a model should fix that. So to start with, how would we go about setting up these three main buttons?

Splines have to be used because the regular mover paths don't take pitch into account. For angles and such it requires that it uses a spline, otherwise I'm stuck working on a level plane. To be fair most the areas setup for the tram are just single paths without any optional turns or routes. The big thing I want to make sure is bulletproof is that it can stop and continue or change directions with ease. Right now I don't seem to have an effective means of stopping without it starting the spline path over again. Unlike the door, the wheel movers aren't essential to start with but I would like to add them later when the core components are in. I'm really just wondering how to get all of this setup.

Well I'd talked a tad bit about starting a tram with my splines thread but I thought I'd post something a little more direct now. For you script junkies I hope this can be a fun little project to collaborate on! So here it goes. The tram I'm making for my mission will be a self powered mode of transportation that rides along a railway. It should basically be a small box car of sorts with a view panel that stretches around all sides. It should have a single door that is automatically closed while the tram is in motion. It should have three buttons for controlling it. Forward, backward and a brake. The directional levers should only be able to change direction when the brake has been applied (so no changing directions while in motion!). The tram brake should probably be it's own script function so that it can be called by other modes of command (from end of path splines or triggered events). It also should have a single state that (when enabled) should make the controls inoperable. This function is only needed so that the tram may carry out it's last defined spline path without player interference. Lastly, I wanted to have a true/false active state available. This is just so that the tram can remain inactive until the story/objectives define otherwise. I will be modeling a entirely new detail mesh from scratch, and I'm hoping that I can eventually get a pretty compact def file established for it. The end goal of mine is to have a nice tram that practically anyone can pick up and use after it ships in my FM. Also for your convenient referencing I already grabbed the original script for the D3 tram and tried to gut most the features I was sure that we wouldn't be needing for this. Such as vertical and lateral movement functions. Hoping we can reuse some functions from it but I'm a script novice so I need some parental advice.

My proposed solution is a script that would convert the patch to a model and then establish a generic modifier on the finished shape (with a script). What really makes me curious is could vertex color data be authored by a non-modeler app? Because you'd be applying black and white vertex color conversion from bounding measurements along a single axis. Otherwise you're stuck trying to implement a whole vertex painting UI and toolset which just seems like an absurd undertaking. Running with that design concept you'd create the said patch and when finished with the shape you'd convert the patch with the new script. The only other thing that would have to be defined somehow is axis selection and an invert color option. Otherwise I think we're starting to see the same point.

Well I'm looking at the blend you're talking about Neons and I'm just not sure how they could implement any kind of painting with patches. I could see it working if the terrain patches in question could be turned into models inside DR, but that sounds like a nightmare operation in and of itself. Something that would be kinda interesting would be a height gradient blend mode. Where vertex z coords register create a heightmap (high areas getting a white coverage). It would likely establish the zeroed point of the selection to a center of origin, which could make gradient confinement unpredictable. The proposed method would be something like an additional selection conversion type with the DR right click (kinda like set to static option). It would have several functions to handle that mode. Being a convert to model and a gradient based vertex color option handled in one click conversion. You probably would have to enable that as a finishing step, and would also have to setup a two stage vertex blend material in order to see the blend occur at run time. I doubt painting vertex colors in DR would be an easy feat which is why I suggest range based gradient. Possibly could have an adjustable center of origin to control gradient intensity? That's the most realistic based operation I could see being implemented. Tell me your thoughts on this one guys?

One of the most powerful usages of editors like Hammer and Radiant has been the ability to quickly create, iterate and expand layouts during the blockout phase. Epic has brought a little bit more work-ability to brushwork (very recently) but had almost completely neglected any form of good brushwork manipulation in the past. This I think was more in an attempt to drive people to use models exclusively (which isn't bad for the final product). However it's awful when trying to start a level when in the concept and design phase. This pushed users to create tools like HamUEr so they could create the level in older editors and import scales and bounding info when done. Overall I still really love Unreal personally. I'm not working exclusively in it right now as I'm more into creating a playable game (in TDM) than pure art pieces.

There are plenty of engines from that time that incorporate a lot of scripting (largely shared in how materials were setup). Besides gameplay functions (done in simplified C++ expressions) the rest is largely very simple and straight forward in material authoring. Even on the scripting front there's a lot of predefined examples, along with custom defs and scripts to fall back on and reuse for FMs wholesale. Solid art and design doesn't rely solely on using a full visual featured interface and node based editor to make a good game. Yes Unreal is a great engine but what it makes up for in artist friendly UI, it fails to accommodate in methods of BSP blockouts and more practical designing. Saying someone can't produce a good level due to spanning a larger skill gap; is like telling someone from the 50s they're bad drivers because they had manuals and we drive automatics. We get that you like Unreal's approach. That's great but this is a much different engine that requires you to adapt to it's unique work environment.

Even if it was a simple parallax shader I would be very intent on using that myself. If you fine fellows ever find the itch to take a shot at that, I'd be down for making some new materials to test it with.

Hello there stranger! So you say you wanna get involved with FM collaboration? Well progress around here is slow but there are plenty of projects around here that are slowly chugging away. I would like to make a suggestion as you mentioned voice acting? It may be worth while to make a small demo reel of sorts showing off your fine voice skills. It wouldn't have to be long or drawn out, possibly you could write your own small script to give some character background for a video? Either way it would give people a good idea where your range is at and the kind of roles you could possibly pull of later! For general FM creation there isn't a tremendous amount of actual, "coding" unless you get into gameplay script work. Even if you're not into level designing, I'd recommend taking a look over the basic features of Dark Radiant (our wonderful in house editor). Knowing the workflow and basic implementation of things is a very worthy trait here in the community. Download link: http://darkradiant.sourceforge.net/ Beginner's guide to DR: http://wiki.thedarkmod.com/index.php?title=A_-_Z_Beginner_Full_Guide_Start_Here!

So okay you do have some tools for terrain in UE4 but a lot of the time before that, people would still model it all out. As Obsttorte pointed out, the brush and patch system doesn't embed vertex colors or complex data. As far as I know material shaders only support white to black painted coverage (so no four RGBA channel blending available). My advice would be for you to make patches in DR, export them as OBJ and then paint vertex colors in lightwave. It doesn't take super modeler skills to do it either, just a working copy of lightwave and a tad bit of getting your feet wet to manage basic view navigation and operating the painting UI (which is really super simple). Benefits are... 1: LWO is a native file format for id4 that's extremely small and compact. 2: Lightwave saves to this format by the single push of a button (hotkey "s"). Achieving very quick testing iterations by using the console command reloadModels and tabbing between TDM and Lightwave till you like your result. 3: You're also chipping away at the brushcount by converting patches to models (always a plus!). 4: You can further clean up (and cull/remove) hidden faces that would otherwise be rendered were it a brushbased entity. I create the tiling textures in Substance Designer and then paint their coverage with Lightwave, so this is my exact workflow I'm using for my upcoming FM. I would be more than happy to do up a tutorial so other mappers could pick up the method for terrain creation. All you need is a working copy of Lightwave (I'll leave the method of acquisition to your discretion).

I'm more speaking from conversion in texture creation. I can't speak for anything the engine could devise. Most stencil brushes and detail maps work as heightmaps to start with which are then converted to normal data to combine with baked out normals. Now when I think of parallax affects, I primarily think of faked image warp/depth affects. This would be useful in some detail heavy materials that are trying to pull across a lot of protruding shapes. I don't ever recall it being a lightweight process though, so it would be overkill to see extensive use where it's not crucial.

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?