Clearing and Deleting Queues From Quick Portal Manager V3

[KonstantinMMRR]

I have been using Quick Portal Manager Version 3 for quite a while. I have found that I cannot clear or delete queues. When I clear them in driver mode, the consists suddenly reappear later on. In Driver or Surveyor mode, under "Options", I select "Quick Portal Manager Stack Library." There are places to delete and clear queues. Whenever I try to click on them, they do nothing. Nothing ever gets deleted. How can I delete queues and clear queues? They are now getting so filled up that they are difficult to manage.

Thank you
Dean

 

[kkopchynski]

Hello,

I will add that I use QPM a lot and I am seeing the same issue. I thought it might have been me but perhaps not. Yes, the data for these queues seesm to be buried somewhere. Renaming the queue does not help. The trains from the old-named queue end up in the new one. It appears there is only one queue per portal; you can name and rename it, but there is only one. I also have deleted queues from the options panel or in QPM, but when the next train goes through the portal all the old ones reappear. Sometimes you cannot delete a queue even though it is empty. Data seems to be kept somewhere other than the area affected by the Stack Library.

Recently I have started to have portals dedicated to each other on different routes. When I am careful to delete the consists and empty the queue after emitting the consist, and before saving the session, the queues seem to work better. Usually I do not see the older consits when a new one goes through in this case.

Thanks in advance to anyone who can shed any light on this.

Kevin

 

[KonstantinMMRR]

Kevin, you have decribed my problem exactly. There must be some kind of a bug in it.

Dean

 

[Lots_Trains]

Hi Guys

If you want to delete the queues in the portal, go to options in the top menu, and look down the list for "Quick Portal Manager Stack Library" and delete the queue there. There is also a clear queue option in the portal manger window, but you have to do a save after doing that to clear them from the globalmodule file.

If you want to get really tricky with the queues, you can fined them in the UserData/settings folder, the globalmodle file is where all the queues are stored and you can manually manipulate them there. Beware don't stuff it up !!!! if you do just delete the globalmodule file it will recreate itself just not qportal queues you had in it.

Hey Kevin nice one using the Qportal between maps, it was the original idea behind Qportal. New version coming along soon.

Cheers

Lots

 

[KonstantinMMRR]

Lots

What you are referring to is exactly what I am referring to also. I know about both of the ideas you mentioned, but neither of them work. Using the options menu and quick portal manager stack library, I can see a list of portals and the numbers of trains queued. I cannot do anything to the list. There is nothing to click on.

Dean

 

[Lots_Trains]

Hi Dean

Heres is a couple of pics of the menus showing where to clear the queues, they are working perfectly for me. Now these are queues from other portals, I'm fortunate enough to use 2 monitors and watch the globalmodule file where all the queues are stored and it clears them when the clear button is pressed.


All I can think of is you are using Consists from the Surveyor menu and they are stored as kuids and have to be deleted in CM. But I don't used pre existing consists all my stuff is one portal to another.


What version of QPM are you using (the end number on the kuid)

Cheers

Lots

 

[KonstantinMMRR]

Lots

Your pictures look just like mine do. But when I try to click on them, nothing happens. How can I find out what the Kuid number is on my Quick Portal Manager? Or, maybe a better question is: How can I update my Quick Portal Manager.

I am a relative novice with Trainz. I don't do anything unusual or complicated with it. All of my consists are made from typical rolling stock and locomotives that either came with Trainz or was downloaded from the DLS. I don't use any premade consists either. I have created all of mine myself.

Since your version works, it makes me think my version is outdated.

Dean

 

[Mouse84]

I stick with the Portal Timetable Manager.

 

[pguy]

QPM queues management is a bit tricky as it has been designed to support several distinct sessions using the same queues.

QPM keeps for each portal the history of all consists that have leaved the session through a managed portal since the start of the session.

When the session is saved, if a queue is associated to the portal the referenced queue in QPM stack library is created if it does not exist, is cleared and then reloaded with all the consists that have leaved through this managed portal and associated queue since the start of the session. This method is used to guarantee that the queue state is consistant when running a session in several parts using session save/restore operations.

When a session is saved, all the queues are updated in a consistant way whatever has happened on the queues between the two parts of the session. This also means that a queue always contain data from only the last saved session that has been run, but all the data since the initial start of that session.

