OK, My game is pretty well done. I’m working on the menus, sound effects, finishing touches etc. I thought I was going crazy a couple weeks ago because all my fixed way-point guys switched to random way-point. I fixed all the enemies in all my levels and moved on. I just open my project again and all of my fixed waypoint guys are now random again on every level. What might I be messing with that would cause them all to switch to random? I did just add footstep sounds to the player and alert voices to the enemies. Could that have caused it?
Update: I think that when I change the AI controller, for example to add the footstep sounds, when I press the recompile button it sets them to the default of random waypoints.
Hi Raymond, glad to hear that your project is nearing it’s completion. I think what’s happening is that the enum value for movement type within the melee & ranged patrol bots got reset & hence retained the values of the parent patrol actor which is set to random waypoints. It sometimes happens due to circular dependencies when using inheritance, though I’m not sure if that’s the case.
I’ll try to move the waypoint calculation logic, including the enum over to an actor component in the next update. This way you can just add this waypoint calculation component to an actor & it should act as an independent module. And don’t worry, it’s not going to be a big change. Just a couple of functions within the parent patrol class moved over to an actor component.
Alright, the patrol waypoint calculation logic has been moved over to a dedicated component which should prevent the issue that you mentioned. It will be made available for both 4.12 & 4.13 versions of the toolkit in the upcoming update.
Update 4 (v1.4) has gone live on the Unreal Engine Marketplace. This is a v4.13 exclusive update & introduces the following changes to the product:
Added two new weapons: Handgun & Silenced Handgun, thus providing the option to destroy AI bots instead of just temporarily disabling them. The implementation is handled through the Weapon Targeting System component introduced in the last update. Both these weapons functioning almost identically, with the exception that the Handgun produces a loud noise that could alert nearby patrol bots.
Since the aforementioned weapons introduce the possibility of AI bots being destroyed, the update introduces a new class of actors that act as replicas for the destroyed bots without the performance cost of the real bots that they replace. These Defunct Replica Bots are spawned with the same physical state as the original.
Added a new actor component ‘Distress Signal Broadcaster’ that can be added to any incapacitated bots or dead bot replicas, in order to alert nearby AI bots that are capable of responding to it. For example, an incapacitated patrol bot will use this component to continuously search for other patrol bots that are capable of reviving it. Once a suitable entity has been detected, it will be tasked with reviving the incapacitated bot.
Added a basic Main Menu system.
Moved the waypoint calculation logic for patrol bots to the new actor component ‘BPC_PatrolWaypointSystem’.
Added Motion Sensors that can detect player movement & trigger alarms to alert nearby patrol bots.
All changes within the blueprints are marked with the boolean variable ‘Version1.4’ in order to easily identify the workflow changes introduced with this update. Comments are also written to describe the major changes. The new variables, as well as functions added to existing blueprints, are also marked in the event graph as shown below:
Thanks for pointing that out, James. I’ve updated the tutorial & new screenshots have been added with descriptions to demonstrate the modifications required for migrating the v1.4 Patrol AI to a new template.
The Laser Security Systems in Top Down Stealth Toolkit function as an auxiliary layer of AI Threat Detection by alerting all nearby patrol bots upon being intercepted by the player. The underlying logic is a simple combination of Timeline based movement & Collision Overlap checks. These actors support drag & drop functionality from the editor & can be easily customized using the variables exposed to the editor from the blueprints. This post goes over the impact of the aforementioned parameters on the working of Laser Security Systems.
Length: The Laser Security System uses a box collision component to determine if the player is within it’s range. The length parameter determines the total length of this box & also controls the area covered by the laser particle system.
Max Height: As described in the tooltip, this variable determines the max height up to which the lasers move relative to the default position at which the actor has been placed in the level.
Player Height: The Player Height parameter is used to control the color of the laser based on it’s position relative to the ground. Red color indicates that players passing through the laser will trigger an alarm while white color indicates that the laser tracker has moved up beyond the player’s height & thus enable safe passage below it. This can be quite useful in top down games, as perception of the location of actors that move along the z plane may not always be intuitive to the player.
Alarm Timer: The Alarm Timer value determines how often the alarms are triggered while the laser system has an active target. Since the range of alarm noises are limited, having a timed alarm system can improve the chances of alerting nearby AI patrol bots.
Movement Timeline Starting Time: This parameter determines the starting location of the laser along it’s movement trajectory. It has a range of 0.0 to 4.0, with 0.0/4.0 representing the starting position [i.e. the location at which the actor was placed] & 2.0 representing the highest position along it’s movement trajectory. Anything between 0.0 & 2.0 implies that the laser will have an upward motion going towards the highest point along the trajectory, while a value between 2.0 & 4.0 means that it will have a downward motion going towards the lowest point or the starting position along the trajectory.
Hi, I did a simple test to see how the AIs handle verticality and found out…not so well.
It looks like they properly turn to look at the player, but don’t know to reset their orientation afterwards. I would really like to have a level with some verticality, so is there some way to fix this?
Hi, I added gamepad Left Thumbstick Y-axis and X-axis to <Axis Mappings> under <Input> in <Project Settings>. When I run the game, the player just falls from the sky and drop all the way down.
how do I add Gamepad control?
Thanks for pointing that out, espionageguy. It will be fixed in the upcoming update. The update is going to introduce a lot of changes to the AI design & hence taking a while longer compared to the usual updates. If the changes required are minor, I’ll send in a hot fix update to the Marketplace team before the major update.
Edit: And sorry for the delay. For some reason, I did not get an email notification about the comment.
Hi Leebaba, I just tried out gamepad controls with an Xbox 360 controller & it seems to be working fine at my end. Here are the control mappings I applied to the input settings:
If you’re still experiencing the issue, may I know the version of the toolkit that you’re using? Also are you experiencing this issue in the default level supplied by the toolkit, or within a custom level?
I will be submitting the bug fix update for this issue to the Marketplace team later today. It should be available for download from the Marketplace sometime next week. However, if you want to implement the changes within your project in the meantime, I’ve shared a screenshot showing the changes required to rectify the issue.
Also in the future, if you have not received a reply to your queries within a day, feel free to contact me through the support mail id: [EMAIL=“rohitmohan.k@outlook.com”]rohitmohan.k@outlook.com
Glad to hear that it’s fixed. Yes it could have possibly gone to the junk mail.
Btw the bug fix update has been applied to the Marketplace project files. So if you’re creating a new project in the future, you wouldn’t have to make these changes.
I’m very interested in this kit. Just one question, does it have camera zoom? I would like to let the user zoom in considerably to view the characters small details even better was if it was possible to zoom and pan… I’m actually looking at the camera commands now to see if I can implement this (very new to UE4 and almost only doubts at the moment… eheh)
Hi JMHenriques, there is no camera zoom or panning support at the moment. If you’re interested in something similar to what’s done in Shadow Tactics, I could include it in the next update due for submission later this month.
Any chance you’re looking for a OSX tester?
Either way, I’m picking this up at the end of the month.
I love how responsive you are. Your support for your product alone is enough to make someone purchase this. Thank you.
Thanks a lot for the generous feedback, BoothDigital.
And thanks for the offer to test out builds for the OSX. I would love to add support for it since it wouldn’t require much in the way of code alterations. However, without direct access to an OSX device, I wouldn’t be able to reproduce/debug any issues that could potentially crop up exclusively on the platform. Plus there is also the issue of not being able to package builds for the Mac from a Windows system. As a result, I’m not really looking to add official support for the Mac OS at the moment.
even better was if it was possible to zoom and pan… I’m actually looking at the camera commands now to see if I can implement this (very new to UE4 and almost only doubts at the moment… eheh)