※ Dnh Q&A/Problem ※ for Danmakufu ph3 (locked)

[Sparen]

I checked all three scripts using ph3 0.19 and didn't get that bug even once. Probably it's related to the OS environment somehow, I played under Linux (wine).

I use Mac with Wine 1.7.1 compiled and built from source.

The other testers use various Windows Operating Systems. Therefore, this bug is OS-independent

[PhantomSong]

I checked all three scripts using ph3 0.19 and didn't get that bug even once. Probably it's related to the OS environment somehow, I played under Linux (wine).

It happens here and there.  Not all the time

[Necrotek]

Wine 1.7.4
Well... probably I'm just "unlucky". Does it happen for replays too? If it does, attach one which definitely crashes at some point. I could try to run it again and again until I get something (crash, I guess).

[Lavalake]

So, I'll get straight to the point.
It seems I can't play scripts because the player scripts won't show up. I enter a script and at the player selection menu, nothing comes up. Pressing z makes danmakufu crash.
I checked the player script, have the latest version of ph3, and everything seems to be looking right.
I don't know what's the problem...

[Drake]

Download ph3 by itself and see if it works, or download another standalone like Lucas' contest 10 entry. I assume the player scripts are actually in their proper /script/player directory.

[Lavalake]

I'm trying to play TalosMistake's contest 10 entry with the player script included. Nothing inside was touched. I've also tried with other standalone scripts. I have a default player script too, but nothing appears on the player selection screen.

[Drake]

Download ph3 by itself in some random directory and see if the samples work

need to isolate the possibilities of it being an application issue or a system issue

[Sparen]

Check the last script you downloaded/edited and make sure there aren't any weird symbols in the fields following #

Danmakufu crashed every time I tried to open a folder once because my text editor autocorrected (P) into something weird.

[Lavalake]

Nevermind my problem, turns out I didn't change my locale to japanese on my laptop. Although I'm still wondering why I could play some scripts without applocale.

[ExPorygon]

Nevermind my problem, turns out I didn't change my locale to japanese on my laptop. Although I'm still wondering why I could play some scripts without applocale.

Danmakufu will correctly read and run any script that does NOT contain any Japanese or similar foreign characters in it. Applocale is only needed for those scripts that DO. The reason that 0.12m almost always requires Applocale as a general rule is because the default, hard-coded player characters contain Japanese in their names and are almost always loaded when trying to play scripts, even if they aren't always used.

The players you were trying to get Danmakufu to load, I suspect, contained some Japanese characters somewhere in them (I don't think it matters if they're commented out).

[KuroArashi100]

I'm sorry if this question has been asked before, but I'm having a problem and I can't find a solution on my own.

I'm trying to make my own shotsheet, and I ran into some problems once I wanted to test it.
Danmakufu gives an error that shot_image is undefined.
Writing a replace script seems to solve that problem.
However, when trying to use it in Danmakufu, the bullets won't show up.
I already checked the pathing and file names, and the error doesn't seem to have to do something with either of those.
Does anybody know what the problem could be?

Shotsheet data
Replace script
(The begin of a) test script

[Necrotek]

I'm not sure if it's related to your problem but... isn't it supposed to use slash symbols instead of backslash ones for paths?

[KuroArashi100]

Oops. I think that might be a small error too. I think 0.12 used backslashes, and I used them out of habit.
I don't think it's related though. Swapping the backslashes for slashes gives the same result.

[Necrotek]

Probably it's worth to take a look here.
Upd: on the other hand, the answer wasn't found there.

[KuroArashi100]

Seems like I made another stupid mistake... I forgot to place a = behind rect and delay_color.
Fixed that and now it works fine.

Now I just need to move all the bullets around again, because stuff clips in the bullets everywhere :V

[Necrotek]

Seems like I made another stupid mistake... I forgot to place a = behind rect and delay_color.

But... the equal sign is there in those pastebin links...
Oh well, if it works now then it's fine.

[KuroArashi100]

Code: [Select]

ShotData{ id=1 rect(0,0,16,16) render=ADD angular_velocity=0 delay_color(255,64,64) }
ShotData{ id=1 rect=(0,0,16,16) render=ADD angular_velocity=0 delay_color=(255,64,64) }No it isn't. The first line misses the equal signs in the places I mentioned, the second line is the correct one.
If you try to run this in Danmakufu with an image with something at those coordinates, the first one won't do anything, but the second one should appear correctly.

[MoonRabbit]

Well, I've done some research. Here are my findings:
1. LoadTexture function actually loads the texture into the ram (you can see it in the task manager). If you try to load twice, it will ignore the second one. If you load a texture in one script, it will apply to all scripts.
2. I tried the same thing with LoadSound with a huge file, but the RAM didn't go up! So I used procmon and found this out -
What LoadSound does is to open a handle to the file. When you use PlaySE, it starts reading the file.

