Epifire

I could do that. At this point I'll probably just upgrade my version to the current DR release and report again if I have this problem. At the very least I'm hoping we can log the fix (or at least catalog the bug) for future knowledge in that regard.

Okay this helps tremendously. So far I've corrected the issue of the player dying to collision interference. There's something still wonky about the camera. Right now (with this script) it just kicks the player out, runs the spline path and then places the player in the camera position when finished. I've been trying to move the lines around but it either does this or nothing at all. void spline_path_forward() { $tram_dismount_1.activate($player1); //kicks the player away from the tram to avoid collision smashing $mover_object.startSpline($spline_forward); //starts mover moving along spline $tram_camera_1.activate($player1); //switch view sys.waitFor($mover_object); //wait for func_mover to finish moving along spline before doing anything else $tram_camera_1.activate($player1); //switch view $tram_dismount_1.activate($player1); //kicks the player away from the tram to avoid collision smashing } void spline_path_backward() { $tram_dismount_2.activate($player1); //kicks the player away from the tram to avoid collision smashing $mover_object.startSpline($spline_backward);//starts mover moving along spline $tram_camera_1.activate($player1); //switch view sys.waitFor($mover_object); //wait for func_mover to finish moving along spline before doing anything else $tram_camera_1.activate($player1); //switch view $tram_dismount_2.activate($player1); //kicks the player away from the tram to avoid collision smashing } Getting really close now. Everything in my alterations really seems to depend on the lines whether it's ahead or behind the sys.waitFor function. It's like the camera can't activate ahead of it in the timeline. ALSO, Obs while we're on the discussion of cameras. Would the keyhole-look mechanic you came up with be compatible for a vehicle attachment scenario like this? That would be ideal compared to the locked camera placement I'm working with now. Not the foremost concern but it would definitely be a much better option if possible.

MEANWHILE, BACK AT THE RANCH Okay, so I did a little bit of comparison checking. From what I'm gathering, the issue lies in how DR is saving the map. I looked at proper compiling maps and realized that the worldspawn is always slotted in at the beginning after entity 0. I rearranged the data in the correct order and it all works fine now. If my case may help any digging into this problem in the future (should it arise) this occurred on DarkRadiant 2.1.0 x64 I may try and update to the most recent version to see if this still happens. As far as I can tell it's a sorting issue that gets botched, as to what causes it I can't really tell you. Hope this can help someone else in the future tho.

So this seems to something I've only ran into since 2.05 dropped a while back but is happening often enough to be problematic. Sometimes it can be a fresh map save, other times I can be working in the same map for weeks before this pops up. At some given point when I testmap (or dmap) I get this error, Entity (number) has surfaces, but no name key This in fact will always point to the worldspawn notation in the .map file and will shift entity number depending on what ever else is crammed in there. I don't know what this information is declaring (so I can't do much with it myself) but this is what my current test map had under that bracket. It's a simple box map so the six primitive definitions are all that follow under worldspawn. This happened in my ongoing tram test map. Copying all of the tram components out into a new space didn't seem to help either. In the opposite affect, deleting all tram components (leaving only the box) only accomplishes the same thing. So how does one go about fixing this?

So there seems to be a strange problem with the camera I'm porting the player view to while the tram is in motion. When I hit a button (forward or backward) the screen flashes into the set camera and then instantly returns back to player1. Stranger still, when the tram completes it's assigned path, the camera will become active (once the tram comes to a halt). If I noclip I return back the the original player1 position, though I have no movement. If I'm in range of the buttons when froze I can frob the buttons to run again. If I switch back on the second trip around the camera works flawlessly. So why is it behaving so strange the first time? Here's what the script looks like... If I get this part working, I just need one more script that teleports the player off to the side of the tram when ever a button is pressed and when it comes to a stop. I'm not all sure as to how I kick the player out with a info_player_teleport yet, but I think that should be easy once I can figure out what can trigger it automatically. After that I'll worry about the active/inactive button flipflop modes.

Pst, a modified func_cameraview with mouse look implementation would be mint!

I actually didn't see that part. Navigating the old saved pages was a little odd how it was all organized. It kinda flew past me when I was asking around but I realize now that I don't have to worry about the duration of the trip. This being because I'm using cameras and player interaction isn't possible. So that leaves the last bit of button sorting. Can a button disable itself while enabling the other? It would just need to be in one press, as you wouldn't be able to use the other button until you came to a stop. It also would be worth mentioning that a negative press (inactive) would be great to have a snd attachment of some kind. The sound of course is extra fluff but in the end result I want to communicate to the player as best I can with glowing skins and so on.

If it were an lwo, or obj I'd fix that up for ya. ASE is actually the most difficult to find proper supported plugins for with my software.

Right now I've been able to stabilize the path by making turns and inclines separate. I would like to point out that removeinitialSplineAngles() and disableSplineAngles() behave very differently. The only reason I wasn't able to use removeinitialSplineAngles() was because it inverted the incline angles when running the reversal spline. That is a really interesting usage you came up with. I feel like mine is much more simplified since it's just a two way mover. What I'm shifting my focus to now has been making sure the buttons behavioral settings are correct. Say the button to start you out (forward) should only be able to trigger when at it's respective tram garage. When you reach the end of the track, the other button (backwards) should then be available. Neither button should ever be able to work at the same time and they can only fire once per trip.

It's more of my tram research I've been looking into. The problem lies in two things, that the player bounces pretty unpredictably on turns and that changing directions kills the player. My initial thought was to bind a camera instead and then possibly define a dismount position to teleport the player when the mover comes to a stop. I guess the only other thing I wonder is if there's a way to get mouse look on top of a camera position. Otherwise that would be a sure way to solve it.

Hey does anybody know a good method for binding the player to a mover via a trigger or something?

Couple that with the gutted lore, character progression and mixed with bad controls I can still agree.

I'm rereading my post and I think I forgot to mention that I had to create an identical spline (a backwards track) to run the opposite way. See as far as I know, the splines only have a starting point. From anything I've tried, they don't seem to support and kind of inversion methods. This runs in line with what Obsttorte was saying about using a spline for what it wasn't meant for. And believe me if I could find a smart and compact way for node based pathing to blend turns and pitch, I'd use them in a heartbeat. So I'll back up a tad bit and explain what's causing that whole flip dilemma... .removeInitialSplineAngles() This command is perfect for taking roll out of the func_mover_amodel. However, it has the unforeseen side affect of inverting pitch axis. Meaning you flip the wrong direction when moving on the same path (in reverse). This however is remedied by commenting out the, removeInitialSplineAngles() but then we return back to unpredictable roll on turns as well as the model realigning to face the newly introduced spline direction. My untested theory is that it may be resolved if the same model is mirrored (saved as an additional mesh) and toggled back and forth when either matching courses are plotted. It's too bad there wasn't a ready made command to just run a spline backwards, but I supposed floating cameras in DooM3 might have looked odd going the wrong way.

Yeah np, hope you get that all worked out on your end.

What kind of results are you getting? I copied that skin into my WIP skins folder and it seemed to work fine. Although solid lines don't seem to hold up so well with this set, it still worked fine. I'd check and see if there's something up with your folders on your install. Cause I didn't have the change anything in the script to make it work.

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.