trevor

Working on my signalman plug-in. I managed to get 8 trains automated on a figure-8. I figured I'd share a video..

Sigh... my bad... Apparently I had a slew of unnecessary variable set commands in the Q I didn't know about... I hate multi-threaded code. Sorry for wasting your time again.... thanks for checking though

hmmm.... weird then... 200FPS.... wow.. I get that if I zoom out to cloud level in 3D... then it reads at 250ms. Do you have a dot net system over there... maybe u can run my code in the IDE and see if it's just my system.

PC_Test_6.mbp

btw response time drops to close to 1 second if I make the trees invisible.....

Ya sending as a group. FPS is a meagre 25ish with all those trees even when the simulation is not running.

1. I am sending a group of command 360s, to find the location of rolling-stock at start-up of my plug-in. It's only 31 rolling-stock objects with 128 tracks total but it takes 3.5 seconds to return. The time was fine before I added a bunch of trees and other decorations to the layout. 2. For some reason when I run Internet Explorer when my project is loaded it pretty much kills my computer. Though I guess the latter may be something I am not cleaning up right in the debug environment.

And I'm certain a ContainsKey is a lot quicker than all the overhead associated with transmission and reception by the time you add in all the thread wake up latencies.

Yes I do realize that NEO, but sending receiving and filtering through a bunch of "noise" seems counterproductive if it can be done at your end easily enough. I mean one of us has to do it.... and the CPU can only do so much...

While you have the hood up.... New Command : Filter Events; <OBJECT>;<OBJECT>;...... <OBJECT> Create a dictionary for each port, Set the dictionary to the list values if you receive this command. Only send events for the objects listed in the dictionary to the current port, or default to ALL if the dictionary is empty. This will significantly cut down the port traffic and make both ends more efficient. My train controller plug-in works pretty well at the moment, but will be less so if the user has a slew of other events happening from the EV code, or there is another plug-in running. Note: Certain events should not be filtered. e.g. Project Close, Load and the like. Again... IDs would be better than names as an option.

<<<<<<<<<<<<< LATEST EDITION >>>>>>>>>>>>>>>> Fastest yet... Command strings are now sent almost immediately without waiting for responses to each one. Responses are handled later by a separate thread. Bottleneck is now the MBS end.. MBS_TEMPLATE_20161101.zip

Nein

LOL .. it might be if the engine didn't end up inside the tender... doh.. but something to bear in mind for some hidden piece of track somewhere to turn a loco

Hi Lys, Derailers and run-off tracks exist in real life, but like the lock-switch in model layouts, they really are a method of last resort. They are usually found on long inclines where a break away carriage can cause havoc if allowed to accelerate back down the hill. In a perfect world you would be able to control your rolling-stock so well that lock-switches would not be required. However, things conspire against you, and occasionally your computer or the software will hesitate so long that the appropriate commands to change the engine speed or whatever will arrive too late. That can of course cause things to go rather out of control. Therefore it is prudent to include lock switches as a catch all if you know what I mean. Despite the fact that there is a significant added overhead in controlling them, it pretty much guarantees you a more stable system. Another object that is used far more widely in the real world is a wake up alarm. A physical device between the tracks that trips an alarm in the drivers cabin when the train passes over it. The driver then has a short time window to cancel that alarm. If they fail to do so, the engine is cut and the brakes are automatically applied. You can implement a similar safeguard in MBS by having a short piece of track before the lock switch and an appropriate event handler to set the engine speed to zero if the train enters it while the switch is closed. But again, that method only works if everything happens in time. As a modeller, it's considered bad practice to rely on the lock switch alone to stop the trains. The goal is to get it to work so that the trains never hit them under normal conditions.

I found this double switch setup works well, and blocks in both directions. Position 0 is pass, 1 is lock.... Odd thing too.... positions 3 and 4 flip the engine....

Latest Edition : Now with non correct thread releasing waits on stream reader. MBS_TEMPLATE.zip

You can attach one camera to another but I'm not sure that will work for your particular desire.

