Freelancer Community Network
Reminder: Internet Explorer 6 or below are NOT supported.
HomeHome
ForumForum
WikiWiki
DownloadsDownloads
ForgeForge
Multiplayer Connection Tutorial
Collapse/Expand Random Image
Bretonia Battleship
Collapse/Expand Login
Username:

Password:

Remember me



Lost Password?

Register now!
Collapse/Expand Main Menu
Collapse/Expand Forum
Collapse/Expand Chat
Collapse/Expand Who's Online
60 user(s) are online (28 user(s) are browsing Forum)

Members: 1
Guests: 59

LordNul, more...
Collapse/Expand Donations
Monthly costs: -30€
Income (ads): +5€
Donations (last month): +5€

Current balance: 0€
(last updated 06/2020)

Please make a donation if you want to help keeping The-Starport online:

Bitcoin address:
Thanks!
Collapse/Expand Links
Collapse/Expand Advertisement
There are currently 53 users playing Freelancer on 40 servers.
 August. 6, 2020

Browsing this Thread:   1 Anonymous Users



 Bottom   Previous Topic   Next Topic  Register To Post

« 1 2 (3) 4 »


Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#31
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
With , flip added, the second leg of the path is properly connected now:

Open in new window


Code:
[zone]
nickname = Zone_Br07_xpath_mollys9_2
shape = CYLINDER
size = 750
pos_begin = 71125, 0, 3996
pos_end = 60000, 0, 9800, flip


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.


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).

Posted on: 2018/12/4 14:37
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#32
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
Quote:
[...] A visit = 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->11

That replaces something like str += "visit = 1" + vbCRLF with str += "" + "".


Quote:
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 shape, size (first value), pos_begin and pos_end, whilst subsequent legs should only need pos_end. It may still need tweaking if there are any paths across the Y plane.

Attach file:

zip ZonePos.zip Size: 5.18 KB; Hits: 65

Posted on: 2018/12/5 2:12
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#33
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Thanks!! It'll have to wait until late in the evening though.

Posted on: 2018/12/5 5:57
Open in new window
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#34
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
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.

Posted on: 2018/12/5 6:16
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#35
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Quote:

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.)

Posted on: 2018/12/5 20:30
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#36
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Quote:

adoxa wrote:

Attached is a new version which should flip automatically. To summarize usage: the first leg should define shape, size (first value), pos_begin and pos_end, whilst subsequent legs should only need pos_end. It may still need tweaking if there are any paths across the Y plane.

The new version works fine, both without and with , flip 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?)

Posted on: 2018/12/5 20:46
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#37
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Quote:

adoxa wrote:
Quote:
h[a]ck

Thanks; when I'm tired my brain apparently defaults to Dunglish.

Posted on: 2018/12/5 20:50
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#38
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
Quote:
Oh btw, would these new-style coordinates be parsed by RimShot's System Calculator?

That's a good point - none of the system readers (e.g. FLE, Studio) or ini error checkers would recognize them, so the standalone utility is probably the way to go. Bugger, I didn't really want to write one.


Quote:
[...] then again your plugins do not seem to trigger any conflict anyway, so this presumption might be baseless.

Actually, I'm still amazed that there's only been one (known) conflict (EngClass & MultiCruise).

Posted on: 2018/12/6 1:15
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#39
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
Quote:
The new version works fine, both without and with , flip 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?)

Only the point is read, everything else is again ignored. It would, of course, be better to fix the generator rather than require manual flipping (it was uncertainty on my part that I did that).

Oh, you might also want to check the direction is right (i.e. ships go from start to end, not end to start). Is there a better way of testing that than just waiting for a patrol to show up and join it? Or is direction implied by the sequence of paths?

Posted on: 2018/12/6 1:29
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#40
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Quote:

adoxa wrote:

Oh, you might also want to check the direction is right (i.e. ships go from start to end, not end to start). Is there a better way of testing that than just waiting for a patrol to show up and join it? Or is direction implied by the sequence of paths?


