Here's what we think

The locked jumpgates are the FLHash of the nickname of the jumpgate objects in question. I assume that when the game loads, it basically stores objects in a hashtable, whereby it uses the hash of the nickname of the object to id the item, and be able to access it. How? dunno, but it's a constant time search operation so it makes sense. The game, therefore, references all objects by hash.

How it makes gates locked I dunno, whether it uses different types of jumpgate object in the engine to set a flag to being locked or not I dunno. Not a games programmer, but that's how the file works. On starting, it most likely parses the file and loads up the fact that objects with that hash are not accessable.

Now, for gates/holes. I haven't seen how the game defines what is a legal/illegal path. We note that legal = jumpgate, illegal = jumphole. Where this is actually defined (solararch?) i do not know, but since most people use either a jumpgate or a jumphole, and not custom ones, it appeared to not be something relevant at this time. The alien jumpgate is assumed to be illegal.

The paths generated are "shortest" paths, in the terms of numbers of system. Legal paths are shortest using jumpgates only, illegal are shortest using jumpholes only. You cannot plot a nav map waypoint via illegal, only legal appears to allow this to occur. So therefore, for navmap purposes, we assume only jumpgates matter - it appears to be a fair assumption.

The algorithm is quite simple, it's a shortest path algorithm. It start with a system, find the systems connected to it via jumpgates, and then map those as being 1 path (so that's like Li01, Li02, Li01, Li02).
Then it goes from the systems it's just found, gets their gates, and if they're not visiting a system already found (so from Li01 it finds Li02, Li03, Li04... and Li05), it will map those too (so Li01, Iw03, Li01, Li02, Iw03) If there was a jumpgate from li02 to Li03, it won't map this path - a shorter one from Li01, Li03, Li01, Li03 exists than Li01, Li03, Li01, Li02, Li03, so this path is ignored).

It does this until either all systems are visited, or it runs out of connections via jumpgates.

When it's doign shortest illegal, it does exactly the same - but using jumpholes instead of jumpgates. For System_shortest_path.ini, it does the same - but uses any method - so either jumpholes or jumpgates.

This is all, however, based upon assumptions - what constitutes a legal path, illega path, and shortest path. We THINK we've got this right.
It also assumes that there is no method of determining which path is actually physically shorter - for example, when going from Manhatten to New Tokyo, there's TWO paths of the same system length. That is because from Colorado you can either take one of two possible systems... I think it's Kepler and the other one... i can't remember there names, but it's Iw06 and Iw05. My algorithm doesn't descern if there's any method of working which is shorter phyiscally - both include the same number of jumps. Does it make a difference though? No, both paths plot fine depending upon which you have in the files.

We're also assuming that in system waypoints are determined by the game engine without our knowledge. Now this bit is pure pure assumption. I assume that when you (for example) plot the path from Li01 to Ku01 (manhatten to tokyo) that it loads this path up and displays it on the nav map. This path does NOT get reloaded as you, for example, jump into Colorado... it retains the path of Li01, Ku01, Li01, Li03, Iw06, Ku03, Ku01 - i've altered the path from Colorado (in the files) to be using the other Independant World (so Iw05), and when I jumped to Colorado the universe nav map did NOT change course... so once loaded, it keeps that path loaded.
So the assumption is that when you're progressing, it loads the path up and displays it on the nav map (universe map). However, when you VIEW each system individually, it utilises another hardcoded method to determine the waypoints within the system. I assume it searches for any legal method of getting from the system to the next system on the path. So an internal search goes for the jumpgate that has a goto line for the next system. eg, in Li01 it searches for the jumpgate that will go to the system Li03, and allows waypoint plotting using shortest path within the system (tradelanes or space dependant upon location) to sort out where all the waypoints lie.
When you jump to Colorado, it looks at the pre-loaded path and sees Iw06 as the next location, so looks for the jumpgate (legal path) that goes to Iw06. Once found, it uses that internal waypoint system to plot to that location.

Now I say once found... not strictly true, as if it attempts to find a non existant jumpgate, it actually plots to the sun.
I haven't tried putting objects higher in the order of system layout THAN the sun to see if it plots to the sun or the first object reference in the system file (order of loading into hashmap?). Anyway, it doesn't crash.

Having path files altered also didn't cause crashes - hence how i tested that it loaded one path file and stuck to it as you progressed, instead of re-plotting every time you jump... so that doesn't cause crashes.

