QuickPortalManagerV3 by pguy

[Dap]

I am of the opinion that pguy's QuickPortalManagerV3 is the only portal controller to use. It is solid and so versatile with the ability to schedule trains over a 7 day period.

However, I have always been curious about the Output and Input Queues, so I asked Pierre about them. He is quite busy with his job at the moment and does not have time to write a manual, but he gave me the short version which is quite interesting and opens up all kinds of possibilities for operations.

From Pierre with his permission:

" . . . when you associate in QuickPortal Manager a global name to a portal as an outgoing queue, every consist that leaves through this portal has its consist definition saved in the queue with the time it left through the portal. Before quiting your session, you need to save your session so that all the queued saved data is then saved in the global queue library.


If in another route and session you associate the same global queue name to a portal this time as an input queue, when you will start your session, QuickPortal manager will read the queue saved data and will schedule trains coming in through the portal at the time saved in the queue and with the same consist definition.


So globally, the queuing system enables to transfer consists from a portal A in session 1 on route 1 to a portal B in session 2 on route 2 keeping consist definitions, driver, odometer data, train variable data, ... and with incoming time in session 2 route 2 being the same as outgoing time in session 1 route 1. The queuing system works also with two portals on the same route.


There are a few options to add a delay between outgoing time and incoming time, to empty or fullfill product loads, to tranfer or reset odometer and train variable data, ... "

Is this awesome or what? Opens up a whole new world of possibilities in Session structure.

David

 

[Yorkshire]

Thanks Dap for putting this up - I agree with your sentiments. I only use Quick Portal Manager now as I can instantly call up consists to arrive at my terminus as well as running it in a timetabled fashion. It is brilliant.

Regards

Yorkshire

 

[Lots_Trains]

Hi Dap

Yeah its an awesome peice of kit, I was fortunate to involved in the development of the thing.

Another couple of things it does, It transfers odometer, tripmeter, and speed profile data through the portal, also the Driver.

Also if you use Copy Commands, any commands that are not executed before the train goes through the portal are present when it arrives out the next portal. Qportal is so well setup I can start a train off on one map and have transfer through 4 other maps without having to touch a thing eash map with it own complicated set of copy commands. The train arrives on the new map the same time as it left the old map, its just one big world.

Another cool function that is available but not documented but I can't wait to get my hands on is, Train variables are also passed through the portal but I'm not sure how this is done.

It is one powerful peice of kit, top work Pierre!!

(edit)Also allows you to name train with a designation, that will also transfer through the portal, its does get really confusing with lots of trains, and this helps emensly, still needs to have a few more features to this, also a mission code coming a future version

Cheers

Alan

 

[kkopchynski]

Hi Dap

Yeah its an awesome peice of kit, I was fortunate to involved in the development of the thing.

Another couple of things it does, It transfers odometer, tripmeter, and speed profile data through the portal, also the Driver.

Also if you use Copy Commands, any commands that are not executed before the train goes through the portal are present when it arrives out the next portal. Qportal is so well setup I can start a train off on one map and have transfer through 4 other maps without having to touch a thing eash map with it own complicated set of copy commands. The train arrives on the new map the same time as it left the old map, its just one big world.

Another cool function that is available but not documented but I can't wait to get my hands on is, Train variables are also passed through the portal but I'm not sure how this is done.

It is one powerful peice of kit, top work Pierre!!

Cheers

Alan

Hi Alan,
This sounds like what I am doing with iPortals, only way better. Does this rule work with iPortals or is it essentially giving (within computer) iPortal function to the other portals?

Thank you,
Kevin

 

[Lots_Trains]

Hi Kevin

I've never used it with iportals, it dosn't have the function of sending trains via the web, it was considered doing that at one stage, but it will do everything a iportal way better with in the bounds of your own computer.

I use Standard portals

Cheers

Lots

 

[Paulsw2]

....He is quite busy with his job at the moment and does not have time to write a manual....

That's a shame. How are we meant to use this if there are no proper instructions for it? Sorry to be snippy, but I see these rules and commands and stuff to build sessions going up on the DLS (and I even download some of them), but they are very rarely properly (and accessibly) described or explained and therefore, I suspect, very rarely used by people other than those with IT backgrounds.

Building sessions is one of the hardest things in Trainz and we get very little help with it from N3V or creators of rules or commands.

Paul

 

[hminky]

