Epifire

Yeah it didn't seem to have any affect adding a negative spawnarg to the mover. It just created a crash if I tried to input them via script.

These would certainly benefit highpoly sources, how big would you plan them to be? I mean you could get away with a whole set of fist sized pieces that have a little bit of edge details (to denote depth) but use a detailed alpha cutout to show the holes in the middle. It would require the least amount of supporting geometry that way but it sounds like a fun day project to me.

Alright so I'm just taking this one on the simple route, as I don't wanna cut it but I don't see any practical means of resuming (or reversing) a spline mover. I'm content with a two button call system but I wanna make it visually informative as well as fool proof. Current problems are... Track reversal: This I may have covered but not thoroughly tested for a fix. The problem lies in the fact that when switching to the identical spline (ran the other way) is that the mover will flip to face it. This is an inherit problem with how the spline angles are implemented. I think it can however be overcome by toggling in a identical tram model that has inverted forward axis. The result should be instantaneous without a noticeable hitch. Even if it is slightly more work. Player Still Dies a Lot: So it's not exactly unheard of but on the same note as the last problem; when switching directions, the, "flip" tends to kill the player for some reason. This may be given that I've been testing with, "4posterbed.lwo" and you can't fully stand in it. Possibly just more headroom is needed when I make the actual mesh so that there is standing room. Button Active States: One track is ran on a forward button and the other track is ran on the backward switch. These buttons need to have two conditions to work flawlessly. Firstly they can only trigger once (when idle at the spline start). They cannot be re-activated during transit other wise it will teleport to start as well as kill the player. I think if done right, either button will trigger once and will reset the other button when the the tram has come to a stop (possibly fired from sys.waitFor in said button script?). Done correctly it should be able to flipflop between the two modes whenever you reach the other platform. Call Buttons: This should be extremely similar if not even using the same scripts derived for the aforementioned button functions. The only condition here is that the call button must not be able to call the tram until it has reached the opposite platform. If I can iron out some example lines for the last two problems here, I think that'll be my biggest worry out of the way.

Might I also include the war on volume for this debate? https://en.wikipedia.org/wiki/Loudness_war Sorta speaks for itself but it's a very sad, very true facet of listener life now.

Oh? For some reason I thought it was already added to the core mod. Should definitely be the default in water usage. Though I'm wanting to create larger waves in my current project, (like the oceanic based demo you made) this is still a worthy addition for standing water.

Awwww yis! That list is exactly what I was needing. Already dug out a great find from that. Turns out you can disable just the roll factor in a spline mover if you just add .removeInitialSplineAngles (instead of disableSplineAngles). That's one annoying thing fixed. Not seeing a lot else relating to movers thus far. I think I'll try the basic two way setup first, and see what could be possible to add after that. There is a stop command relating directly to splines, but I have my doubts as to whether it will just restart the path if enabled again. I'll have to try and bind some buttons to my test mover and see if I can actually continue a path.

Honestly the syntax is what I'm having the most difficulty with right now. I don't fully understand what commands are all available to utilize in a format the game will understand. Usually there's some sort of fallback archive I can find that documents available functions and brief explanations (much like the mtr documentation) but alas I can find none. If all else fails I may very well just have to settle for a single trip button loop. In this scenario we'd just have one throw switch in the control panel that would take you all the way to your destination. Upon arrival the button would toggle over to another script activation, so when triggered again you'd just hop on an identical path that's just the same path but reversed. If there was some sort of .startSplineReverse command that'd make that whole bit easier. Just have it check for position and kick in the reversal script if the tram is at end of the spline. Again I don't even know if that function exists so I'm flying blind. At worst I'd just make the duplicate path running backwards, but I'm really trying to save that option as a last resort if there's no other option.

I hadn't thought of a three stage switch before. It looks like these all check an order, so couldn't the forward/backward modes toggle back to the brake if these values were adjusted? That essentially would be what we need. Visually it would make sense too because you couldn't put it in a different gear without tripping the brake first. For the brake I'm very curious as to how that could work. Everything I've heard so far points to the fact that it needs a solid defined point of origin to end a script on. Whereas I just want to be able to halt it on the fly. This is the current little bit of script the spline mover type requires for one way direction right now. void spline_mover() { $mover_object.time(30); //how long object take to move along spline $mover_object.accelTime(2); //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($spline_path); //starts mover moving along spline sys.waitFor($mover_object); //wait for func_mover to finish moving along spline before doing anything else }

As long as the rails aren't bizarre the curves should be able to be tweaked to match pretty easily. My only real concern was the unpredictable amount of roll axis tilt that occurs on hard turns along an incline. I had tried running $mover_object.disableSplineAngles(); but that seems to disable all axis of rotation. Pitch and yaw are the only two axis that the spline seems to handle in a reasonable fashion. However if there's not a lot of control options there, I can work around the problem of intense roll if I keep inclines and turns separated. Right now though, I'm just trying to get some usable functions for the buttons fleshed out. That's the main running theme that the tram must have to function. After that I'd look at an automatic door and wheels, since those are more a last step. I was really wanting to smartly include the tram for accessing, what would otherwise be out of reach areas. So that's why the stop and start buttons are so important. The key to their functionality is that it can't change directions on a dime. Example: if moving forward the reverse direction lever would check to see if stopped before being able to move to the opposite end of the track. Maybe insert a metallic grinding sound affect on a false attempt.

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.