And to enable to reset or delete a queue outside a session, you have the opportunity to use the options menu and click on QPM stack library to obtain the list of created queues and to empty or delete each one. Deleting a queue will delete its data and the queue will not be recreated before a new session save operation requests to do it again. So it is a way to delete a queue created by a session you will not use again.

This is how outgoing queue is managed when the on the fly save option is not ticked on. When the on the fly save option is ticked on, you should consider that each time a train leaves through a managed portal, the session data for this portal queue will be automaticly saved without any explicit session save operation.

When a session is loaded initialy or after a restore operation, the input queues are scanned and all new consists in the queue are scheduled in QPM to be emited at the correct time. Clearing an input queue before launching a session enables to start the session without any new schedules.

That is the way queues are implemented to be consistant with save/restore session operations. What I understand is that some users would like to have a "forget portal history" option link so that they can clear the portal history on the fly during a session. I will think about adding something like this option in a next version ...

By the way QPM v2 and v3 shares QPM stack library and its queues ...

Hope this helps.

Pierre.

 

[kkopchynski]

Hi Guys

If you want to delete the queues in the portal, go to options in the top menu, and look down the list for "Quick Portal Manager Stack Library" and delete the queue there. There is also a clear queue option in the portal manger window, but you have to do a save after doing that to clear them from the globalmodule file.

Hi Lots,

This is exactly what I am doing, that is using the Stack Manager in Options or the Portal Manger window. I can make the delete in either place, save the session, then come back to the session (I run a lot of sessions in continuous operation). The queue in question shows as empty. But if I run a new consist through it, all of the old ones come back.

I am aware of the globalmodule.txt file and I saw the queue consist info in there. However, I have not experimented with modifying it. As you say, a lot of potential to stuff things up there. I did not check to see that after I deleted the queue, the info was gone from the file.
Also, for some queues, I can click on delete and nothing happens. It is as if they are locked somewhere.

In reading Pguy's response, I think he is describing the situation ( I have added bold):

"QPM keeps for each portal the history of all consists that have leaved the session through a managed portal since the start of the session.

When the session is saved, if a queue is associated to the portal the referenced queue in QPM stack library is created if it does not exist, is cleared and then reloaded with all the consists that have leaved through this managed portal and associated queue since the start of the session. This method is used to guarantee that the queue state is consistant when running a session in several parts using session save/restore operations."

I would add that the system seems quite robust and actually saves the info ever since the creation of the the queue, somewhere. Maybe in all of the binary .gsl files in UserData\Cache?

When I first started using QPM (I started with 2 and am now using 3), I had a central yard layout, (still have it) and an exit portal. I would set the output queue to the input queue of whatever map I wanted to send it to. But I believe I mis-interpreted the description and you really can't do that. The output queue for a portal is always the same data object, no matter what you name it, and there is only one. I think pguy is saying this in his post.
Dean - if this is what you are doing, it looks like you can't.

Now I have dedicated portals between maps, and I think your last comment is that this is how QPM was meant to work, which I have come to realize.
It was a lot of work to set up all the portals, and my central yard looks like a mutant spider in map view. But now I can just send to a portal, and I don't have to mess around with remembering to set queues on either end. ( well, there was a quirk which perhaps I will describe in a different post.)

I really appreciate QPM as it has allowed a whole new level of continuous operation of several routes whose industries can interact with each other.

Thanks very much,
Kevin

 

[KonstantinMMRR]

I may understand part of the problem now, as described by Pierre and Kevin.

First, there are queues from portals in routes that I have not used in months, and are not even on my computer anymore. I still cannot delete them under the options menu. However, the following may be the largest part of my problem:

Typically, I always continue a session, and almost never start one. The session I am running now started about six months ago. Whenever I stop runnning, I save it. Then when I return, I continue from where I left off. I run it like a real railroad, that just keeps going. When one train drops some cars off at a spur, another will pick them up later. This may be why whenever I clear queues, the consists keep returning.

Thank you for your help
Dean

 

[kkopchynski]

Dean:

I am operating in a way very similar to you. One session had over 500 saves.
(I only keep the most recent 10).


Pierre:
Until a "forget all history" option cones out, could you comment on the suggestion in an earlier post to delete the globalmodule.txt file?
Assuming I have emitted all of the consists I want, can I close Trainz and delete this?
I think this is what I (and possibly also Dean) have to do.
Also when V3 came out I used it in newer routes/sessions but still had V2 running in older sessions. Can this cause a problem.

Thanks again for this useful rule.

