P3D v5 LineToPoint questions

[arno]

Right, maybe the FMOD attribute can also help here to filter some out.

 

[Clutch Cargo]

Sounds like you are saying on the new INTERSECTION step one could use ADDMODULUS1ATTR? Noticed I put the 1 in there for one object, ha! I saw a scenProc update but you have not included this yet, correct?

 

[arno]

No, it is not yet in the development release. But will be soon. I decided to not use FMOD but a special attribute that you can use to filter the amount of lights.

 

[arno]

The new development release with the new point placement mode is online now. Please check the LineToPoint section of the manual for details.

 

[Clutch Cargo]

Just testing INTERSECTION and got my first error & unhandled exception:

All I did was copy this line:

LineToPoint|fclass="secondary" AND popValue="over200"|INTERSECTION|0|5|0|String;objType|light|hdg

and then made a copy of it directly on the next line. An exact copy and that is when the error occured.

The error in scenProc said

10:17 AM SceneryProcessor Error System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at ASToFra.scenProc.Steps.LineToPoint.ScanAttributes(String[] arguments, Boolean quick)
at ASToFra.scenProc.Processor.SceneryProcessor.ScanAttributes(Boolean quick)

Could not send this error report via Error Handler as is casused an Unhandle exception. Could it be that I was trying to add two filters in the LineToPoint step? I believe you said earlier that one cannot have multiple filters in the LineToPoint step? Need to remember how I got around that. It would be a nice addition if that is the cause.

 

[arno]

I got your error report as well (about 4 times). It seems something goes wrong when scanning the attributes, I'll check.

 

[Clutch Cargo]

ha... that was me. Every time I clicked Send Report it would give an Unhandled Exception so I thought is wasn't being sent.

 

[arno]

I have fixed the crash, a new build will be online soon.

 

[Clutch Cargo]

I tried your new release and with a very basic script following your example. Mine was:

LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|hdg. Here is the results:

Initial thoughts:
1. As mentioned, one would only want a single light at a remote intersection. Would need a way to either randomly create a single object or the option to select how many objects via an integer?
2. The step above shows I was using the road type 'secondary" as the primary road. The road intersecting the secondary road is 'residential'. What would happen if I also created a step where residential was the primary road? That would mean I would not see 3 lights but see 6 lights at that intersection?
3. Could not get the light poles to face towards the intersection. Changing heading was based on true north.

Now let's go back to my initial script idea using buffer roads as opposed to a line. Here are my steps trying it this way:

I imported a population data set and roads that were already buffered, then
AddAttributeIfInside|roadtype="secondary"|popValue="over200"|String;popValue|over200

SplitGrid|LOD13|*
BooleanFeatures|INTERSECTION|type="secondary" AND popValue="over200"|roadtype="residential" AND popValue="over200"|1
PolygonToPoint|roadtype="secondary" AND popValue="over200"|CENTER|0.0;0.0|0.0;0.0|String;Type|INTERSECT|hdg

PointToPolygon|Type="INTERSECT"|5;5|hdg|0|String;TYPE|WHITELIGHT
PointToPolygon|Type="INTERSECT"|8;8|hdg|0|String;TYPE|LIGHTPOLE

CreateAGNLibObject|TYPE="WHITELIGHT"|{c140b28e-7d3f-4278-8c76-aba4f0e9ac02}
CreateAGNLibObject|TYPE="LIGHTPOLE"|{0017a263-464f-14fd-f77f-2996fed44864}

ExportAGN|P3D v4|B:\path\texture

Here is the results of this test:

1. If I create the intersection lights this way only one light is created. Good.
2. I believe it would not require creating INTERSECTION steps for each road type in order to work as each different road type is intersecting the 'secondary road" and will produce a light. I do need to test this way further.
3. Currently, I cannot create an offset the way the step is written currently. The light and the pole are at the exact intersection of the two "poly" roads.
4. The HDG of the light is not pointing towards the intersection.

I could be wrong, but I think this way has more options for filtering... more options to control when the light is shown or not shown in certain conditions. Of course one needs to create "buffered roads:" for this method to work. I do it before I use scenProc and import them, but I believe you have a step inside scenProc that can create buffered roads on the fly so that may eliminate any extra steps required. Not sure idf a new complete step could be created or it is part of the PointToPolygon?

