LocalCurrentUnit -> getActorForwardVector -> convert_to_string -> printString
the PrintString exec connected after the addActorLocalRotation
same things happen, I can’t turn the pawn after initialisation and nothing is printed of course.
even when pressing “A” , nothing is displayed.
After I select an other Pawn, I can turn it as I want and the forward vector is correctly printed on screen.
it look like just after initialisation, the automatically selected first pawn doesn’t know his coordinate …
could it be a localisation table not beeing populated ?
@0thy: What happens if you just print “Hello World” instead of the name of the current unit when pressing A? Just to check that the player controller is receiving input at all.
Okay, as I expected. Try going to Editor Preferences -> Level Editor -> Play and setting Game gets Mouse Control to true. If that doesn’t work, try using this node in the HUD widget: Set Focus to Game Viewport | Unreal Engine 5.2 Documentation
@ how do you limit where the grid camera can move? I tried blocking it using blocking volumes but it didn’t work. I even set the capsule collision to BlockAll but it doesn’t do anything. Any help would be great!
In version 1.7 I limit the grid camera movment by checking its location as part of the nodes for panning in the Event Graph of BP_Grid_Camera. Here are the relevant nodes:
Blocking volumes are probably not working since I’m setting the location of the camera directly. If you want to use blocking volumes you would have to add your own system for panning.
By the way, your game looks awesome! I’ll be following its progress closely
@ thanks! I don’t have that “Check Outer Bounds” function so I just used my own pawn movement. It works now.
Also, I don’t know if this is already fixed in 1.7, but in 1.61 there’s a bug when spawning units on a Multilevel. Particularly when the tile is higher than the 1st level. I fixed it by removing the “Vector to Index 3D Naive” in the Unit_Parent blueprint’s construction script. I’m not sure if this will cause problems for me but it works for now.
And thanks for following my game. I’m glad you like it
@ Purchased yesterday, thank you. I have got some of my own characters in with only a few minor problems.
First the animations start to play on the second movement they will not animate on the first move of game.
And second the death animation loops, any ideas that may help ?
Found The problem, in the pawn child at the event move timeline… I changed the cast to anim BP to a pure and the animations work now on first move…Yehhh
Had a brain fart on the death too…it plays death anim until pawn is destroyed…will have to add a body on the ground after it dies…(headslap!!)
I love this set of blue prints… thanks for your hard work…Gotta go play more…
Hi , glad you figured it out own your own as I did nit get a notification of your comment and have been too busy during Easter to check the thread regularly. Good luck working with the toolkit!
Have an Issue, Like I said before in the forum, I recreated all the blueprints with them being a C++ class and all the variables so I can eventually rewrite in code, One issue I have at the moment is the move range tile (blue) seems to show up at index 0 when the player is near the last index (shown in picture Below), you can not click to move to it and a spline does not show, but it appears there, and only when the range goes beyond the last index of the grid it seems. I was just wondering if you could possibly point me in the right direction where I might of made a mistake in recreating the blueprints to make that happen?
Checking up on the forum here at Raptagon Studios. We are excited for the next updates with multiplayer and large unit functionality. Will multi-tile units also work with hex grids (our game is completely hex based)?
I’m sure it’s difficult to predict in the early stages, but do you have an estimate as to when you might have the next version finished?
@MatthewDouglas: Hi Matthew, it seems like the edges at the fringes of the grid are not being removed properly. During setup the toolkit loops through all tile indexes and connects each tile to its surrounding tiles by adding an edge between each index and the index at index+1, index+GridSizex, index +GridSizeX+1 etc. This works well for most tiles, but for the tiles at the fringes this connects them to nonexistent tiles (for the tiles at north and south) and the tiles at the other side of the grid (for the tiles at east and west). I fix this in the Create Walls on Grid Edges function, where I loop through all indexes and delete the inappropriate edges. My guess is that you have coded something wrong there, as this will cause pathfinding to continue searching beyond the grid when it hits the fringes of the grid and place TilesInMoveRange at index 0 for all nonexistent tile indexes. One way to debug this is to use the GetHitTileIndex function, get the value of the EdgeArray at the outputted index and printing it to the console to see if it the underlying tile has the correct number of edges.
@Mewbits: Hi Mewbits, that’s a question I’ve always been really bad at answering. My estimates are always way off when I do so. I am making great progress and have managed to mostly complete big units (only for square grids at the moment, but I’m working on it) and have networked multiplayer partly working already.
There is still a lot of work to do, however, and as I’m going through all of my blueprints and rewriting anything I feel can be improved this will still take a long time. Often the best way to make an estimate is to look at previous data. Looking at my changelog, the time between my last two major feature updates was almost 11 months. A lot of stuff happened between then and now, like me getting married and traveling a lot, which delayed me by a couple of months, but life being unpredictable is one of the reasones estimates are difficult to make.
I feel that this update should be a significantly quicker, but it might just be the planning fallacy doing its thing again. On paper the list of stuff I am adding is bigger rather than smaller than the last update, though my scripting skills have also improved since then. In other words, expect it to take some time. When I’m happy with it I could post my solution for large units if you are interested in implementing this earlier.
I frequently check in on your game’s progress, by the way. It is shaping up really well and I’m greatly looking forward to the day I get to play it
It’s helpful to know the average time between updates. I was hopeful it might be quicker than before because your first post says that the next planned update just includes Multi-tile units and Networked multiplayer. If your list is longer than last time, what else is on it, if you don’t mind my asking?
Also, thanks , we wouldn’t be nearly as far along without your awesome toolkit, video explanations, and your direct help. Hopefully soon we will have some more to show.
Glad it worked! Good luck on your further conversion! Might I ask what your motivation is for converting everything? I agree that it makes sense for the heaviest functions, but many things should not see much of a performance boost, especially after blueprint nativization was added. Is it merely preference or for practice?
It is mainly just multi-tile units and networked multiplayer and multi-tile units, but the devil is in the details. There is a reason I’ve waited so long to add these two. Multi-tile units is a lot more complex than one would think; especially when I want it working with all other features of the toolkit and it affects a multitude of different part of the toolkit.
How do you account for colliding with thin walls or height differences, for instance, or change all code for hovering and selecting tiles to account for the possibility of the center of a unit being between four tiles? How does the unit array update so that the game understands which tiles are occupied and what is the best way of displaying move indexes to the player for larger units? These are just some of the problems I’m facing, and though I’ve thought up solutions to most of them by now, implementation is tricky and time consuming.
Networked multiplayer affects all different parts of the toolkit to an even greater degree, and not having worked with this before it was a completely new side of the engine for me to learn. I’ve got the basics working by now, but it will take a lot of reading and experimentation to make sure it is bug free, cheat proof and complies with Unreal’s standards.
Speaking of which, I’m taking the opportunity to do a major refactoring, to have the names of variables, blueprints, functions etc. be more consistent and to comply with Unreal’s coding standards to a greater degree. At the same time I’m going through every blueprint I’ve made and using the knowledge I’ve aquired while working with Unreal over the last three years to make improvements and simplify wherever I see the possibility. This will undoubtedly also take time to get done the right way.
That is the basic rundown of why I expect the update to take some time, though hopefully still substantially less time than what it took to make the last one. Fingers crossed that I’m not tricked by the planning fallacy again.
I am very interested in seeing this solution when it is completed. I, too, am using your system for my own game and a major part of it is reliant on unit size.
