Giter VIP home page Giter VIP logo

adventurelandcpp's Introduction

Project shutdown notice

For the past few months, the issue I have over and over run into has been pathfinding. Pathfinding as it stands is slow and inefficient. In January, I bumped the pathfinding issue to a high priority. I've since spent a lot of time trying to make it work.

I have made several attempts to fix it. One attempt used a different algorithm, and that made it worse. With recent map changes, there's places where it thinks it has a path, but completely breaks when it tries to execute that path. This approach used a brute force approach, where every 7 pixels relative to some position is a "node". On a map that's thousands of pixels big, you can already guess this is inefficient.

My last attempt tried to use triangulation. This was easier said than done. After an initial failure to attempt to find a library, I decided to write some code from scratch. There's surprisingly little information on this online, and me having no idea how to go about it presented several challenges. I managed to write some basic stuff, but it wasn't even constrained. Attempts to add constraints and account for padding failed. How adding holes to this outer hull is done is still something I have no idea how t odi. I did after this, however, find a library. Specifically, I found earcut.hpp. This looked promising, so I started to implement it. Once again... challenging.

The library does its job, don't get me wrong. it just isn't meant for this type of use, where there's complex shapes. In addition, there's lines where the outer hull splits into several lines, and then merge back together. The library isn't meant for this. Of course, it can be done. Other players have as well. I just have no idea how, and in spite of having spent hours on research, I still have no idea how to generate a navmesh. With C++, it's mostly Recast, Unity, or Unreal. None of those three can easily be applied.

The only remaining option I had to make this work was triangulation in some form. Proper pathfinding is a big deal, because it's the only way the library can be used to truly automate the game.

Therefore, this project will no longer be developed. Pathfinding is such a blocking issue that I can't just ignore it and move on with other parts of the library. The game is constantly evolving, as the home page says. I can't keep up with building the library, keeping it up to date, and dealing with pathfinding. I'm willing to bet I'm missing something super obvious, but I can't find any usable resources on how this is done. My own unsourced attempts didn't yield anything either.

I might find a solution some day, or even learn about it, but for now, I'm going to move on. I do have some alternate solutions to work around these issues, but they all require manual game data modifications. Keeping up with that is going to be extremely hard. So for now, I see no other choice but to leave it.

That being said, I'm going to leave the repo open (not archived) just on the off chance someone who actually knows how to generate navmeshes finds this and takes the time to submit a pull request. Until that happens, or like I said, I figure it out, the project will be on ice.

Status notice

Note that this is a work in progress, and only supports primitive bot scripting at the moment. If you're looking for a fully working alternative while this is being built, check out ALBot, or stick to the website/steam client.

If you want to get started with this client, the rough equivalent of default.js is available in the apidocs folder. Note that the code is subject to unnotified changes while the library is being developed.

Library developer setup

Run init.py. This will set up the dependencies. If you decide to use virtualization (Docker), it's still recommended you do this before installing it in Docker. This is because of autocomplete. If you don't use autocomplete, you can naturally skip that.

This is intended to be a library, but in its current state, it isn't importable as one. Building can be done by running SCons.

adventurelandcpp's People

Contributors

lunarwatcher avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

adventurelandcpp's Issues

Critical: replace Poco

Poco works like a charm on Linux, but on Windows with MinGW, it's a different story.

It injects incompatible libraries (attempts to link -lCrypt32.lib - -lcrypt32 (used by a different library) is fine, but the .lib ending breaks it), and I can't fix it. It probably works fine on full-native Windows,

My current plan is to switch over to whoshuu/cpr (through conan-cpr), which relies on cURL (fortunately available through Conan). One major advantage with changing, beyond potentially better support for Windows, is that cURL and CPR is considerably lighter than Poco. This is especially noticeable on devices with little resources available (such as the Raspberry Pi)

Disconnection problems

Disconnection currently breaks the bots - it fails to log back in because of a bool switch that isn't toggled.

Additionally, server shutdown isn't handled

Improve smartMove

The current smartMove function is... suboptimal, to say the least. It does its job, but it's far from efficient, and needs a whole lot of improvements.

I've gotten stuck while attempting to improve it, but I still need to move the other components forward, and rather work on improvements later. I'll revisit this later, but if someone else wants to get into it to fix it earlier (the current fix schedule is on a 6-8 basis), I'll accept pull requests that fix it.

That being said, to avoid unnecessary work, please leave a reply if you're serious about implementing it (serious as in plan to finish it and submit a PR), both so I know this is being worked on, and to avoid unnecessary work by having people work on parallel fixes to this.

But this is also pretty far from a popular repo, so the chances of parallel fixes are low. This is just for good measure.

The socket.IO connection project

Background

(you can skip this part if you're here to report something. This explains why it's needed, if you're interested)

The Socket.IO client for C++ relies on boost, which isn't really practical to use when this project is intended to run and compile on low-memory devices. The project also hasn't been updated since 2017, so I'm not sure about standard compliance, and I'd rather not find out. Boost also adds a complicating layer because of Windows command line length restrictions which need to be handled separately, and it's a slight mess to integrate it, and this goes under the assumption most users of the wrapper aren't familiar with C++ and able to fix it. I want to keep the library as "plug and play" as possible.

In order to build this library, I needed to parse the raw data, which alone is hard because the documentation is kinda fuzzy on the raw formats. I've managed to reconstruct a lot by connecting to the AL servers, but there's a massive downside to this: there are missing events. Type 3, 5, and 6 may not be used at all, but they could be. But without any data, I can't parse it. Without real-world data, I can't create anything, and with the wrapper almost being ready for low-level use, I ask for the help of people using this library to help with the data formats.

Why was I told to go here?

The reason this issue exists is in case it's needed. If you've found a log redirecting you to this issue, you've found a message type that isn't parsed properly, and as of writing, that means ack, binary event, and binary ack. If you received such an event, please leave a comment with the line (if there's some sensitive info in there for some reason, please remove that. removals of data for good measure are also fine, but if the data contains a map, please keep the keys if possible). Doing so helps me get data to create the parser, as well as the sender for the system.

Alternatively, if you received an unparsed event 4, please create a full issue if it's something beyond regular disconnection. Those will likely contain errors important enough to warrant their own issues, as they need to be handled.

Make vector[index] disappear

Use vector.at(index) instead. [] doesn't check bounds ya know, and accessing outside the area is undefined behavior. That would explain why the canMove function some times acts unexpectedly

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.