Interesting question from the point of view of trying to understand the game engine, but of little practical consequence: there is no use tracing a ship from the start til the end of a path anyway. So, if the ships reverse midway, it has little consequence (unless the other legs aren't used because of it).

A path imho should:

  • not trigger a crash;
  • appear as if the faction would actually use it, if FL's universe were real;
  • actually generate traffic;
  • occasionally trigger a trade_lane attack (if it's a pirate faction's path


The ZonePos path that I'm using to test the plugin with, does all that, even it they would hypothetically be less functional than the vanilla paths, which they likely aren't anyway.

I've always assumed that path-legs are bi-directional, mostly because it would be awfully inconvenient if they weren't; if there even is a preferred direction, I assume it would be governed by the order of the path legs as expressed in the path_label (e.g. path_label = mollys9, 1, path_label = mollys9, 2 etc.), and not by an individual leg's rotation values. Theoretically we could test that by swapping a few labels inside a multi-legged vanilla path, but I have a bit of a hangover now and don't want to look at the game crashing


In a broader sense, which of the following assumptions do think better describes an encounter / pop zone (they are almost but not quite identical)?

  1. When the player's ship approaches a pop zone, that zone will be filled with traffic as defined in the zone's setup.
  2. While the player's ship is inside a pop zone, the game will render traffic as defined in the zone's setup.

So, is the zone primarily a property of a certain area in the system that gets 'alive' by the player's ship approaching, or a condition of the player's ship being in a certain area? (Of course, these are hard to distinguish between, and I'm not even 100% sure whether I fully comprehend what I'm asking )

Posted on: 2018/12/6 11:48
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#41
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
Quote:
I've always assumed that path-legs are bi-directional, mostly because it would be awfully inconvenient if they weren't [...]

Yeah, makes sense.


Quote:
So, is the zone primarily a property of a certain area in the system that gets 'alive' by the player's ship approaching, or a condition of the player's ship being in a certain area? (Of course, these are hard to distinguish between, and I'm not even 100% sure whether I fully comprehend what I'm asking )

Sounds like you're asking is there traffic because of where you are or what you can see. A quick experiment suggests the former (from Manhattan I went 21K straight up, outside New York's NW ambient zone, and the traffic stopped). That makes sense, too, because where you are is a lot easier to test than what you can see.

Posted on: 2018/12/7 1:19
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#42
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Quote:

adoxa wrote:
Quote:
Oh btw, would these new-style coordinates be parsed by RimShot's System Calculator?

That's a good point - none of the system readers (e.g. FLE, Studio) or ini error checkers would recognize them, so the standalone utility is probably the way to go. Bugger, I didn't really want to write one.

Well... for me personally it wouldn't actually matter that much, because I mainly have used the System Calculator because creating paths was such a drag — which ZonePos has now fixed.

To elaborate: On a few occasions I used an existing system as a basis for a new one. To make it look different enough, I changed its size with FLSysCalc, and semi-manually left-right-mirrored it. Then, I replaced the Faction constellation i.e. Rheinland Navy + Hessians with Bretonia Navy and Mollys. But now that paths can be generated a whole lot easier, this approach is now redundant.

FLSysCalc might still be usable if all pos_begin and pos_end entries are changed into just pos? Each path would have two pos entries then; not sure whether one would be ignored? Also, afterwards all the _begin and _end suffices must be restored.


The main error checker that I use is FLScan, mainly to eliminate those very obvious yet overlooked errors (e.g. missing base files, undefined archetypes and loadouts etc.) Afaik FLScan doesn't even check whether the legs of a path properly connect. So, no real loss here.

Posted on: 2018/12/8 10:04
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#43
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
I should be able use two pos values, if you like (although then you'd have to supply both, as there's now way to tell if begin is missing). There's also the option that having the plugin deliberately prevents the patrol paths from being read. Well, not really a big deal with paths, but if there was a similar trade lane plugin, it would hide those from things like Companion.

I've had the thought of using a separate file, allowing all your custom patrol paths and trade lanes to be stored in a single file (per system), The tool would then take that file and generate the equivalent FL version, which you would then (manually, possibly automatically) insert into the system file.

Posted on: 2018/12/8 14:58
Top
Moonhead
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#44
Home away from home
Joined:
2010/2/22 0:47
Group:
Registered Users
$$$ Supporters $$$
Senior Members
Posts: 928
Offline
Quote:

adoxa wrote:

I've had the thought of using a separate file, allowing all your custom patrol paths and trade lanes to be stored in a single file (per system), The tool would then take that file and generate the equivalent FL version, which you would then (manually, possibly automatically) insert into the system file.

Sounds great, I suppose, but I do not fully comprehend.

Posted on: 2018/12/9 0:08
Top
adoxa
Re: Request: an easier way to implement paths (no idea whether this is even possible)
#45
Home away from home
Joined:
2009/8/16 2:58
From Qld, Aus.
Group:
Registered Users
FLServer Admins
Trusted Speciality Developers
Senior Members
Posts: 1957
Offline
I'm not entirely sure of exactly how I'll format it, but given something like:

Code:
[PathPatrol]
nickname = Zone_Li01_path_navy6 ; underscore & number appended automatically
sort = 99
toughness = 2
; etc
; path_label, if absent, could be based on nickname, taking everything after "path_"
pos = <begin point>
pos = <next point>
attack_ids = 24 ; specific to this leg
pos = ...

[PathPatrol]
...

[TradeLane]
; normal common stuff
start = <number of first ring>
begin = <point of first ring>
end = <point of last ring>
; still haven't decided how to handle ring-specific values

[TradeLane]
...


you would end up with a file (or maybe stdout or clipboard) containing the proper Freelancer zones/objects.

Posted on: 2018/12/9 0:23
Top
Top Top   Previous Topic   Next Topic
« 1 2 (3) 4 »

  Register To Post