Wormhole types do not match in-game data

[mobius_chimera]

When adding a wormhole, can we have buttons that match the in-game data from "show info"?

In particular if it is a K162, add a couple buttons next to the "Type:" saying:

HS | LS | NS | Unknown | Dangerous Unkonwn | Deadly Unkown

And mark them as such in the map, with the last three corresponding to C(1-3), C(4-5), and C6 respectively.

Also the "Life:" field does not match in-game data. Instead the drop down should read:

    Stable
    Reaching the End
    Critical

This will ease matching tracking data to wormhole sigs. With multiple K162's, Tripwire will often assign the wrong destination to a sig. For instance if you have both a high sec static (B274 etc) and an incoming K162 that goes to high sec, and you jump through the K162 first, Tripwire will incorrectly assign the target HS system to the B274 sig instead of the K162.

[mobius_chimera]

Furthermore all that data above comes from the "show info" page on a wormhole. Tripwire could detect the paste of the data while editing a signature and parse it automatically...

[Steven Harrigan]

Hey! So, I can help address a few of these:

In particular if it is a K162, add a couple buttons next to the "Type:" saying:

HS | LS | NS | Unknown | Dangerous Unkonwn | Deadly Unkown

HS / LS / NS are available in the leads-to field. You can type "High-Sec", for example, and there is an autocomplete option for it. There are also ones for you to put in Class-1/2/3/4/5/6. The type field is specifically for in-game designations such as N766, etc.

As for unknown/dangerous/deadly, this has generally been left out because the class options are available. It is generally known through the community that the destination of a wormhole is very visually identifiable, so there's no reason you shouldn't be able to put in the exact class. A helpful graphic for people who haven't learned it yet: http://i.imgur.com/T68AP5n.jpg. (The only caveat is that when playing on completely low/potato settings, the WHs become too simplified and are missing their inner graphic.)

And mark them as such in the map, with the last three corresponding to C(1-3), C(4-5), and C6 respectively.

When using the leads-to field as described above, it does exactly this already.

Also the "Life:" field does not match in-game data. Instead the drop down should read: Stable, Reaching the End, Critical.

I think the original goal was for the life field to be simplified. In-game, there's technically 4 states:

• Not yet begun its life cycle (24hr+ remaining, IE, it JUST spawned and has a life of 24 hours)
• Beginning to decay (Less than 24 and more than 4 hours)
• Reaching the end of life (Less than 4 hours remaining)
• On the verge of collapse (Less than 15 minutes remaining)

Since the first and last states are extremely rare, the first two and last two are combined - it's either Stable or EOL. I believe the wording is probably just an quirk making it consistent with mass (Stable/Critical). It's entirely agreeable that this could be named more accurately.

I believe the upcoming update of the signature window actually fixes this though. @daimian would need to comment on that.

With multiple K162's, Tripwire will often assign the wrong destination to a sig. For instance if you have both a high sec static (B274 etc) and an incoming K162 that goes to high sec, and you jump through the K162 first, Tripwire will incorrectly assign the target HS system to the B274 sig instead of the K162.

This is a known issue with the auto-mapping system. It has its own issue (#93). With any static + k162 of the same class, if jumped, auto-mapping will currently automatically assume the static instead of asking like it does with multiple K162s.

Furthermore all that data above comes from the "show info" page on a wormhole. Tripwire could detect the paste of the data while editing a signature and parse it automatically...

@daimian would also have to comment on this one. I'm not sure how the current paste detection for signatures is done, and if differentiating would be an issue or over-complication. That said, it would not always get exact class information from the text alone (could only guarantee HS/LS/NS/C6), and it's not terribly difficult just to fill out the form, so value vs dev time would have to be taken into consideration.

[Ashy]

Steve has provided a lot of great info there. If you wish to raise this again then please open another ticket and reference this one (Issue #280)