trevor

Having played with it a bit more it seems changing the FOV is not a great solution since it just tends to distort the image and make things look further away than they are. Interestingly, the speed effect can also be reproduced by making the window wide and short with better results. My screen isn't true 16x9, so I tried sizing the MBS window to those dimensions and it was quite a bit better. I notice you "zoom" the image with window height. That will cause different results for each user. It may be prudent to use a standard zoom and simply change the display extents instead to produce a more consistent user experience. Regards T

Something has always bothered me about the apparent speed of trains.... so check out this video...... The train is maintaining a steady 100 km/hr.. I did all the math, and took some measurements, so I know the scaling / speed is as I am demanding. At the start of the video the cockpit camera is selected.. note visually it just DOES NOT feel like 100km/hr. Actually it feels more like 50 or 60 km/hr. 30s in, the video switches to a camera attached to the front of the train with a wider field of view.... Note ,suddenly it now feels like you are going that fast. Me thinks the default field of view on cockpit cameras is a tad tight.

I don't see a plug-in command to activate/deactivate these....

My controller plug-in now handles animated bridges... I must say, that was a lot more complicated logic than one would think. Having multiple levels with multiple trains/boats on each level creates some interesting challenges with ownership of the animation itself and required that locks be shared for the rail traffic or water traffic. That's why I started out with the only double rail bridge in the catalog. It also didn't help that there is no program visibility to the actual current state of the animation. Even the animation started/stopped event doesn't distinguish between starting or stopping.... but whatever... work arounds abound Regards T

We could do with some parallel track versions of these... and possibly double ended lifts (dual and single tracked). Regards T

154 Fetch current animation position... String - Name of the object string (optional) - Name of the animation. If not specified, all animations are returned. Returns string - Name of the animation. . Floating Point - position of the animation between 0 (zero) and 1 (end) x Number of animations if name not requested in command. Perhaps return -1 if the animation is moving instead of a position too.. (trying to control a swing bridge.. cant tell if its open or closed.... )

Since this is a "work" computer I'm sort of stuck to the basic Microsoft crap for defaults.

Yes I know Curt, and none of them are great, but having the Google hook would be more user friendly. I do use chrome when I want to read the German posts, but I don't use it as my default browser for privacy reasons, so switching back and forward is a bit of a pain.

Hey Neo, Not sure if you control this site... but is there any way you can add the google translator widget, or similar, to this forum...

We really need events that occur when carriages connect and disconnect from each other.... something like <event_code>;<State 0=Uncoupled,1=Coupled>;<Rolling-stock_ID_1><Rolling-Stock_ID_2> Also need coupling state query command like this,,, <Get Rolling Stock Connections command code><Rolling_Stock_ID> <response_OK>;<front coupling connected to Rolling_Stock_ID or Null>;<rear coupling connected to Rolling_Stock_ID or Null> <Get Train Stock command code>;<Rolling_Stock_ID> <response_OK>;<Front Rolling-Stock ID>;<Next Rolling-Stock ID>;.................;<Last Rolling-Stock_ID> It would also be helpful to have.... <Get Front of Train XYZ Coordinates> and <Get Rear of Train Coordinates>

I added a workaround there since nobody seemed to answer the question

I have found the same issue through the plug-in interface, track events can be sourced from ANY, but only ONE, of the driven locomotives and appears arbitrary and will change from track join to join. The work around to this is to add a variable to the locomotives.... something like Train_ID = 1,2,3 etc. Obviously with the same numeric value on all locomotives attached to the same train. Then in the event handler "ANY train enters/exits track".events, add a qualifier condition that filters for $Trigger_1.Train_ID.

Oddly... Loco4, which is 2nd in line... never seems to report OOPS no wait the loco 4 one was me... I had 2 3s