QuickPortalManagers were all in RED in surveyor so I went to ContentManager. There was an update indicated.

Now the Quick Portal Manager is missing:

"Unknown Location: <kuid:61392:4000>"

And is faulty and won't work.

Harold

 

[Lots_Trains]

Yup thats quirky 2010 for ya "location unknown" do and EDR or 2 and see in that brings it back. if not try and somehow download it again from the DLS

Paulsw2

Sorry Paul its always been like that for session commands very little documention however some guys do really good documentation, so its just trial and error. Best thing is to ask on the forum

Cheers

Lots

 

[hminky]

QuickPortalManagers were all in RED in surveyor so I went to ContentManager. There was an update indicated.

Now the Quick Portal Manager is missing:

"Unknown Location: <kuid:61392:4000>"

And is faulty and won't work.

Harold

Found everything on DLS, have to delve into the config.text. The files: navigatetotrackmarklist, etc. are now newer.

 

[Dap]

That's a shame. How are we meant to use this if there are no proper instructions for it? Sorry to be snippy, but I see these rules and commands and stuff to build sessions going up on the DLS (and I even download some of them), but they are very rarely properly (and accessibly) described or explained and therefore, I suspect, very rarely used by people other than those with IT backgrounds.

Building sessions is one of the hardest things in Trainz and we get very little help with it from N3V or creators of rules or commands.

Paul

Paul, Don't be snippy. Most of us have lives outside of trainz and these major assets we create are done out of love for the hobby. But sometimes life gets in the way and things don't get finished on schedule. It's not like you are paying us content creators to create these things for you. Please approach the situation with more of an attitude of gratitude for the assets that are available. Rather than complain, ask if anyone can explain.

And you are right about session creation. It is difficult. And it does help if you know a little about programming. I asked N3V/Auran to create a Forum catagory specific to Session Creation. They just blew off my suggestion.

So, we could start a thread here devoted strictly to Session creation or go to another Forum Site where we could have more control over the forum and have multiple threads addressing more specific issues.

When it comes to QuickPortalManager, I thought pguys brief description was rather comprehensive and quite understandable. If you don't understand some specific aspect, ask a specific question.

David

 

[pguy]

Documentation for Quick Portal Manager rules are just now under progress. Rule screen capture illustration has been done last week end and beta version of the documentation should be available in 2 - 3 weeks time frame in both pdf and online format.

Hope this will shortly help to use the rules.

 

[kkopchynski]

OK, here's a specific question: In a running session, I would like to be able to get a train from one input queue, then switch the portal to a second input queue and get a train from there. So far I have had no luck at this. After the first train, clicking any controls on the portal gets a quick flash of the description label but no other response. I am running 2009 SP4 and CMP shows no errors on the asset.

Has anyone done this with this rule? I will keep experimenting but I would appreciate anyone's input from their experience.

Thank you,
Kevin

 

[pguy]

OK, here's a specific question: In a running session, I would like to be able to get a train from one input queue, then switch the portal to a second input queue and get a train from there. So far I have had no luck at this. After the first train, clicking any controls on the portal gets a quick flash of the description label but no other response. I am running 2009 SP4 and CMP shows no errors on the asset.

Has anyone done this with this rule? I will keep experimenting but I would appreciate anyone's input from their experience.

I don't know if anybody has already tried input queue switching, but what I can say is that the rule has not been designed with this option in mind. When looking and thinking about the current script code, there is no specific reason why it should not work. You may have some side effects or pitfall if you have in two queues some consists rescheduled at the same time as portal can't emit two trains at the same time. The script code has been protected for this type of situation, which is considered as an internal error and should not happen in a one queue context, and will skip the second, third, ... consist entries scheduled at the same time than a first one ...

Except this problem, I don't see any reason why it should not work. If I got this afternoon some free time, I will also do some testing and come back editing this entry.

RESULTS FROM MORE TESTING

I confirm that there is no problem with switching input queues in a portal definition in driver mode. There is a short latency as the driver mode interface updates only the input queue field and reading the queue input is done at next rule clock period (input queue is read with a latency between 0 sec. and 15 sec.). But on my tests with two input queues, both input queues were read one after the other and all the trains were correctly scheduled.


Have a nice day.

Pierre

 

[Paulsw2]

