The "How do I..." Thread

[Blue Shadow]

Unfortunately, nobody answered by question about voxels...

Is there a limit to the number of voxels spawned? I've tried using voxel blood pools instead of sprite ones spawned by blood spurts in Beautiful Doom, and the game keeps crashing after killing about 30 monsters (or after trying to gib just one).

I tried your demo, and despite the horrible lag I experienced due to lots of blood being in my view, I didn't get any crashes (I'm using ZDoom 2.8pre-283).

---

[Endless123]

I wonder how i could do the following with SBARINFO

Do you want them to change color like this? (See here for a demo)

---

or to be on top of each other (overlayed) like this (notice the blue bar overlaying the green bar when over 100)? (See here for a demo)

---

I'd like it overlayed like in the second demo.

i'd like the bar to be red when health is between 1 and 100, blue between 101 and 200 and finally green between 201 and 300

Edit : Here what's happening with the codes i used(codes mentioned in a previous post)

---

At 100% health, here a screenshot of the the bar

(i want it to be red all the way not half way like this)

After i took a few hits


And finally with 300% health and armor

[Blue Shadow]

So, the demo I linked to didn't help you? Make sure to check the bar graphics as well, and not only the SBARINFO code. The overlay bar has in fact double the width of the "regular" bar.

I'll see if I can make another demo with 3 overlay bars later.

[Endless123]

So, the demo I linked to didn't help you? Make sure to check the bar graphics as well, and not only the SBARINFO code. The overlay bar has in fact double the width of the "regular" bar.

I'll see if I can make another demo with 3 overlay bars later.

I noticed 2 things about the demo.

1 - the size of the overlayed element is x2 longer than the normal one but with same height
2 = the location of the overlayed element is also different

so my question is ... why? is this necessary to have the overlayed element like that? if yes i guess it's the problem i have because all my elements for health and armor(normal and overlayed) are of the same size and at the same location in the HUD. Would be easy to solve it if i had simple shaped elements but i made curves in them and i guess i would mean one thing, i'll have to redo the elements without any curves if i want them to work.

EDIT : Problem solved i only had to add 300(for the first overlay bar) then 600(for the second overlay bar) to the normal high to make it works. I'm surprised it works without having to change the overlay bars location. At least it works now thanks to you I'll add you to the credits of my Predator mod GREAT THANKS

[Blue Shadow]

1 - the size of the overlayed element is x2 longer than the normal one but with same height

For the 101-200 bar, the width or height (it depends if the bar is to be displayed vertically or horizontally) of the bar graphic should be double the width or height of the normal bar(1-100). The same goes for the 201-300 bar, except it should be triple.

2 = the location of the overlayed element is also different

In that demo, I took an approach to change the x and y position in SBARINFO. If you want you can have all the bars in the same position and instead, play with the bar graphics' offset.