Your thoughts?

 

[arno]

Hi,

1. As mentioned, one would only want a single light at a remote intersection. Would need a way to either randomly create a single object or the option to select how many objects via an integer?

RTFM . The point already get an attribute FNUMINT which has a number from 1 to the number of points on the intersection. So if you want only one light per intersection you can test for FNUMINT=1. They are assigned in random order so that you don't get the same point as number 1 all the time.

2. The step above shows I was using the road type 'secondary" as the primary road. The road intersecting the secondary road is 'residential'. What would happen if I also created a step where residential was the primary road? That would mean I would not see 3 lights but see 6 lights at that intersection?

No, that is not how it works. You are not selecting the primary road. When you only select "secondary" as class it will find intersections between lines of "secondary" class only. If you want intersections between "secondary" and "residential" you would need a filter like roadtype=" secondary" Or roadtype="residential". So I don't think you need multiple instances of the step as well, you just select which roadtypes need intersections and run them all at once.

3. Could not get the light poles to face towards the intersection. Changing heading was based on true north.

They should do that now already. You will need to add the same heading offset in the PointToPolygon step that you do along the normal lines.

 

[Clutch Cargo]

Ahhhh! RTFM I thought I did read it all... musta missed sumpin' Just got back from FS Expo so I will blame it on jet-lag!

Mmmm... I will try again going all through this tomorrow. Thought I tried the offset but I will try again.

Ha... discovered I was reading a one version older User Manual which did not have the updated Intersection information . Getting back on track with testing now.

 

[Clutch Cargo]

Need some help here. I now was able to place an offset but do not fully understand the attribute or I should say I do not understand Table 10.2. Here is my step:

LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|

As I understand by using '20' in the above step, I was able to offset the lightpoles 20 meters from the intersection. So what is the 'VALUE__2' mean and how is that inserted? What is meant by 1/2 distance? Distance from what?

I still am not able to reduce the lightpoles to just one (or any other number). I have tried:

LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|FNUMINT=1
LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|FNUMINT="1"
LineToPoint|fclass="secondary"|INTERSECTION|0|20|1|String;objType|lightpole|FNUMINT

I also still cannot get the lightpole(s) to point towards the intersection. If it is set as default then should I need to add anything? I would only think so if the arm of the lightpole is not truly facing 0 degrees and need to adjust.

Can you use my above example and write the step to show how it would show 1 lightpole at a 20 meter offset facing towards the intersection. Thx.

 

[arno]

Need some help here. I now was able to place an offset but do not fully understand the attribute or I should say I do not understand Table 10.2. Here is my step:

LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|

As I understand by using '20' in the above step, I was able to offset the lightpoles 20 meters from the intersection. So what is the 'VALUE__2' mean and how is that inserted? What is meant by 1/2 distance? Distance from what?

That table is for the CONTINUOUS mode, not for the INTERSECTION mode. So it's not relevant here.

I still am not able to reduce the lightpoles to just one (or any other number). I have tried:

LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|FNUMINT=1
LineToPoint|fclass="secondary"|INTERSECTION|0|20|0|String;objType|lightpole|FNUMINT="1"
LineToPoint|fclass="secondary"|INTERSECTION|0|20|1|String;objType|lightpole|FNUMINT

It's the LineToPoint step that adds the FNUMINT attribute to the created point features. So it's in the next step (e.g. PointToPolygon) where you can filter on that attribute.

I also still cannot get the lightpole(s) to point towards the intersection. If it is set as default then should I need to add anything? I would only think so if the arm of the lightpole is not truly facing 0 degrees and need to adjust.

I made a test script where I placed point along a line and at intersections. When I use the same heading offset in the PointToPolygon step the lights are facing towards the road line and towards the intersection.

Can you use my above example and write the step to show how it would show 1 lightpole at a 20 meter offset facing towards the intersection. Thx.

Not behind my PC now, but will have a look later.

 

[Clutch Cargo]

Thanks for the clarification. I think I got it now. Even though I am using the same default lightpole, I created two separate steps. Creating light poles for intersections and create lightpoles for roads. Same hdg offset for both. They are now pointing towards the intersection and road lightpoles are still pointing towards the road!