. /../StarMap2 discussion/ 12
absent more than alex
written by Shadowlord on Dec 22, 2008 01:03
It seems (I had forgotten) that Noctis internally holds the same coordinates for the star that are in starmap2. It negates the y coordinate only when it's showing coordinates to the player. All the starmap2 and starmap3 utilities and all of NICE except for NoctisMapper (apparently) expect the y coordinate to be the same as it is internally in Noctis.

Methinks NoctisMapper should probably be doing the same thing as Noctis (negating the y coordinate for display and having the +/- y axis direction reversed to match Noctis'.

Neuzd said:
Since on stramap2.bin there are no IDs, retriving the correct info for the duplicate is possible only if you know which of the 2 (or even 3, like DEATH) object you're interested in.
Actually... The ID is calculated from the star location. Example code from the starmap 2 -> 3 converter which calculates the ID for each starmap 2 entry, in order to search the sectors around the star to find what sector it belongs to:

You'd probably still prefer starmap2 to have the same order as starmap1, of course.
r'lyeh sweet r'lyeh
written by Neuzd on Dec 22, 2008 08:48
I don't have ADD, but I have different and equally valid excuses for not noticing some pretty obvious fact.

Damn, I'm a Java programmer!
I'll be modifying the java port source of Triceratops and have the ultimate (for my needs) version.

Thanks Shadowlord!
r'lyeh sweet r'lyeh
written by Neuzd on Dec 26, 2008 13:05
Sorry for the double post.
I split the thread as this Triceratops/StarMap2 discussion is only loosely related to the inbox topic and there is more to be discussed.

I found some other problems in Triceratops while trying to modify the source code.
First, the Java port seems to write a lot more than the cpp version; in the scan() function there are 4 instructions for wtiting the current entry in the starmap2 file, while in the cpp version it occurs only 2.
I also noticed that the CompareSM2E.compare() function has an error when checking for the code.

else if (a.code[i]<b.code[i])
should most probably be:

else if (a.code[i]>b.code[i])
By the way, I tried to fix something, mainly because I wanted to output the star ID so that I can generate a file with all the info I want, which I can feed to a MySQL DB (with stars IDs all my problems to identify one precise object will be gone forever).

Having so many problems with the Java port I tried to alter the cpp source, thinking that probably it would have been more reliable, but I noticed something strange there too.

In the end, not being sure if all the mess was caused by my modifications, I ran the original exe provided by SL and I found that there are some objects that get reported more than 1 time, and with different parsis.

LISDHA is a star that gets listed four 6 times. Ok it's a star part of the Grid and we already discovered these anomalies are hell to deal with, but anyways, I don't know how to proceed.
It looks that the correct one is the first one in the list, and that probably there's simply an error in the scan() function, or at least this is what I hope for.

I know I haven't been so clear, I wanted to point out that Triceratops seems to have some more problems than expected and ish we can find the origin of the problems.
absent more than alex
written by Shadowlord on Dec 26, 2008 15:27
I was aware there were some mistakes made in the java port (but I didn't know what they were), but it was only made as a quick attempt to compare the speed of java, c#, and c++ programs like triceratops. Though if it's writing more than the c++ version then oops for that too.

LISDHA (and others like it) isn't a bug in Triceratops. That's a system seed which exists in more than one location in the galaxy, which is to say that you can calculate the seed for coordinates and come up with LISDHA's seed in 6 different valid solar system locations in the galaxy. Because NIV does not store system location or sector location there's nothing in the starmap to say which location LISDHA is referring to, Triceratops writes them all out so that they will all be shown in NoctisMapper rather than just one of them (since we have no idea which one was originally labelled).

LISDHA's seed is 391.875000. All the systems like that have seeds ending in .[0-9]25000 or .[0-9]75000.

lost, not forgotten
written by Alex on Dec 26, 2008 15:43
I was wondering: but if NIV was modified to save a starmap2 directly, including coordinates rather than just that collision-prone hash (ID), and we updated the inbox/outbox modules to deal directly with starmap2, we wouldn't have to convert the maps anymore, would we?

The drawback would be that outboxes sent from old versions wouldn't be acknowledged, but well... we don't get many of them anyway, and we could send warnings about having to mark discoveries again in the few cases, after downloading the updated "vanilla" NIV. Perhaps it would be worth that?

As I mentioned in frespych, all these problems arise by the fact that NIV was a hobby project, coded without thinking to widespread use (and hash collisions, in the specific case of starmaps). The fact that it saved IDs and not coordinates was likely originated by considerations on reducing the size of both the starmap and the guide, and possibly because I didn't want to map everything to make it intentionally difficult to locate stars, perhaps thinking it would have added some fun.
r'lyeh sweet r'lyeh
written by Neuzd on Dec 26, 2008 16:00
Yes, I remembered the discussion about Grid members' seeds and that it causes them to exist in several places.

Though Empty Blanco (another Grid member) is present 15 times and most disturbing has different INDEXes (the 4th value: 0 for stars, 1...80 planet's position). It should always be 0 but I also read a 3, 6, 10....and even more disturbing, there's a planet listed!

Now, weren't all grid stars without any planet? Indeed they are, the planet listed as belonging to Blanco Empty is not a planet but an S06 star: Grey Star 8.

By the way, Grey Star 8 is another one with those round seeds that cause this problem (I'm using 'Grid member' but in reality I'm referring to those with strange, round IDs), so I'm assuming the problems will stack one over the other...

Still, the original EvolveSM seems to be more faithful to what you can experince in-game.

I hope you don't think I'm criticizing your works, all this is aimed to provide full informations in my next online Noctis DataBase, so I'm desperately trying to find a reliable way to have parsis calculated (yes, it's the only thing I miss!).
absent more than alex
written by Shadowlord on Dec 27, 2008 06:07
Side note: I'm going out of town for a couple days (and was entirely too busy to come on here today, though I left firefox open all day, heh). Just so it doesn't look like I stopped talking for no apparent reason.
lost, not forgotten
written by Alex on Dec 27, 2008 06:16
Shadowlord said:
though I left firefox open all day, heh
If you had this site and the chat frame in show, you've been stealing bandwidth! and are so banned

kidding
r'lyeh sweet r'lyeh
written by Neuzd on Dec 29, 2008 12:56
With some effort I managed to combine the informations retrived from EvolveSM starmap2 and the copy Ferinex obtained running Triceratops.

Looks now I'm missing less than 300 stars, most probably part of the outer rim, notably The Deepest Point is missing from Ferinex's Starmap2.bin, so I'm led to think it's the farthest points from the center of Feltyrion that Triceratops didn't scan.

I also decided to accept the parsis proposed by Triceratops for those stars wiht round IDs that are causing so many problems.
It's believable by now that each one of those triplets identifies one of the actual locations of the object.
It may be at least curious, to go see if BLANCO EMPTY exists in each of those 15 "places".

The awkward relationship of these stars (like the already mentioned Blanco Empty and Grey Star 8) is again due to their IDs. If I didn't screw up tonight when populating the tables, I should have avoided to bring this "bug" into my DB.

I really hope to finish very soon, so that I can finally dedicate to other (always NIV) projects and maybe also playing some Noctis, why not!
absent more than alex
written by Shadowlord on Dec 30, 2008 19:40
If I remember right, The Deepest Point is definitely outside the galactic boundaries. Triceratops is set up to not scan outside those, I don't remember if evolvesm does or not.
r'lyeh sweet r'lyeh
written by Neuzd on Mar 02, 2009 17:52
Obviously I'm always working on this front, so I have news.

This weekend I tried running a modified version of Triceratops aimed to scan outside Feltyrion's borders.
First attempt didn't go far enough, so I'm currently running another version which pars are 40200*1500*40200, instead of 40002*1335*40002.
(These numbers are for SL and Ferinex, everyine else: don't worry)
Hopefully I'll come out with some new labels (The Deepst Point is just one of those systems I want to track), sure it will take some time, about 45 hours I guess, but there's no other way.

Anyway, the StarMap2 I generated this weekend already has some interesting things to say, the most important of which is reagarding inbox32, which I am sure Ferinex used to update his copy of the Starmap.
What happens using inbox32 (isntead of the regular INBOX module) is that it imports a name even if that is already present in StarMap.
I'm not very sure if this "bug" is only limited to the labels being imported or the whole starmap anyways, Ferinex and everybody who has used inbox32 to import the last StarMap update has the wrong names for at least 6 labels (and probably more, if you count also planets).

SPECTURE (ZTRX)
CODBLU (BLUEFIRE 2)
GREY GOLD 07 (SARRMAROOS)
QUIET'S GAZE (QUADRUPLE RAYS)
GLACIAL CALM (LONESOME BLUE)
OZONIA (TRIOSA)

These are all stars and labels in bold are the one present in the official StarMap; I suggest to have a check to your copy.

There's another very interesting thing that the StarMap2 generated by Ferinex has unveiled and it was somehting reallyj unexpected: duplicate systems (like the grid ones), but with planets!
Oddly enough my copy of StarMap2 I generated didn't report these anomalies (which are something that effectively happen in-game), so it seems I'm missing some impotant step during the mapping process.

If you want to know which systems these are I compiled a list here:
GOESXNET and click the HOME link on the left.
written by Pwin on Mar 08, 2009 11:39
I don't recall seeing Triceratops in the list of companion programs.

What is it?
r'lyeh sweet r'lyeh
written by Neuzd on Mar 08, 2009 13:50
Pwin said:
I don't recall seeing Triceratops in the list of companion programs.

What is it?
Triceratops is a program that, starting from the labels in the StarMap, writes a file called Starmap2.bin, that contains additional informations, the most useful of which are the parsis coordinattess of objects.

The same thing was once accomplished by EvolveSM (this program instead is listed in the page you went searching on) and the original purpose was that of having a tool that could port the Starmap into Noctis V.

The starmap porting is actually an impossible thing to do, so these programs (well, their product:the starmap2.bin file) have been used for different goals, and a very good example of this is Peek's NoctisMapper, a 3D visualization tool of the mapped part of the galaxy.

There are some difference between EvolveSM and Triceratops, though and all points are in Triceratops favour.
One is the speed, another is related to the doubts I was expressing in these same discussion, about names duplicated several times: despite looking as errors, the situation Triceratops writes replicates what happens effectively in game.

This latest fact is not really important to "normal" users, (Noctismapper will NOT show any duplicates in the map), but for me that I'm trying to study Feltyrion and building a scientific knowledge about it with GOESXNET, it is crucial.
reading this thread
no members are reading this thread
. /../StarMap2 discussion/ 12
43632, 12 queries, 0.101 s.this frame is part of the AnyNowhere network