Open ariesclark opened 4 years ago
It is! There are a lot of improvements we'd like to make and not all of these are reflected within the Issues. I'll share a recent comment I left in #82.
This project could really use some TLC. It's past due to be converted to TypeScript along with generating both ESM and CJS bundles. These things should probably happen as part of a 1.0.0 release.
I'm definitely open to any and all suggestions or PRs to improve things. Theres probably also room for some general housekeeping around Issues and PRs, which I haven't had an opportunity to get around to just yet 😬 but probably should do soon.
Ah I see, I saw quite a few stale PRs and issues so I wasn't sure, that could use some cleaning up. I was considering making my own fork with quite a few changes and improvements.
Well if you're interested in contributing your improvements back here then I would certainly welcome it, but if you decide you want to take a different direction then you're of course welcome to fork and do whatever you like. The license is very permissive for this reason. 😄
honestly, I just wanted the customization to declare custom functions for things like isTileWalkable, checkAdjacentNode ect.
I like the idea of providing a custom function for something like this. You're jogging my memory of a past PR that started to do something similar, but I don't believe it was ever finished.
Would love a custom condition for those functions - would allow for things like elevation, especially useful for isometric games (E.g. can't go from tile -> tile if elevation is too high)
I ended up writing my own implementation. It's usable something like this.
const WALL_TILE = Object.freeze(new AStaar.TileMeta({walkable: false}));
const SLOW_TILE = Object.freeze(new AStaar.TileMeta({cost: 2}));
const NORMAL_TILE = Object.freeze(new AStaar.TileMeta());
export let astaar = new AStaar({
getTile: function (x, y) {
if (!window.app.biomeData[x] || !window.app.biomeData[x][y]) return WALL_TILE;
let color = window.app.biomeData[x][y];
switch (color) {
case "#808080":
return WALL_TILE;
case "...":
return SLOW_TILE;
default:
return NORMAL_TILE;
}
}
});```
Not sure that'd work for my use-case unfortunately - elevation would depend on knowing both the current and target tile to know if the elevation difference is too high :(
is this still maintained?