Right, I got that much. I’m wondering in a multi-level map, should it be returning a result like I’m seeing? You mentioned that 4,010 would actually be 0,004,010. When it sets up the “levels”, does it do it in reverse order? e.g. 0 is the uppermost level and going down from there?
I just did a little more testing, and I noticed something a little strange. It seems to do the level switching when targeting the robbers, not the police officers. It’s only been a few exchanges, but so far after about 5-6 attempts on each of those 4 characters, the robbers when shooting, can shoot more or less normally as I expect, but the police get the switching levels when trying to fire. The difference being that the robbers have “accessories” as far as I can recall I’ve set everything to no collision (their masks). Verifying this yes, both the hair and mask meshes are set to no collision so they shouldn’t interfere with anything. This may instead be related to the robbers starting inside the building, but the issue persists if I walk them out of the building. I’m going to rebuild with them placed outside the building and see if i get the same issue or not.
Using some slow deliberate presses (Rather than quick taps, I observe the following), and using the exact same weapon ability (pistol snap shot):
Robber attacking Police officer on the map shown in the video:
-
First press, the hover activates, but the index clicked does NOT update. I’m not exactly sure why here. It should, as you can see in the above code that hover gets run if the clicked indexes don’t match. Which tells me the first click is actually running hover in another place.
-
The next long press sets the clicked index, but that’s it (it probably reruns hover)
-
The third long press notes that the clicked index matches and fires.
This is pretty close to what I should see, except for that first click. I need to investigate that.
Police Attacking either robber:
-
First long press, nothing seems to happen at all.
-
next long press it seems to hover
-
The next long press nothing
-
the next long press it sets the index
-
The next long press it returns the wrong index and the camera jumps a little
-
Wrong index again and the camera jumps a little bit more
-
It seems to match the index and fires.
I’m attaching a screenshot of my component list for my robbers so you can see. There are only 2 additional meshes, and I’ve verified that everything involved is set no collision. The skeletal mesh, the weapon, the hair, the mask, the armor. Otherwise there is no inherent difference between the police officers and the robbers in this case.
Now the police shooting do not always produce the same sequence. Sometimes it flickers back and forth between indexes, so 7 isn’t always typical, it can fire after 4-5 taps sometimes. But it is behaving differently.
Too many mysteries with what’s going on here.
I’m uploading another video so you can see what’s going on here, but over a few exchanges, the robbers never once had an index result of x,xxx returned when firing at the police. The police had it returned every time at least once during the tap sequence. The alien robber and the police both have the same ability set.
I just got an idea to drop a police officer in there but set to the robber faction to see how that works.
Edit: Okay this is really bizarre. I made a female cop a member of the robber faction and she has no issue firing at the police officers the same way the other robbers do. The police DO have an issue targeting her and have the same index issue. Is there any way at all that the faction could play any role in this at all? Robber female cop firing on police female cop 3 taps done, reverse and it’s multitap index issue. I’m going to make an alien robber a police faction and see what happens there.
Edit2: Okay this provides more odd results. Made an alien robber a police faction unit. This unit has issues targeting robbers, and robbers have issues targeting it. That’s at least somewhat consistent. I guess. it has issues targeting the Robber Faction Female cop unit.
Edit3: I’ve just discovered the “use mouse as touch” option in the project settings and this returns the same issue as I’m seeing on the phone. but in PIE, this will hopefully make debugging and tracking down this issue easier.
Edit4: With a little luck, I’ve started to find part of the issue, in BP_Abilitybase when Find Close Valid Overlapping Grid Index is run, it’s returning false a lot of times. I’ve noticed this using the mouse as touch when I’m touching the red square around the unit, but not within the target icon that would pop up on hover. The mouse is clearly over the red square, but I added a print when that returns false, and it’s coming up constantly. As I move closer to the center of the square, it returns true. I still can’t explain why the robbers don’t seem to generate that error targeting the police like the police do targeting them, but that is one of the issues causing the attack to fail. I’m attaching an image, print screen doesn’t capture the cursor, but I drew where I was clicking, You can see the prints on the left, that “can’t find overlapping grid” prints when the above mentioned function returns false.
I may have fixed the weird x,xxx style index being returned. I’m not sure how or why but in bp_abilitybase right before “switch on eheight” there was a branch checking for touch.I skipped that and now run straight to “switch on eheight” and now the index being returned always seems correct. So that problem may be solved. The other function return false isn’t. If that function returns true it’s 2 taps to fire which is exactly what i want, now i need to figure out why that’s failing. Sometimes even if I click right on the center of the unit’s body it’s return fail over and over.
I know my posts can sometimes get long with lots of edits and a little rambling, but I hope these posts can help people understand how I debug things and look at them and might give them an avenue to solving their own issues.
Another touch related bug:
On BP_Ability you have it set to check if “released” and if it has been released, you just do nothing. But on touch, you want the person to move their finger before activating the ability. This goes back to BP_AbilityBase where there was that question about whether or not it should be hooked up after “check hovered location” for touch. I mentioned that I couldn’t seem to get it to fire without that hooked up. The reason is that BP_ability won’t work if it’s been released and the “pressed” path in abilitybase never went anywhere. So if that remains unhooked, you need to change BP_ ability per the image to account for if touch is being used. It’s just an additional bool condition and changing that branch from false to true. Then it’ll work regardless of your input method.
So currently I have the clicks working entirely as intended. The only outstanding issues is “Find Close Valid Overlapping Grid Index” returning false sometimes. It returns false a lot…like…50% of the time sometimes. I’m not sure why. There is only one way for it to return false. It’s on this “found height level” for some reason it must be returning an invalid one. Which may come back to you, because I’m not entirely sure on the intricacies of how that works. I’ll experiment, but if you can think of a reason why that might be frequently giving me a bad value that might be helpful.
A quick print right before the first branch in the attach image shows that the “Found height level” is being returned as -1 sometimes… sometimes 0 as it should be. and a print of the float above solves that issues. For some reason, the height level is being calculated as 0 - 0.5 which gives us -0.5 which rounds to 0, but sometimes the float is -0.500001 which rounds to -1 causing it to fail.
This seems to be a bug with the “corrected Z vector” node as it sometimes outputs it as -0.00001, I’m attaching a log of the full math operation. I would guess, that the correct Z vector does not have to be correct to so many decimal places, and the slight inconsistency of that function is causing the issue. All of the units and tiles in the game are set to the same Z value. I’ve temporarily solved this by truncating the value. I’m not sure if any decimal precision is required at all, I’ll wait for your feedback on that.
With this fix, it looks like ability touch controls more or less work as intended, however, there are still camera jumping issues. Sometimes while using an ability just clicking on a tile will cause the camera to jump I’ve got no idea how that is even being called in there, so I’m hoping you might have some suggestions there.
Just took a built version for a test drive and it’s about 90% better. There were still a couple of times it seemed to take more than two taps, but I think that was because the camera jumped just a tiny amount. I think it’s sometimes reading taps as pans…or something. I might accept that on the phone as the human finger isn’t very precise, but it jumped around in pie too, using the mouse.
One thing I do notice is that clicking on any of the gun abilities makes the camera jump. Like just to activate them. The camera jumps to a specific location, but i can’t see any code in the activate section of bp_ability or abilitybase that would set the camera position. All my gun abilities are duplicates of BP_laser with the variables effects, etc changed. if I click sprint, that’s fine, it overlays the squares, but if i click snapshot or aimed shot the camera jumps to a specific position (different for each ability). The same thing happens when clicking the shoot ability for the uzi. Is there some code somewhere related to BP_laser that resets the camera position when you click it?
All aboard the train to strangeville!
I stuck a print statement in the pan function on the gridcamera to print the new location it sets the camera too. First thing I noticed? When I click an ability in the ability box, somehow, pan get’s called because it prints a location when the camera snaps to a slightly new location. I’m going to have to dig through this, but I don’t recall seeing anything wired up like that. Also under the current set up, if I select any ability (including sprint) and attempt to pan the display using the mouse, it jumps 100% of the time. Just touch the screen and start to pan and the camera always jumps once before panning. After it jumps once, it pans normally. So current issues:
-
why is pan being called when simply clicking on an ability? - SOLVED: Any click on an ability to activate it is registering in the touch controls as “moved”. Very interesting. Greater mystery! Clicking ANYTHING on the UI makes input touch - moved fire. Clicking portraits in the bar at the top or clicking the arrows i added for the height levels also makes it go.
-
Why is the location jumping when you start to pan the first time, I’m guessing something in that math function that is wired up for defining the pan is off.
Getting closer though!
Okay, so for some reason, when you click anything on the UMG, moved then released fires. I have no idea why either of those are firing.
Ah-ha! I need to override On touch move and on touch end (already did start) in the UI to prevent those from firing.
I have a line of attack. When you first start to pan the camera, the touch points are the same by default. in the event graph the if they are the same from the beginning, there is no opportunity to set the camera location from the start. So the first time it goes to pan the camera location is still set to the old location. And the reason for that is because the reset for the pan never runs. When you stop moving, the moving execution path stops, and the branch which checks if you have a finger pressed, never gets called 1 time after you stop moving. I put in a print statement, and it never runs. So it needs to be run another way.
Success! I just had to run the cast to the grid camera and call to “touch controls” as part of “input touch - released” When it calls it under released, since there is no finger touching the phone that part of the touch controls can run. And no more camera jumping! Time for a shipping build.
Touch controls appear to be in working order. Main points:
- the bTouch needs be run throughout the execution and passed to all down stream functions and blueprints.
- You need to rewire some branches as I’ve pointed out in a few screen shots
- you need to override all the touch events and return “handled” in your UI blueprint
- in BP_abilitybase after check hovered location you do NOT need to connect that up to check ongoing actions if you rewire the released/touch check per my screenshot
- Tick can be disabled by switching on string and getting the platform. If a mobile platform is returned, then just do nothing, otherwise leave it hooked up. This leaves your functionality for a multiplatform build.
- You need to truncate that one float
There is one remaining issue in that once in a while on the second tap instead of firing it disables the hover…but then the next tap fires. Bit strange. I’m going to debug that later. I’ve accomplished a lot today. The only real outstanding issue i guess I have right now is that mesh I sent you which is causing the strange results for multilevel stuff.