So - loading texture in the beginning is essential, but loading sound in the beginning only saves you the CreateFile phase (getting a handle to the file).
Also, if you use LoadSound then you can only play it on the same script, so trying to load everything together is a pain.

So...... maybe the function I showed in my last post does make sense?! I am so confused.

Old post but I must correct it -
I just found out that LoadSound DOES load the file into the memory, unless you use a really big sound file.

[Necrotek]

Code: [Select]

ShotData{ id=1 rect(0,0,16,16) render=ADD angular_velocity=0 delay_color(255,64,64) }
ShotData{ id=1 rect=(0,0,16,16) render=ADD angular_velocity=0 delay_color=(255,64,64) }No it isn't. The first line misses the equal signs in the places I mentioned, the second line is the correct one.
If you try to run this in Danmakufu with an image with something at those coordinates, the first one won't do anything, but the second one should appear correctly.

Ah, now I get it. I didn't notice those words in ShotData lines.

Upd: heh, mkm fixed the issue with paths and now some of them which were implemented using wrong syntax don't work

[KuroArashi100]

Asking another question, though this one might not have all that much to do with Danmakufu.
Like I said before, I am trying to create my own shotsheet, but the spinning bullets (Bubbles etc.) always appear to shake in game because they seem to be off-center.
I tried using photoshop's align with center option, but this still happens, even though I'm pretty sure my bullet should be symmetrical.


Does anyone know a solution for this?

[Helepolis]

Asking another question, though this one might not have all that much to do with Danmakufu.
Like I said before, I am trying to create my own shotsheet, but the spinning bullets (Bubbles etc.) always appear to shake in game because they seem to be off-center.
I tried using photoshop's align with center option, but this still happens, even though I'm pretty sure my bullet should be symmetrical.


Does anyone know a solution for this?

There is an ancient thread regarding this, forgot where but it seems to be that Danmakufu likes to off-centre bullets, even if you set perfect rects. It has something to do with the angular movement and drawing (?).

I think having shotsheet in square size reduces this problem someone said in that ancient thread (256x256/512x512) but I have still some off-centre bullets in my shotsheet.

[KuroArashi100]

There is an ancient thread regarding this, forgot where but it seems to be that Danmakufu likes to off-centre bullets, even if you set perfect rects. It has something to do with the angular movement and drawing (?).

I think having shotsheet in square size reduces this problem someone said in that ancient thread (256x256/512x512) but I have still some off-centre bullets in my shotsheet.

So there is no real solution?
Because it happened before, I tried using one image only as shotsheet (64x64) but that ends up like this.
And that is a squared image. But if I understand correctly, Danmakufu is the culprit, not the image itself?

[Necrotek]

KuroArashi, could you share that sample script from your video?

[Helepolis]

So there is no real solution?
Because it happened before, I tried using one image only as shotsheet (64x64) but that ends up like this.
And that is a squared image. But if I understand correctly, Danmakufu is the culprit, not the image itself?

Unfortunately it is danmakufu's fault. Everybody has exactly the same problem.

Even if I spawn a single bullet/sprite with a power of 2 size, danmakufu will put it off-centre for an unknown reason. Afaik there is no solution but to fiddle with the rect like decreasing a pixel one one side or adding one:  Rect(1,0,64,64); / Rect(0,0,63,64);  etc until it spins smoothly.

Quite frustrating, unless someone knows a solid solution.

[ExPorygon]

I know of a solution that seems to work reliably but I'm not quite sure. Using a 64x64 bullet as a reference, what you want to do is to use an image editor to decrease the size of it to 63x63. Then you want to use a (0,0,63,63) rect instead. That's worked for all of the bullets I've tried it on so far.

[KuroArashi100]

Too bad there is no easy solution.
I tried messing around with the rect for a while, and I can't make it stop shaking, I only make it worse.
Gotta keep trying I guess :V

@Ozzy
That doesn't seem to work on my bullets. I tried it multiple times, from multiple corners, but that doesn't seem to solve the problem.

@Vectorfish
I have no idea what you want with it, the problem doesn't have anything to do with that as far as I know.
But here it is anyway: Pastebin

[Necrotek]

I just want to check some possible solutions but I'm lazy to write that test script myself
Upd: hm, something is missing, just invisible bullet in the center of the screen. Oh, well.

[KuroArashi100]

Well, yes. The shotsheet is missing.
The "bullet" in the middle is the boss...
You need to put these two attachments in the same folder for it to work.

[Necrotek]

Ok, not sure if I got the point of the problem correctly and this is what you're looking for. Just as I thought, the problem is that the image uses even number of pixels. Because of that, there is no pixel which could be used as a symmetric center for rotation and because of that the movement is shaky. If you change bullet image to be odd pixeled and set rectangle for it the same way, it won't shake.

[KuroArashi100]

Thank you very much, that is indeed what I'm looking for.
Out of curiosity, what exactly did you change in the image?
It still is 64x64, so I don't completely understand what you mean with odd-pixeled.