Kevin

 

[Lots_Trains]

Hi Kevin

"One session had over 500 saves"

Congrats, this is the way I like to play the game. "The Never Ending Game" a real Railroad.

Backup the globalmodual file and then delete the in game one. It will regenerate itself at next game start with no entrys. If it all goes wrong just copy the old file back in.

I always backup my saved session and the globalmodual file after every session.

A word of warning be careful when you update to a new version of QPortal Manager, it will wipe you out.

Cheers

Lots

 

[pguy]

When I first started using QPM (I started with 2 and am now using 3), I had a central yard layout, (still have it) and an exit portal. I would set the output queue to the input queue of whatever map I wanted to send it to. But I believe I mis-interpreted the description and you really can't do that. The output queue for a portal is always the same data object, no matter what you name it, and there is only one. I think pguy is saying this in his post.
Dean - if this is what you are doing, it looks like you can't.

I think I was not clear and you misunderstand my previous answser. Each distinct queue name has its own distinct object in Quick Portal Manager Stack Library. So you can have a session where you use a queue A to send trains to a Route Map Session 1 and a distinct queue B to send trains to a Route Map Session 2. Each queue is independant from the other ones and the main underlying idea was to have as many queues as the links between several maps with one distinct queue for each way between maps. if I split a big route on three maps, the intermediate map will need 4 queues : 2 to exhange with first first map in each direction and 2 to exchange to the last map in the two directions.

First, there are queues from portals in routes that I have not used in months, and are not even on my computer anymore. I still cannot delete them under the options menu. However, the following may be the largest part of my problem:

This is an abnormal situation and it is a bug. There is no situation where you cannot delete a queue under the options menu. When you delete a queue, all of its data is deleted from QPM stack library and the queue data is no longer available for input in a new session using this queue for input. But if you restore a session using this queue as an output queue, when the session data will be saved it will recreates the queue and reload in it all the consist data output from the start of the session, restoring in fact all the initial queue content. If you have such a situation can you contact me by private message so that we try to find the cause of the bug.

Until a "forget all history" option cones out, could you comment on the suggestion in an earlier post to delete the globalmodule.txt file?
Assuming I have emitted all of the consists I want, can I close Trainz and delete this?
I think this is what I (and possibly also Dean) have to do.
Also when V3 came out I used it in newer routes/sessions but still had V2 running in older sessions. Can this cause a problem.

globalmodule.txt is the place where data is saved for all global modules. It is better not to edit it as you can easily break its data structure and so break any global library including global trainz preferences. Normaly, if you delete all the queues in the option menu and then close trainz (it is the time where globalmodule.txt is saved by trainz) , all the queue data should have been suppressed for the globalmodule.txt for the current version of QPM stack library.
There is only one pitfall with globalmodule.txt with the version numbers. When you upgrade QPM stack library, the queue data will be saved using the new kuid2 number for QPM stack library, but this will not delete the data for the previous versions of QPM stack library, and they will stay for ever in the file ... In fact it not needed but for the globalmodule.txt file size, it would be better to delete all the queues before upgrading to a new version of QPM stack library ...

By the way I am tracking the last bugs in some new version of all my assets and I expect a new version of all the stuff released before the end of August to DLS. And I will try to implement a forget portal history link in this next version. I will post an information in this thread with the instructions on how to retrieve the beta cdp when it will be available in a few week(s).

Hope this helps. Have a nice day.

Pierre.

 

[KonstantinMMRR]

Lots and Kevin:

I operate the same way as you do, the never-ending session. I don't think I have gone 500 times, but I have been going for a long time. I typically save only the last few session saves.

Pierre:
I will contact you privately. I must have a bug, because no matter what I do, I cannot click on anything in the options menu.

Dean

 

[pguy]

I will post an information in this thread with the instructions on how to retrieve the beta cdp when it will be available in a few week(s).

