Suspiria

Possibly temporarily intended to influence SEO ranking. @Cronus ?

This music vid is "Full-On" Goa Trance I'd recommend anyone who's into electronic music to visit such a festival once in their life It is beyond fun, especially if you like trance music and/or practice any form of spirituality

That looks amazing. Hopefully +15% new players this way.

When the website was just new, I myself literally thought I was on the wrong website before my mind further processed "Totem Arts". And if I didn't know Totem Arts I would've thought I was nowhere near the real deal. What you call "a bit obtuse", to me is something that simply does not register. tl:dr: People gonna miss it lol.

Also, the deeply technical explanations were really not ment for you, haha. They were ment for other developers. Many of which have little experience with systems level programming. (C++, Rust, Assembly) I wouldn't be surprised if only SonnyX and I are comfortable working with it. I use this thread to document the bug hunt. For education and curiosity's sake, but also in case of failure so that the next could pick up. But I absolutely appreciate your appreciation of my efforts and your ongoing eyes-and-ears support. To me this is fuel for the hunt. ^^

Don't know about you, but when I google "Renegade-X", it is a "Downloads - Totem Arts" page that pops up first. ("first" as in: after Renegade-X.com) Possibly, the vast majority of people from Google come in through this page. But when I click that, it actually links to https://totemarts.games/forums/files/ Which brings up a fruitless upload page. There's no intro, no product name that stands out. And nobody knows Totem Arts. I fear that a big bunch of these people will just.. be confused and find another game to play. People's attention span on the internet can definitely be that poor - I know this for a fact. Ask any web designer, entrepreneur or PM who has ever A/B tested. So, this community's churn rate was problematic enough already, but now with the brand domain hijacked and SEO still in recovery there's now also less new players coming in. I know it's not the end of the world, but personally I don't like it. Especially since this new website's product presentation pages are absolutely brilliant IMO. Love it. What I'd like to suggest is to implement a (temporary) smart redirect on that files upload page, to point to the page that actually "sells", which is: https://totemarts.games/games/renegade-x/ This redirect function should detect if the visitor comes cleanly from Google. (= redirect them) Or, if they consciously navigated to that page through the website. (= serve the file upload page) For the time being until SEO further improves.

Have not fixed anything yet so I'm still eating some humble pie here. But I fully intend for this bug to go down before Firestorm. I've learned in life that sometimes you just have to stick to your guns and eventually you'll get it. Albert Einstein said: "It's not that I'm so smart, it's just that I stay with problems longer." and I guess we're gonna find out if that's true.

Ooh sweet jesus, I may have found the true culprit on the deeper level, within code. Look at this! So inside Rx_HUD.uc we set WorldInfo.MusicComp to JukeBox.MusicComp during PostBeginPlay. We then set the WorldInfo.MusicComp.OnAudioFinished delegate to MusicPlayerOnAudioFinished so that it runs the rest of the playlist. So far so good. So, Rx_HUD also implements a Destroyed() event which is called during mapchange. Destroyed() calls ResetToDefaults() which resets all properties. But delegates are not properties. So the delegate is still set. And - here comes the sound bug - Rx_JukeBox's bStopped has not been set to true. Because Rx_HUD's Destroyed function is calling Stop() directly on MusicComp instead of on Rx_JukeBox. Guess what happens after we call Stop while the bAutoDestroy flag is set?? ... I highly recommend we change this line within Rx_HUD's Destroyed() event: JukeBox.MusicComp.Stop(); to this: JukeBox.Stop(); ASAP @Handepsilon @SonnyX @NodSaibot

.

QuickSupport is good. You can also daisy-chain that into fully executing the ability with a single button-press or some other personalized way. For example: SetBind V "QuickSupport 5 | onrelease Spotting" SetBind B "QuickSupport 6 | onrelease Spotting" SetBind G "QuickSupport 1 | onrelease Spotting" SetBind H "QuickSupport 2 | onrelease Spotting" SetBind J "QuickSupport 3 | Spotting | OnRelease ReportSpotted" SetBind K "QuickSupport 4 | Spotting | OnRelease ReportSpotted" Here I have EMP and Cruise firing immediately after pressing and holding J and K. But if I quick-press, it will only give me the target reticule and I can execute manually with Q. Radar, smoke and buffs will only fire once I release their buttons V, B, G and H. So with a quick-press they will execute right away, thus aiming must have been done beforehand. But if I keep holding the button, that will postpone its execution, which I can also still cancel out of with E. Another setup that I'll be experimenting with is using the SHIFT button together with the numericals. For this, you do have to go into the UDKInput.ini file because of the SHIFT addition: Bindings=(Name="one",Command="QuickSupport 1 | onrelease Spotting",Control=False,Shift=TRUE,Alt=False,bIgnoreCtrl=False,bIgnoreShift=False,bIgnoreAlt=False) Bindings=(Name="two",Command="QuickSupport 2 | onrelease Spotting",Control=False,Shift=TRUE,Alt=False,bIgnoreCtrl=False,bIgnoreShift=False,bIgnoreAlt=False) Bindings=(Name="three",Command="QuickSupport 3 | Spotting | OnRelease ReportSpotted",Control=False,Shift=TRUE,Alt=False,bIgnoreCtrl=False,bIgnoreShift=False,bIgnoreAlt=False) Bindings=(Name="four",Command="QuickSupport 4 | Spotting | OnRelease ReportSpotted",Control=False,Shift=TRUE,Alt=False,bIgnoreCtrl=False,bIgnoreShift=False,bIgnoreAlt=False) Bindings=(Name="five",Command="QuickSupport 5 | onrelease Spotting",Control=False,Shift=TRUE,Alt=False,bIgnoreCtrl=False,bIgnoreShift=False,bIgnoreAlt=False) Bindings=(Name="six",Command="QuickSupport 6 | onrelease Spotting",Control=False,Shift=TRUE,Alt=False,bIgnoreCtrl=False,bIgnoreShift=False,bIgnoreAlt=False) Same execution as the other setup, but now bound to SHIFT+1, SHIFT+2, SHIFT+3, SHIFT+4, SHIFT+5, SHIFT+6. Benefit being that you can keep some fingers on WSAD and you can very easily use commander stuff while sprinting. Drawback also being that I wouldn't recommend switching weapons 1-6 while sprinting. Thanks for kicking off the topic, RealLegendaryJ. Perhaps once there is consensus for a certain setup, something could get implemented officially one day.

