[Sticky] Support – Modern Survival Horror Framework

@jsanzs Yes, the custom arm mesh should be using the UE4 skeleton, so this may be the cause of the issue you're experiencing.

For my test, I used this free asset pack and everything worked correctly. You can try using the same pack as a reference. Just make sure that the first-person arm mesh is assigned to the same UE4 skeleton used by the framework.

After assigning the mesh to the character class, save the project, close it completely, and reopen it. Everything should work correctly afterward.

For future updates, we are also planning to add UE5 Skeleton support for first-person arms, similar to what is already supported for the third-person character setup within the framework.

@farshad thanks for the quick answer, the ladder problem i have is that the character doesn´t get off the ladder  and it just keep climbing.

Edit* I tested a newly install of the framework and it works as intended, but once i migrate my maps to it, the ladder stop working correctly, so the problem is on my end (epic should really implement a better way of updating content, migrating is so frustrating)

@hosna Thank you so much, you've found the solution! I now have functional arms, haha. Cheers!

@jsanzs Great to hear that 😊 , If you run into any other issues, feel free to reach out anytime .

Posted by: @hosna

↑

@commancho I'm glad you're happy with the AI changes! More improvements are on the way. We're also currently exploring the addition of a zombie grab and bite system, which I think could be a great addition 🙂 

Regarding your question, do you mean the weapon animation or the character animation? you should be able to edit them there without any issues. If there are any issues, we would really appreciate it if you could send a video so we can take a closer look and investigate it further.

Weapon sockets are OK. I would like to for example adjust the animation of the left hand of player character, because it doesn't match my weapon's skeletal mesh. I was trying to edit animations for the player's character (for example MSHF>demo>animations>shotgun>AS_shotgun_aim or AS_shotgun_fire), press save, close sequencer and open animation again, it brings back the oryginal animation. Btw melee animations are in the same folder as pistol animations and shotgun is using the same animation as rifle, which is fine, but still I think it should be a separate file in the correct folder (sorry, I'm obsessed with keeping things tidy and I can't help with it 🤣).

I mean, I will eventually replace all the animations with my own. I'm just curious, wheter I'm doing something wrong or if there is anything overwriting my changes.

Here is screenshot from my project, where you can see, why I'd like to adjust floating left hand of player character during aiming with a shotgun

@commancho Thanks for pointing that out. I'll review the animation folder organization and make some improvements in a future update to keep everything more consistent and easier to navigate.

Regarding the hand position, it looks like the animations may have an offset with your character. When editing the animation, are you pressing the Key button after making the adjustment?

Also, make sure you're making the change on frame 0 and avoid modifying the transform on later frames unless intended. Otherwise, the animation may not behave as expected.

@calo Yes, unfortunately, that's currently the only way to update the project. That's why we plan to launch a dedicated DIY section that will make the update process much easier.

There are 5 issues with the door:

1 - I found that the door still has a physical glitch. I just tried using it, and it’s still causing problems; if you walk past the side of the door, it will still “break.”

2 - Another issue. The door is too physically constrained by the scene; the animation doesn’t move freely, and the door isn’t independent of the scene. That is, it requires precise positioning within the scene to open; if it isn’t positioned correctly, it “breaks” (the door becomes disconnected and starts opening and closing on its own).

3 - The door’s sound (initial test, I haven’t tested other sounds): the door’s sound plays in reverse when you add a sound to it. When I set the sound to play when it opens, it simply didn’t work, and the sound only played when it closed.

4 - This is the most serious issue of all. When I duplicated the door, it completely compromised the original blueprint. When I duplicated it, not even the original door sound worked, and it started functioning in reverse. And the door exhibited bugs (issues from item 2, and even acting more autonomously).

5 - The door’s animation is still very aggressive. Not that it needs to be 100% natural, but it delivers a hard slam, and it doesn’t move in sync with the character (when you walk through it with the character), and when it opens when you press E, it opens but still delivers a hard slam. But the positive point is that it closes smoothly. However, it sometimes exhibits the issues from item 2.

- I think the door needs to be sturdier and heavier; it’s too light. It also needs to interact less with the environment. (For example, if the door is positioned in front of a wall, it shouldn’t break through the wall—it should simply pass through it.) Otherwise, if the environment is too rugged, the door will either break or fail to open. I saw the message indicating that it isn’t in the correct position; I thought that was very good, but sometimes in certain scenarios, it will actually need to be positioned imperfectly. (A raised plank behind it, or a broken floor.) -