I did find that it says "no path available" when no entry exists in the Shortest_legal_path for that jump. I haven't tried removing ALL paths for that system, just the odd one - but that's when the message appears.
If you have an incorrect shortest path file, so shortest_legal_path professes to have a root from Manhatten to Omicron Alpha available, it actually plots it in the Universe Map as per the root stipulated (try it). However, in the systems themselves, on the nav map, you find it behaves strangely - something I pointed to earlier. It plots just fine until it hits a system that has no jumpgate to the supposed next system in sequence... this for me was Ku03 to Ku02... there's no jumpgate. There IS a jumphole (which is what the shortest_legal_path file plots out) but no jumpgate - so it set the waypoint to be New Tokyo's jumpgate.
When I arrive in New Tokyo, it's NOT on the overall path in the shortest_legal_path.ini - so no waypoints existed in the system view for this system. If it loaded up the New Tokyo to Kyushu path, it would have plotted points, but it didn't... so it doens't. I had to jump to Kyushu before the waypoints picked up again.

So this proved that having a path file which didn't match the actual real path available does NOT cause crashes. If it's halfway through journey (so you plotted path from Li01 to Hi01 whilst in Li01) - it works fine until you reach a system that doesn't have a jumpgate its looking for - but no crash.
If it works from attempting to plot a travel from Li01 to Rh01, whereby the shortest_legal_path file had a path of Li01, Rh01, Li01, Rh01 - when you launch, it plots to the star.... still no crash.

So I've not experienced any crashes with bad paths whatsoever... which contradicts directly with what others are saying. Only issue being, they're using mods. I did it on vanilla FL, which is why I was confident enough to therefore generate path files for mods

Some notes - my path generation takes into account locked jumpgates, IF the mod maker tells me the nicknames of locked jumpgates in their mod These jumpgates won't be included when generating paths.
This matches Freelancer itself.
The storyline we THINK uses the system_shortest_path.ini file, but I think the storyline also manually plots waypoints for you, so I am not convinced. All I do remember is that IF the system doesn't contain an entry in the systems_shortest_path... then you get a crash. I haven't tested this in the past 4 years, so it may be worthwhile testing it out, but this only crashes (from memory) when jumping. I don't think i ever tried to plot waypoints though, but like I said before - I don't exactly have lots of time to start experimenting with Freelancer to try and work out the way it all works

Hope that helps clarify what we BELIEVE to be the case with Freelancer. If anyone knows different, suspects different, or disagrees - then please contribute Tis easy to argue against, but when you're asked to prove or back up, things tend to fall silent.

hmmm
it looks like once again posting my observations and views about a problem leads to troubles with certain members of this forum

calling paths that are working "incorrect" is very very stupid in my eyes and asuming that somebody did mistakes with something very easy such as gates and holes is also not the best way to find out how correct paths are working

i know rankor and his work long enough to know for sure what his modding abilities are and judging on this and the abilities of almost every other good mod creator which created some impressive mods i simply exclude the possibility that they did something wrong with the systems

well - im not up for more argueing about "incorrect working" and "correct not working paths or blames about bad asumptions and before more discussions about right or wrong appear here i simply leave and find a solution for this prob somehow else

Has anybody else just sat down and studied the path files, you will find that they are in a preset order, just like several other Fl files. The ones that FlScan produces are in a random order and includes every jumpgate/hole whether it's locked or not, the ones that Chips has uploaded for StarTrader & Rankor are just as random.

Rankor’s Shortest_Legal_Path.ini starts in Li01 and makes connections to Li01, Li04, Li03, li06, En01 etc. Then it goes to Li02 and connects to Li02, Li01, Iw03, Iw04, Li04 etc, when it probably should have been Li04 connecting to Li01, Li04, Li03, Li06, En01 etc.

**shuffles off with a new headache**

I confirm Chips general account -- very helpful thanks -- but I'd like to add a couple points.

==

(1)

As far as the locked jump-gates work: there's at least a couple sorts. Until the middle of Mission 4, all jump-gates out of the central Liberty area are locked. However, these traversals are generally included in the path files: during the compile-time shortest-path computation (which Chips' utility emulates), they were not specially flagged as locked.

Other gates/holes become unlocked during the campaign (the NY-Magellan gate in Mission 4, the Cambridge-Leeds hole in Mission 5, etc.) but they *were* flagged as locked during the compile-time shortest-path computation, so they'll never be used in the path files.