Yes, that's why I tried to make the class self contained with a simple interface outside of the main form. And don't knock yourself down like that, I'm always learning new stuff too, even after 40 years. In fact I picked up a couple of new new tricks writing that class. If you need more help feel free to PM me or even Skype if u have it.

Yes, I kind of wish I had left that menu item out. Fixing duplicates is only really needed if you have multiple objects with the same name that have variables attached. You could have a million trees with the same name so it would be a pain to sequence through them all and pointless since I can't imagine why ANYONE would add a variable to a tree.. LOL However, I will look at using my new command group handler for that, though I am not sure it would help much since changing an objects name causes MBS to do quite a bit of work to fix up any event handler references. OK so bad names are anything with a space, period, semi-colon or left or right brackets.. for obvious reasons... Bad references can be misleading. For the purpose of the editor I assumed that most text variables would be used to "point-at" some other object. Indeed I was using them for that purpose a lot. As such, the editor will highlight text fields that do not have an object with that name on the layout. If you are using the variable for some OTHER textual meaning you can safely ignore the warnings. I found it irritating that things did not run right because I had some typo like Signal = Singal_42 somewhere....and had to go hunt for it... hence the feature. BTW... if you change the name of objects referenced in variables the editor will also update the variable references.

Slightly better version that demonstrates using the block and wait commands. MBS_TEMPLATE.zip

OK I took some time to clean up and add comments to the class and make a nice simple template example and layout. Unzip the file somewhere, and load up the included MBS example before you run it. MBS_TEMPLATE.zip

Hi Easy, Hmm... I could take a little time to do that sure. Yes, you are right, I started out with your template. However, I found it a little slow for doing real time simulation control, so I fine tuned it a bit to improve the performance and add a few new features like prioritized command queues and asynchronous sending. Latest edition also greatly improves block command handling. Regards Trevor (BTW: Been coding for 40 years.. so ya... it's not my first time LOL)

Note the synch one could be as described, i.e. plug-in driven, OR it could be implemented from the MBS end, i.e. have the Synch wait command cause the simulator to regularly send an event that needs to be responded to using the synch command within a time window or the same soft pause will occur. Both methods work, whichever is easier to implement. The current one sided control method is dangerously lacking.

I'm sure there are lots but the following would be EXTREMELY helpful. 1. EVENT Terminated Stream--- AKA "Sayonara": Would be nice to gracefully shut down the plug-in when the MBS application quits. 2. EVENT Simulation State Changed : An indication that the user paused the simulation, and or changed the simulation rate. 3. Coupled State (Augmentation) : For a particular rolling stock, getting coupled state should include front coupled to rolling stock "A" and rear coupled to rolling stock "B" 4: Train Stock : For a selected engine, return a list of the rolling stock attached AND the total length of the train in mm or whatever is set. 5: Synch Wait and Synch Commands : A command to tell the simulator to wait for regular synch commands from the plug in, with an associated synch command. The idea being the simulation would auto-pause if the next synch command did not arrive within the a time window, and auto-continue at whatever rate it was running when the next one arrived . Time of the window could possibly be set by a Synch Wait command parameter. For simulation plug-ins that would help keep things In tune, especially when windows unexpectedly decides to go do some high CPU chore, and would really help during debugging sessions when you hit a break point. 6. It would ALSO be REALLY nice to be able to set Acceleration and Braking rates as well as just speed target or absolute. 7: And as I mentioned to Neo before, A command to switch modes to use object IDs instead of Names. 8. Oh one more... MARK AS CHANGED... You can make a lot of design changes through a plug-in that never get saved because the user does not get warned to save them when they close the layout. It might also help if this command also added a state to the undo buffer. (The latter also raises the possible need for an UNDO performed event.)

It's not so much that Curt, it's not obvious from the track editor, but each track section has an inherent "direction". That feature is not really accessible from the application itself, but is from the plug-in interface. Other information like how far along a track an engine is can also be read from there. Obviously.. knowing which direction the track is vs the engine is required if you want to do some higher order functionality...