The physical rigidity (if she can simply pass through anything, it can interrupt her physical conflict with the environment and the character) and her limiter are causing this problem.

@gamestart Thanks for taking the time to share these very useful points about the doors. We are continuously working on improving this system, and with each update the doors will get better. we will review your great feedbacks.

Hi everyone,

I was reading the documentation and noticed it mentions that the framework includes two different types of zombies.

I've been digging into the files and found the BT_DemonZombie Behavior Tree and the VomitingEndSpawnPoint component inside the character, but I only see one base character class (BP_AIZombie) in the folders.

Could someone point me in the right direction? How exactly do I set up or activate the second type of zombie? And how do I trigger that vomiting attack?

Thanks in advance for the help!

@jsanzs Thank you for asking this question. Yes, there was also a second zombie type in the previous version, but it has been removed in the latest version because it is currently being updated and improved as part of the framework overhaul.

Some parts of the documentation still reference the older version, and we apologize for any confusion this may cause. Our goal is to update the documentation across all sections as quickly as possible. Many parts have already been updated, but it is still in progress.

Additionally, the current zombie includes a “vomiting attack” behavior, but it does not always trigger in order to avoid overwhelming the player. In upcoming updates, zombie AI will be further improved, and more variety will be introduced as well.

@hosna Thanks for pointing that out.

I reviewed the new version 4.2... I just forgot to add it to the game. Sorry...

I'll test the new version in-game (extensive testing), outside of the demo system (it's very stable in the demo system).

I liked the idea of the two doors. A tip about doors:

Check out this project:
https://www.fab.com/listings/e6c7316d-ec60-4207-b7d0-b66fdecf1860
(if you don’t want to open the link, here’s the name):
DarkPlayerASSETS
Advanced Door System
It has many very good door systems, which I’m trying to implement in the project (and it’s proving quite complicated, since its system works with interaction inheritance, and adding interactions isn’t working).
Example: I add the parent class to the interface of another interaction from a different project, add the start interaction from that code, and it doesn’t work), because the system is working with inheritance (which is good—very good—it reduces future conflicts, but it makes it complicated to add more things later).

Another insight: chains on the double door.

Another Insight: https://www.fab.com/listings/3225fc4e-f90e-48a8-821e-e1efdd44ad7f
(if you don’t want to open the link, here’s the name):
TansuErgene
Horror Engine SE
(it has very good interaction systems and great footsteps [I like the idea of variations like doors, footsteps, interactions, etc., as it gives more options to work with), just a tip for the scope of the project, not a request for an addition.

I’m really more concerned with the robustness of the system.

Thanks for pointing that out.

I reviewed the new version 4.2... I just forgot to include it in the game. Sorry...

I’m actually more concerned with the system’s robustness and ease of implementation than with new features. But I like to provide insights in case you want to create things in the future.

Note: In version 4.1... when I added the drawer, I ended up picking up the table instead of it opening. I don’t know if it was a conflict I caused (since I only added it; the doors conflicted in that version when I duplicated them). But when I took the blueprint and placed it on my map, my character picked up the table instead of opening the drawer. And I don’t know if they fixed it for version 4.2.

I’ll test version 4.2 tomorrow. I could have sworn I had implemented it in the game.

Thank you.

Hi

I wanted to make two types of zombies (the old one and the new one), so I changed the new zombie name(so that it won't replace the older one) then I migrated it to my older project. Everything works fine, the zombie sees me and attacks me and kills me. But If I try to shoot it, it's not affected by bullets and can't be killed. Is there an easy fix for this? Or maybe the new update changed a lot of things that it won't be possible to fix something like this, I just have to use the new player blueprint.

@gamestart No worries at all, and thanks for the detailed feedback and suggestions!

I completely agree that robustness and ease of implementation are very important. At the current stage of development, our focus is on expanding the feature set. As you can see on the roadmap, versions 0.5 and 0.6 already have some exciting features planned.

But 😊 after that, we plan to focus more on improving usability, integration workflows, and overall ease of implementation. Feedback like yours is very valuable and helps us identify areas that can be improved during that phase 🙂 

Thank you again!

Posted by: @hosna

↑

Regarding the hand position, it looks like the animations may have an offset with your character. When editing the animation, are you pressing the Key button after making the adjustment?

Also, make sure you're making the change on frame 0 and avoid modifying the transform on later frames unless intended. Otherwise, the animation may not behave as expected.