Forums » Community Projects
I assume that because there is no colour change specified for the axia report set message, it takes the colour of the most recent message used in chat... I find this with other plugins.
Yeah, it just does a print() - which uses whatever the last channel is. I'll see what can be done about that.
Also, that disconnect error is in the ancient httplib library I'm using. I've seen the error - it happens when there is a socket error between the plugin and the server, and emits a warning about a missing callback that the library doesn't assign. That's another thing I'll look into.
Interesting that someone is building another navigation plugin.
Some things to remember however (and advice for the would-be navigation plugin writer)...
Navcomp was created to store and process data locally, because 1) I didn't want a plugin which required membership in a guild to function and 2) I didn't want a plugin which was subject to the vagaries of being hosted offline. (e.g. if the person originally doing the hosting were to leave VO, the plugin would become useless) I always try to use distributed databases whenever possible.
Players can affect the logic used by Navcomp for creating routes. (this includes the creation of #avoid: sectors which are ignored during calculation) This flexibility comes at a cost however. In its early days (during beta testing), NC was excessively fast (less than a second per system in calculating paths), but utilized a fixed logic path algorithm. I chose to make it flexible because 1) players like to make choices, 2) players like to sell stuff in VO and selling routes and algorithms made perfect sense, 3) once a fixed algorithm is known, malcontents like pirates can easily calculate the most likely places to jump people in unmonitored space, negating the reason behind NC in the first place. NC is a bit slower now due to its flexible nature, but is still very fast once a system has been cached.
Don't forget that you can exchange encounter data (storms, hive), anchor, and route data using the Exchange with anyone in the same station. (it was done this way as an RP thing. I think universe wide broadcasts of data are unrealistic and go against RP)
Best of luck in developing your new plugin.
Some things to remember however (and advice for the would-be navigation plugin writer)...
Navcomp was created to store and process data locally, because 1) I didn't want a plugin which required membership in a guild to function and 2) I didn't want a plugin which was subject to the vagaries of being hosted offline. (e.g. if the person originally doing the hosting were to leave VO, the plugin would become useless) I always try to use distributed databases whenever possible.
Players can affect the logic used by Navcomp for creating routes. (this includes the creation of #avoid: sectors which are ignored during calculation) This flexibility comes at a cost however. In its early days (during beta testing), NC was excessively fast (less than a second per system in calculating paths), but utilized a fixed logic path algorithm. I chose to make it flexible because 1) players like to make choices, 2) players like to sell stuff in VO and selling routes and algorithms made perfect sense, 3) once a fixed algorithm is known, malcontents like pirates can easily calculate the most likely places to jump people in unmonitored space, negating the reason behind NC in the first place. NC is a bit slower now due to its flexible nature, but is still very fast once a system has been cached.
Don't forget that you can exchange encounter data (storms, hive), anchor, and route data using the Exchange with anyone in the same station. (it was done this way as an RP thing. I think universe wide broadcasts of data are unrealistic and go against RP)
Best of luck in developing your new plugin.