※ Q&A/Problem Thread 6 ※ for OLD Danmakufu version (0.12m)

[Qwertyzxcv]

You just happened to spawn 8 bullets there. Check loops, check other stuff, and check... yeah.

Task Fire:

Code: [Select]

                ang+=5000/5;
                dir+=5000/5;What is this supposed to accomplish?

OK. So... a lot of your bullets overlap because you coded it that way. When you create two bullets with the same parameters, yeah...

Basically, not every bullet = 8 bullets. Just a few. However, rectifying the issue isn' practical because your script depends on the layout of bullets and angle incrementations that you have in place.

Yup, my graze goes up 16 for fire...
I fixed what you said and now it goes up 8.
The green squares also are overlapping, so  .
Edit: @Maths ~Angelic Version~, Thanks, that fixed firec!

[Qwertyzxcv]

NOW, I messed with it a lot and now the only thing is fireb is 2 bullts:

Code: [Select]

task fireb{
  wait(60);
  let dir = 0;
  let x = 0;
  loop{
  while(x<36){
  CreateShot01(GetX, GetY, 3, dir, BLUE02,0);
  dir+=500/5;
  x++;
  }
  x = 0;
  dir=0;
  wait(12);
  yield;
  }}


[Sparen]

OK. My question and error message have been resolved.

["E", -40] is illegal because an array must have the same characteristics throughout.

[Drake]

NOW, I messed with it a lot and now the only thing is fireb is 2 bullts:

Code: [Select]

while(x<36){
   dir+=500/5;
   x++;
}


You just didn't really pay attention to how your angles will work out. Angles work in modulo 360; that is, 360 = 0, 361 = 1, 390 = 30, etc.
You're increasing the angle by 100 every loop, over 36 times. You get this sequence:
0, 100, 200, 300, 40, 140, 240, 340, 80, 180, 280, 20, 120, 220, 320, 60, 160, 260... 360 = 0.
Then it repeats that sequence for the next 18 loops, so you end up with 2 bullets on top of each other.

[Qwertyzxcv]

You just didn't really pay attention to how your angles will work out. Angles work in modulo 360; that is, 360 = 0, 361 = 1, 390 = 30, etc.
You're increasing the angle by 100 every loop, over 36 times. You get this sequence:
0, 100, 200, 300, 40, 140, 240, 340, 80, 180, 280, 20, 120, 220, 320, 60, 160, 260... 360 = 0.
Then it repeats that sequence for the next 18 loops, so you end up with 2 bullets on top of each other.

OHHHHHH  :derp: 
Thanks!

[TheTeff007]

So I have this problem with the Events...


It's supposed to load the image of the boss for the conversation, but instead it loads that.


The code is the next one (I Apologize for not using pastebin, but it does not open right now for some reason...)

Code: [Select]

#TouhouDanmakufu[Single]
#Title[Stage 1 Boss Conversation]
#Text[Chimei Jigyosho Pre-Battle Conversation (Reimu)]
#Player[FREE]
#BackGround[Default]
#ScriptVersion[2]

script_event Event01
{
let Boss1 = GetCurrentScriptDirectory ~ ".\enm1img\Chimei00b.png";
let Boss2 = GetCurrentScriptDirectory ~ ".\enm1img\Chimei00c.png";
let Boss3 = GetCurrentScriptDirectory ~ ".\enm1img\Chimei00d.png";
let Boss4 = GetCurrentScriptDirectory ~ ".\enm1img\Chimei00e.png";

let White = GetCurrentScriptDirectory ~ ".\enm1img\white.png";
let BGM = GetCurrentScriptDirectory ~ ".\enm1bgm\02.mp3";

let BossAll = [Boss1, Boss2, Boss3, Boss4];

@Initialize
{

ascent(i in 0..length(BossAll)){LoadGraphic(BossAll[i]);}
LoadGraphic(White);
LoadMusic(BGM);

}

@MainLoop
{
SetChar(LEFT, White);
SetGraphicRect(LEFT, 0, 0, 1, 1);
MoveChar(LEFT, FRONT);
TextOut("\c[BLUE]Plants are acting berserk \naround here...");
TextOut("\c[BLUE]Somebody must be surely causing \ntroubles!");

MoveChar(LEFT,BACK);
TextOut("\c[RED]T-that's probably my master.");

SetChar(RIGHT, BossAll[0]);
MoveChar(RIGHT, FRONT);
SetGraphicRect(LEFT, 0, 0, 384, 512);
TextOut("\c[RED]She is resurrecting plants /nall over the forest.");


End;
}

@DrawLoop
{

}

@Finalize
{

}
}

