A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Assets and Asset Store' started by sr388, Sep 1, 2015.
Wow thx. I keep you informed and thx for awnsering so fast
Wow. it worked. Men you are insane!!! I bought this assset 2015 but at this time it was too complicated. And i learned a lot over the years and now there is your Package with soooo much parts. Wow!!!
Of course, I always try to answer any message asap.
Haha, thanks, glad to hear that . And thanks for being one of the first supporter of the asset in their first weeks/months, back then when it was gravity twist controller instead of an engine.
I have questions just bought the asset on 27th still learning not sure if its my error on setup of character. But once i put character in scene with inventory and weapons on character. I push 1 or 2 or 3 weapons it does not equip out to where i can use them. I have to open UI and click on weapon un-equip and equip to be able to use weapons. Another way It also works if i drop weapon and pick up it equips and i can use.
Thanks for your purchase and interest in the asset.
How do you configure the weapons? If you want to use weapons through inventory, they should be configured in the inventory manager inspector, here:
Every inventory object here can be configured as equipped or not and also if the inventory object will be added to the player's inventory or not (to avoid to remove an objects just to not included it, for an easy workflow).
Set Is Equipped and Add Inventory Object as true here and the object, in this case the weapon, should appear as equipped.
You can select the inventory object in the field Object Name
Take a look at this doc with the basic use and first steps: https://www.dropbox.com/s/74xm3rp9u...ntation 2.4d (First Steps and Setup).pdf?dl=0
It explains how to manage weapons, in case you use inventory for them, or just as a weapon list separated from inventory.
Tell me if you are able or not to configure the weapons. We can make a remote session to explain this deeper.
Awesome ill look into this thanks for quick reply. ill get up a great review just trying to learn the system. Look forward to cool updates. Also i saw on poll experience and skills high on list any timeline or expectations on that update if its coming.
If you incorporated voting items 1 & 2 I would buy this as well as many others I know in a heartbeat.
Cool, glad to hear that, thanks for the support.
All the elements in the poll belong to the roadmap for next update after current 2.9, which is 3.0.
3.0 will be started in a matter of days, and it will be composed of different updates inside of it, focused on specific elements (vehicles, player, AI, weapons, save system, etc...), with 1-2 months for each update.
Crafting/trade/vendor/experience/skills will arrive in the first update of 3.0, so probably around 1-2 months from now.
Thanks @SickaGamer for your interest.
In fact, RPG elements is something that will be powered in 3.0, including melee combat, along with all the elements of the poll on this forum, including Crafting/trade/vendor/experience/skills/quests, which will arrive very soon.
The melee combat will be inside of the second update of 3.0, so you can wait for these elements to be added before to decide to get GKC, but you can be sure these elements are very planned and will arrive on 3.0
Or get it right now....haha just kidding, take the time you need.
Also Dual weapons, melee combat system/ magic casting would be awesome as well.
Yeah, planned as well for 3.0
You get it done and out and then I will buy
I'm not sure what you need, but I'd think GKC must come fairly close to fitting your needs already.
If you have dual weapons animations already, I'd think you can hook them up in GKC. The only modification you'd need that I can think of is draw / re-holster and hold two weapons at once ... and that's probably already do-able?
Likewise, I'm not sure what else is needed for melee combat. Very early on, GKC used a punch and kick animation from a free character kit. So I'm guessing that again, if you have melee animations, you may be already able to do some fighting.
As for magic, the GKC controller does already have some "magic" type powers; attacks that are like spell casting. You could probably add your own magic animations to this, although maybe there's no room for an animation since those attacks currently use IK. IDK. But there's a free spell casting animation set in the asset store that a lot of people use.
I'm sure there's room for improvement in these areas, but I'm not sure you have to hold off on buying GKC. It's possible it would already fit into your development process.
Are you planning a Sword fight combat system like breath of the wild?
The animator has been improved to make easier to add new layers and parts to manage the future melee combat and other systems and actions, so very soon, it will be possible to manage all of this without need to additions or modifications. And of course, the power system will be able to use animations as well, for spells, magic and similar stuff.
Yes, the melee combat system will be as general as possible to allow all the customization needed. I want to take inspiration from botw and dark souls for the initial melee system, including dodges, block attacks with shields and other weapons, two hands weapons, use lock on target (which is already done), combos, weapons that are damage and can be broken and repair from using them and more stuff.
If you aren't directly implementing a Playables-based animation system, may I suggest you try to keep the animation system hookups flexible enough to allow us to implement one?
I don't know what that would look like yet, personally, but I imagine it would be similar to how animation control would be handled for multiplayer; that is, not tightly hardwired.
Didn't remember about Playables. Thanks for remind it, I will put on the todo list to take a look to see if it is a good solution for the melee combat system (I think it is not very extended yet, is it?).
About animation system hookups flexible enough, do you mean for example to have the animator parameter strings names visible on inspector?
My idea for attacks management and combos is to use an ID field in the animator parameters to trigger different animations and avoid a lot of connections between animations, though not sure how flexible this solution would be yet.
Haven't totally thought how the whole melee combat system will work (for the animation management part), so any advice about it is very welcome.
One user asked about using the previous system to carry weapons on third person using IK, instead of the new option. So, just in case, I want to clarify that the previous option is still present, as none feature or option is never removed, unless it doesn't work as expected.
In that case, it is just delayed to a future update, similar to what happened previously to the climb ledge system and the IK foot system, which weren't as good as I wanted some time ago, but now both have been reworked, achieved and added for upcoming 2.9.
And back to the carry weapon option, you can see an example of changing and carrying a simple gun freely on player's hand and a rifle being carried with both hands and using IK, so according to the type and size of the weapon, one option or other can be selected.
I don't know if my comments on this will be all that helpful, as I'm still learning all of this myself, but I'll give it a shot.
I imagine you have a pretty good idea of how to go about it. Probably following the philosophy of setting up events is the way that can best be intercepted and redirected as needed.
In a multiplayer environment, the client translates player input through a player preferences table into commands that go to the server. (GKC is already built generally in this direction, where players can set the keys to represent different actions.) So if the player has configured W to be forward movement, when they press down the W key it should set a state of "forward" and set "dirty" on the direction state. Then under a separate script that maybe polls the states every fifth of a second (the dev sets the rate; philosophically you want to use Unity's Update as little as possible to unburden it), if dirty is set, the script looks at the state of all directions (up, down, left, right, forward, back; or WASDX + space) and calculates a heading, and then a command would be sent to the server to indicate a change in heading. The server receives this command, and if the player is not inhibited by other game states (it might be immobilized by a spell or glue trap, or is falling, for example), the server sends an event to each client telling them that this player has a new heading.
Player location and rotation is a separate state, which can be sent at regular time intervals, to authoritatively override the client's estimations. Movement modes (walk, run, fly, strafe, fall, jump, crawl, swim, skate, ski, surf, stealth, etc.) are separate too and may change, though usually a lot less frequently than direction.
Also, when the player releases the W key, this change of state is transmitted to the server, and all clients receive the event signalling the new heading for that player.
This same client / server structure will work for single player as well. The client scripts tee up the events, and the server / game manager scripts periodically process the commands along with any AI reactions and send the result back to the client scripts for updating the rendering of characters and UI.
If regular mecanim animation graphs are used in GKC, when a customer wants to change the default jump animation, they can find it in the graph and swap it. But if they want to add several spell casting and melee attacks, and hit reactions / status animations, and variations depending on movement mode, it can start to get complicated and the graph can swell up.
Playables were introduced in 2017.2, I think, after having been experimental since 2015. (If it's important we can look it up.) Playables should be present for 2017 LTS and 2018 LTS. What playables do is allow you to build an animation graph for each particular action, and switch the graphs around on the fly as needed. So instead of having one monolithic graph with every single animation you might ever use in your game loaded, you dynamically load the graph with combination of animations you're going to use at the moment. Maybe something like "combat idle, roundhouse kick, combat idle." Or something more advanced, combining modes like grounded, gravity direction, flight, swimming, and stealth with movement directions, additive animations like breathing, and using masking to put a sneer on the face of the character as he also masks to combine left and right pistol firing while running on the ceiling. And then add IK with tweening for "look ats" on eyeballs, head, and pistols in late update, of course.
Having all your game's animations and their permutations in one graph gets crazy fast, unless your game's animations are small in scope. That's why they finally developed playables. Here's a teeny tiny view from one popular kit from back in 2015 that included some prop animations. The full graph for this was immense and mind-boggling.
Add a lock-on for the closest enemy within a certain angle in front of of the player. Similar to how 3D Zelda games have or GTA has an interesting lock-on setting. When the player locks on to an enemy the player can side step around the enemy but will always be facing towards the enemy as long as they're within "combat distance"
Very interesting explanation and pretty good detailed, thanks a lot for it @hopeful
The animation and state explanation for online multiplayer will be useful as well.
About playables, yeah, will take a look at it when I start with 3.0 and the next animation improvements for the player (and inside of it, all humanoid AI receives same improvements as well since they use the same animator controller by default).
In fact, for 2.9, the animator has been simplified, removing a couple of not needed layers, keeping its previous actions, adding new ones and improved them at the same time, with a few new tree states to manage better different movements in player.
What you said about get pretty big graphs is one of the things I want to avoid in 3.0, to make everything as modular and independent as possible, keeping customization and make it also able to combine different layers, to combine different animations at the same time.
Thanks again for your explanation, it is very good.
There is in fact a lock-on system which was added a long time ago, and which can be used as aim assist or as a separated key action to lock targets on screen, making the camera to look in that direction and with it and making also the player movement relative to that position as well. There is also an option to make player to always faces the object which is being followed by camera.
It can be used in any free and locked camera (fixed camera position, top down, isometric, 2.5d, etc...). Here some examples:
Here the aim assist on weapons, which only actives the lock-on a certain amount of time and then disable, so player can move the camera again.
Here is used to aim to different body parts according to the closest one to the center of the camera. Any amount of body parts can be added to a character, vehicle or object which can be damaged.
And here using the lock-on key action to follow the closest target to screen center. Another key disables the lock-on.
Thank you! Let me amend and add a tiny bit.
First, I was just winging some of the networking illustration to give the gist of the approach, and upon reflection I realize I got some of it wrong. I guess actually the client shouldn't calculate the movement heading, but instead send the direction states to the server. Since there's a limited number of direction inputs (at least when using the keyboard), and they are binary (off/on), the six direction states (up, down, forward, backward, left, right) could easily be described by six bits. So send the six state bits to the server whenever they change (as determined by the polling), and the server can calculate the actual heading. The server (even if on the same computer) has the manager scripts that make sense of the movement context (like collision, navmesh, etc.), while the client scripts are limited to gathering input and rendering the result, so the client should give up the raw direction data and wait for the server to give it an animation and heading, receiving that info in at the same time and in the same manner as the other clients.
As for the really large and complicated animation graphs like the one in the picture, my impression is that most of the professionals generate those by code, which makes it easier to keep them straight. An example of a UAS helper for this is here (C# Animator).
The playables graphs probably would also be generated by code. An example of that is found here (Animancer Lite, free).
Networking issue are well explained here too
With nice animation that show strategy for clients and server around various problem.
Damn forum notifications, today I have received one from a message here from saturday -.-
I see, thanks for the extra info, very useful to know
About animations, I am getting used to use animator graphs, but using generation by code would be interesting as well. Will take a look at it as soon as I start with 3.0.
Cool, I think I already had this GDC video pending to view haha. Will be useful to see as well.
Thanks for the info about online to both, it is very appreciated
I have improved lock-on target system for the camera, allowing to change between targets on the screen using the camera input direction (mouse, gamepad, touch joystick), so according to targets on screen, their position from the camera center, their position direction respect camera center and mouse movement direction, the next target selected is calculated with a great accuracy.
This allows to have a better lock-on target system similar to games like dark souls, the legend of zelda, sekiro, etc... Also, this can be used on any view mode, with weapons/powers and with the future melee combat system.
Here an example where the player moves freely, but when lock-on is active, he enters into strafe mode, facing the target direction.
In this one, the player is by default in strafe mode, and same when the lock-on is active.
Here the player can move freely in both states.
And here an example on first person.
Another option will be added to just use vertical movement in the mouse to select the target to check, being the closest on left or direction to the center of the camera.
Do you have auto lock on? the most potent example is batman arkham, basically the game "snap" toward a target, generally wirth a few more rules (like aggressivity of the character) to select a target. Will be useful to make a generic melee system that can cover huge range of fighting style. Basically there is 3 general mode of fighting target detection, broad swiping collider, target snapping, or contextual move (lugaru, overgrowth).
For now, this is a manual lock on, used as a separated key action (L by default) and in aim assist for weapons and powers in any view.
But an auto lock on option could be added, for example, when the player engages combat with an enemy or a group of them, with different options, like the ones you said, and others like distance, manual target change using mouse/gamepad/touch joystick with the new option added to change target to look manually, etc...
Will add this features in the todo list for the melee combat system, thanks for the suggestion
Btw, I have added the option to change target to look on the lock on to just use horizontal movement in the mouse/gamepad/touch joystick to select the target to look, being selected the closest on left or right direction to the center of the camera.
This make easier to change target, since the player only needs to know if he want to select the next one at right or left and move the mouse in that direction.
Here in first person with a bunch of NCPs.
And here in third person with some positions to look, which can be placed anywhere in the level without need to being a character or an object to damage.
As you can see, the system always checks the current position of camera and the position of the targets on screen when the action to change target is activated, making the system very dynamic and taking into account any new position or distribution or targets.
I finally go ahead and added an option on weapons to configure if the arms rotate in the right axis (up and down) toward the camera direction when the player aims. This looks like the player is actually moving his arms to aim up and down, with a more organic behavior, so the rotation in the upper body will be more limited combined with arm rotation, getting a more dynamic player. There are options to configure speed rotation, clamps values with top and bottom maximum rotation values and how much rotation is applied according to camera rotation.
This is how the system looked on 2.41d:
Here, along with the rotation point on the weapon, the upper body use the new clamp option to limite the amount of rotation in the player spine, so combined with the rotation point, it makes a more realistic movement on the player.
And here how it looks ingame.
Also, the rotation point where the weapon and arms are rotated can be configured in any place, according to where the weapon is carried in player hands (for example, the rotation point can be placed close to the right shoulder using the assault rifle and most weapons grabbed with two hands).
Btw, I am quickly removing all the final tasks in the todo list, so I think this week the update 2.9 will be finally complete.
I have improved a few elements.
A new option in the lock on system allows to activate the outline system in the object to follow, like in the grab object and interaction systems. It also works with the option to change between targets to look.
The aim power state already has the same option as weapons to rotate player's arms around a point, to allow a more natural movement.
And finally, a new improvement in upper body rotation and look direction when the player is in aim mode, for powers or weapons, making him to look in camera direction in a better way, disabling also the spine animation in the avatar used on strafe mode.
Today's work has been some polishment and improve some internal things, but nothing too much noticeable. Another new thing is an option in the input to toggle movement and camera orientation for separated vertical and horizontal value, allowing to invert any of these player movement and camera rotation values.
I am working to have everything complete tomorrow, but I am also waiting for the person who is making the new animations to tweak the new run strafe animations in order to include it, since the animator is already configured to work with them and will be included in 2.9.
do you have planning cover system ??
I realized you could do a better anthem than bioware using this asset in its current state
Okay I heard you are putting swinging in 3.0, turns out gdc 2019 had treasure trove of advice with spider man mechanics' talks
Energy hook is open source from: https://www.gdcvault.com/play/1025725/Classic-Game-Design-Postmortem-Swinging
Yes, a cover system is planned to be added inside one of the updates for 3.0, which will be started this month and will contain many updates with a place of 1-2 months between each other. Cover will be made probably for the third or fourth update, I have already thought how most part of the system will work and how to manage.
Haha, yeah, I made the free floating mode (maybe a better name could be used for it) in update 2.4d thinking in the fly system from anthem and control and was pretty straight forward to add. I have already planned elements to improve on it.
I feel sorry for the postmortem of anthem and bioware, it is an example of how bad a company can be managed until everything is shown to the world.
Yeah, can't wait to work on this.
Thanks for the material resources, it will be very useful muhahahaha. I knew Energy hook and found it very cool, didn't know they released the source, very cool, can't wait to try it out.
Other game that I want to study for this is worlds adrift, it has many mechanics very interesting, including swinging, flying vehicles, climb system, player customization and more.
That Spider-Man swinging thing ... it seems so complicated! And I totally get why it's complicated. Using physics, the overwhelming tendency of real webslinging would be to swing toward whatever building you've targeted, slam into it, stick for a moment, then slide down with a long squeak.
My feeling about how I'd want to control it, as a player, reflects the controls I'd mentioned before (WASDX + space + pan & tilt using mouse + RMB). I'd have the controller assume I always wanted to go forward, in the direction I'm looking when I activate the swing, so no need to press W. The pan and tilt of the mouse + RMB would help me choose the lateral and vertical angle I wanted to look at, and that's the direction I'd travel. I'd press a key (maybe C) to sling a line, holding it, and that would use some crazy algorithm like in that presentation to use approximated swing physics to send me roughly in the direction I'm pointed at the moment I sling. However, once the sling key is held and the motion activated, I can move the camera to look around, including behind me, and it doesn't affect the course of my swing. When I feel like swing physics is taking me off course, I release the sling/swing button and look in the direction I want to go (thereby correcting course) with the mouse + RMB. Then I press and hold the sling/swing button again.
While swinging, I can press the X (down) or "space" (up) to cause the line to stretch or contract at some rate of speed in that direction. This, I think, could help me land or get more altitude when swinging, and it could also help me do a simple rappel upward or downward, like Batman or Spider-Man might do.
Since not all players would have a Spider-Man like wall-walking type ability, I imagine a grappling hook / rappel type game mechanism would favor getting players to ledges they could pull themselves over, or attach above an open space of some kind (window, cavern entrance, etc.), or lift them to a catwalk or ledge they can walk on. I wouldn't want to tag the geometry for that, if I could avoid it, as there's so many possible situations to cover, so I'd prefer to add a world space projected targeting reticle, like a cross or bullseye, so I could select the landing point for the grapple precisely. So for that mechanism, press the grappling activation key, use the mouse pan tilt with no button pressed to place the reticle, and then press LMB when the reticle is at the desired spot. That would attach the line, so after that, press space to go up. It would function kind of like a grapple-assisted jump.
BTW, that's the same basic method I'd use for any player ability that can target in world space. Like, if you wanted to throw a smoke grenade to a spot, click to activate the ability, which causes a projected targeting reticle to appear. Use the mouse to move the reticle to the location you want, and then press LMB.
Of course, attacking while swinging / grappling would be a fun feat. Swinging your sword like a swashbuckler, or blasting everyone with your submachine gun while you're lifting or descending on the line. Great if it can be done, but ...
@hopeful so basically the hamsterball of fortnite?
Beats me. I don't really play games so much any more, I just try to find time to work on my own.
Mmmm interesting. Yeah, I think it is more or less similar to some spiderman game I played (I think the first amazing spiderman from 2012). And by seeing world adrifts, it seems like a similar control scheme as well.
Thanks for the detailed explanation
I will play that spiderman game and energy hook to start to organize controls and the system structure, rules and settings to add.
About using other tools or weapons while swinging, yeah, I want to add that, in fact, in the above video of world adrifts, you can see some parts where the player is able to swing and use a kind of tool at the same time, so that will be possible in GKC as well.
Haven't tried that vehicle (I barely played fortnite), but I will check some gameplay about it. Could play a little with it to see its control scheme too.
I know that feel, spend more time working than playing and sometimes, playing for research purposes haha.
Spiderman and world adrift have very different system actually. World adrift is mostly similar to bionic commando reboot and the hamster ball for being a full physic driven with little help, which mean a lot of fumbling like in video share, while spiderman is slighty automated in invisible ways.
Yeah, they are different, but I want to try both types, giving options to use a physics driving swing or an automated way.
By automated, it's just sugar on top of the physics (see the spiderman talks) to help the balancing go fluidly, so the primary implementation is bionic adrift hamster ball THEN spiderman auto attachment and navigation help.
What I was aiming for in my description - aside from the more vertical grappling aspect - was basically kind of like a forward flight that gets tugged off into left or right leaning parabolic paths the longer you keep holding onto a particular webline (holding the C key).
The game would know what direction you want to go - it's the direction you're facing, due to manipulation of the mouse + RMB - and the player chooses how long they want to stay on a particular swinging arc by how long they hold the sling / swing key down. Most of the time the player would want relatively short individual swings before casting another line, thus on the average keeping them on a straighter path ... and I think this can really only be accomplished by doing the dual handed swinging unique to Spider-Man. The Spider-Man presentation indicated that players wanted to move more straight and be a little less at the mercy of the physics, and I think it could be managed, if needed, by automatically stretching and contracting the line a little bit here and there to keep the player heading more in their chosen direction, and less to the side. I think in order to be satisfying, there must be some swing, and some ability for the player to control it, especially with timing. Automatically stretching too much could completely flatten the arc, and disable any ability to flip at the end.
The player should preferably manipulate the swinging arcs by making the line stretch or contract. In the comics, Spider-Man can start a swing from the ground by jumping several meters into the air because he's super strong, but a typical human character would have to laboriously climb probably at least 30 feet up before getting even a tiny swing ... and even then, they'd be continuously swinging into city buses, awnings, and fences. It would be really hard to gain any altitude. That won't work, so you should have the ability to contract the swinging cable after it latches on, by holding down the space bar, drawing the player into the air. Likewise, it could be awkward to be swinging at a reasonable swinging height - with the nadir well above the traffic - and then wanting to control the landing. So let the cable stretch downward, by holding X, and the player can gracefully exit the swing onto whatever landing zone they desire (provided they have good timing).
I said hamster ball, because fortnite does something vaguely similar, I totally can go in straight line, even though It's a point and shoot grappling hooks. IMHO they probably do the fake anchor point to compute the swing, and you have a button to "rush", the cord is also stretching by design. While ultimately it's not having advance avoidance system, after a bit of practice you go full spiderman with it, which put me into many victory position by letting the enemy exhaust and die himself yeah they nerf it by making it more fragile lol (they had remove impact earlier) so no easy win anymore lol (also player have learn to shoot that stuff on sight).
Oh, yes, that would be the order. By automated, I was more talking about a "fake" physics swing, but not sure how good could be. I think a physic based can be better, so I will work on that. The automated mode will be easy to add, similar to batman arkham or sekiro, to show the player available points to attach the cable.
Yes, think the same, give control to the player to where to move and how much is very important and a must have.
The last part you mention is very similar to world adrifts, where the player can lift by collect the cable. I recommend to take a look at any video from it if you haven't done it yet. It has a very interesting grappling hook system.
Btw, I have had more progress for the update 2.9.
A fixed issue with gamepad triggers to use actions that could be of hold button type. The reason why it didn't work properly before it was due to it wasn't taking into account the type of press to check, down, hold or release, for those gamepad keys that aren't buttons, in this case, axis. But now, they work properly, with actions like aim and fire an automatic weapon (and of course, the rest of actions.
Also, the player now aims properly in top down (or any aerial view). Previously, if the cursor was to close to the player, he could look down to the ground, due to the way it works, which is based on the same system to make the camera to look toward a certain position.
This is how looked before:
And this is how it looks now:
It didn't need any extra addition, just move a little up the transform used to aim, which is the one followed by the camera on a locked view
The animations are almost ready and the animator is ready to use them. The only animations that will be added for 2.9 are running strafe and sprint.
Also, I have removed all the getcomponent lines from the start/awake functions on the scripts for those variables which can be assigned in the inspector. This will decrease the start time.
In the meantime, you can check the changelog so far for 2.9:
Hey there, love you asset man. I have a question though and I'm sorry if its been asked before (probably has) how can I get the close combat working? Please and kicks. Can you walk me through how to set it up?
Nevermind I got it lol
Thanks man, happy to hear that.
That was quick haha. I suppose you saw the explanation in the documentation, glad to know it.
After the main work in the update, I have been checking AI works correctly with the new additions (taking also into account that the player and humanoid AI use the same components).
I have decided to go ahead and make the initial version of the dialog system and it has been faster and easier than I expected (about 2 hours), due to I have it already the structure on text.
This system allows to configure different dialogues, each of one has a list of lines and inside every line, different decisions can be selected. Every decision points to the ID of another line, so it is easy to configure different conversations. Also, every one of these elements allows to trigger events, in the moment the line is changed or when a conversation is over.
There are two components, one in any place/object/NPC to talk, where the dialog lines are configured and other component in the player which receives those lines and manage them in the UI.
Also, along with this, I have added a new system to trigger events remotely. This allows to configure a group of events on an object, using a list of events with a name each one. Like that, this general system can be called from other component with no relation, searching the exact event to trigger by name.
An example of this is the conversation with this friendly AI, which by default, doesn't follow the player when he finds it. So the conversation allows to get the remote event system of that AI and trigger it from the player using the event settings of the dialog system, activating in this case the option to follow the player and sending him as the target to follow and disabling the dialog system from that AI.
All of that without need to use code (of course, for very specific actions, additions could be needed). So the system is very flexible and customizable so far, contains many options and it will be improved with new ones in 3.0.
In these gifs, it uses other previous elements from GKC, like the outline system, head track system, the move camera to a fixed position manager and a few more.
Here a quick video so you can see it better:
And yes, I forgot to change the name of the AI and it says Friendly Turret haha.
Similar to how was made with the components in the player, I have removed all the getcomponents lines from the start/awake functions on all vehicle components, setting these elements as public fields and assigned in inspector, reducing the start time.
Also, I have added an option in weapons and powers to use or not the mouse wheel to change between powers and weapons (previously it was active by default). Along with this, there is a new option in player camera to configure if the mouse wheel can be used to move the camera backwards or forwards, similar to skyrim.
There are values to configure when the view changes from third to first person, according to the distance to the pivot camera, along with camera movement speed and an extra offset, so the camera can be moved backward with a farther distance than the default value in the camera state. So this allows to change from third to first person and vice versa (if the mouse wheel is rotated in the backward direction in first person, the camera is set to third person again.
Also, AI checks are almost finished so today I will move to the final details to complete the update, which is just minor stuff.
Finally, I have also the running strafe and sprint animations properly configured, so I will add it to the animator layer too for 2.9.
Quick question in regards to the top down camera. When aiming in top down view, it seems as though the bullets always stay at the same height on the Z axis. Thus if I have an enemy that is on a platform above or below me, the bullets will either fly over them or below them. Is that an accurate statement with this asset or is there a way to hit an enemy above me or below me when using the top down view? I noticed this when trying out the demo but wasn't sure if this is easily changed in the main asset or takes some tinkering to get it to function like this.