[QUOTE=;273340]
I was trying to figure it out and got an engine crash, after reload I can’t reproduce it anymore O.o If it happens again I’ll make it a point to get a snapshot of all the data and send you the files.
[QUOTE=;273340]
I was trying to figure it out and got an engine crash, after reload I can’t reproduce it anymore O.o If it happens again I’ll make it a point to get a snapshot of all the data and send you the files.
Bugs that seem to happen at random are the worst I tried to replicate your exact scene and didn’t get the bug. It seems that for some reason the player unit does not detect the enemy unit when it is activated (otherwise there would have been a red decal beneath it), but I have no clue what would cause this.
Hi ,
The new version of the toolkit is just great.
Also the old version was very good, but after playing with the new version I have a strong feeling that my game is really going to be completed sooner or later.
I also recognized that average Autosave time has been drastically reduced (and that was a real INFERNO :o) , this probably because there are more components in the field and not just a bigger one.
I finally recommend to create a migration document for everyone (like me) that needs to paste some already done game implementations on the new toolkit version, it was really helpful for me.
Hi ,
I am interested in purchasing your toolkit, but I have a question. I want to setup a hex-based grid system with up to 6 units on it. Is your toolkit flexible enough to accommodate multiple units on one tile (similar to Civ 5). Not only that, but I want to be able to do positional damage to units on the tile based on the direction they are attacked from. So units in the back would take more damage if they were attacked from behind. Finally, I’d like to be able to have air units reside above ground units on the same tile. Will this be possible?
Thanks!
Great to hear that you like the new changes. Makes me feel all the time I spent shuffling things around was worth it. I’m a but confused about your recommendation for a migration document. You’re speaking in the present tense as if I have already written one? Are you thinking of the one I wrote a few posts up? Or is this something you want me to write? In that case what would need to be in it? Simply describing in what separate blueprints the various parts of Grid_Manager is now located?
Hi Spunkify, glad you’re interested. If you’re talking about multiple units per tile in the style of Civ V that’s really mechanically just one unit with the number of displayed units as a sort of a health bar. You would achieve this by creating a duplicate of one of the units and attaching a few more skeletal meshes. You would then set up the blueprint to play death animations and destroy some of them when the unit is damaged. Destroying units in the back when attacked from behind should be possible by getting the look at rotation of the attacking units towards the target and comparing it to the yaw of the target. Then you would make that output interact with the targets blueprint to decide what skeletal meshes are destroyed.
The easiest way to have multiple different kinds of units on the same tile would be to have a separate pawn array for aerial units. This requires you to add new blueprint nodes checking this array whenever you would normally check the regular pawn array.
Hi ,
Your first thought was right.
It was just an hint for the other “old” implementors because having a migration document was great for me.
I’ve given some more thought to how I’m going to structure future updates, and I feel like I’m pretty close to completing the base system at this point. That does not at all mean that I’m done adding features, just that I will be adding those features through example maps. This deviates a bit from my earlier plans where I intended to include support for large units, multilevel grids and touch controls before moving on to making example maps. There are a few reasons for this. Firstly, large units and multilevel grids are absent in many turn based strategy games, so including them by default will make the blueprints larger and more cluttered, while only benefitting some users. Also, both features will cause a very slight decrease in pathfinding performance, making it even harder to justify setting them as default options. Meanwhile, touch controls will require a rewriting of some parts of the toolkit, and I think it will be easier for users to have touch controls examplified in a separate map compared to having loads of branch statements checking whether the playes is using touch controls or not. I am not fully decided on this approach yet, however, so I would like input from any users reading this as to what they wpuld prefer. The future maps and features are currently planned as follows:
Mobile Game:
XCOM-like:
Dungeon Crawler:
4X Strategy:
@Wisdom-: Ok, good to hear. When I make a new video showcasing the new features transitioning should become even simpler.
Hi , if I want to add this to an existing project, is it enough that I copy the contents to another project. Do I need to edit the config files as well?
You need to copy both the content and config files. If you do not copy the config files you will not get the custom input and trace channels. You might be able to merge two config files by copying and pasting the text of both into one of them, if you have a lot of custom config stuff you do not want to set up again.
I don’t know much about config files. The only thing I’ve edited so far is the project name.
So I just copy everything and change the project name?
Yup. Just the content and config folders. Remember to backup your old stuff first.
Hey! Got my inventory and progression bars working in the old atbtt version (still doesn’t work in the new one)! Unfortunately I encountered an issue with walls (what worked okay in the old version) and don’t know if it’s a bug or if I’m just doing something wrong.
I want to create a rectangular building on a hexagonal grid (using thin walls). I dragged the BP_Grid_manager_Child_Hex into the viewport, disabled walkability and the default tile, added a transformed box as walkable floor and added a player character. Everything worked fine so far.
I now wanted to create a room using the wall tiles from the toolkit. I dragged in walls and scaled them to surround a 3x3 tile floor with 4 walls. Now the problem was that my character was just able to walk though them almost everywhere.
I then started to drag in walls that are roughly the size of 1 tile (from the square tiles) and put them next to each other. Here the character could also walk through the walls at a few spots… Namely the spots where the wall is not exactly placed on the edge of one of the hex tiles of the grid manager…
Is there any trick on how to do this?
@Hinato: When I first read your post I was skeptical if it was possible to make square rooms on hex grids and make it look good, so I tried it out myself and was surprised at how well it worked. I never intended for this in the toolkit, but it works with very little adjustment. If I understand you correctly you were trying to do something like this?
If I’m reading your post correctly I suspect that you may be mixing up the visual representation of the walls with how edge costs (walls) are stored in the various grid arrays. If you place a wall on a tile and resize it by increasing its scale the toolkit will still only register the tile you placed the wall as a wall. You have to either place a separate wall on each tile (as I have done in the screenshot above) or you can represent the wall as whatever mesh you want and place invisible walls on each tile. In the screenshot above I have used the regular wall tiles. The center wall two tiles behind the pawn won’t snap in the center of the hex by default, so I ignored Snap to Custom Grid and placed it appropriately.
Edit: Still, for this kind of stuff I think your best bet is to create your rooms with regular meshes and use invisible walls to modify the edge costs. The wall tiles for square grids are a pain to line up properly on hexagonal grids. Adjust the edge cost variables of the invisible walls to 0 for all directions you don’t want to be able to enter the tile from.
Thx! I created invisible hex walls and used them to block of the path through wall sections. This doesn’t seem to be completely optimal but it works pretty well!
Sometimes after playtesting I get an error shown in the message log. It says:
Accessed None ‘CallFunc_BreakHitResult_HitActor’ from node ForEachLoopWithBreak in bluepring BP_Grid_Manager
Most of the time this error is shown in the message log (2-15 times) after a playtest. Sometimes it isn’t shown at all. Didn’t manage to find a way to get the error 100% or 0% of the time. So I don’t know what it has influence on or why it appears.
Hi,
I have a question on how to write on the HUD.
Yesterday we have tried to use some “Draw Text” functions, but I was not able to find the context (one of the mandatory variables for Draw Text).
Instead, using the ugly “Print String” worked pretty well but obviuously can’t be used for production purposes.
Has somebody here created a nice HUD with the toolkit and can help me?
@wisdom-
Why not just use widgets? Do you want to create a pop-up text or something that is visible all the time?
I know that I can design on the HUD permanently, but I want an HUGE text that needs to be shown when a character hits another one (or if it miss the enemy) like “HIT!” or “MISS!”.
That text should disappear after a couple of seconds.
Okay so basically a text that is shown as soon as a specific event occures. I have something like that for a character entering the interaction radius for a chest but the condition should be easily changeable.
I first created a widget which consists only of a horizontal box and a text (deleted the canvas panel). In the blueprint I created 2 variables, 1 for the text (InteractText, text variable) and one for the actor on which the text location depends (InteractActor, actor variable). The content of the text (in the Designer tab) is bound to the text variable (InteractText). Then I created the following to set up text location and so on:
After that I used the following to show the text (here on event overlap). To hide it again just use ‘removefromparent’ as soon as it shall disapear. You can also just add it after a delay. In your case this should be added after the hit/miss event.
@hinato: You’ve created your own invisible walls, then? The default hex ones only block one direction and are probably not ideal to your uses, since you always want to block at least three directions in your case. If you’re worried about performance, UE4 can handle a huge amount of invisible actors without any performance hit, so it shouldn’t be an issue unless you’re using massive grids with tons of walls
@Wisdom: Hinato’s method looks good, but if you only need something very simple and basic you can do what I do with the “Player/Enemy turn” stuff in the HUD. I use a simple interface and change the text of the string to what is needed. To make it invisible after a few seconds you can just set visibility after a delay or even just change the text to an empty string if you want to be really lazy. HUD stuff is really not my forte, but I’ll be looking into it more in future updates.
I just copied every premade hex wall and set the meshes of the copies to hidden in game. Then I placed one of them at each way that I want to be impassable and afterwards put a wall mesh right over them. So I can walk on every field but can’t cross the directions in which the invisible walls are.
Right now I have a problem with getting my doors to work with the new version. Up until now I got ‘all actors of type’ ‘grid manager’, got position 0 and with that casted to the grid manager to get the ‘edge array’ and change it. Redoing this with the new grid manager instead of the old one or the grid manager hex child (since i’m using hex tiles) doesn’t work. Same when I get all actors of type game mode and cast to the grid manager/hex child via game mode. The cast to the grid manager/hex child just fails and I don’t know why Maybe you can help? Thx!