Request: an easier way to implement paths (no idea whether this is even possible)
-
First test.
I’m getting an almost, but not quite, perfect result, and the oddness of where it is not perfect, baffles me:
It would have made more sense to me if all the paths would have their angle mirrored (because that is what seems to be wrong with the 2nd leg), not just one of them.
This is the code (and I also tried with adding a [c]pos_begin[/c] to every leg, which rendered the same result, and with and without CYLINDER in leg 2, 3 an 4) :
[zone] nickname = Zone_Br07_xpath_mollys9_1 shape = CYLINDER size = 750 ;--------------------------------LD-4 pos_begin = 29834, 0, -47360 pos_end = 71125, 0, 3996 ;--------------------------------TLR_47 attack_ids = br07_4 tradelane_attack = 15 sort = 99 toughness = 13 density = 3 repop_time = 90 max_battle_size = 4 pop_type = attack_patrol relief_time = 30 path_label = mollys9, 1 usage = patrol mission_eligible = True faction_weight = fc_m_grp, 10 density_restriction = 1, patroller density_restriction = 1, police_patroller density_restriction = 1, pirate_patroller density_restriction = 4, lawfuls density_restriction = 4, unlawfuls encounter = patrolp_assault, 13, 0.290000 faction = fc_m_grp, 1.000000 visit = 1 [zone] nickname = Zone_Br07_xpath_mollys9_2 shape = CYLINDER size = 750 pos_end = 60000, 0, 9800 attack_ids = br07_4 tradelane_attack = 15 sort = 99 toughness = 13 density = 3 repop_time = 90 max_battle_size = 4 pop_type = attack_patrol relief_time = 30 path_label = mollys9, 2 usage = patrol mission_eligible = True faction_weight = fc_m_grp, 10 density_restriction = 1, patroller density_restriction = 1, police_patroller density_restriction = 1, pirate_patroller density_restriction = 4, lawfuls density_restriction = 4, unlawfuls encounter = patrolp_assault, 13, 0.290000 faction = fc_m_grp, 1.000000 visit = 1 [zone] nickname = Zone_Br07_xpath_mollys9_3 shape = CYLINDER size = 750 pos_end = 61500, 0, 15500 ;--------------------------------TLR_45 attack_ids = br07_4 tradelane_attack = 15 sort = 99 toughness = 13 density = 3 repop_time = 90 max_battle_size = 4 pop_type = attack_patrol relief_time = 30 path_label = mollys9, 3 usage = patrol mission_eligible = True faction_weight = fc_m_grp, 10 density_restriction = 1, patroller density_restriction = 1, police_patroller density_restriction = 1, pirate_patroller density_restriction = 4, lawfuls density_restriction = 4, unlawfuls encounter = patrolp_assault, 13, 0.290000 faction = fc_m_grp, 1.000000 visit = 1 [zone] nickname = Zone_Br07_xpath_mollys9_4 shape = CYLINDER size = 750 pos_end = 79038, 0, 41800 ;--------------------------------Omega=3 Hole attack_ids = br07_4 tradelane_attack = 15 sort = 99 toughness = 13 density = 3 repop_time = 90 max_battle_size = 4 pop_type = attack_patrol relief_time = 30 path_label = mollys9, 4 usage = patrol mission_eligible = True faction_weight = fc_m_grp, 10 density_restriction = 1, patroller density_restriction = 1, police_patroller density_restriction = 1, pirate_patroller density_restriction = 4, lawfuls density_restriction = 4, unlawfuls encounter = patrolp_assault, 13, 0.290000 faction = fc_m_grp, 1.000000 visit = 1(Btw the disconnected path does not cause a crash. That sounds good but it might actually mean there are now encounters at all. The whole thing is in a huge pop zone; I’ll turn that off in the next test so that I can be sure that any molly that I encounter, is generated by the path. But, that has less priority than reporting this.)
-
adoxa wrote:
Try swapping begin & end (sorry, I meant to mention that).I presume that you mean for the entire path?
On it… (and after that I gotta do some offline things as well (sucks)
-
That renders the first and last leg reversed, but leg 2 and 3 seem to be okay now…
EDIT: No, only leg 2 is okay now (leg 2 and 3 are small so it’s not apparent at first sight) so the results are exacyly opposed to the first test.
-
The paths seem to be in the proper position. So my layman’s assumption is that the issue is with how the angles are calculated. I find it odd that not all the angles are mirrored though…
Btw apparently tests 1 and 2 rendered the exact opposed angles in the paths.
-
Adoxa wait!!
Just noticed that a rotation value in one of the vanilla-style paths got mauled! Maybe that caused the issue!
EDIT, No it matters not. With the error in that vanilla-style-path* corrected, the path-new-style still has the same issie.
*I presume that that path just somehow inherited the value of its predecessor? (Although I once tried to see how much is inherited, and was disappointed.)
-
Since I don’t really know what I’m doing, I took the simple approach and added an extra parameter to [c]pos_end[/c] that flips the rotation. Now you should be able to have a single [c]pos_begin[/c], with a chain of [c]pos_end[/c]s, manually adding [c]flip[/c] to the legs that aren’t right. I hope.
-
Thanks, I’ll test that tonight.
Btw some vanilla paths have 90, but other -90 as the first rotation value. I don’t know how significant that is here, but iirc if you reverse these values (turning 90 into -90 or vice versa), those paths show the same behavior as the faulty paths generated by ZonePos.
No success with looking into the Trade Lane Calculator? That tool does the angles right.
I have absolutely no idea how complicated it is to create such a standalone tool like the TLC or your XML->UTF (and vice versa) converter. But as I’ve always been content with the TLC (although I do find a bit annoying that it writes a [c]visit = 1[/c] line to every single Trade Lane Ring) , I always wondered why the same dude didn’t make a path (a single leg of a path that is) calculator, which would be similar. Maybe he already left the scene before paths were even discussed; iirc the TLC was a very early tool.
-
Btw some vanilla paths have 90, but other -90 as the first rotation value. I don’t know how significant that is here, but iirc if you reverse these values (turning 90 into -90 or vice versa), those paths show the same behavior as the faulty paths generated by ZonePos.
That’s effectively what swapping begin/end did; flip does it by subtracting 180.
No success with looking into the Trade Lane Calculator? That tool does the angles right.
That wasn’t my experience with these paths. Both this and FLDev generated <0, n, 0>, which apparently is a vertical cylinder. I add 90 to the X-rotation and swap the X values for Y & Z.
[…] although I do find a bit annoying that it writes a [c]visit = 1[/c] line to every single Trade Lane Ring […]
Change 2E88 from 31 ([c]1[/c]) to 30 ([c]0[/c]) to write [c]visit = 0[/c] instead.
[…] iirc the TLC was a very early tool.
V2 is from May 2004, so about a year after FL was released.
-
adoxa wrote:
Moonhead wrote:
[…] although I do find a bit annoying that it writes a [c]visit = 1[/c] line to every single Trade Lane Ring […]Change 2E88 from 31 ([c]1[/c]) to 30 ([c]0[/c]) to write [c]visit = 0[/c] instead.
Thanks, but tbh that’d be just annoying
A [c]visit =[/c] entry isn’t necessary, and hence redundant, for Trade Lane Rings. Could you think of a heck that totally eliminates the entire line from the generated code?About to download and test the updated ZonePos now.
-
With [c], flip[/c] added, the second leg of the path is properly connected now:
[zone] nickname = Zone_Br07_xpath_mollys9_2 shape = CYLINDER size = 750 pos_begin = 71125, 0, 3996 pos_end = 60000, 0, 9800, flipSignificant (to me at least) is that leg 1, 3 and 4 all go from upper-left to lower-right, while leg 2 (which was the one that was skrewed up in the first tests) goes from upper-right to lower-left.
Btw As they now show up as they should, I think we can assume they are treated by the game as any other path encounter. So, whether or not ships show up, whether or not they actually attack Trade Lane Rings etc. is not something governed by ZonePos.dll and hence not relevant (Adoxa correct me if this assumption is wrong).
-
[…] A [c]visit =[/c] entry isn’t necessary, and hence redundant, for Trade Lane Rings. Could you think of a h[a]ck that totally eliminates the entire line from the generated code?
I could, but the VB6 decompilers I had didn’t work, which is why I just changed the number. I’ve now got a new decompiler, so here’s how to remove the visit line altogether:
2E74 12->00
77B9 0C->11
7C2A 0C->11That replaces something like [c]str += “visit = 1” + vbCRLF[/c] with [c]str += “” + “”[/c].
Significant (to me at least) is that leg 1, 3 and 4 all go from upper-left to lower-right, while leg 2 (which was the one that was skrewed up in the first tests) goes from upper-right to lower-left.
Attached is a new version which should flip automatically. To summarize usage: the first leg should define [c]shape[/c], [c]size[/c] (first value), [c]pos_begin[/c] and [c]pos_end[/c], whilst subsequent legs should only need [c]pos_end[/c]. It may still need tweaking if there are any paths across the Y plane.
-
Thanks!! It’ll have to wait until late in the evening though.
-
There’s a few more settings I could automatically duplicate: nickname (add 1), sort, toughness, density, repop_time, max_battle_size, pop_type, relief_time, path_label (add 1), usage, mission_eligible, density_restriction (multiple), encounter, faction (multiple). Alternatively, take the TLC approach and instead have a standalone utility that takes a few parameters and generates all the zones.
-
adoxa wrote:
There’s a few more settings I could automatically duplicate: nickname (add 1), sort, toughness, density, repop_time, max_battle_size, pop_type, relief_time, path_label (add 1), usage, mission_eligible, density_restriction (multiple), encounter, faction (multiple). Alternatively, take the TLC approach and instead have a standalone utility that takes a few parameters and generates all the zones.Both approaches would be great assets, I suppose.
The first one (the extended / enhanced ZonePos) would have as advantage that it would make the creation of more complex systems, like the House Systems, exponentially more easy! It would become possible to, almost intuitively, alter the course of a patrol_path by changing a single set of coordinates!
(One would almost be temped to re-write all the paths in the vanilla files according to this new ZonePos format, to create the ultimate SDK! But that’d be hard labour… Oh btw, would these new-style coordinates be parsed by RimShot’s System Calculator?)
The second one (the standalone ‘TLC style’ utility) would have as advantage that it would render ‘orthodox’ code, indistinguishable from the vanilla paths. As a layman I’d presume that, the less plugins, the better, to avoid possible conflicts; then again your plugins do not seem to trigger any conflict anyway, so this presumption might be baseless.
A standalone tool would btw also have an unintended second function that the TLC lacks: it could be used to calculate a trade_lane’s traffic zone. This isn’t that difficult, but it takes some time doing it manually. A path calculator would be able to do that faster, and more accurately (although a trade_lane differs in several aspects from a typical patrol_path, the pos, rotate and size (length) work the same.)
-
adoxa wrote:
Attached is a new version which should flip automatically. To summarize usage: the first leg should define [c]shape[/c], [c]size[/c] (first value), [c]pos_begin[/c] and [c]pos_end[/c], whilst subsequent legs should only need [c]pos_end[/c]. It may still need tweaking if there are any paths across the Y plane.
The new version works fine, both without and with [c], flip[/c] added (I tested that to see whether that parameter could still be used. It didn’t cause a crash but it also didn’t do anything so I wonder if it would work when somehow the path would actually need to be flipped?)
