[TOTEM ARTS - DONUTS?]

Possibly temporarily intended to influence SEO ranking.

@Cronus ?

[What kind of music do you hear?]

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

[SEO new domains]

On 5/20/2022 at 6:06 PM, Cronus said:

Yes we are working on SEO, thanks for that.  Check the downloads now, how does it look?

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

Spoiler

Yes 15% guesstimate. I think it may be so significant because visitors have already been through Renegade-X.com and found nothing but drama there, literally suggesting that the project is dead. Then on second search attempt ("double-checking") they arrive at the previous empty-looking Downloads page with no logo in sight, and this again confirms the suspicion. It's double-trouble.

But because of your changes now, such a suspicion would be instantly debunked and these prospects are retained.

[SEO new domains]

On 5/14/2022 at 4:30 PM, roweboat said:

All the downloads are here actually, but it is a bit obtuse I agree.

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.

Spoiler

To me, it's a fun fact to know that only the fovea of the human eye registers detail.

What I've learned during my psychology education is that the "complete picture" that you see lives almost entirely in memory.
Your eyes make very quick (almost undetectable) and continuous twitches to keep this memory "up to date" by aligning the fovea.

While the rods offer unrecognizably vague contrasts yet are absolutely excellent at detecting movement,
the cones in the fovea you have to really scan your environment with to actually be able to see stuff.

You can try it out by attempting to hold your eyes still while having some kind of symbols in your lateral vision that you have never seen before.
Be aware that your eyes can twitch so fast that it is easy to "cheat", but nevertheless my proposition here being that you won't be able to read it.

And if we *would* really want to find out just how dramatic this effect is for our web page here then one could start an A/B test and serve different pages 50/50 to record its impact on the continuation of the user session.

tl:dr:
People gonna miss it lol.

[Possible solution: x64 audio bug]

17 hours ago, roweboat said:

to be honest, this is all Greek to me, but if it fixes the problems and more people want to play the game. awesome =D

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. ^^

[SEO new domains]

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.

[Possible solution: x64 audio bug]

1 hour ago, roweboat said:

to be honest, this is all Greek to me, but if it fixes the problems and more people want to play the game. awesome =D

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.

[Possible solution: x64 audio bug]

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

Spoiler

Look, I'll explain.

During travel a destroy function is called inside the AudioComponent.
This will neately cleanup the audio first, and then mark this component for kill by GC.

So, it *was* the intention to design UE3 in such a way that you can't accidentally deallocate a live audio stream before first cleaning it up through a destroy function.

Sound bug arises because bAutoDestroy does not actually call a destroy function under the hood.
Rather it directly marks the component for kill by GC without cleaning up through destroy first.

IF there is no audio playing, which they have attempted to make sure through syntax, this is not a problem.
bAutoDestroy has been designed in such a way that it is only applied during Stop or ResetToDefaults. (the latter already calls Stop internally)

But Epic forgot one thing.. Delegates.
Delegates that might just start Playing a new audio stream.

So here we had Stopped the MusicComp and had it marked for kill with bAutoDestroy.
But then the OnAudioFinished delegate called into our MusicPlayerOnAudioFinished and started a new Play because we have failed to set bStopped to true.

Guess what happens when GC now comes around for its periodic sweep, midtravel after all Actors were destructed??
Right! It's totally going to deallocate a live audio stream.

And if I were an audio subsystem or XAudio2 interface, I'd go kaboom at this point.
Would you not?

@Handepsilon @SonnyX @NodSaibot

[What kind of music do you hear?]

.

[How To Use Keybindings! [Tutorial] [Command Powers] [Console Commands]]

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.

[Possible solution: x64 audio bug]

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.

Spoiler

Like, adapting in PlayerController / Rx_Controller:

Old:
/** forces GC at the end of the tick on the client */
reliable client event ClientForceGarbageCollection()
{
    WorldInfo.ForceGarbageCollection();
}

New:
/** forces GC at the end of the tick on the client */
reliable client event ClientForceGarbageCollection(optional bool FullPurge = FALSE)
{
    WorldInfo.ForceGarbageCollection(FullPurge);
}

And then not forgetting (!) to also change the call from ProcessClientTravel in GameInfo / Rx_Game:
from P.ForceGarbageCollection() to P.ForceGarbageCollection(TRUE).

[Possible solution: x64 audio bug]

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.

[Consolidated Soundbug Topic]

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.

[Renegade X: Patch 5.61.245 Patch Notes]

On 2/20/2022 at 7:34 AM, AshbyJones said:

After all these years you potentially hopefully might have fixed the sound bug?  Lolololol #blamethedevs

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

We try.

[How do you setup a server with friendly fire?]

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:

Spoiler

// Copyright 1998-2015 Epic Games, Inc. All Rights Reserved.
class UTMutator_FriendlyFire extends UTMutator;

var float FriendlyFireScale;

function bool MutatorIsAllowed()
{
    return UTTeamGame(WorldInfo.Game) != None && Super.MutatorIsAllowed();
}

function InitMutator(string Options, out string ErrorMessage)
{
    UTTeamGame(WorldInfo.Game).FriendlyFireScale = FriendlyFireScale;
    super.InitMutator(Options, ErrorMessage);
}

defaultproperties
{
    FriendlyFireScale=0.5
    GroupNames[0]="FRIENDLYFIRE"
}

 

[Consolidated Soundbug Topic]

On 2/20/2022 at 7:22 AM, AshbyJones said:

Wow is soundbug STILL a thing??  #blamethedevs

Hahah,
you try to fix it.

On 1/14/2021 at 3:46 AM, Dr_Chat said:

Reproduction
The soundbug is trivial to reproduce by changing the output audio device on the desktop.

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.

[FIX candidate: Repair gun visual bug]

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.

[FIX candidate: Repair gun visual bug]

4 hours ago, Handepsilon said:

Because it will affect all particle emitters on all weapons, and ChangeVisibility happens in more cases than just getting in and out of vehicle. For example, third/first person camera switch. This might cause problems where particle emitters do not get hidden when switching perspective, and not just the beam emitters from beam weapons.

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.

[FIX candidate: Repair gun visual bug]

5 hours ago, Handepsilon said:

Unfortunately I find some possible holes in the script you edited

Care to elaborate on that?
Does not killing the emitters and instead setting them to hidden introduce some sort of significant memory leak?

5 hours ago, Handepsilon said:

it did help with isolating the issue

That was my primary intention.
And simply put I just want this bug out of the way before FS.

5 hours ago, Handepsilon said:

Setting the particles to Kill on Deactivate solved the problem entirely

One of the many other possibilities to solve this problem, yes.
Even more perfect since the emitters are not retained.

Nice find!

[FIX candidate: Repair gun visual bug]

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.

[FIX candidate: Repair gun visual bug]

Just now, Handepsilon said:

Are you referring to the part where Repair Gun beam pops in despite not being fired? We haven't fixed that one at all

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.

[FIX candidate: Repair gun visual bug]

10 minutes ago, Handepsilon said:

You're *almost* right however. The prominent particle bug was related to Repair Gun sort of.

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

[FIX candidate: Repair gun visual bug]

Thank you both for clearing that up! 😄

[FIX candidate: Repair gun visual bug]

3 minutes ago, Handepsilon said:

EMP grenade's effect generation actually comes from its' projectile class,  not the weapon

Yeah that makes sense.
Different issue then.

[FIX candidate: Repair gun visual bug]

8 minutes ago, NodSaibot said:

How could repair guns/beam weapons cause EMP fields/grenades not to display their particles?

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