I have just finished testing a new v19 version of all my assets including a new "clear output queue and forget portal consist history" link in Quick `portal Manager V2 and V3 assets.
For people wanting to test this latest version before general release to DLS, you can download the beta update cdp at http://trainz.guynet.org/download/beta-cdps/update assets pguy v19.cdp
If no major problem is encountered during next two weeks with this beta version, it will be uploaded at the end of the month to DLS.

Regards.
Pierre.

 

[kkopchynski]

Update:

I tried removing globalmodule.txt but when I opened a session all of the consists were gone. I tried another session and Trainz crashed. So I restored the original file and all was well. Is this expected behavior? I made a test, and If I send a consist through an iportal to a new session, then delete the globalmodule file, this time only 3 of the 5 locos showed up an all the rolling stock was gone.
I went through that file carefully and I don't see how it references those missing consists. There must be some other files involved? This looks like some sort of database operation with a lot of tables in different files interacting with each other.

So now this makes me afraid that if I used a "clear queue and forget history" option, the consists will disappear from the sessions.

It seems that something is badly crossed up in my QPM system. Is there a way to get to a clean slate without losing all of the consists in my saved sessions? I would like to test the new system, but in the current condition I don't think my experience will be helpful in guiding the development. I believe I can do some careful file editing if needed. I edit a lot of config files, and this file looks fairly understandable, just very long. Also, is there any interaction with Quickdrive V2? This will at times get a "unable to link compiled script" error, and go missing from all my sessions. A database repair fixes this, but it keeps happening.


"There is only one pitfall with globalmodule.txt with the version numbers. When you upgrade QPM stack library, the queue data will be saved using the new kuid2 number for QPM stack library, but this will not delete the data for the previous versions of QPM stack library, and they will stay for ever in the file ... In fact it not needed but for the globalmodule.txt file size, it would be better to delete all the queues before upgrading to a new version of QPM stack library ..."

Yes, I see the section in the file referring to the v2 kuid. There are 42 queues in there. Some of these are the same queue names as in V3, and I wonder if this is why they will not delete. The V2 is no longer installed and no routes or sessions are using it.

"I think I was not clear and you misunderstand my previous answser. Each distinct queue name has its own distinct object in Quick Portal Manager Stack Library. So you can have a session where you use a queue A to send trains to a Route Map Session 1 and a distinct queue B to send trains to a Route Map Session 2. Each queue is independant from the other ones and the main underlying idea was to have as many queues as the links between several maps with one distinct queue for each way between maps. if I split a big route on three maps, the intermediate map will need 4 queues : 2 to exhange with first first map in each direction and 2 to exchange to the last map in the two directions."

Yes, I think I see the unclarity/misunderstanding is referring to queues. I think what you are saying is that you can use queue A to map 1 and queue B to map 2, but I wasn't getting that each queue needs its own portal. I was trying to do it with the same portal (and about 6 different destination maps). I think you are referring to queues and portals as the same object and use the words interchangeably. I was (wrongly) thinking of queues as distinct from portals, with possibly a portal having more than 1 queue. In your 3 map example you say the intermediate map needs 4 queues, but I now believe it also needs 4 distinct portals to do this. I was trying (and still am) for a map that is a central hub to a bunch of other maps.

I apologize for being a problem with this, but this is such a cool function and I would really like to use it. Thanks for your patience and interest in this.

Best regards,
Kevin

 

[pguy]

Hi Kevin

I will try to explain below links between globalmodule.txt, queues and portals in QPM system.

globalmodule.txt is a file where Trainz saves properties data for global scope assets. globalmodule.txt will be read when you start trainz and will be writen when you quit Trainz. And global scope assets library will be initialized when Trainz starts by reading from this globalmodule.txt the asset properties and calling the asset SetProperties(soup) function. When Trainz will quit, it will call the global asset GetProperties() that will return a soup containing it properties data, that will be saved in the globalmodule.txt.
globalmodule.txt is shared by all the global assets and so when you remove globalmodule.txt, you suppress all saved data for all the global assets which are then re initialized back to their default values. For QPM stack library asset, you are in fact deleting all the queues in the system and their contents.

globalmodule.txt is structured with an entry for each asset begining by its kuid value and followed by its soup initialization data in the usual config format. If you edit globalmodule.txt and suppress the text from the start of a kuid to the end of its following soup, you should remove the entry for this kuid from the system. You need to be carefull in doing that not breaking other data for others kuid. So if due to succesive version of QPM stack library you have several QPM stack library entries with different version number, you can edit the file to suppress the obsolete kuid definition keeping only the last current kuid number for QPM stack library and it should clean the globalmodule.txt with no impact on the data saved for QPM stack library. But keep a copy of the ininitial globalmodule.txt because it is quite easy to do an error and break the file structure ...

QPM stack entry ( kuid2:61392:5013:X ) has a soup that contains first the number of queues as stacksize named parameter, and then a subsoup entry named stack-x for each queue (stack-0, stack-1, ... ). The stack-x subsoup begins by the queue name and has all the queue parameters and contents following. If you are unable to delete a queue in the options menu interface, you may try to suppress the queue data in globalmodule.txt but you need that the remaining queues data are in a subsoup format named stack-0, stack-1, ... and with stacksize containing the total number of queues with nobreak in the numbering scheme.

Portals in QPM can reference two queues : one for input and one for output. And the output and input queue names should be unique for each portal. If two portals reference the same output queue, as the queue is emptied and then reloaded in save operation, the queue will only contain the last portal saved data. If two portals reference the same input queue, as queues are not emptied after a read operation, the two portals will read the same data and will schedule the same train emitions. So trains will be emited twice, once by each portal ... So the normal operation way is to use unique output or input queue names for each portal.

Portals ans queues are different objects. Portals object are local objects in a map, have a life linked to the session life and QPM will save/restore managed portal data during the session life. Queues in QPM stack library are global objects that you can share between several map and sessions, have their data loaded and retrieved using the globamodule.txt to save/restore their data at trainz startup and quiting. And data is transfered from portals to queues when you save a session and from queues to portals when you restore a session.

Hope this makes how it works more clear.

Regards.

Pierre.

 

[kkopchynski]

Pierre,

Thank you, yes that was very helpful. You verified how I suspected things were working in that file.

I did delete the section of the old version which is not in my CMP any more. I then deleted all but 2 of the queues in the current version. I left 2 undeletable queues because I did not want to remove all of the list. When I get current queues in there I will go back and delete the remaining undeleteable ones.

After running some sessions I got back an old queue with all of its consists. So that data is saved somewhere else besides the globalmodule file and restored to the globalmodule file. Will the "forget all history" option clean that "somewhere else' location? I am now more confident in trying that option.

I looked on your website and in current pdfs but did not see info on the following:
1. If I run the v19 updater, how will that affect the sessions that are already started under the previous version?

2. Will sessions already started under a previous version be able to send consists to new sessions of other maps started under the new version?

3. I remember the previous advice to delete all queues before upgrading. Is there any other advice on how to upgrade, especially for those of us who run continuous sessions of several maps for extended times?

Could you also comment on how 1-3 may apply to the Quickdrive rule?

Thank you for your help with this. I think an understanding of the best way to upgrade your scripts will complete my education on this great rule.

Best regards,
Kevin

 

[pguy]

Hi Kevin

If I run the v19 updater, how will that affect the sessions that are already started under the previous version?

I am not sure but I don't think that an asset update affects current sessions save/restore operation. When you restore a session previously saved under driver, all the session is restored in the current state it was when it was saved which includes the assets script code. Of course, the updated asset will be used for new sessions starting in driver ( I think a session saved with an asset at level x in surveyor can be restored with the asset at level y > x when starting in driver mode ), but when it has started with level x in driver mode, it will be kept at level x for the duration of the current session even through save/restore. So v19 update should have no impact on current running sessions.
May be that Windwalker can confirm this assumption if he reads this thread post ?

Will sessions already started under a previous version be able to send consists to new sessions of other maps started under the new version?

The soup used to transmit consist from one map and session to another map and session has been enhanced through the updates, but has been kept compatible between versions. So you can send consist from one session at level x to a session at level y and vice versa, but may be the latest functionality will not be transfered. For example, v19 supports the new enhanced quick custom hud that enables to have distinct huds depending on a train attribute. When transfering a consist from QPM v19 to QPM v19, the hud used by the train is saved and restored through a portal, but if you are transfering from QPM v12 to v19 or from v19 to v12 the hud reference will not be either saved or restored ...

I remember the previous advice to delete all queues before upgrading. Is there any other advice on how to upgrade, especially for those of us who run continuous sessions of several maps for extended times?

I have no other advice other than as new versions include some bug fixes, it is better to upgrade to the latest version. And there will be no fixes for previous versions but only for the latest one.
What I wonder is that for people like you, that has started a few months ago a session and always uses the same session through save/restore in driver mode, the update may be not very useful. The update will only apply to new sessions started and not to current ones running through save/restore in driver mode. So may be you will install the update and find no changes as you will be still using the old version assets currently in used in your session ...?

Sorry, but I can't do anything for that. Upgrades and changes will only apply for new sessions ...

By the way, v19 is just now under progress on DLS upload and should be available in the next 24 hours.

Regards.

Pierre.