question concerning bStatic

[gopostal]

I had hoped to quickly throw together an online working version of the HD textures Lightning_Hunter made but like all things Uscript it's just never that easy.

I'm doing simple textural replacement checks via timer but I'm having issues with decorations that have bStatic in the default code. Here's what is occurring and I'm hoping someone can explain the 'why' part...

(This on online, I've just joined my coop server)....You spawn into Nyleve. In the first courtyard all the trees and plants are not texturally replaced (they should be). However if you drop over the side to the canyon below then all the same trees and plants *are* texturally replaced. These 'Tree5' classes are identical in every way except for location.

That got me researching bStatic. I can't find exactly what I need but I think it may be that actors with bStatic that are currently relevant to the player (close by) are 'locked' and can't be texture adjusted. Am I close on this? Thanks for any light you can shine on the problem. I just don't have the energy to spend all day testing to brute-force figure it out like I always have.

[Masterkent]

Static actors are usually not net-relevant (bAlwaysRelevant=True makes them net-relevant). A server doesn't replicate modified properties of a net-irrelevant actor to clients.

This can be demonstrated using the following console commands:

Code: Select all

admin set Tree Mesh BarrelM
admin set Tree bAlwaysRelevant True

Note that the modification becomes observable client-side only after execution of the second command.

[gopostal]

Thanks, that falls right in line with how I thought it went. If I can trouble you with a follow up?

I've just tried several methods of adjusting bAlwaysRelevant. I've tried adjusting it via mutator, I've even went so far as to manually edit the map (Nyleve) and set all the Tree5 to "bAlwaysRelevant=True". It still continues the behavior of properly skinning the trees away from the start but skipping the ones close by. Other actors without the bStatic setting are getting reskinned correctly. Can you take a stab at what I might be missing here?

[Masterkent]

Other actors without the bStatic setting are getting reskinned correctly.

I can imagine an opposite situation - when attempts to modify actors having default.bStatic == true && bStatic == false do not result in visible changes, while attempts to modify actors having bStatic == true do result in visible changes. Some map-fixing mods replace actors having default.bStatic == true && bStatic == false with aux actors that can be safely replicated to pre-227 clients (where an attempt to spawn a replicated actor having default.bStatic == true && bStatic == false results in immediate crash). A code that operates on the original actors may not affect the aux actors. Then you might need either disabling the replacement or using a more clean approach, such as defining the corresponding subclasses with default.bStatic == false.

Not sure what's going on in your case. More information is needed.

[gopostal]

I think you pretty much nailed it. To clear any doubts I created a simple box map filled with decorations. Some are bStatic, some not. I put this on the server and then ran my texture replacement mod.

It correctly replaced all actors that were not bStatic by default. I then recode my texture replacement mod and added:

Code: Select all

function SetUpRelevance()
{
      local Decoration DC;
      
      foreach AllActors(Class'Decoration',DC)
        {
              if ((DC.IsA('Tree'))       || (DC.IsA('Knife'))       || (DC.IsA('Plant1'))       || (DC.IsA('Plant2'))       ||
                   (DC.IsA('Plant3'))       || (DC.IsA('Plant4'))       || (DC.IsA('Plant5'))       || (DC.IsA('Plant6'))       ||
                   (DC.IsA('Plant7'))       || (DC.IsA('Boulder'))       || (DC.IsA('Sign1'))       || (DC.IsA('Flag2'))       ||
                   (DC.IsA('Flag3'))       || (DC.IsA('Lantern'))       || (DC.IsA('Lantern2')) || (DC.IsA('Lamp1'))       ||
                   (DC.IsA('Sconce'))       || (DC.IsA('Candle'))       || (DC.IsA('Candle2'))       || (DC.IsA('Robot')))
                          DC.bAlwaysRelevant = True;
        }
}

and called the function in post before texture replacement happens. This completely fixes the problem and all decorations are properly reskinned. Yay!

However if I load Nyleve it still retains this weirdness where only some trees are fixed. I think I'm going to chalk this one up to UGremlins and just run with this. Every other map I test on seems to be just fine. I hate that *the* default coop map is not working perfectly though. You knew it had to be that one if it was just going to be a single issue lol.

Thank you for your help MasterKent. I appreciate the guidance.

[Masterkent]

This completely fixes the problem and all decorations are properly reskinned.

Remember that a big number of simultaneously relevant actors may result in broken replication. If you can modify actors client-side (from simulated event functions), better do it client-side.

However if I load Nyleve it still retains this weirdness where only some trees are fixed.

I can't reproduce such an issue with console commands:

Code: Select all

summon ShieldBelt
admin set Decoration bAlwaysRelevant true
admin set Decoration bMeshEnviromap true
admin set Decoration Texture newred

All decorations are affected uniformly.

[gopostal]

Remember that a big number of simultaneously relevant actors may result in broken replication. If you can modify actors client-side (from simulated event functions), better do it client-side.

Roger that. I'll recode it this afternoon to make sure this does not happen.

I can't reproduce such an issue with console commands:

Code: Select all

summon ShieldBelt
admin set Decoration bAlwaysRelevant true
admin set Decoration bMeshEnviromap true
admin set Decoration Texture newred

All decorations are affected uniformly.

Same here. When I use the set command on server it works too. It just won't accept it if it comes from mutator, and only for the trees close to the start.

I even checked the map to make sure I hadn't gotten a messed up version on the server. Nope, it's default Nyleve.

Let me get this recoded properly and then I'll get some screenshots to show you the buggy behavior.

[[]KAOS[]Casey]

actors that are AlwaysRelevant probably should have some slow accumulation of changes over several ticks, in case there are a crap ton and they dont get effected like masterkent said. Anything else will become relevant when the player can see it, and the server will send it any information about it that is non-default

also note that anything that is bGameRelevant (projectiles only?) don't get effected by mutators. (see prebeginplay in actor.uc)

[Leo T_C_K]

I remember me many years ago figuring this stuff out, but I never posted about it on forums.

Mostly conversations with people who knew the engine well etc got me closer to understanding this.

So many years into future now I can barely remember it all on the spot, mostly because I learned to live with it.

The thing is this and const variables like collisionradius etc always made some troubles. Because setcollision cannot be used in all situations and everywhere, sometimes temporarily modifying engine.u etc was the only solution to resolve something so the mod would compile and then it would work, cuz it was all compiled and in "memory".

I know, a real programmer would shoot me for those incorrect terms, but when put into everyday language I wouldn't know how to say it simpler.

[gopostal]

In this particular case wouldn't it be 'good enough' to just run the above code since the deco actors will replicate their data once then go silent? It's going to be a large gulp of data at map load but by the time the players drop into it and initialize shouldn't the storm be over? I'm not trying to avoid a recode, I'm more asking as a way of understanding all this. I've always struggled with making this gel in my mind.

Thanks for the advice on the projectiles too Casey. I had that added into the mod but I'll remove it since it won't work.

When you say "slow accumulation of changes over several ticks" how would you do that so it slows that initial (potential) barrage of net traffic? Is this a situation where I would do a simulated tick and adjust a number of actors then wait for the next tick to do a few more?

[[]KAOS[]Casey]

Well it's tough, because you'd have to propagate those changes while the client is connected. It's not an easy fix. It's that or set all bStatic actors to bHidden clientside, and spawn replacements with the same drawscale/rotation with no collision and the new textures applied

[gopostal]

Yeah, I considered that route too but that's a ton of work on the server when the map sets up and creates too many potential spots where a replacement might break map flow or cause it to be unplayable/unfinishable or have some other undesired effect.

I've been running this on my coop server and it seems to do OK across multiple maps. There's the initial crunch where it all loads at map start but that's always that way because of mapvote. This isn't perfect code or a perfect way but at least it allows Lightning's impressive texture work to be used online (where it should be).

Thanks again for your guy's guidance on these things. I'll get this to LH for his approval by the weekend and formally post it as soon as he endorses it.