SRL Archive - SRL Suggestions

In its current state, TPAtoATPAEx/SplitTPAEx does not take into account the compass direction when executing from the width and height parameters.
This can cause inaccuracies when finding rectangular objects with much higher width than its height or vice versa. To demonstrate what i mean:

With the compass facing north, the stone will be vertical, and if my w/h is set for vertical, its going to return a single ATPA and give me a single point perfectly. But if the compass were to turn to the east/west, it will become horizontal and hence the same width/height will result in 2 ATPA instead (and hence 2 points).

So maybe we can have another TPAtoATPAEx/SplitTPAEx function dedicated to RS that calls rs_GetCompassAngleRadians, then adjusting the search rectangle to the same angle as the compass.

I know this is to do with WizzyPlugin and isn't really to do with SRL include but cant find a more suitable place to post it.

This is my personal preference; to me it'd be easier to know the angle you are working with ahead of time, rather than trying to account for it. On the flip side, I see how looping through a check array of results and pulling the data that fits your criteria (or closest-to) may also be desirable. If anything becomes created as result to this thread, I couldn't think of a place aside from snippets for this – again just my brain thoughts. Overall I do see purpose in this, as it helps increase accuracy potential within scripts.

Well if you MiddleTPA the results you will get the same point anyways if you split it correctly. You can use sin/cos with the rad of the compass to compensate the angle. I don't think it's necessary. You should also realise that SplitTPA does not split the TPA in the width that you input! It does search for points within the width/height you input.

The bottom picture should show it:

Can't you rotate the points before passing them to SplitTPA?

From: Le Jingle
This is my personal preference; to me it'd be easier to know the angle you are working with ahead of time, rather than trying to account for it. On the flip side, I see how looping through a check array of results and pulling the data that fits your criteria (or closest-to) may also be desirable. If anything becomes created as result to this thread, I couldn't think of a place aside from snippets for this – again just my brain thoughts. Overall I do see purpose in this, as it helps increase accuracy potential within scripts.

I want to create scripts that can work with dynamic angles. I find it extremely bot-like to keep ur compass perfectly north all the time.

From: J J
Well if you MiddleTPA the results you will get the same point anyways if you split it correctly. You can use sin/cos with the rad of the compass to compensate the angle. I don't think it's necessary. You should also realise that SplitTPA does not split the TPA in the width that you input! It does search for points within the width/height you input.

The bottom picture should show it:

I guess SplitTPAEx will result the same result most of the time (unless the width/height is super disproportionate). But TPAtoATPAEx will not be the case as i've demonstrated above, as even though all the points are accounted for, it's grouped wrongly (in my example, it should be a single ATPA instead of grouping the stone into 2 ATPA (due to the width not being long enough)

From: nielsie95
Can't you rotate the points before passing them to SplitTPA?

Damn it, i thought i finally know all the WizzyPlugin after spending hours reading this, guess i'll read up the documentation. Thanks a lot!

RotatePoints :)