Okay, I’ll try making a new project when I get a chance and test it with the default stuff and see what happens. It could be the meshes themselves causing the issue or something else.
Something I’ll test when I get a chance to make a blank project. I think the controls are pretty close with those two changes, if you have any quick thoughts on what might differentiate moving and shooting, I can try and dig into that specific spot, I think it’s the server interact that handles passing the input into BP_ability right? And that’s where they all get it?
Unfortunately I’ve found a new issue last night, and it’s a doozy. I’m not sure if it’s related to your toolkit or not.
As you know I’d built my app for android, several times in fact and it works fine, but I wanted to add a menu. The first issue i had was that I had a couple levels (from content packs) with the same name in multiple folders, so I needed to give my level a unique name. I changed the name from demonstration->heistdemonstration and then created a simple menu level called “menu”, updated all the references, changed my settings to make sure to package the two levels and built it. When I loaded it on android it was complaining that it couldn’t find the level “demonstration” in the command line. it would ask if I wanted to load the default level, and on doing so would load the menu which would work fine and the game could start and everything worked perfectly except that pop-up. I spent hours digging through the settings make sure there was no reference to the old name anywhere, and there isn’t. Finally I gave up, and changed the name of the other levels, and then I renamed the new level back to demonstration and built that. However, when I run that on android, it completely ignores the project settings which say to load menu as the default map and it loads directly in to the game level. I’ve never seen anything like this and have spent about 3 hours completely tearing the settings apart. It’s like the project is somehow hardcoded to load that level first no matter what, but “menu” is set in the .ini settings and in the project editor as the default map, and it’s included in the build. Is there any way this could be remotely related to your toolkit itself? I can’t imagine how, but I just wanted to make sure there isn’t some setting in the gamemode or something that would try to override things.
I finally solved this, leaving this here in case anyone else has a similar problem. I was building the game as a development build. As a shipping build this works as intended. I have previously built windows games as development builds and not run into this problem.
I finally got a chance to test the controls on a variety of android phones today here are my observations:
Only basically every phone (including my own) the first character to move has some issues. I’m not sure why. But it needs some additional tapping and fussing. After that, any other characters move on a single touch.
There are some slightly camera/hover issues with the weapon abilities based on laser. they work, and they’re functional, but if you click the weapon ability and click the target, it highlights for a moment but then the target symbol jumps to another spot on the map, however tapping the target once (followed by a target symbol jump) and tapping the same target again does allow the unit to fire. As well when sliding the camera around, it sometimes jumps a bit back to where it is, this can be solved by rotating
So my verdict is: the controls are functional, but glitchy. They’re at least sufficient with the changes I made above (ticking the bool and connecting that one node) to be functional for testing purposes. I played out a whole game using them and it was fine, with the mildest of frustration. So I’m going to focus on other aspects of the game (like my roof snap issue), if you expect that you may get to the controls in a couple weeks or so. As you are much more familiar with all the guts of this I’ll wait for your more detailed checking and feedback on it before I get to it. If I managed to clear everything else that I need to do before you get to it, I’ll try to look at it more in detail.
Side note on the roof issue: even removing the ladder so that there is no path to the lower levels, still has the cursor unable to snap to those roof tiles. I also note that for your test, you’re using BSP aren’t you? and not static meshes? the first layer is also BSP or is that from the grid itself?
I finally got a clean project made, I can’t replicate it there either. At least not on the first pass. That’s very strange…
I took the jungle map, and just extended the grid a little, and migrated a piece of floor over from the other project, put 3 on top of each other with ladders, and it works okay. Something else must be causing the issue. I assume the grid that is used on the jungle map is stock? it hasn’t been modified in any way? To my recollection I haven’t modified anything on the grid beyond the settings I showed you. So no changing code or anything like that. Only camera stuff to add pitch, and allow me to use the middle mouse button to rotate and pitch.
I’ve rechecked all meshes involved and can’t find any unusual collision settings or anything else. Later I’ll try reapplying a grid to a fresh copy of this map and see what happens. Not a huge deal, but I’d like to make sure I have complete coverage
So, I just had a test with the default project. I loaded this demo map (it’s included with the asset pack), and after dropped in an advanced grid, setting it multilevel and changing the height to 2000, I am noticing exactly the same issue as before. So it isn’t any change I made. It’s some kind of conflict between the grid system and these assets. I know you’re busy, but if you have time later let me know and I’ll share some pieces with you so you can check it if you want.
Attached a screenshot. Completely fresh project, just imported the map, dragged the grid in, height set to 2000 set to multilevel, appropriate boxes checked (Same as jungle) then dragged a unit up to the top. Then, just for testing, I dragged a copy of all 3 floors over to the right, to make sure no other meshes were involved, and as you can see, even though those lower levels can’t even be navigated, at all, the cursor is snapped down.
I do notice that with some mad clicking, about every 20 clicks or so, I can somehow get the click to register on the upper floor and he moves to a tile there. But there is no way for me to actually get the cursor to actually hover over one of those upper tiles, so it confirms the tiles are working, and this is a cursor/hover/snapping issue. Why it doesn’t show up on your map, or the jungle map, I’m not sure.
Breakthrough: This might have something to do with the thickness of those roof meshes. They’re incredibly thick. I just deleted the upper one, and dragged up a copy of the second floor to the height of 600, and voila I can path to it. More experimenting to be done. it looks like the mesh is around 100 units thick. I’m not really sure why that should be important, but maybe that tells you something. I tried making a new collision mesh on it that was a thin slab rather than a big thick one, but that didn’t help.
A little more testing: I first changed the mesh to be thickness 7 (same as the below floor) but at height 85 so that it lined up with the top of the actual mesh. It did not work when there was another floor below.
I then changed it to be height 0 on the staticmesh itself so that the collision mesh was hidden in the bottom of the mesh, and voila, I can’t see the grid, but my guy can run around (waist deep) in that mesh. There is is some kind of issue with the following scenario:
0 (7 unit thick collision)
300 (7 unit thick collision)
600 (100 unit thick collision)
that top collision is now up around 700 actually. So when I was putting it up 725, that was actually 825. So collision mesh tops were at 0, 300, 700.
Further testing: I made a copy of the red floor below, and on that copy changed the collision mesh to be 100 thick, even with that, the unit can path to it just fine…so it’s not even an issue of the collision? It’s almost like it’s something inherent to that mesh itself. Which… seems very strange. I even removed the collision on it and made a custom one, so not an issue with some premade collision.
If you give me an email address, I’ll give you this static mesh, maybe you can try it out and see if it behaves strangely for you as well.
Just started working on a sniper kill cam, this is… unfortunately not an easy endeavor due to the ways that animation and unit handling are setup. Because they’re separated, you need to interrupt the normal process in more than one place. The shoot function calls a take damage, which kills the unit and kicks off the death action, but the damage is still passed through another queue as part of the “hurt” option, I guess. Because completely disconnecting take damage in the shoot function still results in the character running the dying animation when they are hit for enough damage. if I zoom fast enough, it’s not that noticeable, but it seems like doing it properly would involve quite an in-depth rewiring of multiple parts. It’s not a bad idea to separate those, but it makes certain kinds of things, like x-com style camera work, really difficult because you need much more precise control over the target’s dying animation in these cases. I’ve got the sniper done, but I think I might have to alter my plans for other kinds of kill cams. This is just more of a head’s up note for anyone wanting to do something similar, they should know what they’re getting in to 