View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0002389 | Spring engine | General | public | 2011-03-27 07:46 | 2011-11-24 16:09 | ||||
Reporter | user744 | ||||||||
Assigned To | jK | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | 0.82.7.1 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0002389: several unit reply sounds are played at same time, producing noise/echo | ||||||||
Description | If you quickly click a unit multiple times its reply sound plays multiple times. Also happens if you give alot of orders in short time. This only allows the use of really short samples like "yea" or engine sounds. But something like "mega tank ready for mega battle, prepare for mega attack" will just become distorted noise/echo because the last reply is still playing when a new sound starts. This makes the unit reply system basically useless. I think instant of playing several unit replies at the same time, only one reply start ever play at the same time. ie by stopping the previous sound if a new one starts. Also the "ok" sound plays on all kind of commands: move, stop, attack, wait, toggle move start,... It would be nice to have a bit more controll, at least: ok_move (for move, patrol, guard, fight,...) ok_attack (for direct attack orders) ok_build (for construction units, when giving a build order) and ok_others for all the rest. (state toggles, wait,...) Lua can play all kind of sounds but imo this is such a basic feature of an RTS engine that it is worth fixing (or documentated if all the above is already possible) | ||||||||
Additional Information | http://springrts.com/phpbb/viewtopic.php?f=14&p=479054 http://answers.springlobby.info/questions/585/unit-reply-sounds-without-echo I'd be glad to know if there are plans to fix that or not that I know if I should make a sound-widget like zeroK already does. | ||||||||
Tags | No tags attached. | ||||||||
Checked infolog.txt for Errors | |||||||||
Attached Files |
|
![]() |
|
2011-11-24 13:52 |
was working nicely in 83.0 but in 84.0 it is back to the old multiple-sounds-at-once-drone. In 83.0 it was quite good except that unitreply sounds played in 3d. I think unitselection voices and such are more "interface" than "gamesound" and as such should always play with the same volume and in mono/front? |
jK (developer) 2011-11-24 14:20 |
widget fault, uses wrong channel (you couldn't select a channel in 0.82, now you can) |
2011-11-24 14:35 |
I do not mean the "unit voices" widget of zK or any other widget. I mean these unit sounds: http://springrts.com/wiki/Units-UnitDefs#sounds played by the engine. BA: select commander, click him very fast: the sound plays multiple times. if you are missing the ubermicro to click fast enough: select unit, hold down w(wait) or s (stop) |
2011-11-24 14:38 |
"painting" long paths with the "custom formation" widget will also cause a lot of noise by multiple sounds playing. In 83.0 only one unitsound ever plays at the same time. |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2011-03-27 07:46 |
|
New Issue | |
2011-08-25 19:28 | jK | Status | new => resolved |
2011-08-25 19:28 | jK | Resolution | open => fixed |
2011-08-25 19:28 | jK | Assigned To | => jK |
2011-11-24 13:52 |
|
Note Added: 0007671 | |
2011-11-24 13:52 |
|
Status | resolved => feedback |
2011-11-24 13:52 |
|
Resolution | fixed => reopened |
2011-11-24 14:20 | jK | Note Added: 0007673 | |
2011-11-24 14:20 | jK | Status | feedback => resolved |
2011-11-24 14:20 | jK | Resolution | reopened => no change required |
2011-11-24 14:35 |
|
Note Added: 0007674 | |
2011-11-24 14:35 |
|
Status | resolved => feedback |
2011-11-24 14:35 |
|
Resolution | no change required => reopened |
2011-11-24 14:38 |
|
Note Added: 0007675 | |
2011-11-24 16:09 | jK | Status | feedback => resolved |
2011-11-24 16:09 | jK | Resolution | reopened => fixed |