script_enemy_main
{

@Initialize
{
SetLife(1);
SetMovePosition01(GetCenterX, GetCenterY-100, 2);
CreateEventFromScript("Event01");
}

@MainLoop
{
yield;

if(OnEvent == false){SetLife(0);}
}

@DrawLoop
{
}

@Finalize
{
}
}

[Ozzy]

Code: [Select]

let Boss1 = GetCurrentScriptDirectory ~ ".enm1imgChimei00b.png";
let Boss2 = GetCurrentScriptDirectory ~ ".enm1imgChimei00c.png";
let Boss3 = GetCurrentScriptDirectory ~ ".enm1imgChimei00d.png";
let Boss4 = GetCurrentScriptDirectory ~ ".enm1imgChimei00e.png";

let White = GetCurrentScriptDirectory ~ ".enm1imgwhite.png";
let BGM = GetCurrentScriptDirectory ~ ".enm1bgm2.mp3";


I don't believe the "." is needed when assigning file paths to a variable like that.

[Sparen]

I don't believe the "." is needed when assigning file paths to a variable like that.

It shouldn't affect the script though. That's probably not the cause of the bug. Are the directories navigated to correctly?

[TheTeff007]

Yes, they are. The Cut In for the Spellcard Declaration works just fine, as demostrated on the attachment. And they are on the very same directory.

[Drake]

Why it's all sparse dots is beyond me because I don't know what your graphics look like. I'm going to guess that white.png has a single white pixel and maybe other things, in which case it will show in the bottom-left corner in the first bit of dialogue. Then it gets pushed back, then its rect gets set to 384x512, which would wrap the graphic until it fills that area. There's a definite pattern going horizontally, even if the brightness changes a bit (there are 6 lines of white-ish lines, then it wraps).

Anyways, a major error is probably just your assignment of (LEFT, 0, 0, 384, 512). I have no idea what the heck you're doing besides that.

[Lavalake]

I have another stage problem.
So, I have enemies in my stage that shoot bullets. And the main bullets spawn other bullets.
These other bullets start with a velocity of 0 and increase little by little after waiting 120 frames.
So basically

Code: [Select]

