Mr. Singleton Link - by Ricebug
Ricebug on 11/10/2013 at 22:45
I've dealt with the singleton link problem before, mainly when reversing CONTAINS data with the player start point. However, this one is giving me trouble:
Quote:
Adding moving terrain objects...ERROR: Caller expecting a singleton link on (TPath [0 --> 163])
Actual links were:
TrainCntrlPt2 (145) --> SwitchTerrPt1 (163) [02D10031]
LeftSwitchTerrPt1 (162) --> SwitchTerrPt1 (163) [02D10065]
ASSERT: [RELATION.CPP@164]
Singleton link expected (TPath [0 --> 163])
I've examined TerrPts 163 and the other objects mentioned and can't find anything wrong. Is the red text telling me what the correct parameters are? The train object works just fine, BTW.
kdau on 12/10/2013 at 01:59
The red text is the description of the singleton condition: there can only be one TPath link from 0 (= any object) to SwitchTerrPt1 (163) (or any given TerrPt). So the problem is that two TerrPts have TPath links to 163. That restriction is news to me, and seems like it shouldn't be necessary, unlike the inverse restriction (only one TPath link from any given TerrPt). But the mysteries of the Dark Engine are many. If that really is the case, and the assertions are annoying enough to be a problem, then a workaround is needed.
From a very preliminary test, it seems that (1) changes to TPath links made without an intervening pathfind still work just fine, and (2) if a second TPath link to a TerrPt is created without an intervening pathfind, there is no place for the engine to complain. The ugly workaround here could be to use NVLinkBuilder to create any second (or third, etc.) TPath links to a TerrPt at mission start. That way they would be coded in the mission (in the form of DN parameters) but invisible to normal pathfinding. (I assume NVLinkBuilder is how you're implementing diverging tracks?) The cleaner workaround would be a new custom script more specific to this scenario (covering both merging and diverging terrain paths).
Oh, and I gather from the output that you're building a rail network with working switches? That's awesome, and I'd like to volunteer in advance to beta test. :)
LarryG on 12/10/2013 at 04:03
As long as you are going in the right direction, you can ignore the warning. If you try backing up, though, you will get into trouble, as it doesn't know how to deal with a fork in the road.
Yes, he's using my locomotive track switching demo mission as a base.
From the readme packaged in the demo mission:
Quote:
Also, the error message when processing the demo mission is normal and expected.
Don't worry about it. To enable track switching, there are two links to the terrpt
where both sets of track join. This is not an issue since you only traverse the
links in one direction:
Adding moving terrain objects...ERROR: Caller expecting a singleton link on (TPath [0 --> 163])
Actual links were:
TrainCntrlPt2 (145) --> SwitchTerrPt1 (163) [02D10031]
LeftSwitchTerrPt1 (162) --> SwitchTerrPt1 (163) [02D10065]
ASSERT: [RELATION.CPP@164] Singleton link expected (TPath [0 --> 163]) [2]
Ricebug on 12/10/2013 at 11:34
Quote Posted by kdau
Oh, and I gather from the output that you're building a rail network with working switches? That's awesome, and I'd like to volunteer in advance to beta test. :)
You're hired. It will definitely need a tech guy, as the whole train system LarryG designed is mind-blowing. One of the cool things he did was implement automatic placing and connection of terrpts as track sections are laid down. Most of these I've removed from rails that don't have traffic.
Probably won't be for a while, as I'm just starting and the mission will be large.
fibanocci on 22/5/2014 at 10:54
It was a bad idea to ignore this warning. The Pathfinding in your mission is broken on hard/expert difficulty now. Blame terrpt 163 for the hassle.
LarryG on 22/5/2014 at 14:09
No. This warning has to do with the vator, not AI paths (note the "TPath" in the warning). There is nothing wrong. This warning is a normal part of having a setup where the vator can change paths. The engine does not expect that. It expects that every terrpt will only have a single chain of TPath links to follow. I designed the setup and have extensively tested it. The Singleton link expected (TPath [0 --> 163] is not a problem. If there is a pathfinding problem, that is not related.
fibanocci on 22/5/2014 at 14:25
I ran pathfinding database in Ricebugs 3rd mission, got the described error/crash. The patfinding database is broken. I deleted terrpt 163 and ran pathfinding database again. Now it's fine. It's also fine if I run the FM Selector/Darkloader.
So the problem's terrpt 163.
BTW, there are some really bad roombrushes in this mission.
LarryG on 22/5/2014 at 14:39
Believe what you will. The warning is not a crash. It describes the setup. There are two TPath links to 163 on purpose. TrainCntrlPt2 (145) -TPATH-> SwitchTerrPt1 (163) and LeftSwitchTerrPt1 (162) -TPATH-> SwitchTerrPt1 (163). It happens where the two possible paths join up. There is nothing wrong with a Y juncture where two paths join to become one. There is a problem going the other direction, trying to have one path split into two. In that case the warning needs to be taken and the situation corrected. That's where I did the dynamic link switching magic. But I didn't bother with that on SwitchTerrPt1 since it is not a problem. If he wants to replicate the link switching for SwitchTerrPt1 he can. But it is not needed. If there is a pathfinding problem, the cause is elsewhere.
fibanocci on 22/5/2014 at 15:57
I compared the mis files again. Looks like you're right, I mixed up some stuff. I did something else, too: I deleted the "difficulty" property on the locomotive (213).
