Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
all explained.
A recent post rekindled my interest in these. First, let me say I am willing to deal with mutually exclusive visbits only. The engine doesnt properly handle two systems at once, it cant chose when to move you to the newly visible one, and a bunch of other crap that is just really the bad kind of hacking.
So... I just spent about fifteen minutes typing up an explanation. After reading over it, I realised it didnt make any sense, even to me...
So I made a diagram, that I hope will explain. (see attached image)
Ok, so for my test, i had two stacks of systems: 201, 202, 203; and 204, 205, 206.
In the diagram, the dark arrow represents the only declared link, and the ligher arrows are all the links the automatic recoprocal link generator builds.
As you can see, it doesnt matter which of the stack it links too, it only matters which it links from. If system 206 (the bottom of the right stack) links to any of the systems in the other stack, you can jump from 206 to any system in the other stack, but you can only jump back from system 201. The reciprocal link generator ignores 202 and 203, once you get there, you are stuck. Also note that 201 (in every test) will be able to jump to any system in the other stack.
What does this mean for the average visbit developer?
Well, if the stacks are only 2 tall, as is normally the case (ignore the bottom ones), then linking 202 to 204 and 205 to 201 will let you jump from either 201 or 202 to 204 and 205 (every combination therof) and back.
To make a one way jump from 205 to 202, set a link from 205 to 202, then leave 201 and 204 invisible. Indeed, you can make an entire network of systems sitting underneath invisible systems, and the under-systems will use only the jumps you explicitly assign, all of the reciporical links are reachable only from the invisible system, so the player cannot use them.
As an aside, it says in the bible that two systems must be both in the same place and have the same name for them to be counted as the same system. This is not the case, they can have a different name. Note, however, that when you are jumping, it says "Hyperspace destination: " And then the name of the lowest ID system, regardless of the visibility of the systems and which system you are actually jumping into.
One behavior set i was not able to systematise was the jumps the map actually displays. If you are in a system, it will always accurately display only the exits you can jump through. The behavior is unpredictable, however, when you are not in the system. with the one way out jumps. Sometimes it hides the jumps, sometimes it shows them. It must have something to do with which order the map is traversed in by the display.
I hope I've explained one of Novas biggest quirks sufficiently. If anyone has any other strange behaviors they would like me to test, I would be glad to.
All right, our theories weren't quite as opposed to each other as I thought. Mine was based on incidental effects from work on getting rotating systems to work, and in a test I just did, you're right (and on the scale I worked on to come up with my original result, I was right too. I just didn't get to the "left stack" part of it).
As a guide, that looks pretty good, although it could stand to be clarified (the question is how it could be clarified, with such a complex subject).
NebuchadnezzaR said:
If anyone has any other strange behaviors they would like me to test, I would be glad to.
Well, I'd like to request that you not look into the behaviour of spob-based weapons . I'm about ready to publish (yet another off-shoot of those rotating systems ).
Righto. Wouldnt want to steal the thunder of the noble.
Yeah, it could use clarification, but it really has enough examples that everything can be extrapolated, as far as I can tell. If there is anything specific that someone doesnt understand, I can fix it. The unwieldy language is sort of there because it has to be.
Thanks! This will be very useful to me in Arpia 2 ;).
Now that's reverse engineering of the engine... So the actual implicit linking algorithm, once a link from x to y is found, seems to be this: -first, add links from x to all systems that are colocated with y -second, take the system colocated with y that has the lowest ID (let's call it yMin) -third, add links from yMin to x and all systems colocated with x
Therefore, all links, from systems other than x, to y and colocated systems are missing, and all links, from systems other than yMin, to x and colocated systems are missing from what we would expect. Of these missing links, the reciproqual link exists for yMin to anything colocated with x (other than x), and for x to anything colocated with y (including y, if different from yMin), other than yMin.
Therefore, I think the easiest way to implement a one-way hyperlink, from system x to y, would be to have an invisible system "behind" y, with a lower resource ID yMin, and just declare a link to y in x - that's all. Check: according to the algorithm, the link from y to x will never be made. Advantage: the one-way link you wish is explicit in the resource, making reading it easier, and there just needs one "dummy" system, with a low resource ID however (which may make project management a little harder).
The only problem I see with this hack is that, if Matt reads (or not) this, and decides to update the implicit linking algorithm, then plugs that make use of this will be in trouble.
Theres no reason to update it, since it works fine for non-fancy stuff.
And, yeah, I did include one to many invisible systems in my one way link model, but i was assuming that you might want a one way link to X, too.
Yeah, you summed it up rather guide like. Its rather strange behavior, I think. So to connect the two stacks, you need to link from everything X that isnt X min to something in Y (doesnt matter) and every system inY (except ymin) to something in X. This is actually much more efficient than I had been doing... I never even realised.
Zacha Pedro, on Mar 10 2005, 10:42 AM, said:
The only problem I see with this hack is that, if Matt reads (or not) this, and decides to update the implicit linking algorithm, then plugs that make use of this will be in trouble. View Post
Well, I reckon I can always get more systems implemented "in case", though I really don't think it's the kind of "hack" Matt would consider rendering useless
The thing is, the algorithm is basically buggy. If a system that has more than one version is linked to another system that has more than one version, not all are connected together (I think the algorithm was meant to handle connections from a static system to variable system and back only). Matt may decide that this needs improving. Of course, I don't think he will, but that's just like using an undocumented/unsupported-but-that-still-works API: nothing tells you that Apple (for instance) will keep supporting it/making it work the same way.