add initial externally stored levels support #9
Conversation
This feature will only work with `Open()`, since that function can easily figure out the file location (it gets it as an argument). I don't know how to make `Read()` work without there breaking its API. Fixes SolarLune#8
| "path/filepath" | ||
| "strconv" | ||
|
|
||
| "github.com/tidwall/gjson" | ||
| ) | ||
|
|
||
| //LayerType constants indicating a Layer's type. | ||
| // LayerType constants indicating a Layer's type. |
There was a problem hiding this comment.
Some changes like this are due to the gofmt on-save.
I hope it doesn't make this PR much harder to review.
It would be better to send them separately (if at all), maybe?
|
Sorry for the late reply - I'm wondering, though, if it might be better to add the ability to read from a file system - that way, we could reliably know what the file system of an embedded or on-disk asset directory looks like to determine where external levels might be. |
|
Feel free to ignore this input as I haven't used this library, however it is relevant to SolarLune's previous statement. Using one or more of the fs interfaces (https://pkg.go.dev/io/fs) would be the best and most idiomatic go choice. I personally don't like it when libraries always assume that read operations are done with the local filesystem. Traditionally, many games ship their assets in a compressed or obfuscated format, of which access to would be best implemented via an interface. If a local file system is always presumed, then some pretty bad kludges have to be implemented to give access. |
|
That is true. I usually have some sort of a file reader abstraction myself, which can read either from a local file system or an embedded storage (based on a filename prefix). I didn't want to break the API though. I've just started to use this library and I don't feel the courage to propose such changes. :D |
|
Hello! I updated ldtkgo recently to add a function that can load a file from a file-system. Would you be interested in adapting your PR to use that new function now? |
|
Sure, I'll take a look. |
|
I'm not feeling confident about keeping this PR open anymore. |
This feature will only work with
Open(), since that function can easily figure out the file location(it gets it as an argument).
I don't know how to make
Read()work without there breaking its API.Fixes #8