[Sticky] Support – Modern Survival Horror Framework

@herrstickman Hey, Thanks for taking the time to explain the setup and the challenges you're running into. 

The current Zombie AI example is built mainly for survival horror gameplay. You can definitely modify the logic inside AC_AIBehavior, but for what you're trying to achieve, it will likely require quite a few changes and may become more complex than necessary for what you're trying to achieve. 

The framework's AI is designed to be extended through AC_AIBehavior and Behavior Trees, and that's probably the approach we would take for a fully integrated long-term solution. For this particular gameplay setup though, a custom AI class will likely get you up and running much faster with fewer changes to the existing systems.

Since you want to make a new enemy with different behavior, you can create a child of BP_AIMaster (or duplicate BP_AIZombie) and then clear the Behavior Tree reference inside AC_AIBehavior so it no longer follows the standard zombie behavior. From there, you can implement your custom logic directly inside your new AI class. 

The basic flow could be:

-By default, the new AI Enemy moves toward the Keep/Base.
-When close enough, attack the Keep and apply damage.
-If the player is detected, switch focus to the player and chase them instead.
-Use AIMoveTo to move toward either the Keep or the Player, depending on which target the AI is currently focusing on.
-Once within attack range, simply play an attack montage and apply damage.

For the Health, I would keep it simple as well. Two Health and MaxHealth float variables should be enough, along with the usual death/destruction check when Health reaches zero.

One thing to keep in mind is that player detection is handled inside BP_AIEnemyController. Since you're introducing a different enemy behavior, you'll likely want some way to distinguish between the standard framework Zombie AI and your custom tower-defense enemy (for example with a boolean or enemy type variable).

I would recommend starting with the simpler Blueprint-only approach first. Once everything is working and you're happy with the gameplay, you can always move parts of the logic into AC_AIBehavior later if you want a more advanced Behavior Tree setup.

Give it a try and see how far you get 🙂 If you get stuck again, let us know and we'll be happy to help point you in the right direction. Screenshots or a short video can also make it much easier for us to understand what's happening.

@farshad Thx very much!

I really used every source on the internet and after 3 days, I get it working like half, every works half perfectly except for the Behavior Tree. Right now, the enemy must see me to have new awareness, then they attack the keep again or attack me the player. I needed to add many things into the AC_AIBehavior, but still not enough 😀 copied every function I need and changed the targets etc. Your framework is a master peace! 😉
And sry for writing instead of uploading screenshots... sometimes I dont think normal 😀 but yeah, totally right 😀

From your text I understand that:

- from the BP_AIZombie I delete the AC_AIBehavior, then implement all the logics I need into it (HP, anims, Pawnsensing, attack, etc.) when the player needs to implement DMG to them, then I will use nodes I can use for the framework that is not AC_AIBehavior releated.
- I will make the HP setup in the BP_Keep then and use Apply Damage node in the enemies BP.

Thx for your time, cause you also wrote a book 😀 just a joke 😀 thx very much an have a wonderful day!

Hello I'm working on my project using the MSHF and I've run into a somewhat strange behavior when picking up and equipping the melee weapon (Pipe).

I've noticed that when the character holds the pipe in the default "Demo" map, the hands align perfectly with the weapon. However, when I place that exact same pipe in my custom level, the character's hands appear misaligned upon equipping it and don't quite fit the pipe's mesh correctly. I've tested this with both the default character and a custom skeletal mesh, and the exact same thing happens in both cases: it works perfectly in the demo map, but there's a grip offset in my custom map.

What could be causing this difference between levels? Is there any specific setup in the World Settings, GameMode, or a specific volume in the Demo level that I need to migrate to my own map so the hand positioning is calculated correctly?

On another note, I have a quick question regarding the roadmap and long-term development. I know the framework is constantly evolving, so my question is: when future major updates are released, is there a recommended workflow to apply those patches to our existing projects? Or does the framework's structure require us to start a new project from scratch and migrate our content over with every major update?

Thanks in advance for the help and for the great work!

@jsanzs Thanks for bringing up this question and letting us know.

After an initial check, I noticed that this offset appears when placing the Pipe in the level. I reviewed the Pipe in the demo map and found that if you click on the WeaponMesh in the editor, its Location is set to specific values (see the screenshot we provided). When all values are at their default (zero), a slight offset occurs.

