This is a flexible port of the GlassBreak ACS function that can be called both from ZScript and from ACS (by using ScriptCall()) and allows customizing the sound, number of debris, debris speed, and using an actor for debris (if left unspecified, textured particles will be used).
This requires GZDoom 4.11 and will NOT work on earlier versions.
Full documentation and download here: https://github.com/jekyllgrim/ZSGlassBreak
Video:
ZScript GlassBreak()
Forum rules
Before posting your Resource, please make sure you can answer YES to any of the following questions:
Consult the Resource/Request Posting Guidelines for more information.
Please don't put requests here! They have their own forum --> here. Thank you!
Before posting your Resource, please make sure you can answer YES to any of the following questions:
- Is the resource ENTIRELY my own work?
- If no to the previous one, do I have permission from the original author?
- If no to the previous one, did I put a reasonable amount of work into the resource myself, such that the changes are noticeably different from the source that I could take credit for them?
Consult the Resource/Request Posting Guidelines for more information.
Please don't put requests here! They have their own forum --> here. Thank you!
-
- Global Moderator
- Posts: 1117
- Joined: Mon Jul 21, 2008 4:08 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia (Modern GZDoom)
-
- Posts: 537
- Joined: Wed Dec 22, 2021 7:02 pm
- Graphics Processor: Intel (Modern GZDoom)
- Location: Medellin, Colombia
Re: ZScript GlassBreak()
Very cool! Thanks for sharing.
Some ideas for you:
Instead of taking all those parameters on every break, put them into a configuration lump, like GLASSBRK:
Write a function to look up the details for a line based on it's mid texture and pass those into the parameters. Then the map can call that function instead of having to keep all that data itself. Much easier for the user. If they want to chang something they don't have to go change it manually on each line break call.
I noticed you itereate the lines manually. Do you not use LineIdIterator? I'm told it's faster because the search happens in the backend instead of the VM, but I've not tested that myself.
And a suggestion - instead of having a count of debris, have a debris density and let the function count the debris based on the line size. This is how I'm doing it on my breakables, my density is for every 16x16 block. So for example if I have something that is 32x64, it would have a debris field of 2x4 at density 1.0, 1x2 at 0.5, or 4x8 at 2.0, etc. Something 128x128 would have a debris field of 8x8 at density 1.0. That way I don't have to figure out the debris count for each item, I just set the debris density and let a function figure it out from there.
For random debris, you can allow multiple actors:
debrisactor=[debris1],[debris2],[debris3]
or have a randomized actor:
And something I haven't tried yet but just thought of - instead fo a single break sound, make each debris make a small break sound, with random pitch and delay. Then the break sound will sound "bigger" when there is a bigger break with more debris and smaller when there is less.
Some ideas for you:
Instead of taking all those parameters on every break, put them into a configuration lump, like GLASSBRK:
Code: Select all
glass [texture name]
{
brokentexture=[new texture name]
debriscount=[int]
debrisspeed=[int]
breaksound=[string]
debrisactor=[string]
}
I noticed you itereate the lines manually. Do you not use LineIdIterator? I'm told it's faster because the search happens in the backend instead of the VM, but I've not tested that myself.
And a suggestion - instead of having a count of debris, have a debris density and let the function count the debris based on the line size. This is how I'm doing it on my breakables, my density is for every 16x16 block. So for example if I have something that is 32x64, it would have a debris field of 2x4 at density 1.0, 1x2 at 0.5, or 4x8 at 2.0, etc. Something 128x128 would have a debris field of 8x8 at density 1.0. That way I don't have to figure out the debris count for each item, I just set the debris density and let a function figure it out from there.
For random debris, you can allow multiple actors:
debrisactor=[debris1],[debris2],[debris3]
or have a randomized actor:
Code: Select all
class fadingdebris : actor
{
int fadeouttics; property fadeouttics:fadeouttics;
default
{
debrisactor.fadeouttics 15;
}
states
{
spawn:
DBRS A 0 nodelay A_Jump(256,"debris1","debris2","debris3");
debris1:
DBRS B -1;
stop;
debris2:
DBRS C -1;
stop;
debris3:
DBRS D -1;
stop;
}
override void tick()
{
if (fadeouttics && pos.z<=floorz) //is the debris on the ground?
{
A_SetRenderStyle(0.+fadeouttics/default.fadeouttics, STYLE_Translucent);
fadeouttics--
if (fadeouttics <= 0) destroy();
}
super.tick();
}
}
-
- Posts: 59
- Joined: Wed Feb 03, 2016 1:45 pm
- Location: Sweden
Re: ZScript GlassBreak()
Any idea here how to get the glass shards to not suspend in the air if the window is destroyed and it's above ground somewhere?