i made the bp_unit re parent to character so noting from the gridactor. i did what you said and made GridIndex variable in my new bp_unit, but it just seem like i doplicate almost everything from the gridactor to my bp_unit. even the consturction script. am i out of it??
Yep, that is basically how it worked a few updates ago and one of the reasons I decided to refactor it. You need to more or less copy over everything from BP_GridActor if you want it to work this way.
yep got it, i feel so stupid:) its not so complicated but somehow i struggle for hours. but its good i learned few things.
thank a lot
cheers
leo
No need to feel stupid. Iāve also struggled for ages to fix things up when Iāve changed something in one of the blueprints and forgot to change it in the other, or use the wrong GridIndex or whatever. Good riddance too it, and Iām happy I refactored it. It is unfortunate that it makes things a bit trickier for these kinds of corner cases, of course. All of this would not be necessary if Epic included things like the movement component etc. as components that are fully available to all blueprints, but oh well. A man can dream.
Hello
I have problem with animation in diffrent skeleton. Iāve setup new BP for animations, and Unit (I copied BP_Unit_Anim and change mesh, Animate Movement, Animate Ability and cast) and still my movement is not working. I donāt know what else I must change.
Second problem that I have is when my new unit attacks enemy game stops in some kind of loop and nothing is happening.
Regards
Could you be a bit more specific in how it is not working? Is the unit stuck in T-pose? Does it have an idle animation, but does not change to the move animation when moving? Something else? For the game stopping after attacking, Iām guessing EndAction is never called. Take a look at the included ABP. Youāll see that the animations include notifies that call back to the event graph of the ABP to end the action. If youāre not doing this or something similar the game will have no way of knowing the animation has ended after attacking, and so the game will not proceed.
Idle animation is working and itās not changing to move animation, but in BP when simulating speed float has value and itās passing to Animate Movement. I will check EndAction.
Hello, I found this events on animations, thanks for showing this! Now all is working good!
Regards
Great to hear! Let me know if you run into any other issues.
Hey, @Lexx ! Visibility is determined by whether or not the trace channel RangeTrace is blocked. You can make units block line of sight by adding a collision box to the unit that is set up to block RangeTrace in its collision settings. Other than this you need to make sure that the unit does not block its own line of sight, so on unit activation set collision to false for this collision box, and then set collision to true again on unit deactivation.
Unfortunately this not worck, in this way you canāt shoot, enemy unit mark as wall.
Hi ! Iāve been getting more into UE4 specifically for this toolkit - youāve made an awesome job. Could you (or anyone else) share me your wisdom when you have the time? Iāve been watching all your videos and trying to do it myself, but Iām starting to hit some blocks that I donāt know how to approach/overcome. I bet these are very very simple questions - Iām a beginner on this, coming more from the 3d art side of things.
Question 1 - Pic attached
.
Question 2 - Pic attached
.
Question 3 - I noticed that you published a new version of the toolkit on the marketplace, since my launcher suggests me if I want to upgrade the toolkit. How can I quickly compare what version do I have, versus what version is up? No idea for the former, but for the latter, I suppose I could always come here and look for the latest post I can find of you with the update info, unless there is a quicker, more automatic way of doing thisā¦
Anyway, thanks for your time! And if you think these have already been answered somewhere before, donāt hesitate to point me towards it. Cheers, keep up the awesome work dude!
hi
i can only help you with question 1 and 3
-
i think you can move into the wall because you are using a static mesh wall, if that is the case so you have two option: go to the grid manager and enable the trace for walls option, or you can use the bp_ga_tile (it in the project) this tile have everything set inside(edge cost).
-
in order to see what version you have just go to project setting in the editor and look you will see project version number. the last version is 1.91
cheers
leo
Hey Leo, thanks for the reply! I was able to find the Project Version thanks to you, awesome. And as for finding the latest log of new updates, after Ctrl+Fing ā1.91ā through the latest page of this thread backwards, I found the post in page 147. I then had the dumb realization handily transcripts all this info into the second post of this thread on the first page. Oh.
However, , in that changelog I would suggest for you to use hyperlinks to the full post you make later in the thread. Just taking 1.91 alone as an example, even though you correctly summed up all new features/fixes in the changelog, thereās still some cool info you did not include (mainly to not clutter the changelog I would guess) like pictures and your own thoughts on the matter. Itās all useful insight. Obviously itās your call though, but I think those few hyperlinks could really help with your documentation.
And Leo, thanks for your suggestion about Question 1. They are static meshes as you say. Iāll try those two options when I get back home and reply back!
Ah, of course. Sorry, should have seen that one. Ok, then it is going to take a bit more work. Keep the project as per my last suggestion, but make the following changes to the CheckIfTileIsVisibleFromOtherTile function in BP_GridManager (changes are at the end after the line trace). Should hopefully do the trick.
Happy to hear that! Iāll do my best to answer your questions. And thanks [USER=ā641905ā]leo bar[/USER] for chipping in.
Hmm I think the issue is being caused by your extremely high HeightImpassableCutoff. What this variable defines is the maximum height between two tiles of different height at which a unit can move from one to the other. In your current setup, units can move 1000 unreal units (10 meters) in height between two adjacent tiles. Is this what you intend in your game? I have not tested the multilevel tile system for such extreme cases. In order to ensure that everything works properly you should have HeightImpassableCutoff be as low as or lower than HeightBetweenLevels. If you want to have special cases where unit can move between multiple levels for one single tile move you should add these edges manually. I should probably add a descriptive warning message if someone tries this.
Question 2 - Pic attached
.Iām not seeing the same thing you are seeing here. Here I tried to replicate your screenshot and it seems to be working fine:
https://i.imgur.com/Dw3SHS3.png
Maybe youāre rotating the walls instead of choosing different actors for west, north etc? The wall tiles block directions based on the values in their EdgeCosts variable and not based on their mesh. If you want walkability to be based on collision I recommend doing what [USER=ā641905ā]leo bar[/USER] suggested and enable TraceForWalls, which will remove edges between tiles that has something blocking the WallTrace trace channel placed between them. You can always combine this with using Tile blueprints, but be mindful of how they work.
Like leo said, you can check in the project settings. As for finding more exact changes I tend to mark the most important changes with an unconnected boolean variable named after the version it was added (which you can find by using the āFind in blueprintsā window. Like you discovered I describe the general update notes in the second post of this thread. I go into a bit more detail on my Trello, which is also linked to in my first two posts.
No worries! I should really make a tutorial at some point about working with all the procedural heightmap/wall stuff. I agree that it is not all intuitive.
Thanks for the suggestion. As mentioned, the Trello gives a bit more information than the changelog here, but Iāll consider adding some links to posts in the future.
Edit: Impressive Artstation, by the way. Great work!
Hey , thanks for your reply, rich in details too. You were spot-on on all problems haha - Q1 was indeed being problematic because of the HeightImpassableCutoff value, and in Q2 I did rotate the walls around like a silly goose.
This led me to try and solve another issue in my map, which was a narrow zigzag staircase. The player would often be able to cut through it directly, without needing to climb it bound by the laws of gravity. After rewatching your video on multilevels, I was able to complete this! Iām very interested in hearing if you have any other ways to tackle areas like it:
AFAIK, unless I change the geometry, this is the easiest way to lay out this area, right? Height Impassable Cutoff NEEDS to be higher than 150, or else normal units wont be able to walk from the H(height)75 tile to the H225 tile. And the walls are needed too, so that the unit doesnt cut through any tiles.
Alsoā¦
- Since itās all connected, does the grid manager official take this all as 1 level, height-wise? Basically ignoring the āHeight Between Levelsā. If it was set to 74, these would be technically 7 levels?
- For some reason, if I input 150.1 in my Height Impassable Cutoff value, it defaults to 150.100006.
- About your explanation on Height Slow Increment hereā¦If I understand correctly, all itās doing is taking up more Move points from the unit if its condition is met, right? For example: HSI value is 89, and a unit is able to move 5 tiles. If it chooses to move to a tile that is 90 units higher, that tile will ācostā 2 Movements, so in total that unit would only move 4 tiles during that turn?
Thanks again for any reply! And Im glad to hear you liked my artstation haha (:
hi
hope you can help me with this one Because i am stuck.
i hope i can explain in a good way so you will understand.
- i made the bp_unit re parent to character and made all The necessary changes, every thing work great.
- when i select a unit i press a button to go to third person view where i posses the unit so i can move (all done in the bp_player controller).
- when i press another button i can go back to top view and posses the grid camera.
- i encounter a problem that after i posses a unit and go back to top view i can not swap between the units anymore and i cant do anything anymore the game is stuck.
- i figure the after i posses a unit and and then posses the grid camera back the unit now(owning actor) is no longer Associated with the player controller ( i printed the owning actor).
- i made a fix(i thought its a fix) and i set the owner of the unit to player controller after the posses flow. that actually fixed the problem when i play in a stand alone or in the editor view but when i package the game(the package is fine, no error) and run the packaged game The same problem exists and the game is stuck without being able to select a unit or anything.
(my package game run in single player)
I think itās something that belongs to a multiplayer or something,Iām really bad at the multiplayer side of thing.
hope you can help me on that
thanks in advance
leo
Ah, of course. Sorry, should have seen that one. Ok, then it is going to take a bit more work. Keep the project as per my last suggestion, but make the following changes to the CheckIfTileIsVisibleFromOtherTile function in BP_GridManager (changes are at the end after the line trace). Should hopefully do the trick.
Still not work.
1)I create a collision box for BP_UNIT. I put set collision Response to channel - range trace - ignore on event Select Actor
2) I put set collision Response to channel - range trace -block on event End Actor turns.
3)make the following changes to the CheckIfTileIsVisibleFromOtherTile function in BP_GridManager (changes are at the end after the line trace)
Maybe it possible do it same think via ability system?
Good to hear!
Yep, you got it right. If you do not enable TraceForWalls this is the way to do it. However, with TraceForWalls enabled you have some other options as well. You could then skip having the invisible tile actors and instead use a single invisible wall mesh for each ālevelā of your staircase. An even better option could be to enable TraceForWalls and sett TraceForWallsHeight to something really low, like 5 or 10 unreal units. I think that should automatically give you the result you want without having to add any invisible walls (so long as the staircase itself blocks WallTrace). How TraceForWalls works is that it runs a line trace between each tile and its connected neighbors checking the WallTrace channel, removing the edge if it is blocked. It goes from the center of one tile to the center of the other, offset by TraceForWallsHeight. If you set this value low enough it will be blocked by a small height difference when there is a sudden drop, but not if it is a smooth incline. This may or may not work with the way you plan to make your level as a whole, but it should work well for what youāve shown me so far. Test it out and see if it does what you want.
As an optimization measure when I first made the heightmap system, the toolkit will never add more levels than needed. More specifically, a tile will only count as a being at a higher level (meaning that is has a grid index higher than GridSizeX * GridSizeY) if there is one or more walkable tile directly beneath it. In your screenshot above this means that all tiles will be at the same level, as far as the Grid Manager is concerned.
Edit: Just noticed the stairs lead to the top of a bridge. So all tiles will not be on the same level. The tiles that are directly above the walkable tiles below the bridge will be at level 2. If you want to see this for yourself, enable PregenerateGameplayGrids and ShowTileIndexes. You will see that all tiles at a higher level will have a grid index equal to the tile below them + GridSizeX * GridSizeY. Just remember to disable PregenerateGameplayGrids later, as any changes you make to the grid after checking this will not go into effect before it is disabled.
That is just a rounding error that comes with floating point values. It is based on how such values are stored in memory. Integers will always be exactly what you set them to, but floats will be a tiny bit imprecise. I recommend reading an introductory course in C++ if you want to understand this more fully. It should not matter for your game though. UE4ās blueprint nodes are generally set up to take this into account.
Yep, basically movement cost equals height difference divided by HeightSlowIncrement. If you never want height difference to affect movement cost, just set it to be as high as HeightImpassableCutoff.
No worries 
Hmm, my guess is that unpossessing the unit causes the player controller to lose ownership of it. When a unit is activated, the player controller that owns it is told to activate one of the unitās abilities. Since it does not own the unit anymore it does not receive the message. If youāre making a single player game this should be easy to fix. In the event graph of BP_Unit, fins where ActivateAbility is called on the owner of the unit. Replace the owner input with GetPlayerController.
You will also need to change the OwnsActor macro in BPML_ATBTT. Either remove all instances of it or set it to always return true if youāre lazy (though if you do this youāll need to manually recompile all blueprints that use it due to an annoying quirk of UE4 when it comes to macro libraries).
No, what I suggested should work as Iāve tested it. It seems I failed to paste on essential node in above, though. Sorry about that. At the very end of the function, if TargetIndex == GridIndex returns false, you should add a return node with Visible set to false. Here is how I personally set up collision to be enabled/disabled in a child blueprint of BP_Unit:
https://i.imgur.com/Nf1SEi4.png
https://i.imgur.com/FcsSsky.png
Here is how it looks in game:
https://i.imgur.com/gfyKmUx.png