This ought to be my slowest reply ever. Anyway, I should be a bit more rigid with terminology. But, I do understand how it works... you see, when you type in some formula using '=', a single variable on the left-hand-side, and some equation on the right-hand side not involving this variable, the computer automatically evaluates and assigns the found value to the variable. Here's the main problem. With 't', I mean time, as in the very frame the game is at. So basically, I do not want my variable to remain static, but depend in value upon the frame, I want to put a whole continuous thing into said box. A good example program that actually does that is Mathematica, there's several others that can do it too. But as you said, there's no delayed evaluation like in some other languages here apparently. (As an example of how it could work; instead of putting the evaluated formula at the time 't0' into said box the moment the variable is assigned (which is when we call our function), the whole formula we put into the function call will be put in a variable box as a 'string'. Then said string is to be 'converted' back into a formula and evaluated immediately, assigned to another variable, it's 'companion variable'. Then this variable holds the true value it should hold at 't0'. In addition, this conversion process happens every frame, so that the 'companion variable' changes every frame, thus I can have a bullet with speed 2 * 1.01^t, where t is time since launch in frames. Anyway, there's a way around it, it's just that you will have to call your function of time within the CreateShot itself.
Using the w=t*5 example... if 'w' is called at frame 100, it should return 500, and if it's called at frame 200, it should return 1000, etc. Of course, that means either w has to be reset to 't*5' every frame (thus you actually want this variable declaration in the main loop), or you need something else. Of course, a variable created within a task only exists within that particular task, so the w that is reset in the main loop will not carry over to the one set in stone in the task, so this will not solve the problem at all. Basically w needs to be evaluated like that in the task, i.e. the literal programming code 'w=t*5;' needs to be present within the task, and of course I want the right-hand part of the equation to be in the position of 'vxt' for example. So, basically, I just want the program to substitute the vxt within the task with some text that would also go as code. Basically vxt as a variable would be a string that is converted into programming code within the task itself. Because the string just contains some kind of math expression, the code it contains would be resolved when it would be applied as code. However, this happens only when it is converted to code within the task, i.e. it gets resolved inside the task. Thus, it gets applied a new value each time we call it, and that's the way of getting some kind of time-dependant behaviour. A much simpler way of doing this is to just manually replace 'vxt' in your programming code with the intended function and leave out 'vxt' and 'vyt' in the task's variables. But, you will need a new task for each function and some kind of naming convention if you intend to use many.
Code becomes;
task CreateShotF11(x0, y0, xv0, yv0, graphic, delay, duration) {
// Define bullet object
let obj = Obj_Create(OBJ_SHOT);
// Set Object initial settings
Obj_SetPosition (obj, x0, y0);
Obj_SetSpeed (obj, (xv0^2 + yv0^2)^0.5);
ObjShot_SetGraphic(obj, graphic);
ObjShot_SetDelay(obj, delay);
Obj_SetAngle (obj, atan2(yv0, xv0));
ObjShot_SetBombResist (obj, false);
let TOJ = t
// Set the speed of the object equal to the functions.
while(Obj_BeDeleted(obj)==false) {
Obj_SetSpeed (obj, (vxt^2 + vyt^2)^0.5);
Obj_SetAngle (obj, atan2(vyt, vxt);
if TOJ + duration > t {
Obj_Delete(obj);
}
yield;
}
}
Of course, manually replace vxt, vyt with your formulae for these (which are to be only dependant on 't' and variables that are defined.). Now of course.... for several bullets, with functions vxt(n), etc. which can be written out neatly dependent on increasing 'n', you can potentially add in an ascent(i in 1..n+1) around the whole thing... Just add a variable 'whatever' to the task in front and adjust it in, ascent around 1..n+1 whenever you call the thing to make all 'n' bullets, in other words, it can be easily modified to create multiple bullets as long as they travel along the same guidelines save for simple transformations (anything not substantially changing the formula basically, additions, multiplications, etc.). Or, as a more efficient method, simply use arrays to the same effect... We could declare;
\\ in the initialization.
let obj=[0];
\\ in the main loop or task.
ascent(i in 1..n+1){
obj = obj ~ Obj_Create(OBJ_SHOT);
}
And of course, for each additional segment of lines in the task we will need to create an array. The whole code becomes (of course, insert the correct amount of 'zeroes' to first declare the array's size correctly);
task CreateShotF11(x0, y0, xv0, yv0, graphic, delay, duration, n) {
// Define bullet object
ascent(i in 1..n+1){
obj = obj ~ Obj_Create(OBJ_SHOT);}
// Set Object initial settings
ascent(i in 1..n+1){
Obj_SetPosition (obj[i], x0, y0);
Obj_SetSpeed (obj[i], (xv0^2 + yv0^2)^0.5);
ObjShot_SetGraphic(obj[i], graphic);
ObjShot_SetDelay(obj[i], delay);
Obj_SetAngle (obj[i], atan2(yv0, xv0));
ObjShot_SetBombResist (obj[i], false);}
let TOJ = t
// Set the speed of the object equal to the functions.
ascent(i in 1..n+1){
while(Obj_BeDeleted(obj[i])==false) {
Obj_SetSpeed (obj[i], (vxt^2 + vyt^2)^0.5);
Obj_SetAngle (obj[i], atan2(vyt, vxt);
if TOJ + duration > t {
Obj_Delete(obj);
}
}
yield;
}
}
Note that you need all x0, y0 to match up (all bullets starting in the same position) for this trick to work. If this is not the case, also remove x0, y0 from the task declaration variables and replace them with your intended arrays for the task, i.e. x0 becomes let x0 = ["x01", "x02", ...,], with x0n being the intended value of the x-starting position of the n-th bullet. The same goes for all the other variables you put into the task when you declare it, you can't have them dependant on 'i' without actually inserting the declaration into the task itself. Then again, you do gain the advantage of being more efficient, you need far less tasks if you can somehow create an array of bullets with only mildly different functions (say, a trigonometric mutation by a certain amount of degrees, for example creating a ring of bullets that all move in a lissajous pattern (would be funny to watch...)
*notice* vxt, vyt are NOT variables here, they're bits of things you should replace by your formula for them.
The main problem with using the second version (which DOES assign a bullet only a position and velocities of 0 at every frame), is that you have to determine the angle you want the bullet to be at, instead of the game doing that automatically*. Perhaps my example was too simple, but it can be quite a pain for some weird patterns. Say a Rose pattern (i.e. not bullets being in a rose pattern, but a bullet MOVING in a rose-pattern).
About the vx, vy versus the x,y versions; the angle the bullet should be facing has been rather simple in the problems we've seen so far so it's easy to include the angle ('t was included in one of the examples with an x, y version of the thing, basically). It's just that if you have some kind of very weird trajectory, it isn't always easy to come up with an angle(time)-function as well, and apply it each second (which gives you a total of three functions instead of two). Because I've been assuming the only work you need to do is deriving the functions and so on, the option of the vx-version is sometimes more alluring than the standard version. And of course, if you wanted a bullet with a certain speed instead of a certain path, that can be done like that more easily too. Integration is usually a very nasty thing when applied to random patterns, I don't like to do it nearly as much as the much easier version the other way. So, the answer to this bit;
I notice you're using a parametric function for determining the position of a bullet based on time.
Personally, I think it would be much easier if you just kept the bullet's velocities at zero and instead continually reassign the bullet's position. The effect is the same, but it save you all of the hoops you're currently trying to jump through to get it to work.
Is that I actually did both. I saw that sometimes you can use just the bullet's position, that is when your angle(time) function, or your angle(position) function is rather simple (remove angle from the list of variables at the function's declaration, insert your angle(time) or angle(position) function instead of just 'angle' in all the places where it is mentioned). It's just that it needn't be a very simple function
at all. It could be even more of a pain to obtain than the other things. For example;
Problem:
(i) Determine the angle(time)-function of a particle p, travelling in a pattern given by the polar coordinates
r = sin(2/5 * t)cos(2/5 * t)
angle = 0.5 * t^2
(ii) Transform both functions into the cartesian planeThat looks like a far more difficult problem than derivating both functions toward t, after transforming to cartesian coordinates. In fact, the latter would probably take one to five minutes, while that problem actually includes solving all those things (as you need the velocity vector to determine the angle, which is the tangent of the y-component divided by the x-component of said vector, and said vector is the combination of both unity vectors i and j times respectively both derivatives determined, but I'm digressing here. Anyway, my point is that sometimes one version is better, sometimes the other. Note that in the original post I concluded that for that particular problem it's possible to go with the x,y solution!
Conclusion, the x,y solution can be used if:
(i) The bullet has an easy angle(time), angle(position) function, or does not need to be angled (round bullets).
(ii) The bullet has a specified x,y(t) equation set, or one that can be easily obtained through integration (don't do tricky integrals, just go with the vx, vy solution if you get one of them, they're not nice to me, and not nice to you.)
In practice, condition (i) is fairly commonly untrue, while (ii) is true most of the time. Both need to be true for the x,y method to be more efficient. By the way, here's the updated version for the x,y, the simpler version, you should be able to deduce the one with arrays as well

.
task CreateShotF13(x0, y0, graphic, delay, duration) {
// Define bullet object
let obj = Obj_Create(OBJ_SHOT);
// Set Object initial settings
Obj_SetPosition (obj, x0, y0);
Obj_SetSpeed (obj, 0);
ObjShot_SetGraphic(obj, graphic);
ObjShot_SetDelay(obj, delay);
Obj_SetAngle (obj, 180);
ObjShot_SetBombResist (obj, false);
let TOJ = t
// Set the position of the object equal to the functions.
while(Obj_BeDeleted(obj)==false) {
Obj_SetPosition (obj, xt, yt);
Obj_SetAngle (obj, 180);
if TOJ + duration > t {
Obj_Delete(obj);
}
yield;
}
}
Once again, replace xt, yt by your chosen/found formulae for movement...
You can also replace 180 by your angle function if you want one.
CreateShot01(GetX(), GetY(), 2, w(t), RED01, 5);
... it may just be easier to use:
CreateShot01(GetX(), GetY(), 2, t*5, RED01, 5);
That won't really work, as the angle of the bullet won't change with time, it'll just become the time the function is called times five. Of course, you could just do that with angular velocity... However, what if you had something more complicated, like
w(t) = 0.1172t^6.4 - 2t^3 + arctan(5/8 * t - 7 + 3* t^0.5)
As your angle, as a function of t, with t=0 at the frame the bullet is launched? Surely you would need to adjust the angle frame-by-frame or each couple frames to maintain this part of the bullet's equation of motion. The derivative of this does not even approach a straight line, nor a set of a couple straight lines (so we could use a pair or trio of SetShotDataA). Each frame you would need to redetermine the angle as a function of the current time, in other words, put into the 'angle' variable box this function of time. In other words 'let angle = {insert function}' need be called every frame, so it need be present within the yield-loop in the task. Thus this formula need be present into the yield loop inside a task. So therefore, you need to manually put this formula into your task. (basically what I was hoping for was the possibility of having to have a way that you could put the formula somewhere else, like in the task's assigned modifiers as a string, but no luck I guess.)