@MatthewDouglas: Hello Matthew. I’ve looked through the blueprints and tried to figure out what might be wrong, but I’m not entirely sure. If you want to send me a copy I can look through the code and try to find where there is a discrepancy. Very odd that the default tile shows when hex grid is set to true but not otherwise. Those should not be related. The size of the collision plane is done in a macro with lots of regular math nodes (I plan to change this to a math expression node), so imagine it is easy to miss something when converting. Try looking through it carefully again.
@polsds: Hi Stefan. What I do if I resize the grid is to mark all the units and tiles in the Scene outliner and move them away and back again. That should cause all their construction scripts to update the actor’s component locations and variables appropriately. Is this sufficient for what you are doing or are you resizing the grid manager constantly for some reason and need a more automated fix? If so you could always have the grid manager construction script loop through all actors of the Unit and Tile classes and perform the same operations on them as are normally done in these blueprints themselves.
No problem! That is the best solution in most cases anyway. I could add something like what I mentioned to the construction script of the grid manager, but I don’t think it would be worth the slight added time when compiling the grid manager compared to how useful it would be.
Super hyped for the next update, Network Multiplayer and Multi-cell units are the features I was most hoping for! Both are integral to my game concept and I was afraid they might be beyond my capabilities to implement. (I’m a 3D artist but have only basic familiarity with coding). If there is any way to assist or support your work on the next update I would love to help.
Regarding flying units: User Southwind’s solution sounds pretty simple and effective. I wonder if it is also simple to set a kind of unit and attack types, such that ‘Flying’ units can only be hit by ‘Ranged’ attacks.
Hey there! I could use a little help with adding an option to the Find Tiles in Range function of the Grid Manager
As I understand it while checking what pawn is in attack range the function looks at the Current Move and Range variables of the unit. I want to add an option to the function that allows only showing pawns in Range (without considering Current Move). I have difficulties understanding all the details of the function so any tips on where/how to implement an option like that would be amazing!
I am using terrain and therefore - decals. We have different decals for different tiles the game marker in hovering on, depending on cost and range. So my question is, how do I set “Hover marker default material” dynamicly in blueprints? The programmer before me used meshes (instead of decals) and he did it this way:
Happy to hear that! These features are indeed pretty hard to implement, which is one of the reasons I’ve waited so long before attempting to code them. Be warned that it will be quite some time until I’ve completed them, though. Adding features always takes more time than I expect, and though big units are mostly done at this point and I’ve got many of the basic features working with multiplayer there is still a long road ahead. Thanks for offering your assistance! One thing I’ve wanted to add, but haven’t been able to because I’m not experienced at animation is a basic ladder-climbing animation. Ladders and the like is something I think I could code quite easily, but it would look really weird without an animation. I have tired to look for creative commons climbing animations, but have not found anything. Is this something you know how to do?
As for flying units, as mentioned there are many ways to implement this. The one u/Southwind suggested might work in some games, but there are many hidden complexities such as flying over a wall seperating two tiles so that the tiles do not share an edge. I will wait until after the next update until I experiment with something like this.
Hello! Find TIles in Range does not generally have anything to do with the move range. If you run the Find Tiles In Range function on its own all it does is to find tiles in sight range of an index out to the max range defined in the function’s input. The reason you might be confused is that at the start of a unit’s turn both the Pathfinding and FindTilesInRange functions are run in sequence.
Here is a very basic setup for switching the material of the hover marker when pressing ‘1’:
I ran into a problem when I tried to use terrain with the grid manager. First of all, the terrain is huge. I placed the grid manager underneath, with height of about 1000 units, which is sufficien to cover all my “mountains”. The grid size is 200 x 400. I am using tracing for the heightmap. When I place the main player high up on the terrain map, the movement marker does not show, or more like, it shows in red (which means the tiles next to my unit are unreachable or unwalkable).The spline does not spawn, as well. If, however, I place my main player on a lower position, start the game and gradually reach the same high point, the spline spawns correctly, and the whole system works as it should.
Upon further investigation, I noticed that it has to do with the placement index of the player pawn. The index, aparently, goes out of bonds. As I said, the grid size is 200 x 400 = 80 000 tiles, i.e. 80 000 indexes. Then why does the placement index in the second image goes to that large number?
@polsds: are your heightmaps set to multilevel or from tracing? If it is multilevel the grid manager will use traces at the start of the game to determine whether there are multiple levels. If it finds that there are two levels of meshes blocking PathTrace that are a sufficiently large distance apart it will add a new level, effectively doubling the size of the grid (160000 tiles in your case). If you have selected mutlilayer I’m guessing that the trace hits the landscape and then continues downwards and finds the collision plane of the grid manager (disabling “collision plane walkable” prevents this). Check if this is your problem and let me know. If this does not fix it I’ll consider other possibilities, though I do not immediately see any.
You are pushing the size of the grid quite a bit further than what I have really tested for, but I don’t think that is it. I’ve tried to recreate your grid/terrain and I’m not seeing the same problem. The toolkit does hit the loop limit at begin play, however. I’ll need to look into the specific issues for very large grids. But like I said, I’m not seeing your problem. Are you using the latest version of the toolkit?
That explains it. This is a bug that was fixed in 1.7. The issue lies in the construction script of Unit_Parent. Here is what you need to change it to:
Hi
I have an issue on a pawn rotation implementation during the initialisation.
after I select an other pawn, everything work fine, even with the first pawn.
any idea is welcome…
Hmm, I don’t know why this should not work. Maybe the game is just not in focus so no input is registering? If you have not already, try clicking anywhere in the viewport after playing in editor and before pressing left or right. If this does not work, try adding a Print String node anywhere in your node structure to see if the events fire at all. If they do, try printing the name of the current unit using PrintString to see if it is empty. If it still does not work, report back to me and I’ll see if I can figure it out.
Oh, sorry. The screenshot is from the WIP 1.8 update. One of the things I’ve done as part of refactoring for the next update is to change several variable names so that everything follows a consistent naming convension. GridLocations is the variable with the most different name compared to previous versions. It is the same as the old Vector Field Array, so use that array instead.