OK so I thought I'd check out what happens to track events when you have more than one driven locomotive on a train.... It seems to still correctly issue enter/exit events for the front/back of the train as always.. BUT.... Which LOCO supplies the event seems to be random or arbitrary.... It's workable... but I just figured I'd point it out. Regards T

lol good point

Cool... I had not thought of that Still wont get me the which end is front and which axis = track axis though. For most stock that's the longest dimension, but, it isn't written in stone..

Yes, I too am hoping the new implementation is smart enough to include a destination point....

Sorry, but FPS and simulation rate is very important.... Since MBS handles events between frames, the timer expiration event is NOT handled until the next frame end. For fast frame rates that latency is a small time, but it becomes much more obtrusive the slower the frame rate. Worse, it is ALWAYS a positive number and accumulates your error over the deceleration steps. Similarly with simulation rate. At 4x speed the motion is effectively stepped at 4x train speed.. and any errors introduced by latency are thus magnified. Remember, the trains motion is NOT directly dictated by the frame rate, but rather, by some other clock that measures elapsed simulation time within the MBS code.

Well... interestingly, there are sufficient commands through the plug-in interface to permit code to know the linear lengths of all sections of track including each spur path so it is actually a fairly simple matter to calculate the linear distance from any point on the track to some other point on the track, all be it with a little pre-processing on start-up. There is even a nice command that tells you how far along a particular track the origin of a piece of rolling stock is and which direction it is pointing... However, the real killer is trying to figure out exactly where the front or rear of the train is on the track. Since the XYZ origin of rolling stock is not fixed, nor is it's initial orientation, you can't calculate where the load edge is relative to the origin without flipping a coin or two. And that's just for the locomotive.... multiply that by however many wagons or carriages you have attached and you quickly get lost in guesswork. Moreover... if you happen to pick up, or lose, a wagon or two on your travels (intentionally or otherwise...) there are no events to tell you that happened. I have contemplated making my controller run some code to place a copy of each populated rolling-stock, one at a time, on a known piece of straight track and use the distance measure command to check its extents from each end of the track. That, with that directional location command, would get me the information I would need for each vehicle. I'd make that part of the start-up code and store the results as variables in the rolling-stock themselves so I would not have to repeat it every time. Then I could compare ends with ends to figure out the trains. ... but... it's a lot to process on a heavily stocked layout and, with version 4 coming soon... I am reluctant to go that far right now. BTW: There IS a whole other way to do deceleration that does NOT involve timers at all. That is, if you break up your deceleration track into NUMEROUS small segments of known length, you can pre-calculate the absolute speed the train needs to be going when it enters each segment and apply it appropriately. Doing that in the EV though is a tad blah. If I were to try it, I would attach each speed as a variable to the track sections themselves so you can just fetch it as a trigger variable. I'd set those variables to be percentages and multiply that against the initial speed grabbed on entry to the first one. You will still have the same error issues at the fast end, but since the error effect diminishes with speed it should correct itself by the time you reach your target. However, bare in mind, more segments means more events / painting, which means more FPS lag. For ultimate purism, a combination of both methods might work best, i.e. decelerate with a timer down to an end section of multiple small tracks.

Hi Vermanus, happy New Year Your sample is cool and illustrates the issue nicely... I ran some data collection on it. Assuming you wanted to stop before hitting the next track... 60 FPS x1 Simulation : Stop Distance 15.77 mm Late +- 0.918 mm 60 FPS x4 Simulation : Stop Distance 31.24 mm Late +- 4.844 mm 17 FPS x4 Simulation : Stop Distance 161.76 mm Late +- 6.02 mm (Based on a sample size of 20 on each)

Yes indeed, and that "error" can be compounded at each sample point.... I am waiting with great anticipation and interest for the version 4 solution. That gives us deceleration and acceleration values to set, though if it is simply those numbers, there will still be the initial setting delay which is always the one with the biggest error.

