Forums » Community Projects
NavComp Plugin
We've all had problems with ion storms, especially when there are nasty things hiding in them. Also, we've all seen how much a pain it is to save/load navroutes using the current system. All this has been solved with the NavComp plugin!
NavComp has been extensively developed and tested over the past 8 months by the PA guild and Ninjr. What it does is to record all hazard encounters and will calculate a hazard free path around those obstacles. No it won't help you once you've jumped into a sector. (at least not yet) NC is a navigational computer to avoid navigation hazards at the system level.
Using NC is as easy to use as opening your Navigation tab in the PDA, clicking on where you want to go, then clicking the Plot button, or typing /nc plot in the chat buffer. It's that easy. NC has been fully integrated into the VO HUD and PDA screens. NC runs in the background, so it doesn't interfere with anything else you're doing.
NC features the ability to save navroutes by name with notes. All saved navroutes may be interacted with via a popup dialog.
Avoidance logic is fully customizable through the options screen (Options button in the PDA and /nc options in the chat buffer). Default avoidance logic is to not jump into and not jump across any sector which can be seen to have hostile bots in it or has been recorded to have hostile bots in it. Station sectors will only be entered if a route target or if no other option exists to manage avoidance logic. The player may select that all recorded storm sectors and manual avoid sectors be avoided as if they were hostile sectors. Manual sectors can be created easily by entering #avoid: anywhere within a given sector's Sector Notes from the navmap tab. NC's default behavior avoids jumping into manual avoid sectors, but will jump over them. Any time you feel NC has too much data stored (hey it CAN happen), there is a convenient Clear function in the PDA Nav tab giving the player the ability to clear storm, bots, or manual avoidance data.
Hazards can be colorized and are displayed on the navmap, so can see where the storms and bots are. This can be a tremendous help in seeing what NC is avoiding for you. Just enter an RGB value string into the Options tab of the Controls dialog and click the color button to view your decided color. (sadly VO's version of Lua doesn't include the colorbrowser object in IUP or this wouldn't have had to be so manual)
NC uses a series of comparators to iteratively determine the best route between 2 points. Each system starts with its own default comparator metadata, and this may be customized by the user. Access this metadata via the Metadata tab in the Controls dialog. Feel free to play with them. I'll write up what each comparator does in a later post. NC's comparator architecture is fully scalable, so any additional comparators are easily added.
Being chased? Worried that your pursuer has the Autonav plugin? Fear not, NC includes a fully integrated evasion mode calculator which completely nullifies Autonav. This is customizable by the player. (number of jumps involved and a bind for toggling Evasion Mode) When entering Evasion Mode, NC stores your current navroute and reloads it when leaving EM, so you lose nothing using it. A friendly indicator in your HUD identifies whenever you're in EM.
Got friends? NC features a communications module which will allow any 2 players to exchange encounter and navroute data whenever both are in the same station. Just check out the bar and new buttons you'll find there.
That should do it as an introduction. I hope you'll download NavComp and play with it. Feel free to tell me what you think.
NavComp v1.5.3
NavComp has been extensively developed and tested over the past 8 months by the PA guild and Ninjr. What it does is to record all hazard encounters and will calculate a hazard free path around those obstacles. No it won't help you once you've jumped into a sector. (at least not yet) NC is a navigational computer to avoid navigation hazards at the system level.
Using NC is as easy to use as opening your Navigation tab in the PDA, clicking on where you want to go, then clicking the Plot button, or typing /nc plot in the chat buffer. It's that easy. NC has been fully integrated into the VO HUD and PDA screens. NC runs in the background, so it doesn't interfere with anything else you're doing.
NC features the ability to save navroutes by name with notes. All saved navroutes may be interacted with via a popup dialog.
Avoidance logic is fully customizable through the options screen (Options button in the PDA and /nc options in the chat buffer). Default avoidance logic is to not jump into and not jump across any sector which can be seen to have hostile bots in it or has been recorded to have hostile bots in it. Station sectors will only be entered if a route target or if no other option exists to manage avoidance logic. The player may select that all recorded storm sectors and manual avoid sectors be avoided as if they were hostile sectors. Manual sectors can be created easily by entering #avoid: anywhere within a given sector's Sector Notes from the navmap tab. NC's default behavior avoids jumping into manual avoid sectors, but will jump over them. Any time you feel NC has too much data stored (hey it CAN happen), there is a convenient Clear function in the PDA Nav tab giving the player the ability to clear storm, bots, or manual avoidance data.
Hazards can be colorized and are displayed on the navmap, so can see where the storms and bots are. This can be a tremendous help in seeing what NC is avoiding for you. Just enter an RGB value string into the Options tab of the Controls dialog and click the color button to view your decided color. (sadly VO's version of Lua doesn't include the colorbrowser object in IUP or this wouldn't have had to be so manual)
NC uses a series of comparators to iteratively determine the best route between 2 points. Each system starts with its own default comparator metadata, and this may be customized by the user. Access this metadata via the Metadata tab in the Controls dialog. Feel free to play with them. I'll write up what each comparator does in a later post. NC's comparator architecture is fully scalable, so any additional comparators are easily added.
Being chased? Worried that your pursuer has the Autonav plugin? Fear not, NC includes a fully integrated evasion mode calculator which completely nullifies Autonav. This is customizable by the player. (number of jumps involved and a bind for toggling Evasion Mode) When entering Evasion Mode, NC stores your current navroute and reloads it when leaving EM, so you lose nothing using it. A friendly indicator in your HUD identifies whenever you're in EM.
Got friends? NC features a communications module which will allow any 2 players to exchange encounter and navroute data whenever both are in the same station. Just check out the bar and new buttons you'll find there.
That should do it as an introduction. I hope you'll download NavComp and play with it. Feel free to tell me what you think.
NavComp v1.5.3
Pretty sweet stuff. :D
As you know i really like what you've done. I would suggest that you add the confirmation to the case of buddies. The couple of times i've done an exchange the person was a little overcome by the blast of data. My fault for not preparing them but confirmation would give them a chance to get ready and then give the go ahead.
Added to the list. It's been suggested that autoconfirmation of buddies and guildies be made optional, rather than fixed.
The evasion mode is fascinating! I'm going to have to download and check it out to see if I can make AutoNav less susceptible to it! :D
Edit: Downloaded and looking at it now, this is pretty involved. Awesome!
Edit2: It's a sort of style choice, but do you guys understand the difference between table.function() and table:function() in lua? In case not, or if anyone is curious, table.function() is just table.function(), but table:function() is equivalent to table.function(table), where table is passed and accessible as the 'self' variable.
Edit3: I mention this because you often declare a function as navcomp:DoSomeThing() and then proceed to use 'navcomp.blah' to access other variables and functions. Or it's a strict utility function that doesn't require accessing the navcomp table at all, but is still declared navcom:DoSomeThing()
Edit4: The evasion ability of this plugin is pretty cool. Code-wise, I can't do anything that would improve autonav against it, but if you DO use autonav, here are a few tips:
* Don't blindly rely on AutoNav. You're much better off predicting where your target wants to go if they start acting fishy(i.e., warping to a random sector). If they're damaged, a station might be priority. If they are in a trading hull in a backwater system, they'll maybe be heading towards a wormhole. It's less likely for a trading hull to be heading to a station that admires them rather than a station that doesn't, unless that trading hull is empty or is simply trading for profit (not likely to be crossing wormholes in Greyspace if trading for profit)
* Have VO preload your cache. You'll beat your quarry in load times most of the time and have a better chance at predicting their various destinations as they try to evade.
* Be attractive, don't be unattractive. This is easier for new pilots with less of a reputation.
* Kill your quarry before they jump. This will make any sort of evasion impossible and AutoNav unnecessary.
Edit: Downloaded and looking at it now, this is pretty involved. Awesome!
Edit2: It's a sort of style choice, but do you guys understand the difference between table.function() and table:function() in lua? In case not, or if anyone is curious, table.function() is just table.function(), but table:function() is equivalent to table.function(table), where table is passed and accessible as the 'self' variable.
Edit3: I mention this because you often declare a function as navcomp:DoSomeThing() and then proceed to use 'navcomp.blah' to access other variables and functions. Or it's a strict utility function that doesn't require accessing the navcomp table at all, but is still declared navcom:DoSomeThing()
Edit4: The evasion ability of this plugin is pretty cool. Code-wise, I can't do anything that would improve autonav against it, but if you DO use autonav, here are a few tips:
* Don't blindly rely on AutoNav. You're much better off predicting where your target wants to go if they start acting fishy(i.e., warping to a random sector). If they're damaged, a station might be priority. If they are in a trading hull in a backwater system, they'll maybe be heading towards a wormhole. It's less likely for a trading hull to be heading to a station that admires them rather than a station that doesn't, unless that trading hull is empty or is simply trading for profit (not likely to be crossing wormholes in Greyspace if trading for profit)
* Have VO preload your cache. You'll beat your quarry in load times most of the time and have a better chance at predicting their various destinations as they try to evade.
* Be attractive, don't be unattractive. This is easier for new pilots with less of a reputation.
* Kill your quarry before they jump. This will make any sort of evasion impossible and AutoNav unnecessary.
Yeah, it's mostly a stylistic thing. I could've made more use of Lua's inherent scope (i.e. the fact we can define the self object via table.function as opposed to table:function). In fact, when I started NC, I was attempting to do that, but the whole thing started to get so convoluted after a while, it became easier simply to make absolute references to scope. (hence the full namespace references to variables and functions)
Thanks for the vote of confidence. I may be a professional developer (usually Java, C/C++ with a smaller but significant amount of Javascript thrown in), but I still have an occasional need for the heady feeling of appreciation.
I'm in the process of collecting suggestions for improvement. (still wading through the list of things my PA testers have suggested, but the list is open)
Thanks for the vote of confidence. I may be a professional developer (usually Java, C/C++ with a smaller but significant amount of Javascript thrown in), but I still have an occasional need for the heady feeling of appreciation.
I'm in the process of collecting suggestions for improvement. (still wading through the list of things my PA testers have suggested, but the list is open)
The link is broken. Is this plugin still available?
Plugin is still available. My provider changed the forwarding, so the old forwarding domain was broken. I've removed that for now and have provided an updated version.
Version 1.3.2
This version provides a new feature call Segment Smoothing. The primary route smoothing method NC uses is Nodal Smoothing which works by examining each node in a navroute and essentially asking that if it were removed would the resulting segment between the adjacent nodes cross through prohibited sectors. If not, the node is removed from the list of nodes in the navroute.
Segment Smoothing adds an additional layer to this (albeit at a slight cost in performance). It checks each line segment, drawing an imaginary intersection point of the 2 adjacent line segments and asks if either of the new line segments crosses any prohibited sectors, removing the 2 previous line segment ends if okay. In effect, NC adds a new node in order to remove 2. What you'll notice when turned on is that in those systems where convolution is rampant, much of the erratic nature of the routes calculated through them disappears. As one of my testers put it "I'm glad I'm asked to make 5 jumps when only 3 were necessary."
System Logic Metadata also allows for turning on various routing features (which previously were only available in a global sense) for each system. These are added to the system metadata in the same manner as any of the Comparators, but are required to be first in the list in order to work. (for now, I may change the way logic works a bit to allow for the options to be placed anywhere in the metadata list)
In the Works:
* 1 key (or failing that, no more than 2 key) navroute loading.
* Some improvements to some of the Comparators.
* A new Comparator method which tries to look for really long jumps across a system.
* Continued improvements in performance and smoothness. (I have some reports of some people saying NC is still a little jumpy at times when calculations are running in the background)
* A proper Help Manual for using NavComp. (this would be included as an RTF file with the installed files)
I've updated the link at the top of this thread with the new version.
Hope This Helps.
Version 1.3.2
This version provides a new feature call Segment Smoothing. The primary route smoothing method NC uses is Nodal Smoothing which works by examining each node in a navroute and essentially asking that if it were removed would the resulting segment between the adjacent nodes cross through prohibited sectors. If not, the node is removed from the list of nodes in the navroute.
Segment Smoothing adds an additional layer to this (albeit at a slight cost in performance). It checks each line segment, drawing an imaginary intersection point of the 2 adjacent line segments and asks if either of the new line segments crosses any prohibited sectors, removing the 2 previous line segment ends if okay. In effect, NC adds a new node in order to remove 2. What you'll notice when turned on is that in those systems where convolution is rampant, much of the erratic nature of the routes calculated through them disappears. As one of my testers put it "I'm glad I'm asked to make 5 jumps when only 3 were necessary."
System Logic Metadata also allows for turning on various routing features (which previously were only available in a global sense) for each system. These are added to the system metadata in the same manner as any of the Comparators, but are required to be first in the list in order to work. (for now, I may change the way logic works a bit to allow for the options to be placed anywhere in the metadata list)
In the Works:
* 1 key (or failing that, no more than 2 key) navroute loading.
* Some improvements to some of the Comparators.
* A new Comparator method which tries to look for really long jumps across a system.
* Continued improvements in performance and smoothness. (I have some reports of some people saying NC is still a little jumpy at times when calculations are running in the background)
* A proper Help Manual for using NavComp. (this would be included as an RTF file with the installed files)
I've updated the link at the top of this thread with the new version.
Hope This Helps.
Hey, could you possibly add a colour on the map for manual sectors?
Sure.
I've been really busy with other projects (mostly in RL), but the basic list of new stuff is:
* 2 Key binds for navroute loading (1 key wasn't going to work, so I switched the requirement to 2)
* New Comparators (particularly trying to find better long distance hops)
* Caching for system stress maps (will speed performance). These will auto-update when certain events occur like changing #avoid: sectors and getting hive and storm updates from the stations or from communications with other players in the bar.
* A new dialog for data exchanges. This will consolidate the choices and will also allow for picking which systems to transmit, rather than all of them.
* Colorization for manual avoid sectors.
Eventually, I'll get back to all this, promise
I've been really busy with other projects (mostly in RL), but the basic list of new stuff is:
* 2 Key binds for navroute loading (1 key wasn't going to work, so I switched the requirement to 2)
* New Comparators (particularly trying to find better long distance hops)
* Caching for system stress maps (will speed performance). These will auto-update when certain events occur like changing #avoid: sectors and getting hive and storm updates from the stations or from communications with other players in the bar.
* A new dialog for data exchanges. This will consolidate the choices and will also allow for picking which systems to transmit, rather than all of them.
* Colorization for manual avoid sectors.
Eventually, I'll get back to all this, promise
Okay, finally got back to working on Navcomp after a while (and working on some other stuff, sorry). I have some more testing to do, but here's the list of features that will appear in version 1.5 (yeah, been a couple of major releases internally among my testers)
* Colorization for Manual Avoid sectors
* Cache for system stress maps. These are recalculated when changes are made, but otherwise the cache is used for all navroute calculations. Improved speed by a factor of 10 in most cases. (not kidding)
* Changed how NC uses SectorNotes which also speeds up calculations
* Added the concept of "Anchors". These are optimized jump in points for any sector (not just WH and stations) Multiple anchors may be defined for any sector, which are utilized in the order defined. Default behavior is if the path between an anchor and target has bad sectors (i.e. hazards based on the performance settings), the next anchor is tried, successively until either a free anchor is found or the list runs out, when NC calculates a path to the target normally. Anchors may be "fixed" (i.e. remain an anchor regardless of the hazard status between it and the target) either globally (via a checkbox in the options screen) or locally (by affixing * before the anchor definition). All anchor defs go in the sector which is the target. e.g. #anchor (B1, *C2): would define 2 anchors for the sector its placed in. One of the (C2) is a local fixed anchor.
* Fully integrated (and rebuilt) data exchange module. Creates the ability to choose which bits of data to send to another user in the same station.
I'll explain everything fully when I post. I just wanted all of you to know your requests weren't forgotten.
* Colorization for Manual Avoid sectors
* Cache for system stress maps. These are recalculated when changes are made, but otherwise the cache is used for all navroute calculations. Improved speed by a factor of 10 in most cases. (not kidding)
* Changed how NC uses SectorNotes which also speeds up calculations
* Added the concept of "Anchors". These are optimized jump in points for any sector (not just WH and stations) Multiple anchors may be defined for any sector, which are utilized in the order defined. Default behavior is if the path between an anchor and target has bad sectors (i.e. hazards based on the performance settings), the next anchor is tried, successively until either a free anchor is found or the list runs out, when NC calculates a path to the target normally. Anchors may be "fixed" (i.e. remain an anchor regardless of the hazard status between it and the target) either globally (via a checkbox in the options screen) or locally (by affixing * before the anchor definition). All anchor defs go in the sector which is the target. e.g. #anchor (B1, *C2): would define 2 anchors for the sector its placed in. One of the (C2) is a local fixed anchor.
* Fully integrated (and rebuilt) data exchange module. Creates the ability to choose which bits of data to send to another user in the same station.
I'll explain everything fully when I post. I just wanted all of you to know your requests weren't forgotten.
Version 1.5.3
Yes, it's been through a couple of fairly major updates inside the PA guild for testing purposes. I have managed to include a lot of requests in this one however.
I've included everything from the list in the previous post, plus a vastly improved user's guide in the READ-ME file. I'll try to flesh out the user's guide more. While it's better, it's still embryonic. I will explain anchors however.
I've cleaned up a lot of the jerkiness some people were reporting. That took some time to find all the little things that were causing holdups; I apologize. I think you'll find the result very smooth and satisfying now, and with caching blazing fast. NC will still slow down if a system it's plotting through is not found in its cache or if something changed in that system to remove it from cache, but about 2/3 of the systems can be cached now without ever being removed. Note that even in the most dynamic systems, until you visit a station and get additional data, or receive additional data from another player using the exchange, or add additional manual avoidance sectors (then resyncing), a system is available in the map cache.
The definition for defining anchors is:
#anchors (<sector list>):
Example: #anchors (B1, *C2):
The definition goes into the sector note for the sector into which you'd be jumping. There are 2 types: Plottable and Fixed. Plottable anchors may be ignored by Navcomp if the path between the anchor and the target is prohibited, in which case NC proceeds to the next anchor definition until it either runs out or runs into a fixed anchor definition. If exhausting all plottable anchor definitions, NC will plot a path to the target normally. Fixed anchors will never be ignored, even if using one will pass your ship through a prohibited (normally hostile) sector. Locally, these are denoted with a * prefixed to the sector, however there is a global option available in the options screen which makes any anchor defined fixed. Note that once NC encounters a fixed anchor definition, it will proceed no further, even if there are other anchors defined for that sector. So if I defined #anchors (*B1, C2): the C2 anchor would never be reached. There's nothing stopping you from defining one, just a warning that it'll never be utilized since it's preceded by a fixed anchor.
The data exchange section has been completely redesigned and implemented. All functions are now integrated into a single dialog, allowing you to exchange data with another player in the same station, or with a guildmate if both are online. Any exchangeable data is also selectable, so it's not necessary to send one's entire data set to the other player, which should increase profit potentials for those who like selling information, as well as give explorer types an additional reason to RP now. (i.e. they can spend time haunting about systems putting together very accurate data sets for sale to others)
Please Enjoy.
Yes, it's been through a couple of fairly major updates inside the PA guild for testing purposes. I have managed to include a lot of requests in this one however.
I've included everything from the list in the previous post, plus a vastly improved user's guide in the READ-ME file. I'll try to flesh out the user's guide more. While it's better, it's still embryonic. I will explain anchors however.
I've cleaned up a lot of the jerkiness some people were reporting. That took some time to find all the little things that were causing holdups; I apologize. I think you'll find the result very smooth and satisfying now, and with caching blazing fast. NC will still slow down if a system it's plotting through is not found in its cache or if something changed in that system to remove it from cache, but about 2/3 of the systems can be cached now without ever being removed. Note that even in the most dynamic systems, until you visit a station and get additional data, or receive additional data from another player using the exchange, or add additional manual avoidance sectors (then resyncing), a system is available in the map cache.
The definition for defining anchors is:
#anchors (<sector list>):
Example: #anchors (B1, *C2):
The definition goes into the sector note for the sector into which you'd be jumping. There are 2 types: Plottable and Fixed. Plottable anchors may be ignored by Navcomp if the path between the anchor and the target is prohibited, in which case NC proceeds to the next anchor definition until it either runs out or runs into a fixed anchor definition. If exhausting all plottable anchor definitions, NC will plot a path to the target normally. Fixed anchors will never be ignored, even if using one will pass your ship through a prohibited (normally hostile) sector. Locally, these are denoted with a * prefixed to the sector, however there is a global option available in the options screen which makes any anchor defined fixed. Note that once NC encounters a fixed anchor definition, it will proceed no further, even if there are other anchors defined for that sector. So if I defined #anchors (*B1, C2): the C2 anchor would never be reached. There's nothing stopping you from defining one, just a warning that it'll never be utilized since it's preceded by a fixed anchor.
The data exchange section has been completely redesigned and implemented. All functions are now integrated into a single dialog, allowing you to exchange data with another player in the same station, or with a guildmate if both are online. Any exchangeable data is also selectable, so it's not necessary to send one's entire data set to the other player, which should increase profit potentials for those who like selling information, as well as give explorer types an additional reason to RP now. (i.e. they can spend time haunting about systems putting together very accurate data sets for sale to others)
Please Enjoy.