By the way, the second part of this candidate would be to switch to WorldInfo.ForceGarbageCollection(TRUE). I didn't include it in the original post, but it's, like, the other half of this equation and may be more effective. So far I've heard of two people who claim they still encountered this sound bug within the last two weeks. Once there is a third report, I think it may be a good time to consider switching to full purge in the next patch.

After two months since its discovery, my latest fix-candidate is now LIVE. This will be our third attempt since the beginning of 2019. (I can't speak for the developers before me) To anyone reading this: Please report if you still encounter this sound crash on map change a.k.a. "the sound bug". Also, kindly refrain from reporting issues with sound here that do not occur on map change. (please create a new topic for that) Thank you!! 🥰 And thanks everyone #DEV and #TestTeam for all the support and testing. Wouldn't have made it to this #3 without you.

After two months since its discovery, my latest fix-candidate is now LIVE. This will be our third attempt since the beginning of 2019. (I can't speak for the developers before me) To anyone reading this: Please report if you still encounter this sound crash on map change a.k.a. "the sound bug". Also, kindly refrain from reporting issues with sound here that do not occur on map change. (please create a new topic for that) Thank you!! 🥰 And thanks everyone #DEV and #TestTeam for all the support and testing. Wouldn't have made it to this #3 without you.

You have an.. interesting way of complimenting people, Ashby. 🤣 Thanks! We try.

Add to your command line URL: ?Mutator=UTGame.UTMutator_FriendlyFire This will give you some decent friendly fire by default. And if you want to change the amount, you'll have to compile your own mutator. Here's the original UTMutator_FriendlyFire.uc:

Hahah, you try to fix it. Sounds like "a way to break sound". I bet you that the issue you're introducing by switching your sound device is not the "sound bug on mapchange" bug. Sound bug on map change bug has specific qualities such as Reivax describes, Since this topic has been bumped by Ashby, I will repeat one more time what many if not all SB-sufferers have reported: - sound often goes out with a little "pop" - when you alt-tab to Windows and check your mixer you see that the volume bar of the RenX-specific slider is solidly green up to the set volume. (not to the max possible) - all your other sound is somewhat distorted and reduced until you close UDK So again, the issue that you're "reproducing" is probably just one of the many ways to break XAudio2 which is known to be a somewhat "sensitive" system. Also FYI, I am unable to introduce your issue by switching sound devices in Windows. Sound remains perfectly. 😉 Thanks for trying though! A new and somewhat more educated fix attempt has been on its way and will be rolled out next patch.

Now, would you happen to know who wrote ResetRepGunEmitters()? So that I could @mention them in this topic. If they're still part of this community, that is.

I can see how it may well have introduced some new issue. That's why fix candidates are semi-professionally tested before being included. Nice catch! That being said, the purely graphical side of things have never been my specialty per se. So you now did the necessary next step in this process. Good! And in the same way I could ofcourse see traces here and there of people who tried before me. Who's attempts pointed me in the right direction a bit.🙂 I've simply continued on that path with you, and arrived at what should be its final destination. Soon, this bug will be no more. And I hope that will serve this community.

Care to elaborate on that? Does not killing the emitters and instead setting them to hidden introduce some sort of significant memory leak? That was my primary intention. And simply put I just want this bug out of the way before FS. One of the many other possibilities to solve this problem, yes. Even more perfect since the emitters are not retained. Nice find!

From the looks of it there's been several attempts in the past to fix it, but it has become a bit ugly (using Tick and all) and doesn't fix the issue completely.

Yes! The age old bug. 🙂 It occurs on vehicle exit in first person, after one has first fired their repair gun with both fire modes within that game.

I think I may still be right in regards to the repair gun issue. Because: right now since patch rollout the repair gun bug is still there Rx_Weapon's ChangeVisibility code sets the ParticleSystemComponents to visible (which descend from Primitive; this is why it was easy to overlook) when only the weapon itself was intended to be

Thank you both for clearing that up! 😄

Yeah that makes sense. Different issue then.

Because EMP grenades extend from Rx_Weapon and the particle bug is inside of there.