Dumb-founded by stubborn type
Blitz3D Forums/Blitz3D Programming/Dumb-founded by stubborn type
| ||
| Can anybody with a keen set of eyes tell me what's wrong with this code below. It's simply a Type which is being created and having variable values assigned to it. There is a random problem whereby the Type-variable fails or refuses to take the value assigned to it. It always comes up zero no matter if I manually tell it it equals a number or if it is given it from a simple previous calculation. However the next loop through the creation process it will assign the value correctly before choosing to fail at some other point again. I've tried debugging and looked at all the variables etc.. all values are exactly as they should be except this part of the Type. Can anybody tell me please if I am doing something against protocol here? I have been at this for 3 days before wittling it down to this one small part of the code - weep. ( as a side note - the very same piece of code which assigns the 'Y' values for the type always works without fail - it comes directly after this part!!! Sniff!) x1#=5.503 ; I've just assigned a value for simplicity sake x2#=16.5674 If doclones\cx1# And doclones\cx2# < 0 Select True Case doclones\cx1# > doclones\cx2# doclones\platx_distance# = X2# - X1# Case doclones\cx1# < doclones\cx2# doclones\platx_distance# = X1# - X2# default doclones\platx_distance# = 777 End Select EndIf if count =4 then Stop ; just for my debugging with this problem |
| ||
| If doclones\cx1# And doclones\cx2# < 0 Why are you doing this? Will doclones\cx1# be 1 |
| ||
None of the code in your Select/Case construct makes any sense. Your code would need to look something like this:
X% = Rand(1,5)
Select X
Case 1:
;code for X=1
Case 2:
;code for X=2
Case 3:
;code for X=3
Case 4:
;code for X=4
Case 5:
;code for X=5
End Select |
| ||
| Ah.. yes the X values could be 1 or 100.98657 0r -1000.5677 etc.. I do a check for all variations of the coords around '0' centre axis. Basically I'm getting the distance between two X coords - if with a previous check any coords are below zero ie. a minus coord then I just make it an absolute value before subtracting the smallest X number from the larger X number. |
| ||
| Thanks GFK - I'll try that now. |
| ||
| Nope - it's just the same GFK. All other moving platform Types are being processed normally but just this one, even though it's variables are correct and valid will not take the value being assigned to it....I'm at my wits end with this....Wahhaaa! Below - the first 'IF' cx1# and cx2# condition is true - it shows up in the debug and is perfectly valid. The Plat_x1# and 2 values are also there and perfectly valid. In this one case I should simply subtract one plat_x# value from the other but the assigned 'doclones\platx_distance#' Type continues to come up zero when it is being told it equals the answer of the previous equation - which is not Zero!! Yet it never fails to come up zero right after I've put a stop in to check it. I even put a 'default' at the end select structure to force it to take a value of 777 if somehow the cases were not true...it still comes up zero!!! How can this possibly be??? weep... ;----------------------------------- If doclones\cx1# and doclones\cx2# < 0 If doclones\cx1# > doclones\cx2# then xxx=1 If doclones\cx1# < doclones\cx2# then xxx=2 Select xxx Case 1 doclones\platx_distance# = plat_x2# - plat_x1# Case 2 doclones\platx_distance# = plat_x1# - plat_x2# End Select EndIf ;------------------------------- |
| ||
| Actually GFK, that Select looks fine. As you know, Select branches to whichever condition 'matches' the expression that's being 'Selected', so whereas in your example X matches 1, 2, 3, 4 or 5 in Hujiklo's code his Select will branch to whichever of the conditions in his Case statements (in order) evaluate to True. I've found it to be a very handy twist on ye olde Select, and I tip my hat to Mr Beaker for introducing me to it. But I'm sure you know all this. :o) Hujiklo: Given the fact your Select statement looks fine, and that occasionally your values don't get assigned at all, I personally think the only suspect out of the code you showed us is the line If doclones\cx1# And doclones\cx2# < 0 I'm a big fan of the use of parentheses for mathematical clarity, so to avoid the possibilty that it could be interpretted as If doclones\cx1# And (doclones\cx2# < 0) I would suggest the following If (doclones\cx1# And doclones\cx2#) < 0 (assuming I've interpretted your intent correctly). The only other thing to ensure based on what you've shown us is that, if you want to assign a value of some sort every time, to ensure that the type fields you're testing in the above If statement are both less than zero, of course. |
| ||
| Surely the statement should read if ( doclones\cx1 < 0 ) and ( doclones\cx2 < 0 ) If (doclones\cx1# And doclones\cx2#) < 0 Blitz will interperet the ( doclones\cx1 ) as either true or false and same for the other part of the expression. Any combination of true or false will always be >=0 so will never execute. I'm not 100% sure what you want the select statement to do .. I think you may have to clarify. Stevie. |
| ||
| 'Line of 7's' and 'Stevie G' THANKYOU!! You both got me thinking along the right lines in order to solve the problem. This solved the problem: If doclones\cx1# < 0 And doclones\cx2# < 0 Apparently it requires 2 <'s. It's the first time I've noticed this little nuance but I'll damn-well remember it from now on!! I'd better check the rest of my code now. Thank you one and all. |
| ||
| Stevie: It's a couple of days now since I wrote out that 'corrected' IF statement I suggested, and paint me green and call me Gumby if your explanation doesn't make me go 'DUH, nice one Line!'. Of course you're right. *slaps forehead* |
   |