Paul, Don't be snippy. Most of us have lives outside of trainz and these major assets we create are done out of love for the hobby. But sometimes life gets in the way and things don't get finished on schedule. It's not like you are paying us content creators to create these things for you. Please approach the situation with more of an attitude of gratitude for the assets that are available. Rather than complain, ask if anyone can explain.

Ok, I am sorry for being snippy, but I'm often struck by how people spend time creating rules and commands and then don't communicate how they work properly for the benefit of the uninitiated (ie. people like me!) thereby undermining their use. Your idea for a section of the Forum dedicated to session creation seems like a good idea to me, so it's a shame N3V knocked it back.

Documentation for Quick Portal Manager rules are just now under progress. Rule screen capture illustration has been done last week end and beta version of the documentation should be available in 2 - 3 weeks time frame in both pdf and online format.

Hope this will shortly help to use the rules.

Thanks very much Pierre, I look forward to seeing these.

Paul

 

[pguy]

Hi every body.

Beta documentation for Quick Portal Manager should be now available at http://trainz.guynet.org/files/documentation/quick portal manager rules.pdf
Other rules and driver commands documentation should be available in a few weeks.

Thanks to Lots_train and Dap for their help making this documentation better.

Have a nice day.

Pierre.

 

[stovepipe]

Thank-you for the documentation and the excellent rules.



regards
stovepipe

 

[mtldrm38]

Im a bit lost on missing kuids (4) for me off the DLS
I havent had chance to dig deeper on em yet but curiosity has me askin first is this a problem in 2010 only?

 

[pguy]

All the kuids required for QuickPortalManager V2 or V3 have been uploaded and are all available today on DLS. If you have any missing kuid, please let me know so that we understand what is the problem with DLS.

Regards.

 

[kkopchynski]

RESULTS FROM MORE TESTING

I confirm that there is no problem with switching input queues in a portal definition in driver mode. There is a short latency as the driver mode interface updates only the input queue field and reading the queue input is done at next rule clock period (input queue is read with a latency between 0 sec. and 15 sec.). But on my tests with two input queues, both input queues were read one after the other and all the trains were correctly scheduled.


Have a nice day.

Pierre[/quote]


Pierre,

Thanks very much for you interest in this. I have rerun my testing and I confirm your findings. My problem was caused because I forgot the route I was testing had a different portal manager already. I bet that was interfering. I tested on other routes with no other portal managers and it works fine.

It appears that once a train is in an input/output queue, it will stay there even if emitted by the receiving portal. I also have queues from my original tests, even though I deleted the rule from that route and all the saved sessions, and no currently managed portal uses those queues. Is this correct behavior?

Thanks also for the manual.

Kevin

 

[pguy]

My problem was caused because I forgot the route I was testing had a different portal manager already. I bet that was interfering. I tested on other routes with no other portal managers and it works fine.

Portal manager rules give orders through some standard portal interface to the portals to emit trains and traps messages from the surveyed portals to catch outgoing train composition. You can have on a route several portals manager only if each portal manager manages a separate set of portals.

It appears that once a train is in an input/output queue, it will stay there even if emitted by the receiving portal. I also have queues from my original tests, even though I deleted the rule from that route and all the saved sessions, and no currently managed portal uses those queues. Is this correct behavior?

Yes it is the designed behavior. This behavior is needed to be compatible with normal session save/restore process. Input/output queues are located in a global library (Quick Portal stack manager library ) which saves/restores the queues in trainz global context at each startup and when leaving trainz.
When you rerun a session from a previously saved session, local session data is restored but not the global input/output queue stack. So to be able to rerun a session, input queues are not emptied when read, but the session component in charge of reading the input queue remembers in the session data what it has already read from the queue so that in case of a later save/restore it skips the already read data from the queue. Output processing is also designed to be save/restore compatible as it stacks inside the session data all the queue data from the begining of the session and during save processing will first clear the queue and rewrite all the queue data from the begining of the session.
Doing the things this way, you should be able to save/restore a session with output/input queue and rerun the same scenario with the same data sent to the queue and read from the queue.
The counterpart is that used data remains in global quick portal stack library even if it is no longer used and to enable to clear this remaining data, under trainz global option menu you will see an entry for the global quick portal stack library where you have some links to clear manualy the no longer used queues. Sorry I forget to give this information in the documentation, I will make a documentation update this weekend about this option.

Hope this explains better how the queues work with session save/restore.

Have a nice day.

Pierre.