Thanks It doesnāt look this good for everything, though. These frames are comprised of multiple rigid edge meshes, which works great for flat levels, but variable height becomes a problem in some cases, though I have found ways to mitigate this in many situations. For organic terrain I have also made it possible to use edge decals, but these cannot overlap without doubling brightness in the overlapping corners of the frame, which means I had to make it more like a dotted line.
Itās always a challenge with this toolkit to always make sure every new feature works with both hexagonal and square grids, with landscape as well as placed tiles, with heightmaps and flat maps, with continuous maps as well as sparse dungeons. This is one of the reasons updates take so long. In the update after the next one I will be adding true, multi-leveled heightmaps, which will add another layer (literally) of complexity. Iām getting better and better at it, though
A quick test seems to indicate that the toolkit works without any issues with UE4.10 Preview. So if using preview versions is your thing, simply open a 4.9 version of the toolkit in 4.10 to convert it. If any errors show up I will not release a patch until 4.10 is actually released, but I will post what modifications can be made to counteract any such bugs in the meantime.
Iāve been lurking and reading through the thread for a few weeks. The toolkit looks awesome, and the updates youāre planning even more awesome. Iām just starting out with UE4, so please excuse me if my questions are a naive or noobish.
Iām looking for ways for pawns to be moved around by elements of the terrain. I know this is probably not exactly what you had in mind for the toolkit and some work will be required to make it happen. Itās important for me that the player doesnāt have a static world when they play, but has something thatās alive and evolving in front of them. Itāll be another challenge to get the AI working with this obviously but Iāll try to deal with that later. Is there a way to move tiles within the grid, or would it be easier to create any moving terrain as actors and then create a blueprint to move them + any pawns on the same tile to simulate the same effect?
If a simple example helps envisage what Iām talking about: Imagine a shoot out at an airport where some pawns are on a moving walkway and others are still (or with a multi-level grid you might do the same thing with an elevator). Would it be possible to move the actual tiles on the walkway along without causing damage to the grid arrays, or should it be done by just moving the pawns?
Hi kevdotward, I guess it takes a while to read through this thread at this point Iām glad you like the toolkit and Iāll do my best to answer your questions.
As you seem to understand the toolkit is all about the arrays. For the most part the toolkit doesnāt care about where the transforms of actors might be, be they tiles or units. The important part is to make sure the underlying arrays hold the correct information about edge costs and pawns at the appropriate tile indexes.
To answer your question I will assume you are moving the terrain in a turn based manner. That is something like a unit pulling a switch to move a platform, which then moves and stops before the next unitās turn. If it is moving in real time while the units move in turns it quickly gets quite crazy.
So to get back to arrays, moving a platform with a unit on it to another location would look like this for the arrays: the edge costs of the starting index of the platform are changed to edge costs matching the new terrain which is left after the platform is moved (say 0 for all edges if the platform was hovering over an abyss). Then the pawn array and pawn actor arrays at this index are set to empty. Then the edges on the end index of the platform are set to the same values as what the start index had before it was altered (probably 1 for all edges). Lastly the pawn actor array at the end index is set to the actor who was moved and the pawn array at this index is set to the faction of this unit.
To the underlying toolkit logic this would all be well and good, but you wouldnāt see anything change on screen. You can display this visually in any way you would like (this flexibility is one of the reason I made the grid logic independent of the actual location of actors), using matinee, lerping the platform and actor to the new location or any number of other such solutions.
To sum up: change the arrays at the appropriate locations to values reflecting the end state and move the actors however you like. Hope that helps
Thanks . That all makes sense, thank you for replying so quickly as you always do.
Your assumption that the platform movement would be turn based is correct, I canāt really imagine how a real time implementation would work. Iām looking to implement an initiative system something like your discussion with and Hinato in post 236 of this thread, so I should be able to use counter increments to schedule regular movements like escalators or trains or whatever moving across the grid.
The thread did take some time to read through, yes. It seemed easier in some ways than the three hour YouTube video though (I didnāt manage it all!) It must have been a challenge to make that one. Between your videos and this thread itās great that so many of the questions I had have been answered already.
Having quite a bizzare spawning issue at the moment.
Im hardcoding the indexās for testing purposes, and even then my actors are spawning in the wrong locations but behaves aslong the character is where it SHOULD be.
Help?
The reason why my unit is spawning 35 indexes away from my base, is because my grid by X is 35, placing the unit next to the base, as seen in the first image
@anonymous_user_8bdefd7b: Let me know if you need any help with implementing your initiative system The blueprint video tutorial is pretty massive. One problem with my next update is that Iāve probably made changes to at least half the blueprints in the toolkit, which means I will have to riddle the tutorial with comment boxes or redo it, which takes an entire work day
@: That sight is a pretty common sight when Iām adding new stuff to the toolkit. It means that the location the actor is placed on in the world is different from the location corresponding to the index in which the pawn is stored in the Pawn and Pawn Actor arrays. First I need to ask if your grid manager is placed on location 0,0,0. If it is not you will have to add the location of the grid manager to any location you get from using the vector to index or index to vector functions. Secondly I would not use the Index To Vector on Hex Grid function, as it is unnecessary. It is only used when initially creating the vector field array, which means that after that you can just get the index from the vector field array, which is much more efficient. From what I can see youāre doing it should still be working, though, which might mean there is something wrong with the Spawn Unit functionā¦ Check if your grid manager is placed at 0,0,0 and then come back to me and I think I can figure it out.
No problem! It can be pretty confusing that the vector field array holds locations relative to the location of the grid manager instead of actual locations in the game. Iām considering changing this in a later update (though not the next one. Its big enough already )
Yeah fair enough, it was just really confusing when it looked like it worked but it didnt
I think making sure the grid manager is on 0 is fairly straight forward so yeah not a big needed thing needed soon but cant wait for your new update!
I assume projects with your current version will be able to upgrade without issue?
That depends. I have made many significant changes to the core functionality of the toolkit, so I suspect most people who have added a lot to the toolkit will need to spend some time integrating the new update. I will try to mark all changes I make as clearly as possible and discuss them in a video, but it will nonetheless be quite a bit of work if you want to integrate all the new stuff with your own heavily modified project.
Since I have made a fair bit of changes to the toolkit Iām not going to upgrade my toolkit at least for this project; since it already does what I need.
Anyway, I find it really nice that you can expand it functionality of your own
Yeah, if youāve made many changes it might be more trouble than it is worth to update the toolkit entirely. You can however look through my updates and add any new features you find particularly useful and/or easy to implement into your existing project.
Im changing and adding to some of the AI controller and I now am working on a Wandering AI.
How could i implement a random direction and moving to their with its move speed?
@: Random wandering AI is pretty easy to implement, though it might become more complicated depending on what you want to achieve. Iāll give you the simplest solution I can think of, and you can try refining it from there. For this method I use a new array that is not included in the current version on the marketplace, but it is easy enough to implement. In the Pathfinding function we want to add an array that holds the indexes to all tiles a unit can move to similar to the CanMoveToArray. The difference is that we want every index in the array to be an index the unit can move to, unlike in the current CanMoveToArray, which is the size of the grid and thus contains mostly tiles the unit cannot move to. Make a new array of Pathfinding structs and call it Index Can Move To Array and append the Open List to this array after each pathfinding step (in the Pathfinding Function) like so:
Make sure to clear this array at the beginning of a new pathfinding as you do not want it to carry over to subsequent pathfinding.
When this is done you can modify the ATBTT_AI_Controller to pick a random index from this array and run the regular AI movement code. Remember that you can only run this after you have done pathfinding for this unit. You will have to decide what conditions you want to be met for a unit to choose to wander instead of doing other behaviors. In my test project I simply linked pathfinding directly to the nodes posted below, causing all AI units to wander every time. It seemed to work well and I hope it will serve as a good starting point:
@Sulfurize: It should be possible, but I havenāt thought up a very good solution yet. I have a few ideas, but nothing I would immediately recommend. I would suggest you hit up Zeustiak on these forums who has been working on a Civilization-style world map using similar methods of storing map info in arrays to what Iām doing. I believe he has managed to do convincing world wrap. Take a look at his amazing Map Generator thread (recommended reading for anyone, really) here!
Hey there added your suggestion and implemented it, tested it just from pathfinding and found an interesting problem.
This only occurs sometimes, but a problem is a problem.
My turn order goes - Player - Enemy - Wandering
Now after the Enemy turn, the wandering unit searches for any pawns in its range, if not it wanders aimlessly.
However sometimes after the enemy has moved and the wandering turn begins, it switches back to the enemy turn and moves an enemy to the same place they had moved in their previous turn again and again in a loop?
I feel like you may need more info on this so let me know if you need any screens
Hi, I apologize because this has probably been asked before. How do I get the camera to zoom out further?. So far i have been using the default camera when I press play. As Iāve been building larger maps, I need to be able to see a wider area. I use Unreal 4.8 and that may have caused some confusion because the 1st YouTube video was using 4.7 or earlier.
Hi, I got around to watching the destructible mesh tutorial and got it to work which is super cool. However, it only works with the BP grid manager and falls through (as in sinks to the abyss) a custom map. How do I fix is so that the rubble stays?
Hmmm, thatās pretty strange. I feel like it might somehow be caused by how you have implemented custom factions, but itās very hard to be sure. Try to add some breaks to your code and try to determine exactly when it switches back to the enemy pawn. That way it might be easier to determine exactly what part of the blueprints is causing this.
Hi there. There is a variable for adjusting this, and I apologize that it is a bit hidden away. Open BP_Grid_Camera and change the āscroll roofā variable (Iāve changed the name to zoom roof in the coming update) to the amount of unreal units you want the camera to be able to scroll to.
Thatās probably just your collision settings. Make sure the ground in your custom map has collision enabled and configured correctly.
It doesnāt look this good for everything, though. These frames are comprised of multiple rigid edge meshes, which works great for flat levels, but variable height becomes a problem in some cases, though I have found ways to mitigate this in many situations. For organic terrain I have also made it possible to use edge decals, but these cannot overlap without doubling brightness in the overlapping corners of the frame, which means I had to make it more like a dotted line.
Iām glad you like the toolkit and Iāll do my best to answer your questions.
)
