~Hakurei Shrine~ > Rika and Nitori's Garage Experiments
Oh god acceleration
Hat:
My bullet acceleration is going CRAZY. I'm trying to make a code where a bunch of these white bullets drift downwards with varying accelerations in one direction or another, just slightly (think Chen's spellcard in PCB). However, crazy CRAZINESS has been happening. First, when I set the x-velocity maximum to 99, in a crude attempt to get rid of maxima (because I was trying to fix an earlier problem which I will detail shortly), the bullets all leapt to the edge of the screen like they were trying to outrun the swine flu, I swear to god. They might as well have VANISHED. The best part was that I defined the x-acceleration to be 0.00001, and yet they still fled like it was a freaking pandemic.
But the story does not end there, my friend. I tried using rand(-0.05, 0.05) to make the drift randomized, but instead, they all just drifted to one side... aah, see for yourself. The effects are really strange (moreover, I don't get why half the bullets dive to one side, and the other half drift the way they're supposed to).
No comments about how this spell would be impossible even if it COULD work. It's a work in progress atm, and that's why the code is haphazard and flying all over the place.
--- Code: ---#TouhouDanmakufu
#Title[Cloud Sign "The Moryo are Silently Watching"]
#Text[Spell card 02]
#Player[FREE]
#ScriptVersion[2]
script_enemy_main {
let ImgBoss = "script\img\ExRumia.png";
let frame = 0;
let frame2 = 150;
#include_function "lib\SHOT_REPLACE\shot_replace.dnh"
@Initialize {
SetLife(2000);
SetTimer(120);
SetScore(1000000);
SetMovePosition02(GetCenterX, GetClipMinY + 120, 120);
CutIn(YOUMU, "GOD DAMN ASS SHIT BOB SAGET", "", 0, 0, 0, 0);
LoadGraphic(ImgBoss);
SetTexture(ImgBoss);
SetGraphicRect(0, 0, 64, 64);
TMain;
shotinit;
}
@MainLoop {
SetCollisionA(GetX, GetY, 32);
SetCollisionB(GetX, GetY, 16);
yield;
if(frame%20 == 0 && frame >= 0){
Moryo(frame2);
frame2 -= 20;
}
if(frame == 80){
frame2 = 150;
frame = -120;
}
frame++;
}
@DrawLoop {
DrawGraphic(GetX, GetY);
}
@Finalize {
DeleteGraphic(ImgBoss);
}
task TMain{
yield;
TMove;
}
task TMove{
let stepsize = (GetClipMaxX - GetClipMinX - 60)/4;
let move_y = GetCenterY + rand(30, 120);
let move_x = GetClipMinX + 30;
let disc = 1;
SetMovePosition03(move_x, move_y, 3, 10);
loop{
loop(4){
move_y = GetCenterY - rand(30, 120);
if(disc == 1){
move_x += stepsize;
}else{move_x -= stepsize;}
SetMovePosition03(move_x, move_y, 3, 10);
loop(20){yield;}
}
disc = -1*disc;
loop(120){yield;}
}
}
function Moryo(frame_b){
let angle_m = rand(0,360);
loop(8){
CreateShotA(0, GetX, GetY, 1);
SetShotDataA(0, 0, 10, angle_m, 0, -1, 0, WHITE03);
SetShotDataA(0, 7, 0, 0, 0, 0, 0, WHITE03);
SetShotDataA_XY(0, frame_b, 0, 0.1, rand(-0.01, 0.01), 0.1, 3, 5, WHITE03); //GOD DAMN THIS LINE OF CODE. GOD DAMN IT TO HELL
angle_m += 45;
FireShot(0);
}
loop(16){
CreateShotA(1, GetX, GetY, 1);
SetShotDataA(1, 0, rand(7, 11), rand(0, 360), 0, -1, 0, WHITE04);
SetShotDataA(1, 7, 0, 0, 0, 0, 0, WHITE04);
SetShotDataA_XY(1, frame_b - 10, 0, 0.2, 0, 0.1, 99, 3, WHITE04);
FireShot(1);
}}
}
--- End code ---
Enjoy this madness. Oh, and set the x-max to 99 to watch the BULLET JIG OF THE CENTURY. Oh ya, and I used the bullet replace script, but every cool kid in danmakufu should have that by now (I used pretty standard bullets anyway, but I dunno what will happen if it can't find the script)
Naut:
Record your screen, it's working perfectly on my computer. The bullet's do pretty standard things, as in, drift to the bottom of the screen. It's not very random though, but I can see what you're trying to accomplish.
To answer why it might be going bat-shit Bob Saget on your ass, I have a theory. One that I'm actually going to record, if I get around to it. The theory is simple:
Danmakufu fucking sucks.
Allow me to elaborate. Sometimes Danmakufu will just not do what you want it to do. There is nothing you can do about it. And it will infuriate you to no end, but you can't do shit. My theory was that this shit happens if you overload the allocated memory for danmakufu (for example, trying to represent a fucking massive floating point number, for those of you who know what that means). Or when your computer can't properly calculate things fast enough, and if affects things other than your FPS. I do have evidence towards my favor, unfortunately.
Two events in question.
DeleteEnemyShotImmediatelyInCircle(); stops working in the middle of the script, even though it is called every frame and does not change in anyway. I think this is because I was incrementing a value by an incrementing value that was being incremented by another value increasing by one every frame (don't fucking ask). After a certain amount of time would pass, the DeleteEnemyShotImmediatelyInCircle() stopped deleting shots (the radius of the circle was too large for bullets to skip over) and the script would erupt into a massive cavalcade of fury. As cool as it was to see this function fail for no aparent reason whatsoever, this infuriated me, and eventually I stopped the incrementing loop and everything worked perfectly. I didn't save the effed version of the script, but I might try to reproduce it for documentry purposes.
The second event had to do with object scripts. Admittedly, at the time, I didn't really know what I was doing in regards to object scripts, but in retrospect, there was nothing for me to screw up. It was simply changing a frame value from 79 to 78, that made the script move from spawning 2 bullets to spawning 25986896134 and making the screen go white, and chaos ablaze. Interestingly enough, setting the frame value to ANY OTHER NUMBER (above or below) set the bullet loop to spawn only one bullet. I have yet to discover the reason for this, but because of this, I never use the number 78 for anything, regardless. I want to capture this on film as well, it was most humourous.
Anyway, the point of all this is: Your script works perfectly on my screen (or, does exactly what you've typed, and sounds very close to what you described was the goal), yet you claim that it goes nuts on your screen. Danmakufu is fucked. All is lost.
On a serious note to actually solve your problem, you might want to just retype out your script in a different way and see if that works. Sometimes shit just doesn't work properly, so you have to dick around another way to get it to.
Hat:
Pfahahahah! Well, that's a very mixed bag, there. Good AND bad news. The good is that I'm not a failure, the bad news is that I've been slaving away at a program that doesn't do what it's supposed to. Lovely.
Naut:
Usually only happens when you've called something exceptionally large or excessive, that you could've probably done some other way for the same effect (which I can only speculate). All that said, it's still the best shooting game maker available that's relatively easy to understand and pick-up.
...Isn't it sad, Danmakufu?
Anyways, can you at least take a screenshot (or two) of what's going on with your script? It sounds funny.
Iryan:
I'm not really shure if that is how acceleration works, but...
If you say the acceleration is a random number between (0.1 and -0.1), it can be either positive or negative. Now, you have only a positive number as a (min/max) speed value and 0 as the starting speed value.
This could cause the following things if your acceleration is negative.
a) because the direction of acceleration is the opposite of the direction your maximum velocity is going for (from 0 to 5 is increasing, a negative accel is decreasing), the number 5 is then seen as the minimum velocity to which the bullet slows down, thus all bullets for which the accel is negative will be fired at a precise speed of 5, which is much! The bullet will usually leave the screen in less than a second.
b) as the cap is higher then the starting value even though the acceleration is negative, the cap is ignored. With an accel of 0.1, this means that, after one second, the bullet will have a speed of 6 and will have moved by a distance of 0.5*(60^2)*0.1, which is 180, or almost half the width of the playing field. In other words:
The bullet will leave the playing field in little more than 1 second.
Either way, about half the bullets have the potential to kick off like there is no tomorrow. To get rid of this possible cause of error, you could define a variable, lets call it "pol", then, each time during your loop, you will set this variable randomly to either 1 or -1, for example with
--- Code: ---pol=(1-2*rand_int(0, 1));
--- End code ---
, then give the bullet a max speed of 5*pol and an accel of rand(0, 0.1)*pol.
Note, however, that 0.1 is already a very high acceleration. Look at scenario b) up there, and you will notice that the bullet will leave the screen in less one and a half second if the acceleration is 0.5 even if the maximum is 5. you might want to decrease the maximum acceleration to something like 0.05 or even 0.02. I never use acceleration higher than the latter. 0.02 means that your bullet reaches a speed of 1.2 after the first second and 2.4 after the second second, and so on.
So long.