Here is a demo to make a vertical bar (like what you're trying to do here), which consists of 3 bars overlaying each other:

3_bars_v.zip

You'll notice that the x and y position of all the bars in SBARINFO is the same. And the bar graphics' offset is also the same. Being vertical makes a little different in how it's set up.


Edit: Oops! missed the edit.

[Endless123]

1 - the size of the overlayed element is x2 longer than the normal one but with same height

For the 101-200 bar, the width or height (it depends if the bar is to be displayed vertically or horizontally) of the bar graphic should be double the width or height of the normal bar(1-100). The same goes for the 201-300 bar, except it should be triple.

2 = the location of the overlayed element is also different

In that demo, I took an approach to change the x and y position in SBARINFO. If you want you can have all the bars in the same position and instead, play with the bar graphics' offset.

Here is a demo to make a vertical bar (like what you're trying to do here), which consists of 3 bars overlaying each other:

3_bars_v.zip

You'll notice that the x and y position of all the bars in SBARINFO is the same. And the bar graphics' offset is also the same. Being vertical makes a little different in how it's set up.


Edit: Oops! missed the edit.

Even if you missed my edited post above i'm sure those tips will be useful for anyone trying to do this (or something similar). Your explanations are clear and even a noob like me can do it with them.

On a side note, i downloaded the demo you posted, it's simple and well done at the same time and i'm sure anyone who'd like to create their own health/armor bars with multiple overlays would understand how to do it just by looking at the files in your demo.

Thanks again

[Jekyll Grim Payne]

I tried your demo, and despite the horrible lag I experienced due to lots of blood being in my view, I didn't get any crashes (I'm using ZDoom 2.8pre-283).

Sorry, should've mentioned I'm mostly using GZDoom, and it has been crashing with this for many versions. Now I think voxels are rendered somehow differently in it than in ZDoom.

[Blue Shadow]

I have GZDoom 1.9pre-406. I tried the WAD again, spawning and gibbing 30 zombies; no crashes.

---

Now I think voxels are rendered somehow differently in it than in ZDoom.

Voxels in GZDoom are converted into models, if I'm not mistaken.


Anyway, I think your best bet here is to report this issue here (if it's really a GZDoom-exclusive bug), providing the WAD and the crash report, so it can be investigated.

[Jekyll Grim Payne]

I have GZDoom 1.9pre-406. I tried the WAD again, spawning and gibbing 30 zombies; no crashes.

Voxels in GZDoom are converted into models, if I'm not mistaken.

Anyway, I think your best bet here is to report this issue here (if it's really a GZDoom-exclusive bug), providing the WAD and the crash report, so it can be investigated.

That's interesting. I tried it again, making sure I have a clean unmodified GZDoom; still crashes.
Yes, that's what I thought about voxels. Even stranger then.
I will report it.

[Leonard2]

void hudmessage (text; int type, int id, int color, fixed x, fixed y, fixed holdTime);

Anyone know what else could I use for color instead of predefined ones ?
It says "int color" so I don't know could we use something like #FF0000 ?
I need to calculate a color right before using hudmessage, is there any way I can use that color ?

[Gez]

Not really.

You can either use one of the predefined colors, or "you can also specify the color as a string (including custom colors defined in the text colors lump); if you do so you must also add HUDMSG_COLORSTRING to the type with a binary OR ( '|' )" as explained. There is, however, no concept of dynamic colors. If you're only going to use a limited range of colors (like a limited gradient of reds for example) you can get away with defining them all, putting their names in an array, and then computing the position in the array of the color you want. But if you want your colors to be in a large range or anywhere in RGB space, this approach is of course out of question.

[TheBadHustlex]

Good Evening (from europe's perspective).

I got a little problem while making a weapon.

The fire-state doesn't work properly. The bullets are supposed to spread. Instead, they go 100% exactly, with 0 spread.
Here's the code:

---

Fire:
TNT1 A 0 A_JumpIfInventory("UZILOADER",26,"Reloadit")
TNT1 A 0 A_GiveInventory("UZILOADER",1)
UZI1 B 2 A_FireBullets(1.0, 4.0, 1, 12, "BulletPuff")
UZI1 C 2 A_FireCustomMissile("UziCasing",50+random(0,8),0,0,0,0)
TNT1 A 0 A_FireCustomMissile("ShakeYourAssDouble",0,0,0)
UZI1 A 1
goto Ready

I have this problem with plenty of other weapons, too. Does someone know what I'm doing wrong?

[TheMightyHeracross]

Make "1" "-1" to never spread or add A_Refire on the last frame for Doom-like. (Tapping is accurate, holding has spread)

[Popsoap]

A_FireBullets is 100% accurate when the fire state is entered from the ready state. Because your weapon always goes to the ready state regardless if you are holding the fire button, its 100% accurate.

Try this...

Code: Select all

Fire:
TNT1 A 0 A_JumpIfInventory("UZILOADER",26,"Reloadit")
TNT1 A 0 A_GiveInventory("UZILOADER",1)
UZI1 B 2 A_FireBullets(1.0, 4.0, 1, 12, "BulletPuff")
UZI1 C 2 A_FireCustomMissile("UziCasing",50+random(0,8),0,0,0,0)
TNT1 A 0 A_FireCustomMissile("ShakeYourAssDouble",0,0,0)
UZI1 A 1
UZI1 A 0 A_ReFire
goto Ready

EDIT: God dammit Heracross, you ninja'd me.

[Leonard2]

Not really.

You can either use one of the predefined colors, or "you can also specify the color as a string (including custom colors defined in the text colors lump); if you do so you must also add HUDMSG_COLORSTRING to the type with a binary OR ( '|' )" as explained. There is, however, no concept of dynamic colors. If you're only going to use a limited range of colors (like a limited gradient of reds for example) you can get away with defining them all, putting their names in an array, and then computing the position in the array of the color you want. But if you want your colors to be in a large range or anywhere in RGB space, this approach is of course out of question.

OK thanks