Hi Easy, and "Happy New Year" With ANY sampled system like this, there are ALWAYS issues with control systems mechanics. That is, MBS steps the motion of the simulation at some rate, generating events at each step. however, in the case of a locomotive passing a sensor point, that can mean the loco can be anywhere from "right on the edge of the sensor point" to being "speed x step_time distance past it". Then add in the fact that your speed command also gets delayed in the pipe.... well you get the rest. From my own experiences with my controller I have found there is no real way around this. My controller uses the initial assumption that the event is worst case... i.e. the event is late, to calculate the deceleration rate. Furthermore, I calculate the deceleration to a target point short of a final stop point sensor track. I then decelerate to a "creep speed" around that point and let the locomotive slowly roll to the stop point. That method works most of the time and looks realistic. However, even with all that.. things can conspire against you. That's why you still need "Lock Tracks" after the stop point. I was also not sure if you were saying you were trying to use the frame clock to synchronize this, if you are.. don't. The frame clock is not directly tied to simulation time / distance. Use a timer instead. (By the way, a better way to do deceleration is to actually figure out the distance remaining to the stop point from the front (or back) of the train at each step and do the math using that value. Unfortunately.. I have yet to determine a fool proof method of determining that number under all circumstances that does not require way too many calculations.) Best Regards.. T

After noticing some nasty interferences with my longer carriages on my turns, it became apparent that the curve radii I am using are much too small. However, when looking at other users layouts in the forum, my curve usage seems to be about average (at least visually). Currently I am nominally using 300mm radius on my N-Scale layout, which, though looks good on the screen... actually only translates into a 48m actual radius size... way short of the typical 125m ( 781.25mm at Z). Furthermore, if I built that for real, the carriages would not go round those corners (see image). It's also not helping that the radii on the standard catalog parts are even smaller than that. I toyed around with using the larger life-like numbers but the layout would need to be HUGE to accommodate any reasonable amount of track pattern with a LOT of space between. That in itself is not an issue I guess, though filling the intermediate "white space" with toys would likely kill the frame rate. Is it better to ignore reality for the sake of a smaller, denser, more interesting layout, or is realism more important. I am wondering what the general consensus/ experience is on this is... Best Regards T Also wondering if perhaps there is something not quite right with the 4-axle carriage models...the concertina coupler visually seems a tad short.

I guess that's debatable... but my point really is the importer/application should take care of all that behind the scenes. No matter how the original designers 3d model was configured by each users model design preferences, the model library should remain consistent. I came upon the issue when I tried to write some code to figure out which carriages were attached to which locomotives by calculating the end locations of each rolling-stock object and finding the chains that way. The code works great when they are all originally oriented the same way and have their origins in the center.. but otherwise the math doesn't work. Now the only way I can figure to do it is to add some major extra code to pull in the library object as a new instance, surround it with planes, use the distance finder commands to measure its extents, delete all that, and then figure out conversion variables to apply to the math. Repeating for every object. But even then I would need to make some major assumptions.. e.g. the longest size = track length, and which end is the front would be a downright guess. I am really wondering how NEO does this in his code. Either he has access to a LOT more model object properties we can't access, or his layout start-up math must be extremely, and overly, complicated... Yes that is a significant issue, and was why I mentioned it needs to be corrected, if it is, in the next release, where, presumably, opening V3 models will cause significant data manipulation to the design file anyway, so doing the math at that time to adjust the current positions to the corrected library models is doable.

Yes, I figured it was probably something like that. Though, with my minor attempts to create my own models, scaling on the import seems to be a "difficult" concept to control. (I added a waitress to my private set from sketchup a couple of weeks back.... she started out being about 5miles tall LMAO.) I think some additions to the importer are warranted to allow you to set the initial size / origin / rotation AFTER the 3DS model file is read. In particular, for rolling stock... identifying the wheel distance ought to be sufficient for setting the scale. However, generally as a user contribution style application, there ought to be some guidelines and moderator(s) verified rules for folks to follow to improve consistency.