==

(2)

The assumptions or theories we've drawn about the path files are, strictly speaking, theories -- just like any scientific theory. But like good scientists, we've made hypotheses and separately confirmed things based on numerous tests. So when you hear Chips talking about beliefs (what we "THINK", this just means he's being a good scientist, something the opposite of making wild guesses.

I'd like to re-emphasize that we've thoroughly checked Chips' algorithm against FL Vanilla, and where Chips' algorithm shows differences between the given shortest-path files, it's irrelevant differences. (With equally-short paths, an arbitrary one is chosen.) As Chips mentioned, we've confirmed that it doesn't matter.

==

(3)

Maybe the names for the two types of pathfinding are confusing, so I'll begin with a definition:

inter- "between"
intra- "within"

inter-system "between systems"
intra-system "within a single system"

If you think about it, it's a great idea to precalculate inter-system paths. Otherwise the game would have to do a really thorough search through the entire sector every time you wanted to plot an inter-system path. This is a major calculation, and it would definitely cause a noticeable lag in your framerate -- a significant one by the standards of 2003 when the game was published.

With inter-system paths precalculated, all the game needs to do is look up the shortest inter-system path in a table, find your current system in the link-list, and plot the shortest intra-system path between your ship and a jump-gate to the next system in the link-list. This is a very simple computation, in comparison to a very complex computation (in terms of processing overhead). The only time an intra-system path must be calculated is when you're in a system or you pull up the map of a system (as opposed to the map of the whole sector). This means that at any time, only one single intra-system path needs to be calculated.

Of course, we cannot precalculate these intra-system paths, because they depend on the location of the ship. It varies at runtime (that is, while the game is running), so it has to be calculated at runtime.

So again, when Chips observes that we "THINK" that this is how it works, it's more-or-less a logical certainly. Doing it some other way would be totally infeasible from a programming perspective, and doing it this way is ideal. And the facts seem to match this analysis completely.

==

(4)

Considering the high probability that Chips' algorithm is correct, and the unknowns about the game's arbitrary tolerances, I would strongly encourage people who are having trouble with the pathfinding mechanism to assume that Chips' paths are correct, and the problem lies elsewhere. My guess is that there's an arbitrary limit to the number of viable paths in a given system (e.g., there's a limit to the number of jump-holes or jump-gates). So it's probably something like: if the paths are generated correctly, the game chokes when there are too many of them. These things can be tested, but only by people who are having the problems.

@Bejaymac: we've checked the vanilla version, and the order of the entries is arbitrary/irrelevant.

@Swat: The point you're apparently having problems with is the following: it is possible that a correctly working piece of code can allow a bug to appear, while a incorrect piece of code can suppress the same bug.

This is perhaps difficult to wrap your mind around, if you don't have prior programming experience. But believe me, people who are used to debugging know the difference between code that allows the bug to present itself and code that actually causes the bug.

> calling paths that are working "incorrect" is very very stupid in my eyes

Calling an intelligent discussion "stupid" on the grounds that you don't understand it -- now that is stupid.

Well, here is what I did:
Where there were "locked" gates and holes that I could not unlock by
simply removing the npc_locked_gate/locked_gate group file...
I removed the original gate or hole and then replaced it with a "new" one which
then unlocked the pathway.
One of these was the Dyson Airlock that accesses the Dyson Sphere.
It looks somewhat odd to see a regular jump gate positioned exactly
where the Dyson Airlock was but a short story "explaination" justifies the
reasoning behind why the Order replaced the Airlock with an armed gate.
On the other side, originally no jump hole or gate could be found
to provide an exit from the Dyson Sphere back to the Outer Dyson.
It was invisible for some odd reason...so
I removed the invisible hole (with its zone)
and replaced it with a working jump gate oriented just as is should look
as though you just entered from the other side.
(inverted, about 20k above the plane and shrouded in a cloud)
I labled them both as "legal" paths.

Another one that I decided to dump after the fact was the core access through
the airlocks of the nomad lair (St02_to_St02c) .
At first, they remained locked and there seemed to be no way to unlock them.
So, I added new access holes to the core.
That partly worked, but then I encountered an odd problem.
No matter what I did to orient a player ship inside the core,
it always ended up outside the core. So, I simply left that
access point "closed" and removed the extra access points I had used
to get there. (I just didn't see any reason to be outside the core
and seeing through much of it because of the "faces" being visible
from only on the inside)
To counter that aspect, I've built a new, complete lair with a core incorporated
within it. The only drawback so far is creating a .sur file that will work with it.
Thus far, I haven't installed it nor have I tried to test this out.

ANYHOW...
This is just saying what I've done to unlock certain objects that would otherwise
not be unlocked. But I don't know if this has anything to do with the path crash
problem. Maybe there is a correlation with it.
At this point, I'm just trying to remember when I began noticing the crash
problem. It's been a long time.

I do think however that my problems began when I started replacing normally
locked objects with working objects as legal pathways. Before that,
I think the path generator worked fine.
This has me wondering... I could probably go back into the system files and
locate those objects that are flagged as "legal" , then remark them to
"illegal" to find out whether or not this might correct the crash problem.
I'll have to refer to the original system files in Vanilla to see if I can find
a difference in the property flags between legal and illegal pathways.
I'm taking a wild guess that I'll probably find this difference.

Some time ago, I was wondering whether or not those hash codes associated
with the gates/holes group file had some reference
(a simple number or pair of numbers) that told the path generator which one
was legal or illegal.

Hi guys.

I am saddened that someone seems to be having a go at others over preferences and methods.

Swat is just as interested as anyone else in a working utility, and that's what Chips has so kindly volunteered to produce for us. Without mentioning name, (yeh I know you can just go back up this topic yourself to see who, I ain't so daft, just pointlessly polite!) I do hope you will quit it, it's sad to see.

To clear a query or two:-

Here are my locked gates from my initialworld.ini:-
<pre><font size=1 face=Courier>;Gates usually locked Post-Missions
[locked_gates
;locked_gate = 2926089285 ;St01_to_St02_hole
;locked_gate = 2926433351 ;St01_to_St03_hole
;locked_gate = 2460445762 ;St02_to_St01_hole
;locked_gate = 2263303234 ;St03_to_St01_hole
;locked_gate = 2284213505 ;Li05_to_Li01
;locked_gate = 2293678337 ;Li01_to_Li05
;locked_gate = 2541540999 ;Iw03_to_Li01
;locked_gate = 2963174661 ;Li01_to_Iw03
;locked_gate = 2711806985 ;Ku06_to_Ku07_hole
;locked_gate = 3051899916 ;Ku07_to_Ku05_hole
;locked_gate = 2640501769 ;Ku05_to_Ku07_hole
; Easter Egg Systems - Player is allowed to go to these systems, but not NPCs
npc_locked_gate = 2259929730 ; Hi02_to_Ew06_hole
npc_locked_gate = 3128701573 ; Hi01_to_Ew05_hole
npc_locked_gate = 2974773122 ; Ew01_to_Li01_hole
npc_locked_gate = 2942653837 ; Li04_to_Bw05_hole
npc_locked_gate = 3030328194 ; Ew04_to_Hi01_hole
npc_locked_gate = 3163920771 ; Bw05_to_Li04_hole
npc_locked_gate = 3128521351 ; Hi01_to_Ew04_hole
npc_locked_gate = 2868648589 ; Li01_to_Ew01_hole
</font></pre>
Somewhere I saw a comment about whether or not I have a jumpgate to Earth from New York? No, there isn't one. I plotted from Earth to New York and it gave me a path with about 28-30 waypoints, can't remember exactly how many - but that seemed about right. Couldn't test it because the game crashed on launch.

I haven't yet checked to see if there were jumpgates all the way, the reasoning here seems to be that if there are not then it should say "no best path", is that correct?

When I moved to California Minor and plotted a single system path via the one and only, vanilla-FL-too, jumpgate to New York, it crashed on launch again. When I launched first and then plotted, it was fine until I docked with the jumpgate - then when I came to the midway point in the jumpgate tunnel effect, where it fades to white then it should come back to nice colours before spitting you out into the new system, it crashed.

So it's clearly not checking only proximity systems each time, or it would not have crashed in a single-jumpgate path. It must be stumbling on some entry (or entries) in the path files that has nothing to do with California-New York.

Legality of jumpgates:- Reputation= in the system's ini file specifies a legal faction (police and navy groups).

Now - some of my new system jumpgates are rep set to new legal factions.

Jumpholes have no reputation entry.

By the way, who is it who keeps saying all jumpgates are Ageira? Wrong, I think?

And someone also took umbrage to me saying that the path files caused the crash? They do, you wally! What do you think we're trying to fix else then?

We do need to find out why files produced by it are causing crashes, so that we can make working path files easily, rather than by hand.

The curious thing is that files produced by FL Scan also cause similar (if not the same) crashes. With my old files in this same mod, with missing paths to the new systems, the game doesn't crash, just gives me "no best path" between my new systems. When I did add earlier systems manually I had no crashes. But now I have several new systems to add.

I will do a comparison between the old and new files when I get some time, and between Chips' files and teh FLScan files, its just that time is tight right now, as for most people.

So for goodness sakes stop being so bloody touchy you guys. Chips is doing a fine job out of kindness, and I'm sure has better things to do with his time than manage cranky argumentative types here.

Gorblimey, Lorluvvaduck, Fallorrayoosyewlorrar!!

Thanks again Chips.

Hey Rankor,

It could be a lot of the stuff you mentioned, from switching legalities to modifying connections which are excluded by the game as "special cases".

A word of encouragement and strategy on debugging, which should help not only in this situation, but in general as well:

Try to figure out theories what could be causing the problem, guess the likelihood of each theory, and figure out how long it will take to check the theory (that is, either to prove or disprove it). Based on those two things, figure out the order to check the theories. (So feel free to check the less-likely theory before the more-likely theory if the less-likely one will take a lot less time to check.)

Good luck!

Edit: @Startrader: I don't know who or what you mean, but certainly I am not "having a go at others over preferences and methods." Swat has made a number of inflammatory comments (as usual), and a number of incorrect assumptions and counterproductive confusions. In return I've explained more-or-less patiently what he's continuously (and contemptuously) missing in the analysis. I'm not the one "having a go" and I certainly don't care what his preferences and methods are. Chips has been extremely patient with him as well, despite his name calling, contemptuous treatment of others ideas, and general bad conduct. So I'm afraid I don't see your point.


Edited by - breslin on 11/7/2007 2:50:11 PM

Right, I wish to dispel some incorrect assumptions people make. In my short first response to Swats first post in this thread, I asked him for his files so I could generate paths and compare. Failing that, I asked him to outline his methodology for generating his "working perfectly" paths.

Why would i do this? Why would this be of interest? I start with the sweeping statement that programs are never wrong.

Before you take umbridge, lets look at why the program is never wrong. What does the program do? The program executes a series of instructions, and returns a value.

Where do these instructions come from? Programs don't write themselves... so someone writes the instructions for the program to execute. Who is that? Me
What did I do? I sat down and worked out how paths worked... I've hand coded before after all, so I had an idea. I then mirrored my solution in code. The code IS my theory. Well, not just mine - Breslin and I. We've discussed this over half the thread after all So therefore the Program CANNOT be wrong... doesn't mean the output will be right, it just means the program itself CANNOT be wrong.

This means that I AM WRONG. That is, after all, a distinct possibility However, I have asked Swat for his methodolgy. So far, only one person stands out as contributing in theorising HOW paths are made - that's Breslin, not Swat. Many have contributed overall, but we're talking the theory of path making. What consitutes a path? For Swat to come and immediately dismiss all generating programs as being the root of all problems without actually even remotely TRYING to contribute, is pretty insulting. After all, has he READ the thread? Or has he just waded into the last few posts and started posting his assumptions... which, incidentally, are all based on assumptions as he hasn't seen people's code Lets please ignore this for now though, here's a chance. What consitutes a path?

Shortest
Legal
Illegal

So everyone who hand codes and has NO issue - please, how do you decide what your shortest, your legal and your illegal is? Lets compare theories here and get a consensus - as that way Breslin and I can pinpoint exactly WHAT is wrong somewhere. So how do you decide? After all, you all have working paths when hand coding, so if we can narrow down the PERFECT method for plotting paths, we can model it. Remember, hand coded methods work perfectly - and I can program that hand coded method into a program IF it's a correctly working method... as PROGRAMS are not wrong. Anyway, a starter for 10.

Our theory is that the ARCHETYPE of the jump object defines it's legality.
So Legal = JUMPGATE
Illegal = JUMPHOLE, ALIEN JUMPGATE, ANY OTHER SELF MADE ARCHETYPE.
Shortest = ANY SYSTEM CONNECTION!

(system connection is defined by the goto = entry).

Paths are then plotted through systems, for each of the three types, by using only the above methods. So legal is only using archetypes that are jumpgates.
Illegal uses ONLY Jumpholes, Alien Jumpgates etc.
Shortest will use either.

The algorithm simply finds the SHORTEST possible path between systems via the number of systems traversed. Sometimes a route will have TWO same length routes available (like New York to New Tokyo, as either Kepler or the other Independant World System can be used to reach it)... but only one will be mapped.

Now, grey areas have been tested. So when two paths exist which are, for example, 3 jumps from target to destination (manhatten -> Colorado -> Kepler -> Shikoku = 3 jumps. Manhatten -> Colorado -> Galileo -> Shikoku = 3 jumps, both from same start to same end, but use different intermediate systems to get there) I've plotted BOTH paths and tried BOTH in the files. It worked without crashes... this was done with other similar routes, NO crashes... so we theorise from actual experiments that the root doesn't matter, as long as the root given actually exists in correct format!

Does this seem reasonable? It's logical, does it appear logical to others?
From our theories (Breslin and myself are the only two to discuss this point) we think we've got the theory of how these things work down. If you disagree, have alternative viewpoints - then please air them. But lets make NO mistake, the program is NOT WRONG - if there are errors appearing, it's our theories that are wrong and needs adjusting.

Onto a few other points - the pattern of entries in the shortest paths should be irrelevant. This is based on assumption, if you can follow the assumption - then please do, and let me know if you think it's reasonable.

The theory is this - if the pattern of the appearance matters, then they must have hard coded it into the game to only allow that pattern. This, simply put, is problematic and difficult - far more difficult to ensure it's all in a set pattern than just coding it to read paths in and create a table linking them all up
Secondly, if this were the case - new paths wouldn't work. It'd break the expected pattern... doesn't logically follow that the pattern matters.
Finally, it's possible to reinforce this experimentally. Shuffle the patterns about, does it cause crashes? Let us know if you have success with this experiment, I don't have time and I've theorised from the two previous points I make on this... I may be wrong, theories tend to do that as they're based on available evidence only
Now the order which my paths appear is simple... its the order in which they appear in the Universe.ini file.

You'll have to excuse if Breslin and I appear to be a bit tetchy at times though - we've discussed this here, and in emails, extensively. We've discussed our theories on how the game handles paths - we've backed them up with experiments to re-affirm our suspicions. We've only invited people to participate in the discussions, not many appear to have bothered though
We then created what we consider to be a solid representation of our theory. If our theory is right, and I've coded it correctly (another potential error location), then it should work fine.
We've then asked for participants, and thankfully two kind contributors have come forward, and given us feedback about the situation.

Now this is where things get a little sensitive. To imply our paths are causing issues means our theory is wrong. This is fine, the problem is that we need to then decide how the theory is wrong. We cannot do this just by hearing a crash occurs somewhere... it's not possible
The big thing is that other things in a mod apart from paths may cause crashes. Other crashes in a mod MAY be intermittant, and therefore not transparent.
if plotting a path before you de-dock causes a crash, and a plotted path works fine until jumping... when it crashes, it (to me) indicates an INTRA system problem, not inter. If it's inter... it'd crash when you plotted it from space, as well as from land... the fact it plots it fine until the system is loaded up (or another system is loaded up) appears to point at other areas. The path, if it causes a crash, will crash whenever it's plotted...

Why? Once more, based on evidence. The PATH files don't do much more than provide a link to which systems you follow. This is reflected by your universe map.
Another thing, why do I not think the paths are wrong? Well, I put a path from li01, rh01, li01, rh01 - and plotted a path to Rheinland from Manhatten... without physically changing jumpgates.
It plotted to the sun. The path does NOT exist. It can't even find the jumpgate... but it didn't crash... so why suddenly would an incorrect path cause a crash?

Hmm.

Perplexing, no doubt there is far more complication to paths than we are currently allowing for - apart from the fact people manage to perfectly handcode these paths... so once again, I ask people to provide their methodology in how they generate paths

If I have time, I may well write another program that will compare files, and pull out the differing paths.

Edited by - Chips on 11/7/2007 4:21:00 PM

Hmmm.

Guys you need to understand Swat a little bit. He's mostly easy-going and very helful. He's unnecessarily curt on occasion and that's the start of the problem. I got past that and look for most peoples' good sides, having a problematic temper myself! But don't take him the wrong way, he's just very cynical because of previous empty promises. I'm guilty of the same as far as Dynamic Economy - my pal Gibbon was very indignant when I poked at Grover for his inuendos, who still hasn't resurfaced...

Nayway!...

Right.

Paths. This is a very important issue.

Manually I did do the same as you said, it was a couple of years ago and memory fades - 2004/5! Whether right or wrong I just used legal = jumpgates, illegal = holes & shortest = either. If I'm not mistaken I did check standard FL and saw that this was followed by the standard files. However I will check that again.

My starting point will be to compare the files you made for me with the ones I have that don't have the latest systems, and then I will decide on my shortest way of discovering wherein may lie the problem, not sure of a strategy as yet cos no time to do it, maybe next week.

Cheers pals.

Oh - Breslin - the CMP importer still crashes Milkshape 1.8.2 - any plans to fix this?

Thanks.

I went digging into the original path files and the new path files that the
Explorer generated for me.
This is something I found interesting:

The path Li01 to Iw03 (direct though the old gate in the badlands)
That's NY to Magellan (in the story line)
Showed up in Systems Shortest, Legal and illegal paths (all three of them) as:
Path = Li01, Iw03, Li01, Iw03 !
For it to show up in all three files seems to me somewhat contrary
or perhaps in conflict with the following data from the originals....

However, In the original files:
This path does not exist in any of the files!
BUT
It did show up this way in legal paths:
Path = Li01, Iw03, Li01, Li02, Iw03 (this has to be the jump gates)
(That's NY, California, Magellan)

Then in Illegal paths:
Path = Li01, Iw03, Li01, Li04, Li02, Iw04, Iw03 (this has to be the jump holes)
(That's NY, Texas, California, Cortez, Magellan)

Then in Systems Shortest paths:
Path = Li01, Iw03, Li01, Li02, Iw03 (Identical to the shortest legal path)

I believe your theory about using either the jump gates or jump holes in
finding paths. What I've just seen makes perfect sense.
The actual shortest illegal path follows the jump holes in a round about way
to get from NY to Magellan.
So, when you're trying to map from one system to the other, it's looking for
the systems shortest path..which happens to also be the shortest legal path.

I sense that what I've just found here is the cause/basis of my crash problem.
It's because the paths are mixed up. It started with the "unknown path"
of New York to Magellan (direct) which "does not exist" except in the story.
Once a player completes the story line, THAT gate remains unlocked and shows
up. If I remember correctly, I could even map directly to Mactan Base from NY
IF I was close to the gate itself. Otherwise, the path generator would pick the
standard shortest system path which ignores that gate.

This gives me reason to take a deeper look into the new path files
and possibly simply remove the reference to that particular path
where it occurs in all the path files or narrow it down to one or the other.
For instance, the path from NY to Magellan should be considered as either
legal or illegal for it to exist..but I don't think it should be in both.
But, choosing for it to be legal or illegal has me wondering whether or not
it will still be a source of conflict with the other existing paths.
(Simply because in the vanilla files, that path does not exist)

It seems to be a "fluke" that it's listed in all the path files.
This has also got to be partly my error considering I replaced the
story line gates and holes with "new" ones.
This means I've ignorantly thrown a monkey wrench into the entire
pathworks when I did this were they occured.
In this case, that's these pathways...
NY ->Magellan ->Leeds, Omega3->Cambrige ->Dublin ->Leeds ->Tau23 -29
->Kyushu ---Chukogu->Tohoku, Sigma-13->New Berlin--Frankfurt->Hamburg

The FLEx generated the paths faithfully, but I think here that
the game path engine can't tell the difference between them.
That has me thinking this is causing the crashes.

It think perhaps my solution might be to remove the duplicate entries
where the legal and illegal paths overlap. Then just make sure that
the new paths (from the story line) are annotated in illegal paths.

If I remember correctly, when I've created a new jump gate (or alien jump gate)
I was given a choice whether to make it legal or illegal.
I think this option tells the Explorer to generate that information
in the appropriate path.ini.
Where I screwed up is making those paths "legal" when I installed the replacements. This forced the explorer to annotate that information
in all three files.
I'm going back in and remove those duplicated entries from the
legal and shortest path.ini's. In effect turning them into
illegal paths. Then test this out.
Worst that can happen is I'll simply get a CTD. So I'll keep a backup copy of
the mod path files just in case.

What do you think?

Edited by - Rankor on 11/7/2007 7:54:15 PM

Thanks Rankor, if a path exists form NY to Magellan in the files, the reason it's highlighted is this:

---

In a nutshell, I removed all the locked gate references (in effect, unlocking all the gates and holes)
However, in some systems where this did not appear to work, I removed the holes and gates, then replaced them with functional items.

---

The reason for this is if a list of locked gates exist in the game, these won't be included in path generation... but if there are none, then all jumpgates/jumpholes will be considered viable means of travel So if there is any form of jumpgate or hole to magellan from New York - it'll find it.

Another thing to note was this:

---

I will check it out mate - there was one or two things i noticed when compiling files... not ALL system files were included. When this occured, I used the original Freelancer files to replace them - specifically Bw03 and Bw04.

---

This is because not all your mods systems are/were included - so I overwrote existing freelancer ones with yours instead... so that where a system didn't exist, it used an original Freelancer one. However, I am pretty sure Iw03 and Li01 were your files, not original Freelancer

You are completely right - legal, illegal and shortest should not be the same path unless there is both a jumpgate and a jumphole (or alien jumpgate, or any jump object which doesn't have an archetype of "jumpgate" which goes to Magellan as well! There does appear to be an issue here, which should be easy to troubleshoot as to whether it's a genuine mistake or not... just by simple verification that in Li01.ini there is a jump object to Magellan - if there is, how many and what type

Currently at uni, when i get back home I'll see if I still have a copy of your files, and re-run it to find out what happened and compare it to the system files for where my errors may have arisen

Cheers!

Edited by - Chips on 11/8/2007 1:04:24 AM

Few posts removed, either contribute - or don't. But no spam, and no flaming to defend folks. Swat is an adult, he can either help by responding to the requests i've made to him, or not. But no more trolling or anything else. Our time is far to precious to spend any more of it trying to explain things.

Read the thread, get up to speed (if you're new) and try to be helpful. All others will go.
Abuse of power? Do i look like i care?

oh man....what I've found so far looks like an unbelievable mess.

Paths that would normally be illegal are showing up
in the legal path file.
Here's an example: (New Berlin to Tohoku)

Path = Rh02, Ku07, Rh02, Rh01, Bw05, Ku04, Ku07

(in this case "Rh01, Bw05" is the jump hole from New Berlin to Sigma 13)
This happens to be one set of the jump holes I replaced because they were always locked. So it was logged into the legal path file when it really should
have been logged into the illegal path file. Obviously, I screwed this one up
and like many others in the same way.

This is what I found in the legal path file:
A) Path = Ku07, Rh01, Ku07, Ku04, Bw05, Rh01
Path = Rh01, Ku07, Rh01, MS01, Ku01, Ku04, Ku07

(A is the jump hole shortcut through Sigma 13)
((Tohoku, Honshu, Sigma 13, New Berlin

(B is the jump hole shortcut through "middle space" )
((New Berlin, Middle Space, New Tokyo, Honshu, Tohoku))

When I set up the jump hole from Middle Space to New Berlin,
(as I also did from Middle space to New London, New York and New Tokyo)
I thought I set that one up as illegal. But it shows up in legal paths.
I cannot be certain though as this has shaken my confidence.


Ku07 is the Tohoku System which is normally accessed via "locked" jump hole
during the story...
However, I did create a "legal" pathway from Ku04 to Ku07 by placing
a gate at the station inside the minefield and a gate near Tekagi's Arch.
So if I were to set up a "legal" path from Ku07 to Rh01,
It should look like this:
Path = Ku07, Rh01, Ku07, Ku04, Bw05, Rh04, Rh01
Inversely, the return trip via legal pathway should look this way:
Path = Rh01, Ku07, Rh01, Rh04, Bw05, Ku04, Ku07

It looks like I've made a really big mess here.
I've been going through copies of the path files and removing the
"illegal" paths from the legal path file.
There are many more than I expected to find.

Back when I first started experiencing ctd's, I used the FLEx to generate all new
path files (all three) then replaced the troublesome originals with the new ones in the hopes that this would correct the problem.
However, from looking at what I've got on my hands here....
I've made a hell of a mess.
The FLEx was just doing what it was programmed to do.