For now, you can fix this by setting the WeaponMesh Location in the editor for the Pipe to match the values shown in the screenshot. This should resolve the offset issue. We’ll address this in a future update, so manual adjustment won’t be necessary.

About your other question: at the moment, the safest approach is to download a fresh copy from the latest update via the Epic Launcher, then transfer your custom changes to the new versions. Due to the nature of the templates, this is currently the only reliable method.

However, once we reach version 1.0 and move out of Early Access, we are exploring the idea of adding a PATCH section on our website. This section would include step-by-step guides with full details, screenshots, and video tutorials, showing how to apply updates to older versions.

So after version 1.0, for example, when 1.1 is released, you won’t need to download a fresh version. Instead, you’ll be able to review the changes in the PATCH section and apply them directly to your project. Of course, downloading the full updated version will still remain an option as well.

@farshad thanks!

Hey 👋 just wanted to know how to fix this mistake I did. lol 😆 

@jstudios Could you please tell how you encountered this issue? Did you make any specific changes to the Drawer Blueprint?

@farshad I was messing around with other mesh dressers and their own mesh drawers and I deleted my dresser then this happened. I was trying to put the drawer back to default.

@herrstickman You're welcome 🙂

No, there’s no need to remove the AC_AIBehavior component. Just inside your New AI class, select the AC_AIBehavior component and leave the Behavior Tree field empty.

Make sure to do this in the new class that you created as a duplicate of BP_AIZombie, not in the original class itself.

And yeah, I also have a habit of writing book in chats, so no worries at all 😄

@jstudios So right now, when you interact with the drawer, it moves too far forward, correct? Does this happen during the interaction, or even without interacting?

@farshad only when I interact with it. 😆

I might be a bit blind but I cant find where the default storage box items are being set?

Hi everyone,

I'm currently designing a custom level and I'm trying to set up multiple unique Key Cards (e.g., Level 1 Card, Level 2 Card) for different double doors using the Card Only lock type. However, I've run into a wall and it seems the system is heavily hardcoded to only accept the default stock key card.

Whenever I try to use a custom card, the inventory opens in front of the door, but the "Use" button is completely disabled/greyed out.

Here is the extensive troubleshooting we've done so far:

1. Standard Duplication: We duplicated BP_KeyCard and DA_KeyCard. We set a custom name (e.g., "Key Card 2") inside the Data Asset's Name variable, and exactly matched that text in the door's Key Name variable. We also generated new Unique IDs for both the door and the item in the level. Result: Fails (Use button disabled).

2. The Stock Name Test: We tried using our duplicated BP, but reverted the name back to the default "Key Card". Result: Fails.

3. The Stock Class Test: We used the original stock BP_KeyCard in the level, but changed the text in its Data Asset to "Director Card" (matching the door). Result: Fails.

Conclusion: It strongly looks like the Card Only interaction has a strict double-validation hardcoded into it: It requires a strict Cast To BP_KeyCard (the parent class) AND specifically checks for the exact string "Key Card", completely ignoring the Data Asset values.

Is this the intended behavior for the framework? If so, how are we supposed to create multiple doors requiring different color-coded keycards without rewriting the core interaction logic? Or are we just missing a "magic" hidden step specific to this template?

Thanks in advance for the help!

@jsanzs Hey, thank you so much for your detailed message and for taking the time to report this issue.

We’re aware of this, and this part of the system is currently being updated to become fully modular.

In the meantime, we’ve prepared a quick workaround for you. In this video, we show an easy method that allows you to use different keycards on different doors with only a small and simple modification. Please take a look and follow the steps shown there. For now, just make sure your card name includes the word “Card” (e.g., “Director Card” or “Level 1 Card”, etc).

We really appreciate you bringing this to our attention. As part of our ongoing Early Access development, this card system will be fully refined in version 0.4.3 and will provide a much more flexible and modular workflow. If you still run into any issues after watching the video, feel free to let us know; we’ll be happy to help!

Video Reference

@arcticsubn The default and initial items of the storage box are accessible in AC_Inventory. Please check the screenshot