Can't tell without seeing the PRI class. I've found it's better to use AlwaysKeep when assigning PRI too.
When you post code you need to put the entire class in if you want good help. You keep posting these really tiny snippets and there's no way to give good help with your questions. Obviously you are assigning the class to players but how are you doing it? Is this running in a mutator class? How is your PRI structured? What errors are you getting in compiling?
Part of your job as an asker of questions is to supply plenty of information. If you keep making it back-and-forth to get your answers people are going to stop answering. It's just too much trouble.
JackGriffin wrote:Can't tell without seeing the PRI class. I've found it's better to use AlwaysKeep when assigning PRI too.
When you post code you need to put the entire class in if you want good help. You keep posting these really tiny snippets and there's no way to give good help with your questions. Obviously you are assigning the class to players but how are you doing it? Is this running in a mutator class? How is your PRI structured? What errors are you getting in compiling?
Part of your job as an asker of questions is to supply plenty of information. If you keep making it back-and-forth to get your answers people are going to stop answering. It's just too much trouble.
Well the event PostLogin is written inside a GameInfo, usually... And I didn't write the actor that I want to spawn cause I thought it did the same thing to any actor, it's Rri anyway. That's the RRI class:
This is why you post everything when you have questions. Part of the problem is in what you didn't post.
You can't spawn branching PRI's on players, it must be a single chain. Your RRI subclasses ReplicationInfo and the player already has a PRI assigned to them. In order to make this work you'll need to create your PRI at the end of the chain. For most gametypes this would be PlayerReplicationInfo but it could be something else subclassing PlayerReplicationInfo since many gametypes carry their own PRI.
The same thing applies to other actor's replication chains. For example bots have their own chain, monsters in MonsterHunt have their own, gametypes have their own, etc.
BTW, preserving the PRI chain is the root of a lot of the conflicts in UT mods.
It's about PlayerReplicationInfo deal. Player might own more actors per session than you think: weapon, different controllers, some guardians, whatever Navig stuff, etc.
sektor2111 wrote:It's about PlayerReplicationInfo deal. Player might own more actors per session than you think: weapon, different controllers, some guardians, whatever Navig stuff, etc.
Yes but I think no anyone here understood that I'm talking about a RRI and not a PRI.
Plus, I don't rly want to replace the PlayerReplicationInfo with the RacerReplicationInfo, I want the player to own 2 replicated actors :/
SC]-[LONG_{HoF} wrote:I'm not quite sure what class you are trying to edit but from my experience post login is not a place to to try to declare a custom Replication class.
I have referenced this before and many mods tend to use.
//=============================================================================
// RacerReplicationInfoNotify
//=============================================================================
class RacerReplicationInfoNotify expands SpawnNotify;
simulated event Actor SpawnNotification( Actor A )
{
local RacerReplicationInfo RRI;
if( A == none )
return A;
if( !A.IsA( 'PlayerPawn' ) && !A.IsA( 'Bot' ) )
return A;
// Spawn Racer ReplicationInfo for this pawn on the server
RRI = Spawn( class' RacerReplicationInfo', A );
if( A.IsA('Bot') )
return A;
return A;
}
defaultproperties
{
ActorClass=Class'Engine.Pawn'
}
Hope this helps you.
I never knew about SpawnNotify actor o.o, Thank you ^-^ I'll try study how it works and I'll try it
And I swear... in 10 years scrolling throught the actors list, I NEVER noticed "ShareSounds" and "SpawnNotify" actors... O.O
"Your stuff is known to be buggy and unfinished/not properly tested"
You are too fixed in your ideas I as could see. WHAT happens if you were using other kind of actors owned normally ? A tragedy will happen or end of world ? Baby, there are more ways in Uscript toward a certain thing. I can do something able to transmit a message in player console very easy. It really needs RRI or XRI or TRI or XFartRI ? I was probing last time tiny things working properly as long as they are part of some package. If whatever thing from a map is messing with your RRI you'll be dissapointed to see stuff screwed. You can do custom stuff easy having internal variables and even guarding player against evilized habits.
Guys, you may be going down the wrong road here.
The reason why PRI was None simply is because it destroyed itself. And the reason for that is simply that "actor" was not set. PreBeginPlay() happens inside the Spawn() function and there's not much happening before it, particularly nothing that would have set "actor" to anything.
There's nothing wrong with using PostLogin to spawn some special ReplicationInfo for something, although I agree that there are much better places to spawn it. However, it's not a PRI (as it extends ReplicationInfo, not PlayerReplicationInfo), so other means are necessary to associate it with a particular player.
The term replication chain is probably not the best way of describing it. What I should have said was that only one RI sequence can be assigned to an actor so that there are no conflicts. I was using PRI as an example of this. If a mod extends PRI and creates it's own subclass of PRI and assigns that to the player then another mod loads that also assigns a custom PRI, then there will be conflicts since the actor needs a single PRI chain that goes back to default classes. That's what I meant with the term, but yeah it's not very good to use.
Notes: Tag is set post spawn, so new actor won't have it for it's own 'BeginPlay' events, Owner (and location, rotation) although does get passed and seen by said events.
Spawn returns none if the actor is destroyed at any stage of it's initialization, or if a SpawnNotify alters said result to none.
Wormbo wrote:Guys, you may be going down the wrong road here.
The reason why PRI was None simply is because it destroyed itself. And the reason for that is simply that "actor" was not set. PreBeginPlay() happens inside the Spawn() function and there's not much happening before it, particularly nothing that would have set "actor" to anything.
There's nothing wrong with using PostLogin to spawn some special ReplicationInfo for something, although I agree that there are much better places to spawn it. However, it's not a PRI (as it extends ReplicationInfo, not PlayerReplicationInfo), so other means are necessary to associate it with a particular player.
Notes: Tag is set post spawn, so new actor won't have it for it's own 'BeginPlay' events, Owner (and location, rotation) although does get passed and seen by said events.
Spawn returns none if the actor is destroyed at any stage of it's initialization, or if a SpawnNotify alters said result to none.
So, according to what other people said before, it's better if a Player owns only one ReplicatedActor, cause if not, there would be conflicts, so I guess it's better if I replace the PlayerReplicationInfo with a RacerReplicationInfo to every Player, right?
Anyway, I'm trying to fit a RacerReplication info to an ACTOR, and not just to a Player, for now I was able to give the RacerReplicationInfo to movers and all the pawns and whatever, and they could lap etc... the problem is just with the PlayerPawn.
"Your stuff is known to be buggy and unfinished/not properly tested"
Again, it's entirely irrelevant, how many actors (replicated or not) are owned by a player. Being owned is a property of the owned actor, not the owner.
What Higor wanted to point out is that Spawn()'s second parameter already is an actor that will be set as the spawned actor's Owner before PreBeginPlay() is called, at least on the server. In other words, you should use the Owner, not override it in PreBeginPlay().
Clientsidely, Owner will be replicated as a regular variable, so it will only become available starting with PostNetBeginPlay(). Then again, your PreBeginPlay() is not simulated (which is a good thing), so it won't execute on the client. Setting bGameRelevant=True may be a good idea for the RRI's defaultproperties, but really only prevents the GameInfo and mutators from receiving a CheckRelevance call from Actor.PreBeginPlay().