Guess I need to post more often so my own threads don't lock up and cannot be updated.

See original thread http://www.vendetta-online.com/x/msgboard/16/24543

Download latest version Here

See below for notes about version 1.7.3

In the works:
* Loading Navcomp as a module. This will allow other plugins to utilize NC with the require keyword in Lua. This is partially done already, but is still apparently a little buggy.
* Fully gather together the NC API and publish. I intend to allow NC to be used a utility tool and doing this will allow it.

Just started using this. Love it.

I wanted a more basic Navmap colour markup plugin and I asked around, spuck and draugath sent me to navcomp.

I went through the code and extracted the important API functions that you built to handle colouring the navmap squares based on tables and built a little prototype:

http://pastebin.com/z9j74uLD

So the idea with this is your HUD will get marked up based on your sector notes; that part works just fine. The storm part however works, but has the most bizzare side effect and I'm hoping you'll have a clue as to why.

Basically, install the plugin and remove navcomp so it doesn't conflict, then go to any storm in greyspace. Once you get out of the storm you'll see it's been marked blue on the navmap once you refresh it.

Now go and have a look at Sol II. For some reason it generates a bunch of coloured squares there and I have no idea why.

If you have any clues i'd love to hear them.

A new instance of the controls are created everytime you login. So logging off and back on will create 2, 3, 4 or more copies of the controls on the Navigation screen, depending upon how often you do so.

Okay, I'll add it to the bug list. Nice catch.

I'm finally starting to get back into VO after months of RL kicking my butt. I'm dusting off code and will start trying to get onto the bug and requested feature list here.

Does that mean you can take a look at that bug for me? :P

Aye, it's on the list. I WILL get to analyzing your modification plugin.

You actually did give me an idea however - that is a determination on data age. If a give bit of data is too old, it may be removable. Previously, I'd erred on the side of caution (i.e. once a storm or hive sector was spotted, it was permanent unless you revisited the sector. Even then, you could only remove the hostile check for that sector), but it merits examination on determining how people would want data to expire. Shouldn't take that much to add; just want to design it properly so it's easily expandable if needed.

I actually hadn't come up with a concrete solution to data age either. I was basically just going to have a two hour timestamp rule where it doesn't include any data older than two hours. That way there's a slight chance that someone will run into a storm twice, but for the most part you will never *have* to go to the same storm in a two hour play session.

Considering the way I do everything, I'd probably allow the user not only the option to have data expire, but define the expiration time based on a dropdown menu.

ion storms have variable duration, but i'm pretty sure there is a maximum time limit as to how long they remain there. I've seen latos i8 stormed for days but that might have been two or more seperate storms so it's hard to tell. If I did know a maximum I would set that as the data expiry time, but for the time being it'll probably be guesswork based on an average time.

Another thing to do might be to colour code the age of the storm since detection. Fresh storms can start off a very light blue and as they age in hours the colour gets a darker and darker blue that way its a subtle indication to the user of how old the storm is allowing them to make a more informed decision about whether to trust the data.

I like that idea TRS.

That's tougher prospect TRS, but I'll definitely look into it. NC was originally designed to be an aid to navigation for freight haulers, since they usually were running about in barely pilotable ships. Running into a storm with hive bots in it in a ship you couldn't maneuver or accelerate easily was the stuff of nightmares.

It would help too if I would get off my butt and design and implement an actual editor for system data. The current system basically allows you just to clear all of a selected type of data in a given system or universe wide. It's pretty broadly granular ATM.

To be honest as a combat organisation, we found it less useful because often there are occasions where you might want to enter a storm to pursue someone or whatnot. More important was the fact that you built the foundation of a markup and you built an API for controlling it and gathering data from other sources to dynamically markup the minimap like the thing showing a visual representation of hive skirms locaitons on the map was very cool.

What I want to build with it is a lightweight version that emphasizes intelligence gathering and display and leaving the decision of what to do in the hands of the pilot.

I basically built a table system to represent the current state of the maps and then ran it though the API which i extracted from navcomp. I believe clears the whole lot and recreates it. Really simple but you can test it yourself in the plugin. The problem I ran into is that it creates fake storms in sol II and the problem is mathematical I can't figure out why from looking at it.

The potential of something like this is that not only can you do what youve done, and have server side updates for storm locations, but you can allow other types of markup to be shared as well. That is indeed my plan :)

Version 1.7.3

http://its-obvious-solutions.com/downloads/vo/plugins/NavComp-v1.7.3.zip

This version is stable, but has some features that are not fully tested or optimized, none of which should affect the average user. I did add 2 new comparators to system path finding metadata logic: Edge and Line Ratio. Edge is not fully optimized and may eventually be rewritten. It was intended to give path finding preference to system edges (which are usually clear of hazards), but it's slow (it's painfully close to Dijkstra which makes it slow as heck). The other logic metadata is Line Ratio, which about 60% of the time produces similar results to Edge and is much faster. Anchors (those predefined jump in points for various sectors which makes getting to a wormhole or station much faster) are painted now though I'm still trying to figure out how to draw actual lines on the navmap (any clues Ray would be really helpful). Anchors also have another feature. Mouseover a sector and press 'v' to start coding an anchor, then mouseover where the anchor should end (usually the aforementioned wormhole or station sector) and press 'v' again to code it in. If any anchors are already defined at that location, NC just adds it to the end. Make sure to read the User Guide that comes with NC to better understand how anchors and comparator metadata can help you better navigate.

There may be a couple of other things in there. It's been months since I worked on it at all. (been deep in working on a plugin architecture library which will help other plugin authors - some pretty cool feature in the PALib)

Thanks!

Just a quick shout out to TRS and his suggestion for expiring hazard data - I've worked out the process for managing the data in the internal NC database. The problem wasn't so much the data management itself (though referring to that database is pretty deep in the core code, so it was woven in really well), it was upgrading the database from older versions. I figured that out a little earlier, since I was under the hood fixing the navmap colorization issue. Don't know when I'll get that one out (way too many things on my mind of late between my work work and my hobby work - both of which are doing the same thing), but it's been documented now in the web application I use for project management (asana.com), and I'll get to it as soon as I can.

I'm a huge proponent of simplicity in these things, because i've got a silly lawyer brain that can't deal with anything that isn't presentable to a panel of 12 idi-... i mean... normal people.

Amazed that you're still going with it though, ive pointed a few people over the years to the navcomp code as a good source of education regarding how to make a server based application and how to do some advanced interface integration which I think helps massively when it comes to making plugins that really do plug-in to the VO game system. I hate the TCFT2's of the verse where the plugin is basically just lazily put on top of the existing interface.

Anyway good luck with it, hope you find the time to finish it.

Can you add a option to avoid asteroid sectors?

Use of purchaseprint to display messages will cause a dialog box to appear mid screen that will require input to close when a players is on mobile device and using the condensed UI/HUD setting.