(Above isn't actually the problem, to note)
There are a few things going on that are just due to neatness, but the main "problem" is just your control flow.
It starts with a loop if the laser is hitting anything. It won't be since it hasn't been set to a position yet, so the loop doesn't run. None of the other loops trigger either and are skipped, until you hold the shot key. The laser still won't hit anything that frame, and the animation loop starts. Once the animation loop starts the laser is positioned and actually should work more or less. However because you're in that loop until you stop shooting, you'll never get back to the logging loop, which is why you won't notice any collision. Similarly you won't actually check if the player still exists until you shop shooting. Lastly, in the no-shoot state you aren't really doing anything, which could potentially trip you up in the future if you do want something to happen when not shooting. Basically you just have to pay a bit more attention to how your flow works, but otherwise
it probably already functions correctly. Part of it is just that you misplaced your logging code and probably didn't test on a boss or something.
You can turn your logging code into its own task and then run it before your !Obj_IsDeleted(op_obj) loop, or you can plop it inside the shooting loop. The former would look like this:
// ...
ObjRender_SetScaleXYZ(playerShot,1,1,1);
task log(){
while(!Obj_IsDeleted(op_obj)){
if(ObjCol_IsIntersected(obj)) {
WriteLog("collision");
}
yield;
}
}
log();
while(!Obj_IsDeleted(op_obj)) {
// ...
(The following is just my advice and a full example of a player laser. If your stuff is fixed and you don't care about making it cleaner or easier to build on later, you can ignore this)
You seem to have three main states and cycle through them. Often I like to explicitly define my states, like you do a bit with animPhase, since it gives you more control over how your states transition.
Here's an example of how I would structure a player laser like yours. It should be immediately usable as long as you have a shot with ID 1 and have objPlayer defined.
https://gist.github.com/drakeirving/21d142646e9588a694bab30b5f968b31It looks pretty similar to the structure you have now, but the loops are controlled only by the states, which are switched around inside each one. Stuff to run between state switches are just put between the loops. Also note how in the cooldown state you can wait for it to finish and turn off, or press the shot button again to fire before the disappear animation ends.
Another tip would be considering changing ObjShot_SetDamage(obj,0) to ObjShot_SetIntersectionEnable(obj,false) like I do above. It totally disables collision instead of just changing the damage, which is relevant for example right now, when you're testing to see if it's hitting anything; it will react regardless of whether the laser is visibly out or not because the collision is always active.