Hi. The issues you're asking about are described in licence terms. The link to the file is in the attachments below this post.

Hi. AGLS v2.0 for UE5.8 has been available for about two weeks now. https://www.patreon.com/JakubW/posts/ue-5-7-5-8-v2-0-170625540?utm_medium=clipboard_copy&utm_source=copyLink&utm_campaign=postshare_creator&utm_content=join_link

Hi. Unfortunately, I can't be of much help with this particular issue. I’ve never used the 'Story Framework' content, so I don’t know what the tool is based on. However, keep in mind that AGLS is a separate project that using custom plugins, tools and also features not enabled by default in standard projects. If the Story Framework is content that can be imported into an existing project, then I think you should integrate SF into AGLS, rather than the other way around.

Hi. I understand that your question is about the future project I’m planning to start working on. If I were to use GASP as the core right now, I would most likely work with a Character based on Mover. I don’t have extensive knowledge of that system yet, but I think I would be able to get comfortable with it relatively quickly. The bigger challenge could be replication, assuming I decide to keep multiplayer support. I don’t think directly transferring HumanAI would make much sense in terms of the Character-related elements. The AI Controller itself could be a different story, though, because I think that system could potentially be integrated with a Character based on Mover. That said, none of these decisions have been finalized yet. It’s also possible that the first versions of the new project may not include any AI-related features at all. It’s hard to predict, as I’m not really focusing on that yet at this stage.

Hi. As for the availability of full documentation, that is still not fully decided. At the moment, I don’t think such a document would be available any sooner than in about 3-4 weeks. I consider full documentation to mean a proper technical description of the project’s content, and with a project of this scale, covering all of the important information takes time. Before working on the documentation, I was also planning to record a series of tutorials covering the most important parts of the project and showing how certain changes can be made. I’m also wondering whether, in your case, the Blueprint code or the C++ code is more important. I’m not sure whether creating a complete description of the C++ side would even be able to do. For that, I would probably need a few more people helping me. You also mentioned that you wanted to make some changes related to stairs. I’m not sure if I understood you correctly, but the special movement behavior on stairs can be easily disabled in: MovementParamsControl_Player->CalculateSimpleOnStairsValue

Hi. From your message, I understood that your questions mainly relate to the future project I may work on after AGLS v2.0. I think the mechanics you mentioned depend heavily on personal preference, and support for them should ideally be considered from the very beginning when designing a given system. Features such as automatically determining which Traversal action should be performed strongly remind me of games like Assassin’s Creed. The issue is that games of this type usually rely on dedicated navigation data that is either generated or manually placed throughout the levels. So far, AGLS has not used this kind of approach. Actions such as Mantling, Predictable Jumps, Vaulting, and Ledge Holding are determined dynamically at runtime by analyzing the surrounding collision geometry. There are no predefined positions for these types of actions. Which approach someone prefers depends heavily on their own preferences and on the overall structure of the game they intend to build. I don’t really plan to create a system where, for example, the player simply holds Space and the parkour actions are automatically selected and executed one after another. What I would be more interested in is integrating everything through a main Traversal component, which would determine which action or sequence should be preferred in a given situation. I’ll try to explain this a bit more clearly. Currently, many of the parkour related components in AGLS operate independently and have relatively few dependencies between them. This can result in different functions testing the surrounding geometry separately, for example: - ClimbingLedge -> FindingLedgeForHold() - LadderClimb -> FindingLadderInstance - TraversalAction -> FindTraversalPoints() and so on. These functions run in the background, and whichever one returns a valid result first begins its sequence. This is not the most optimal approach, and it can also lead to conflicts between systems. A better solution would be to create one main function responsible for analyzing the area around the player and determining which actions are available, then passing the resulting data to the appropriate components. As for the animation side of things, it is still too early for me to say much. At the moment, I’m still focusing exclusively on the AGLS project.

Regarding UE5.8, I did run into some issues with that version. I mentioned this in the post containing the project files. I will definitely prepare the files for UE5.8, though I just need a bit of time to do it.

Hi. I checked your comments regarding potential bugs, but in my opinion, the bow's behavior was correct. Perhaps I didn't fully understand the issue you're referring to. If possible, could you demonstrate it in a video? In my tests, if the player has 4 arrows, holding the aim button and then click shot button then arrow starts move. If the player doesn't release aiming, the next arrow is loaded, but firing it requires pressing the left mouse button again.

Hi. I think that, in terms of major changes, v2.0 will be the final version. There will definitely still be some smaller file updates, mainly focused on fixing potential bugs and possibly refining certain mechanics. I’ll also provide a list of the main changes. As for Beam Swinging, yes, I did try to improve that mechanic a bit. The main changes there are related to animation blending. For that purpose, I used a solution based on Blend Stack. Interestingly, that was originally the only part I intended to improve, but in the end the Climbing System went through a major overhaul, including a completely new additional solver for dynamic ledge detection. It took me a huge amount of time to complete, so I hope these changes will be an improvement overall 😅.

Update* just came back from testing some of the new stuff love everything i have seen cant wait for the assets to drop you have done amazing work Jakub thank you for your service

ah alr, love the project, sad to not see the crawling mechanic where you can lay on your back, would have been one of my fav things to the update

Regarding the project files. I have the v2.0 files ready, but I still need to prepare the description for the new version as a Patreon post. I should be able to get that done by the end of the day on September 26th 🙂