task Bullet(Parameters){
      ...
      wait(120); // waiting 120 frames
      loop(#){
            Obj_SetSpeed(obj, Obj_GetSpeed(obj) + 0.05); // Twenty times to get the next whole number
            yield;
      }My question is:
When the enemy gets killed/vanished. The bullets that don't have a speed are just stuck on the screen until you die.
How do you prevent this?

[Sparen]

I have another stage problem.
So, I have enemies in my stage that shoot bullets. And the main bullets spawn other bullets.
These other bullets start with a velocity of 0 and increase little by little after waiting 120 frames.
So basically

Code: [Select]

task Bullet(Parameters){
      ...
      wait(120); // waiting 120 frames
      loop(#){
            Obj_SetSpeed(obj, Obj_GetSpeed(obj) + 0.05); // Twenty times to get the next whole number
            yield;
      }My question is:
When the enemy gets killed/vanished. The bullets that don't have a speed are just stuck on the screen until you die.
How do you prevent this?

Please elaborate on the issue and what kind of enemy you are using. Also, are both the main bullet and the child bullets objects?

[Lavalake]

Please elaborate on the issue and what kind of enemy you are using. Also, are both the main bullet and the child bullets objects?

I'm using basic enemies. The fairies that appear and can be killed easily. They don't have a lifebar visible.
Both of the bullets are object bullets.
The issue is that the objects don't gain speed after the fairy is killed, so they are stuck on the screen.

[Ozzy]

I'm using basic enemies. The fairies that appear and can be killed easily. They don't have a lifebar visible.
Both of the bullets are object bullets.
The issue is that the objects don't gain speed after the fairy is killed, so they are stuck on the screen.

This is because the script increasing the speed of the bullets ended when the fairy died. The easiest solution to this would be to delete the bullets when the fairies die. If that doesn't work for you, then you may want to instead of deleting the enemies, make them "vanish" by setting their coordinates offscreen when they take enough damage. This will make them appear to be killed without actually killing them, Thus the script increasing the bullets' speed will still work. Just be sure to kill them off for real soon after that or lag will eventually build up. Note that this method will cause the enemy to lack the automatic death graphic animation that displays when stage enemies are destroyed. A workaround to this problem would perhaps be to spawn another "dummy" enemy at the same coordinates and instantly kill it on the same frame to produce the death effect.

[Drake]

See this is why 0.12 can get really retarded. As far as I can tell there's no workaround besides having the enemy not really die. Having extra management systems can work for things like explosion effects and whatnot (with heavy use of CommonData lololololol gross.), but when it comes to things that were already working before the enemy was killed, it suddenly becomes impossible.

[Helepolis]

Wouldn't scripting the object bullet outside of the enemy file and including it inside the stage script fix this issue? I remember I had the same problem with [P] items which stopped falling down when the fairy died.

Not quite sure any more.

[Ozzy]

Wouldn't scripting the object bullet outside of the enemy file and including it inside the stage script fix this issue? I remember I had the same problem with [P] items which stopped falling down when the fairy died.

Not quite sure any more.

I'm pretty sure stage scripts cannot spawn bullets, if that's what you are suggesting.

[Helepolis]

Indeed I was. That is a shame. Thought that if Effect Obj can be spawned so could Obj bullets but I guess not.

Damn you danmakufu. Why do you have to be so annoying.

[Ozzy]

The nice thing about Ph3 is that you can have enemy scripts continue to run even after the enemy's death. So, it WAS fixed, just not in this version.

[Helepolis]

The nice thing about Ph3 is that you can have enemy scripts continue to run even after the enemy's death. So, it WAS fixed, just not in this version.

I am still extremely fighting within my mind whether I should port my game fully to PH3 Beta6 or stick with 0.12M.

Cannot seem to decide because last time (Beta something) half of the functions did not work, especially the ones I needed (volume control for sound files for example).

[Ozzy]

I am still extremely fighting within my mind whether I should port my game fully to PH3 Beta6 or stick with 0.12M.

Cannot seem to decide because last time (Beta something) half of the functions did not work, especially the ones I needed (volume control for sound files for example).

Ph3 has been significantly updated since then. The aforementioned sound volume control function now DOES work.

[Lavalake]

I found a solution to my own problem just now.
During finalize, I had the script vanish the fairies hitbox, make the image disappear with

Code: [Select]

let die = 0;And

Code: [Select]

if(die==1){ SetGraphicRect(Set a pixel of graphic to a blank spot);Then deleted SE's (The other fairy still has working SE's)
Then I had it wait 130 frames. (The object bullet that were just spawned only needs 120 to get to the ObjShot_FadeDelete).
After the wait. The fairy officially get defeated.
It works, but it is very sloppy.  :3

[Sparen]

I found a solution to my own problem just now.
During finalize, I had the script vanish the fairies hitbox, make the image disappear with

Code: [Select]

let die = 0;And

Code: [Select]

if(die==1){ SetGraphicRect(Set a pixel of graphic to a blank spot);Then deleted SE's (The other fairy still has working SE's)
Then I had it wait 130 frames. (The object bullet that were just spawned only needs 120 to get to the ObjShot_FadeDelete).
After the wait. The fairy officially get defeated.
It works, but it is very sloppy.  :3

Well, it seems that this information will be helpful in the future.

P.S. Does anyone know the source code CreateShotA? If it's an object bullet, then that may give leads to how this problem can be circumvented, since CreateShotA's commands work even after the enemy has died.

[Drake]

Hardcoded functions are bound to work differently than user-defined-in-script ones. Danmakufu's object manipulation is "fake"; while certain predefined functions might directly map to some engine code, these functions are not written in script themselves, and would be impossible to copy by design. Shots created using the predefined functions are definitely objects, but you aren't given any sort of object-like control over them (not that you are with shot objects either), and the functions such as CreateShot01 probably map directly to some basic bullet creating code. Seeing as you "build" bullets with CreateShotA using distinct functions, you would not be able to do the same with the given shot object functions, since you'd either have to make some convoluted event-based system that would wait some amount of frames for flags or whatever, or have something like using arrays for parameters. The latter is "more" viable but I still would never suggest it since it removes the point of "building" the bullet to begin with. Making shot scripts would work better than both of these, and that's still a terrible option. No matter how you look at it, it all comes down to really awful convoluted workarounds.

[JCTechnic]

Everyone was talking about the PH3, it seems to be the new danmakufu engine, but can I ask what are the main diferences between the 0.12 and the PH3?

I think i can ask this here because of how the conversation was going, if not I'll go to the other thread and post my question over there.

[Helepolis]

Everyone was talking about the PH3, it seems to be the new danmakufu engine, but can I ask what are the main diferences between the 0.12 and the PH3?

I think i can ask this here because of how the conversation was going, if not I'll go to the other thread and post my question over there.

PH3 is the next version for the danmaku maker (Danmakufu). The developer stopped the old one (which is currently at 0.12m, hence we call it 0.12). He started a beta version called Ph3(number).

Major differences are the stability, expanded functionality (too much to name) and more flexible and efficient programming with objects. Just to give you an idea, you can define your playfield size now and use shaking bullets/camera.

[JCTechnic]

PH3 is the next version for the danmaku maker (Danmakufu). The developer stopped the old one (which is currently at 0.12m, hence we call it 0.12). He started a beta version called Ph3(number).

Major differences are the stability, expanded functionality (too much to name) and more flexible and efficient programming with objects. Just to give you an idea, you can define your playfield size now and use shaking bullets/camera.

So would it be better if I started learning PH3? Or would that depend on what I wan't to make with danmakufu?

[Helepolis]

Difficult to say: If you're completely new to Danmakufu, I would suggest to pick up ph3 since you'll be immediately up to date with the newest engine.

Pretty much everything which was possible in 0.12m is possible in ph3. The new features are just a bonus on top of it (keep in mind that not all new functions work yet, but hey it is a beta).

So yea, the choice is up to you.

[gtbot]

As Helepolis said, it's entirely up to you. But I strongly suggest updating to ph3 mainly because it has more features over 0.12m, is constantly updated (as of now), and, my biggest and strongest reason, it's a lot easier to do things in ph3. No needlessly mundane tasks like having a stage for a plural script just for the 3D background, recreating enemies for visual effects, having to set up an entire system of CommonData to have your own custom UI (or have a strange block cover the old UI), or even using vertices and atrocious math for a simple four point square image. Another thing is none of the effects in ph3 are hard coded, so you can put your own effects and they won't be overlapping with Danmakufu's default effects. There's also 100 layers that you can put objects into.

I can go on with this list for a bit longer, though I may be biased to ph3 because that's when I was able to make scripts that aren't about my selfinserted overpowered omnipotent deity cat. I'd also still like to reinstate that it's still entirely up to your preference, since 0.12m can still be a powerful tool.

[Ozzy]

To add to this discussion, I've been planning to make a basics tutorial for ph3 to help make ph3 less scary for both new and experienced danmakufu users to get into. Since video tutorials seem to be the ones that most people (beginners at least) prefer, I'm going to try my hand at a video tutorial.