Pretty basic stuff here… I made sure “negatives less than zero” works in general but in this blueprint, it does not. Has anyone else run into this? I cannot clamp in this situation because 0 is a valid space. -6 is not, which should cause this check to be TRUE, not FALSE.
Thanks!
TooLoopyToBeBored
I see 3 conditions. What’s the first OR conditional check?
It is not relevant in this situation as I ruled the top condition out already. The top condition works when its condition is met. You can see from the watches that the “<” watch is showing False during debug. I am only watching the middle OR.
I do appreciate your feedback and support. A further screenshot is not needed. I only have one instance of this blueprint running and the context is correct. The screenshot shows the problem. I may be a new poster but I am a successful developer.
An Int of -6 is being evaluated if it is less than Zero, and it is coming up False. Everything else can be stripped away and the same issue persists. No wire flow because the program is paused as I step through the code. Hint: The big white arrow after the Loop condition is checked indicating code is paused, showing that this condition that is labeled as False. This code is run successfully many times before it gets to this point, only when a negative value is attempted is when it fails.
Additional thoughts welcome.
It might be an optimization going on, if the first pin for the OR node is already true, it won’t even evaluate the other two pins and therefore their value might be old ones. My hint is to change the pin’s order putting the first by last and see if it changes behavior.
Blueprint always evaluate all parameters unless if there has been an update I’m not aware of. I have seen watches displaying the wrong result before though so stepping through the nodes should reveal the truth.
Thanks for the responses. Great input.
@NilsonLima I played with Pin order to no affect, also the item that is currently set to WATCH is the first True in this loop iteration.
@GarnerP57 Watch is coming back as correct and truthful. Other parts that lean on this variable are correct in their results at run-time. If I don’t break into the code, it goes into an infinite loop because I am adding -6 to the same variable on each iteration of the loop so the condition will lever get hit to leave the loop. I suppose I can also add a clamp mechanic on the backside of my loop logic. I can add screenshot later of the rest of the loop, it isn’t much bigger than what I already uploaded.
This logic and loop is useless without the three conditions being applied. I may also try to break the condition logic out to separate area and set the results to a BOOL then use the BOOL in the For Loop. Quite a bit more messy but survivable.
I am still open for further input.
Thanks!
You may be well aware, but I have to put this out there anyway.
When watching variables/nodes comparisons will always default to 0/False. You have to run it for the comparison to be…ran.
Yup … Flow path has to reach the node in order to be executed/evaluated.
Ok, fair reasoning… No timers used here. Thank you for the feedback. The nature of the infinite loop prevents me from showing live wires because I can only step through the code, unless I am missing something in my debugger. I have **MyPlayerController **selected as my context when in debug mode. Without being able to show the live wires, you asked for it…
**BoardState **= Array of Int, 0 - 63. Represents an 8x8 grid that is the game tiles. If a piece occupies a tiles, it has a value in the array.
Example: **BoardState **= (0,4,8) puts pieces on Row1Column1, R1C3, and R2C1.
**Changer **= Value represents the direction I am looking for movement clearance. Screenshots example checks in front, behind, left, and right. If I wanted to check diagonally in all four directions, it would be four sequences of **Check for Clear Space **using: 7,9,-7,-9 as Changers.
**LastClickIndex **= Single Int. Indicates position of the piece on the board I intend to move
**CheckPosition **= Single Int. Is the array position on the board I am interested in evaluating.
**PossibleMoves **= Array of all moves collected through the sequences for my selected piece to move. I later loop through PossibleMoves to light up my board with the available moves, and use the same array to validate my piece is moving to a valid location.
My three conditions. If any of these are met, bail out of the loop, otherwise, continue adding the **Changer **to **CheckPosition **and try again…
**CheckPosition found in Boardstate array **Top one checks to see if another piece occupies the position I am interested in (CheckPosition)
**CheckPosition < 0 **(the one failing here) Am I beyond boardstate negatively
**CheckPosition > 63 **(also tested from the other side of the board and infinite loop counting up too) Am I beyond the boardstate positively
^^ Additional edge cases will be added if I can get things working
I know I am re-inventing the wheel here but I like a good challenge.
My macro loop checks for clear space for my selected piece to move. With this, I can change how I evaluate available moves based on the type of piece being moved without having to write a tonne of code. This way, I can easily check in front, behind, left, right, diagonally or other locations or directions all by changing number of sequences and the direction (mathematically) using the Changer.
In my case, the piece I am moving is already on the first row and fourth sequence so it has already looked forward, left, right, and now is looking backwards, given the -8 for the sequence being debugged. The piece’s **LastClickIndex **is 2. When I subtract 8 from 2, I get -6 which should indicate as invalid since it is off the board (0 - 63). Since this issue is occurring, it never evaluates to be “off the board” so it goes into infinite loop.
I know I also will have additional logic for other edge cases like wrapping from C8 back to C1, and same with Rows. I was in the beginning stages of this adventure and got hung up on this.
I think I covered the gist of it. I hope I explained things well and am looking forward to feedback.
Try a function instead of macro.
Macro graphs are copy/paste into into your blueprints, something unexpected might come from that.
Heh, I actually did that expecting different results, same issue.
Then report a bug, this could be a bug in Blueprints’ virtual machine runtime.
You ever read something and feel like you’re missing critical information? Because I do. But I’ll try anyways.
While loops will loop while true.
If you step into your int -1 “check for clear space” macro, event goes like this:
Wouldn’t this be solved by turning around the lessThan and greaterThan bools? What seems wrong to me though is you said you already have appropriate tiles lighting up for possible moves so my post might be totally worthless.
Fixed it with new logic. Now to add further edge cases…
