DC Ending Silence
#1 Posted 26 February 2019 - 12:28 AM
I originally reported this thinking this was an issue with the HRP (as I used its music pack) but it turns out that is not true.
For whatever reason, the DC ending is completely silent, save for a about a second's worth of the wind sfx. I can't report any version of eduke where this problem started, as I don't believe I've ever seen it work since I returned to the Duke scene in 2013, when Megaton came out. Obviously I am using the Megaton's version of the DC GRP, but I've not heard anyone report this problem before. I've even opened mine up in GRP studio and the ending sound file is still present and working fine when extracted.
I just don't know what's happened, and this issue persists even today.
#4 Posted 13 April 2020 - 09:42 AM
There are now also problems with the normal E3 ending, but I decided the issue was separate enough to warrant its own topic as the versions these problems started in are different (the revision I used for the initial report here was r6428.)
#5 Posted 18 April 2020 - 09:56 AM
#6 Posted 19 April 2020 - 08:06 PM
#7 Posted 22 April 2020 - 09:59 PM
Definitely being pointed to the vanilla ending for reasons unknown.
This post has been edited by Ninety-Six: 22 April 2020 - 09:59 PM
#9 Posted 23 April 2020 - 02:40 AM
Thank you.
#10 Posted 23 April 2020 - 02:50 AM
Ninety-Six, on 23 April 2020 - 02:40 AM, said:
Sometimes people don't know better and don't complain about shortcomings.
Many people just skip the animation.
Most people don't care.
And sometimes you are just unlucky, indeed. I once hunted down a minor typo in DUKEPLUS.CON which made EDuke32 crash on my machine exclusively.
#11 Posted 23 April 2020 - 03:02 AM
LeoD, on 23 April 2020 - 02:50 AM, said:
I've faced that quite a few times. Computers can be weird. Still, a completely different computer with nothing carried over...Hardly impossible, but man that would have sucked.
Regardless, you're doing great work tracking down where these errors come from. Me, I'm just a guy that plays Duke maybe a little too much (Full playthrough + expansions + select mods 2-3 times a year), so I notice the little things more. You, you're doing the down-and-dirty work of digging through years' worth of revisions. And especially on this one, going back that far, I probably would have just given up and assumed "double unlucky" long before I got anywhere close to the revision this started in.
This post has been edited by Ninety-Six: 23 April 2020 - 03:03 AM
#12 Posted 24 April 2020 - 08:11 AM
LeoD, on 23 April 2020 - 02:50 AM, said:
Sometimes people don't know better and don't complain about shortcomings.
Many people just skip the animation.
Most people don't care.
And there are people like me who have many little things to report, but don't dare to create many new threads to not look like a spammer... Should I create one thread each time?
#13 Posted 24 April 2020 - 08:17 AM
Darkus, on 24 April 2020 - 08:11 AM, said:
I was worried about that too. In fact that was one of the reasons I kept quiet on all my issues so long, and just kept to the last stable version I knew of (r6428). But once my harddrive failed and I had to set up shop somewhere else, and saw that there were even more, I decided screw it and just threw in every single one I could find.
Ironically that made me look even more like a spammer but eh, sod it. I like the lack of SoS warping in the new versions, and really just want to see eduke run my favorite game at full power now.
This post has been edited by Ninety-Six: 24 April 2020 - 08:18 AM
#14 Posted 24 April 2020 - 08:46 AM
Darkus, on 24 April 2020 - 08:11 AM, said:
Try to find a title that helps searches once the thread has been "scrolled off" the first page of this forum. Add some final post when the issue is solved. Editing the thread's title to [Fixed] still ain't possible for non-moderators, unfortunately. Or ask a moderator to do that for you to prevent "closed" threads from bouncing back to the top.
You could also put things directly on Voidpoint's tracker, but I think that going here first is better in most cases. Other users might add some valuable information once someone else confirms their own experiences...
I know it can be an annoying and tedious work to turn one's local findings into a publication-ready report. But at least during these days I feel motivated to review the entries from my numerous raw issue lists (local, forums, Flyspray, ...) and put them on the new tracker in silver-platter-style, one by one. It would be nice if I wasn't the only one to do so...
Ninety-Six, on 24 April 2020 - 08:17 AM, said:
This post has been edited by LeoD: 24 April 2020 - 08:52 AM
#15 Posted 24 April 2020 - 09:10 AM
LeoD, on 24 April 2020 - 08:46 AM, said:
Prior to the SoS fix, it was the small things: the silence of the Shrapnel City ending (discovered that while doing a stream for my friends and had to hastily go back to the 6428 build that I kept around because of the polymost problems I'd been having), the problems with the keypad (because I use an abnormal control scheme for the sake of my wrists)... After the SoS fix, there were the inevitable severe issues as a result, so I had to wait for those to pass, and by the time they did there were other problems, plus the aforementioned polymost shenanigans, and it just seemed easier to stick to what I had already been doing with 6428, sans packed-in builds like Alien Armageddon.
Of course now that I'm dumping all those reports I'm realizing that 6428 was buggier than I thought. In addition to the very severe SoS issues, DC's ending was still silent back then, autoaim was broken (I know I'm like the only one who uses it and I probably will until the sprite collision stuff is fully fixed, if that ever comes but I understand they're working on it?), there was another revelation recently but I can't remember which one now...
Point is, lesson learned. I'll just keep reporting them as I find them so I don't have to dump out 6 threads in 2 days.
This post has been edited by Ninety-Six: 24 April 2020 - 09:11 AM
#16 Posted 30 May 2020 - 12:16 PM
Quote
CINEOV3.ANM is however just a black screen with no animation whatsoever, and ends within a span of 3 seconds.
What broke here is that, in older versions of eduke32 and DOS Duke3D, the sound that is intended to play in the cutscene beforehand would carry over into the next, but this no longer occurs since that commit. All sound from the previous cutscene is instead immediately interrupted or prevented from playing entirely.
See this video (https://www.youtube....h?v=oCutcubcsRc) for comparison. Notice how the "squish" sound effect and explosion of CINEOV3.ANM (quite unfittingly so) still play during the animation of RADLOGO.ANM.
Why did they do this instead of using the sound defined for RADLOGO.ANM? Probably because from what I tested, the sound in RADLOGO only triggers towards the very end of the cutscene, even if you replace it with a file that is much larger in size.
So what we are dealing with here is a master-class hackjob to get the ending of DUKEDC working without having to alter the engine code.
#18 Posted 24 October 2020 - 12:13 PM
#20 Posted 01 December 2022 - 10:40 AM
The following def code will approximately play the sound at the right time:
animsounds cineov3 { 1 289 }
animsounds radlogo { 141 30 }
The first line mutes sound for the placeholder cutscene that is skipped after one frame, the second one starts playing dukedc.voc at frame 141 of radlogo.anm, which more or less synchronizes it with the cutscene images.