Nav mesh functions

[quartata]

I'd like to be able to retrieve the navigation mesh area a certain point is in and get its dimensions; are there any built-in navmesh functions that would let me do that or do I need to parse the .nav file myself?

[L'In20Cible]

We could potentially export everything, but that is a lot of work and testing. Lookup all the nav_ prefixed headers in the SDKs (which are most likely outdated for years now) to give you an idea. Feel free to create an issue on the repo so we can label it as feature request but I doubt we will get into it anytime soon.

As a side note, Ojii wrote a python library named "navlib" back in 2008-2009 for EventScripts. Seems like he removed all download links from his site web but I'm sure you can find a way to contact him and maybe he still got a copy on a dusty drive: http://ojii.ch/

[Predz]

I was interested by this quite a bit, so I went digging myself :P

Enjoy! https://code.google.com/archive/p/sourcelibs/source/default/source

Syntax: Select all

from navlib import NAV

nav_data = NAV(<path to nav file>)

[L'In20Cible]

This is it!

[quartata]

I was interested by this quite a bit, so I went digging myself :P

Enjoy! https://code.google.com/archive/p/sourcelibs/source/default/source

Syntax: Select all

from navlib import NAV

nav_data = NAV(<path to nav file>)

Woo, thanks for unearthing this! I see a couple bits of Python 2 code that I'll have to fix but not a biggie

[Ayuto]

You can use the py2to3 converter to update that library to Python 3.

[quartata]

You can use the py2to3 converter to update that library to Python 3.

There was only a couple of things so I just did it by hand.

[Predz]

I have been quite interested in this library so am spending some time to recode the entire library. I want to optimise it quite substantially and am going to post most of my code here for everyone to comment on. I will be working on all the unimplemented functions too! Unsure whether this could at some point be included Source.Python

Any critisism would be greatful.

As an example, here is my quickly recoded Reader:

Syntax: Select all

from struct import unpack, calcsize

class Reader:
    """
    Reader provides the functions to be able to pull specific
    bytes from the file when required. It caches the size
    of bytes retrieved, saving the need for extra calculations
    later.

    :param fileobject file:
        File object to store.
    """

    cache = {}

    def __init__(self, file):
        "Store the file object provided."
        self.file = file

    def read(self, to_read=None, offset=None):
        "Characters to read from the file. An offset can be specified if required."
        if offset:
            self.file.seek(offset)
        if to_read:
            result = unpack(to_read, self.file.read(self.getsize(to_read)))
            if result and len(result) == 1:
                return result[0]
            return result
    
    @classmethod
    def getsize(cls, characters):
        "Retrieve the size of the characters provided."
        if characters in cls.cache:
            return cls.cache[characters]
        size = calcsize(characters)
        cls.cache[characters] = size
        return size

[L'In20Cible]

Unsure whether this could at some point be included Source.Python

If this ever get included to SP, it won't use the struct package to unpack the data but ideally use the classes/enumerators from the SDKs directly.

Any critisism would be greatful.

In the example you posted, since you are defaulting keywords to None, it would be better to do:

Syntax: Select all

if offset is not None:

To ensure a value got passed in. Currently, if someone does the following:

Syntax: Select all

x.read(offset=0)

It will breaks the logic as it will be evaluated as False but should seek 0.

As for the to_read keyword, I think it should be a required argument directly. There is no point to call the read method if you are not passing a pattern to parse.

Also, you are redefining the global type "file" in your local method.

[Predz]

Unsure whether this could at some point be included Source.Python

If this ever get included to SP, it won't use the struct package to unpack the data but ideally use the classes/enumerators from the SDKs directly.

Yep I fully agree that the implementation should be directly from the SDK.

Any critisism would be greatful.

In the example you posted, since you are defaulting keywords to None, it would be better to do:

Syntax: Select all

if offset is not None:

To ensure a value got passed in. Currently, if someone does the following:

Syntax: Select all

x.read(offset=0)

It will breaks the logic as it will be evaluated as False but should seek 0.

As for the to_read keyword, I think it should be a required argument directly. There is no point to call the read method if you are not passing a pattern to parse.

Thanks for the input, will be making these updates quickly today.

Also, you are redefining the global type "file" in your local method.

I have never really understood this one as when I use my python3.5 IDLE it doesnt exist in the builtins. Or is this just clean coding convention?

Syntax: Select all

>>> 'file' in dir(__builtins__)
False

[satoon101]

They removed 'file' as a built-in in Python3, so you should be ok using it. It does exist in Python2, so, if your code needs to be backwards compatible, you should refrain from using 'file' as a variable name. But, that shouldn't really be the case with plugins made to run with SP.