by Nash » Mon Oct 14, 2019 6:26 am
Hmmm, after some thinking, in my opinion, the wrapping should be handled by the scripter. Doesn't seem like the engine's business to be dealing with these problems. You can get a sound's length in ZScript with S_GetLength, the user has everything they need to ensure their scripts behave well.
More stylistically, the way you apply the default parameter value for startTime in the sound classes don't look right. It should be applied to the base declaration, what the calling code will "see". It's pretty useless on the implementation definition since callers won't be aware of it when calling the function. I think some compilers will actually warn about this.
I'm lost here. I don't really know what I'm doing here, if I'm being completely honest.
Can you be very specific? I don't know which one is the base function. Also the fact that these sound functions are overloaded all over the place made it even more confusing for someone inexperienced like me.
Other than that, as far as GZDoom itself is concerned I'm still not sure how to deal with the fact that sounds can be modded and their length/timing changed, throwing off any kind of scripted offset. At best it could just apply a relative offset to a previously retrieved one, like your radio example, but beyond that it starts falling apart. Other people who are more acquainted with modding these kinds of things would have to speak on how that is usually handled.
I think this should be handled by the modder. This isn't the only case where scripting can get data from assets - remember, you can get texture and sprite dimensions too, and this is all freely accessible in scripting. Those textures can be easily replaced and stuff starts to get unpredictable. Whatever will happen here won't be something new to the engine. In my opinion, I think it's fine to leave this issue as-is...
Hmmm, after some thinking, in my opinion, the wrapping should be handled by the scripter. Doesn't seem like the engine's business to be dealing with these problems. You can get a sound's length in ZScript with S_GetLength, the user has everything they need to ensure their scripts behave well.
[quote]
More stylistically, the way you apply the default parameter value for startTime in the sound classes don't look right. It should be applied to the base declaration, what the calling code will "see". It's pretty useless on the implementation definition since callers won't be aware of it when calling the function. I think some compilers will actually warn about this.
[/quote]
I'm lost here. I don't really know what I'm doing here, if I'm being completely honest. :lol: Can you be very specific? I don't know which one is the base function. Also the fact that these sound functions are overloaded all over the place made it even more confusing for someone inexperienced like me.
[quote]
Other than that, as far as GZDoom itself is concerned I'm still not sure how to deal with the fact that sounds can be modded and their length/timing changed, throwing off any kind of scripted offset. At best it could just apply a relative offset to a previously retrieved one, like your radio example, but beyond that it starts falling apart. Other people who are more acquainted with modding these kinds of things would have to speak on how that is usually handled.
[/quote]
I think this should be handled by the modder. This isn't the only case where scripting can get data from assets - remember, you can get texture and sprite dimensions too, and this is all freely accessible in scripting. Those textures can be easily replaced and stuff starts to get unpredictable. Whatever will happen here won't be something new to the engine. In my opinion, I think it's fine to leave this issue as-is...