• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FS2004 Issue with parking spots (v01.52.4699 BETA)

Messages
72
Country
qatar
Hi,

I have an issue with parking spots with this latest version. For some reason, I'm not able to create any parking link. I should normally be able to create the link from a node to the parking spot, the latter 'attracting' the link to its center.

instead, I have a node at the very coordinates where I clicked on the spot. Ultimately, this leads to my parking spots being orphans.

Any reason why? Did I miss something? Thanks,

Fred
 
Hi,

I have an issue with parking spots with this latest version. For some reason, I'm not able to create any parking link. I should normally be able to create the link from a node to the parking spot, the latter 'attracting' the link to its center.

instead, I have a node at the very coordinates where I clicked on the spot. Ultimately, this leads to my parking spots being orphans.

Any reason why? Did I miss something? Thanks,

Fred

Try drawing the link starting from the parking spot...
 
Hi,

Unfortunately, no more luck. It seems like, even with the cursor (red cross) over a parking spot, it's not recorgnized.

When I start from the parking spot, I immediately get a node created :(

Fred
 
Simply put make sure you either start or end at the center of the parking spot. We changed the test for what to connect to a few builds ago. It now works on a proximity test. You need to be within a couple of 'meters' of the parking spot center.

This is a change from the previous code and I have a note [10239] to see if the proximity range can be changed for parking spots alone to make the hit a bit easier.
 
This is a change from the previous code and I have a note [10239] to see if the proximity range can be changed for parking spots alone to make the hit a bit easier.

Why was it changed? I never had a problem starting or ending anywhere within the parking spot circle.
 
There is a module in ADE that performs 'hit testing' to see what object the cursor is over. Earlier in the beta there were problems with accurately connecting links to other links and nodes. This didn't directly affect parking spots however the method of hit testing was changed. Ironically to make it easier to hit links and nodes. In fact it also has the effect of making it harder to hit parking spots. There is a side 'benefit' for folks who want to make paths that run through a parking spot. The new hit test allows placement of nodes on parking spots. So, as usual, there is no free lunch.

I could:
  • Revert to the old hit test for parking spots - not my preferred route since it means messing up the code again
  • Relax the new hit test boundary for parking spots
  • Provide a visual cue as to what part of the parking spot is active for the hit test
  • or just stick my head in boiling oil... ;)

my preference is for a combination of the second and third options above :)
 
Hi,

Just my personal opinion: I preferred the older method where the link easily snapped to the parking spot. If one wants to add a link with a node within the parking spot circle, draw the link to somewhere outside the parking spot and drag the node inside. That works fine. So this side benefit is only relative.
But as you said, maybe the same can be achieved with the second and third option and have this free lunch anyway:).
 
Hi,

Just my personal opinion: I preferred the older method where the link easily snapped to the parking spot. If one wants to add a link with a node within the parking spot circle, draw the link to somewhere outside the parking spot and drag the node inside. That works fine. So this side benefit is only relative.
But as you said, maybe the same can be achieved with the second and third option and have this free lunch anyway:).

Fair points Roby. I have logged it and will take another look at the code to see what can be done to get back closer to the old method without undoing the new code.
 
I think the last option is preferable :D

I think I must stick with 1.50 because the current situation is unbearable.

There is a side 'benefit' for folks who want to make paths that run through a parking spot. The new hit test allows placement of nodes on parking spots. So, as usual, there is no free lunch.

The only reason to have paths running through parking spots is for "drive-through" parking and to restrict push-back.

In this case, one shouldn't create the node whilst adding the link, but rather add the node after the link is created. This has always worked for me.

Edit. When adding a link, if, when the button is released, check the cursor position, if it is within a parking spot, create a parking link, if it is within a node, snap to node, if it is in open space, add an end node.
 
Last edited:
Edit. When adding a link, if, when the button is released, check the cursor position, if it is within a parking spot, create a parking link, if it is within a node, snap to node, if it is in open space, add an end node.

Exactly - that is the workflow that is used. The issue is the method being used. I can't unravel all the code back to 1.50 but I will see about the parking spot testing.
 
I found a way to use the new hit test algorithm and the parking spot radius so it should now work the old way in the next release.
 
Surely the hit test should use the current symbol sizes for nodes, parking spots and taxiways/paths :confused:

Sorry, I forgot to say that a taxiway/path can end on another taxiway/path :o
 
Surely the hit test should use the current symbol sizes for nodes, parking spots and taxiways/paths :confused:

Sorry, I forgot to say that a taxiway/path can end on another taxiway/path :o

Yes George. That is how it works. ADE used the built in hit testing from the graphics engine and this is not entirely reliable. OK it appeared to work fine in older versions but in part that was because ADE forced the testing several times to be sure and that slowed performance down. Don't ask me why - I have the source but it is a Java port and rather arcanely written into C#. It is no longer supported by the developers. I changed the hit test module to my own code and that actually makes it easier to 'hit' a link and a node. But harder to hit a parking spot - mea culpa on that one so I have changed it back but used the new algorithms rather than the older built in ones.

Generally my goal is to improve things :) does not always work though :o

In hindsight I should not have used that graphics engine since there are a lot of things that annoy me about it. However after 6 years it would be a major re-write to remove it and replace it :(
 
Hi Guys,

It works perfectly but I also agree that I have a preference for the older method ;)

But thanks for making this tool so fantastic!

Fred
 
Back
Top