[SOLVED] Question about auto state and replication
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
[SOLVED] Question about auto state and replication
I have a class that in Spawn() it calls GotoState('TheState'), that state overwrites Tick(), the RemoteRole is set to None.
When a reference is spawned, it goes into TheState but Tick() is never called. Fact is that this doesn't happen if I set the state to be auto, if it's an auto state Tick() will be called normally.
What's the reason behind it?
When a reference is spawned, it goes into TheState but Tick() is never called. Fact is that this doesn't happen if I set the state to be auto, if it's an auto state Tick() will be called normally.
What's the reason behind it?
Last edited by PrinceOfFunky on Sun Nov 05, 2017 8:07 pm, edited 1 time in total.
"Your stuff is known to be buggy and unfinished/not properly tested"
Re: Question about auto state and replication
Show us the code, the state ALWAYS overrides the function no matter how you get there.
Learn more:
https://github.com/CacoFFF/SiegeIV-UT99 ... yerData.uc
Learn more:
https://github.com/CacoFFF/SiegeIV-UT99 ... yerData.uc
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: Question about auto state and replication
Well this is the code: It doesn't work in a dedicated server, I admit I put a custom variable to be checked in the replication block, I'm not sure if that's what is causing this lack of replication.Higor wrote:Show us the code, the state ALWAYS overrides the function no matter how you get there.
Learn more:
https://github.com/CacoFFF/SiegeIV-UT99 ... yerData.uc
Anyway about the auto sate, it's the one inside the class Particle.uc, the only state with the auto modifier. It works if auto, of course I removed the call GotoState() from Spawned(), just put it back in there and remove the auto modifier from the state, it won't work(at least yesterday).
p.s. I still didn't use that 'find local player' system with a state.
"Your stuff is known to be buggy and unfinished/not properly tested"
-
- Masterful
- Posts: 577
- Joined: Tue Jun 20, 2017 1:00 pm
- Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋
Re: Question about auto state and replication
Nah, the custom variable is fine, the vars will be replicated anyway at least once (bNetInitial in the condition).
Although if you have doubts, is just a matter of using classical debugging methods and comment it out for testing.
As for the state change, at least at a quick (sleepy) glance, there's nothing there which seems out of place, other than the overall checks in Spawned which cause the particle to destroy itself right away.
So right now I am not sure if this is just the particle destroying itself prematurely, hence running the code in the state when on auto in the first tick, but never running it with GotoState since state changes only occur in the following tick, at which case, if the particle is destroyed by then, nothing is called of course.
Is there a version of the class, with this GotoState added there, which you may share to check it out?
Although if you have doubts, is just a matter of using classical debugging methods and comment it out for testing.
As for the state change, at least at a quick (sleepy) glance, there's nothing there which seems out of place, other than the overall checks in Spawned which cause the particle to destroy itself right away.
So right now I am not sure if this is just the particle destroying itself prematurely, hence running the code in the state when on auto in the first tick, but never running it with GotoState since state changes only occur in the following tick, at which case, if the particle is destroyed by then, nothing is called of course.
Is there a version of the class, with this GotoState added there, which you may share to check it out?
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: Question about auto state and replication
nogardilaref wrote:Is there a version of the class, with this GotoState added there, which you may share to check it out?
Particles don't get destroyed cause I can see them in game, just in case I put a commented log right above the GotoState() I put in Spawned(), the state is not auto now and particles are stuck in mid air.nogardilaref wrote:So right now I am not sure if this is just the particle destroying itself prematurely
"Your stuff is known to be buggy and unfinished/not properly tested"
-
- Masterful
- Posts: 577
- Joined: Tue Jun 20, 2017 1:00 pm
- Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋
Re: Question about auto state and replication
So I assume you mean to say you actually see the log right before GotoState is called. Then in that case, GotoState is really called, however as I mentioned above, a state change is not immediate, it only happens in the next tick, which also means that until then the state can be changed multiple times in the same tick, but only the last change will prevail.
In other words, if something like this happens:
It won't ever go to the Resetting state, it will go to the SleepReset state instead.
So the only way to debug this and be sure on what's going on, is to log the current state in each tick, something like:
Although you have Tick already overwritten in one of the states, so you would need to do this in both that one and a global Tick implementation, but then the logs should become clear on what's going on. You should also limit the number of particles for this particular test, for obvious reasons.
In other words, if something like this happens:
Code: Select all
GotoState('Resetting');
GotoState('SleepReset');
So the only way to debug this and be sure on what's going on, is to log the current state in each tick, something like:
Code: Select all
event Tick(float DeltaTime)
{
Log("State(" $ Self $ ") = " $ GetStateName());
}
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: Question about auto state and replication
I put it in every possible Tick() inside the class, also I put logs to tell when it goes inside BeginStates and Setup(): But this is logs said:nogardilaref wrote:So the only way to debug this and be sure on what's going on, is to log the current state in each tick, something like:Although you have Tick already overwritten in one of the states, so you would need to do this in both that one and a global Tick implementation, but then the logs should become clear on what's going on. You should also limit the number of particles for this particular test, for obvious reasons.Code: Select all
event Tick(float DeltaTime) { Log("State(" $ Self $ ") = " $ GetStateName()); }
Code: Select all
ScriptLog: Resetting's BeginState() has been called.
ScriptLog: Resetting's Setup() has been called.
ScriptLog: StartPhysics's BeginState() has been called.
ScriptLog: [GLOBAL] State(Autoplay.Particle0) = Particle
"Your stuff is known to be buggy and unfinished/not properly tested"
-
- Masterful
- Posts: 577
- Joined: Tue Jun 20, 2017 1:00 pm
- Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋
Re: Question about auto state and replication
It seems that BeginState and EndState of each state are actually called immediately upon GotoState calls, however the actor might not assume the state right away (until it's ticked again, as mentioned above).
So that log seems to be only from the first tick alone.
Also, now I am actually unsure if it's really the last GotoState call that counts in the end, or the first. The events seem to tell it's the last one, but since the actor only actually assumes a specific state in the next tick, it's hard to say, which might actually explain your problem, and why it works with "auto" and doesn't without.
Essentially, if it's the first one that counts, with "auto" there's only 1 state change, from Resetting to StartPhysics, however without there are 2 state change calls, first from global to Resetting, and then from Resetting to StartPhysics, which is probably ending with the actor staying in Resetting.
Do you have more logs from the ticks which follow that one on the same particle?
So that log seems to be only from the first tick alone.
Also, now I am actually unsure if it's really the last GotoState call that counts in the end, or the first. The events seem to tell it's the last one, but since the actor only actually assumes a specific state in the next tick, it's hard to say, which might actually explain your problem, and why it works with "auto" and doesn't without.
Essentially, if it's the first one that counts, with "auto" there's only 1 state change, from Resetting to StartPhysics, however without there are 2 state change calls, first from global to Resetting, and then from Resetting to StartPhysics, which is probably ending with the actor staying in Resetting.
Do you have more logs from the ticks which follow that one on the same particle?
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: Question about auto state and replication
No I don't think so, the logs I posted end like this:nogardilaref wrote:which is probably ending with the actor staying in Resetting.
Code: Select all
ScriptLog: [GLOBAL] State(Autoplay.Particle0) = Particle
Code: Select all
Log("State(" $ Self $ ") = " $ GetStateName());
That last log continued until I closed the game. I should put logs inside EndState() within any state.
Old EDITs:
Spoiler
EDIT 1: I put logs inside any EndState() function and before any GotoState() call. (Even before Sleep(0) which I forgot why 0, and Sleep(particleSys.resetInterval)):
You were right so, EndState() is called, specifically from within StartPhysics state. Now the question is "why?", I probably should leave only BeginState() and EndState() inside StartPhysics to see if the other functions were actually affecting the result.
EDIT 2: Ok "good news", the problem persists, but I reduced the class a lot,no any extra overwritten functions in the states, only BeginState() and EndState(): These are the logs this time:
Next step is to start a map and summon a Particle reference and see what happen.
EDIT 3: Just summoned a Particle reference in a map without a ParticleSystem reference, same result:
Which means it's all fault of that class, nothing from outside.
EDIT 4: Damn... the class is literally nothing right now XD:
At this point should I think it's cause of RemoteRole=ROLE_None ?
EDIT 5: Aaaand no, it has nothing to do with the RemoteRole=ROLE_None, I removed the defaultproperties and still getting the same result.
Now the logs appear like this:
Code: Select all
ScriptLog: Spawned() - GotoState('Resetting')
ScriptLog: Resetting's BeginState() has been called.
ScriptLog: Resetting's Setup() has been called.
ScriptLog: Setup() - GotoState('StartPhysics')
ScriptLog: Resetting's EndState() has been called.
ScriptLog: StartPhysics's BeginState() has been called.
ScriptLog: StartPhysics's EndState() has been called.
ScriptLog: [GLOBAL] State(Autoplay.Particle0) = Particle
EDIT 2: Ok "good news", the problem persists, but I reduced the class a lot,no any extra overwritten functions in the states, only BeginState() and EndState(): These are the logs this time:
Code: Select all
ScriptLog: Spawned() - GotoState('Resetting')
ScriptLog: Resetting's BeginState() has been called. + Call to GotoState('StartPhysics')
ScriptLog: Resetting's EndState() has been called.
ScriptLog: StartPhysics's BeginState() has been called.
ScriptLog: StartPhysics's EndState() has been called.
ScriptLog: [GLOBAL] State(Autoplay.Particle0) = Particle
EDIT 3: Just summoned a Particle reference in a map without a ParticleSystem reference, same result:
Code: Select all
ScriptLog: Spawned() - GotoState('Resetting')
ScriptLog: Resetting's BeginState() has been called. + Call to GotoState('StartPhysics')
ScriptLog: Resetting's EndState() has been called.
ScriptLog: StartPhysics's BeginState() has been called.
ScriptLog: StartPhysics's EndState() has been called.
ScriptLog: [GLOBAL] State(DM-Peak.Particle0) = Particle
EDIT 4: Damn... the class is literally nothing right now XD:
Code: Select all
/*
* Supposed to be done by a community
*/
class Particle extends Effects;
event Spawned()
{
Log("Spawned() - GotoState('Resetting')");
GotoState('Resetting');
}
state Resetting
{
event BeginState() {
Log("Resetting's BeginState() has been called. + Call to GotoState('StartPhysics')");
GotoState('StartPhysics');
}
event EndState() {
Log("Resetting's EndState() has been called.");
}
}
state StartPhysics {
event BeginState() {
Log("StartPhysics's BeginState() has been called.");
}
event EndState() {
Log("StartPhysics's EndState() has been called.");
}
}
defaultproperties
{
RemoteRole=ROLE_None
}
EDIT 5: Aaaand no, it has nothing to do with the RemoteRole=ROLE_None, I removed the defaultproperties and still getting the same result.
Code: Select all
/*
* Supposed to be done by a community
*/
class Particle extends Effects;
event Spawned()
{
Log("Spawned() - GotoState('Resetting')");
GotoState('StartPhysics');
}
state StartPhysics {
event BeginState() {
Log("StartPhysics's BeginState() has been called.");
}
event EndState() {
Log("StartPhysics's EndState() has been called.");
}
}
Code: Select all
ScriptLog: Spawned() - GotoState('StartPhysics')
ScriptLog: StartPhysics's BeginState() has been called.
ScriptLog: StartPhysics's EndState() has been called.
Last edited by PrinceOfFunky on Sun Nov 05, 2017 7:51 pm, edited 1 time in total.
"Your stuff is known to be buggy and unfinished/not properly tested"
-
- Masterful
- Posts: 577
- Joined: Tue Jun 20, 2017 1:00 pm
- Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋
Re: Question about auto state and replication
I just remembered something, try adding this state code at the end of every state:
If it works, I will explain later, if it doesn't, I will probably do as well but the reveal won't be as good.
Code: Select all
Begin:
Sleep(0.0);
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: Question about auto state and replication
Wait maybe you couldn't read the last EDIT:
EDIT: Nothing to do with Sleep(0.0), same result.
But you know...? I thought about something, may Spawned() be called before SetInitialState()?
Cause if so, InitialState is not set, and calling a different state from Spawned() would have effect just for an instant, before SetInitialState() will call GotoState() and set the state to the default one, while calling of course EndState() from the state I called from within Spawned() (in this case 'StartPhysics').
This would have sense with the "auto" modifier, probably cause the "auto" modifier is checked after SetInitialState().
Indeed, the "auto" modifier is checked inside SetInitialState():
You know what I can do now? I can try overwriting SetInitialState() and put a log inside to see when it is called!
Ahhhh That's it!!
That's the code:
And these are the logs:
SetInitialState() is called after Spawned()! Whatever GotoState you have called in Spawned() will be ineffective cause SetInitialState() will change it...
PrinceOfFunky wrote:EDIT 6: Oh Gawddd, the class couldn't be shorter!And I get something like this:Code: Select all
/* * Supposed to be done by a community */ class Particle extends Effects; event Spawned() { Log("Spawned() - GotoState('Resetting')"); GotoState('StartPhysics'); } state StartPhysics { event BeginState() { Log("StartPhysics's BeginState() has been called."); } event EndState() { Log("StartPhysics's EndState() has been called."); } }
Code: Select all
ScriptLog: Spawned() - GotoState('StartPhysics') ScriptLog: StartPhysics's BeginState() has been called. ScriptLog: StartPhysics's EndState() has been called.
Also, "every state"? Ahah you mean the only one state remaining?! XDnogardilaref wrote:try adding this state code at the end of every state:
EDIT: Nothing to do with Sleep(0.0), same result.
But you know...? I thought about something, may Spawned() be called before SetInitialState()?
Cause if so, InitialState is not set, and calling a different state from Spawned() would have effect just for an instant, before SetInitialState() will call GotoState() and set the state to the default one, while calling of course EndState() from the state I called from within Spawned() (in this case 'StartPhysics').
This would have sense with the "auto" modifier, probably cause the "auto" modifier is checked after SetInitialState().
Indeed, the "auto" modifier is checked inside SetInitialState():
Code: Select all
simulated event SetInitialState()
{
bScriptInitialized = true;
if( InitialState!='' )
GotoState( InitialState );
else
GotoState( 'Auto' );
}
Ahhhh That's it!!
That's the code:
Code: Select all
/*
* Supposed to be done by a community
*/
class Particle extends Effects;
event Spawned()
{
Log("Spawned() - GotoState('StartPhysics')");
GotoState('StartPhysics');
}
simulated event SetInitialState()
{
Log("Before super.SetInitialState()");
super.SetInitialState();
Log("After super.SetInitialState()");
}
state StartPhysics {
event BeginState() {
Log("StartPhysics's BeginState() has been called.");
}
event EndState() {
Log("StartPhysics's EndState() has been called.");
}
}
Code: Select all
ScriptLog: Spawned() - GotoState('StartPhysics')
ScriptLog: StartPhysics's BeginState() has been called.
ScriptLog: Before super.SetInitialState()
ScriptLog: StartPhysics's EndState() has been called.
ScriptLog: After super.SetInitialState()
Last edited by PrinceOfFunky on Sun Nov 05, 2017 8:19 pm, edited 1 time in total.
"Your stuff is known to be buggy and unfinished/not properly tested"
-
- Masterful
- Posts: 577
- Joined: Tue Jun 20, 2017 1:00 pm
- Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋
Re: [SOLVED] Question about auto state and replication
Oh, very nice catch.
I completely forgot about the existence of the SetInitialState event, I was thinking that by the time Spawned was called the state would have already been changed.
Noted.
As for the Begin and Sleep stuff, I was thinking if the states were exiting on their own automatically due to the complete lack of state code in most of them, plus I saw exactly this in the TournamentWeapon empty states.
I completely forgot about the existence of the SetInitialState event, I was thinking that by the time Spawned was called the state would have already been changed.
Noted.
As for the Begin and Sleep stuff, I was thinking if the states were exiting on their own automatically due to the complete lack of state code in most of them, plus I saw exactly this in the TournamentWeapon empty states.
Last edited by nogardilaref on Sun Nov 05, 2017 8:20 pm, edited 1 time in total.
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: [SOLVED] Question about auto state and replication
Wait no lol, it doesn't work, it worked cause I forgot to remove "auto" modifier lol.nogardilaref wrote:Oh, very nice catch.
I completely forgot about the existence of the SetInitialState event, I was thinking that by the time Spawned was called the state would have already been changed.
Noted.
As for the Begin and Sleep stuff, I was thinking if the states weren't exiting on their own automatically due to the complete lack of state code in most of them, plus I saw exactly this in the TournamentWeapon empty states.
At this point I think I should create a new state, set it as InitialState, and do all that Spawned() did inside that state.
EDIT: Ok it works. This is the class:
Code: Select all
/*
* Supposed to be done by a community
*/
class Particle extends Effects;
state Init {
event BeginState()
{
Log("BeginState() - GotoState('StartPhysics')");
GotoState('StartPhysics');
}
}
state StartPhysics {
event BeginState() {
Log("StartPhysics's BeginState() has been called.");
}
event EndState() {
Log("StartPhysics's EndState() has been called.");
}
}
defaultproperties {
InitialState=Init
}
Code: Select all
ScriptLog: BeginState() - GotoState('StartPhysics')
ScriptLog: StartPhysics's BeginState() has been called.
Of course I would have done it first adding the "auto" modifier to 'Init' state, instead of setting it as the InitialState.
Last edited by PrinceOfFunky on Sun Nov 05, 2017 8:28 pm, edited 1 time in total.
"Your stuff is known to be buggy and unfinished/not properly tested"
-
- Masterful
- Posts: 577
- Joined: Tue Jun 20, 2017 1:00 pm
- Personal rank: ⚋⚊⚌☰⚞⌖⚟☰⚌⚊⚋
Re: [SOLVED] Question about auto state and replication
But at least that should solve the question about how the actor was still in the global state, even in the following ticks.
Or you mean to say that even so they still do not stay at least in one of the states?
Or you mean to say that even so they still do not stay at least in one of the states?
- PrinceOfFunky
- Godlike
- Posts: 1200
- Joined: Mon Aug 31, 2015 10:31 pm
Re: [SOLVED] Question about auto state and replication
Wait you couldn't read the EDIT I posted:nogardilaref wrote:But at least that should solve the question about how the actor was still in the global state, even in the following ticks.
Or you mean to say that even so they still do not stay at least in one of the states?
EDIT: Indeed, adding the "auto" modifier to 'Init' state, makes it work as expected.PrinceOfFunky wrote:nogardilaref wrote:EDIT: Ok it works. This is the class:Note the InitialState set to Init in defaultproperties, these are the logs:Code: Select all
/* * Supposed to be done by a community */ class Particle extends Effects; state Init { event BeginState() { Log("BeginState() - GotoState('StartPhysics')"); GotoState('StartPhysics'); } } state StartPhysics { event BeginState() { Log("StartPhysics's BeginState() has been called."); } event EndState() { Log("StartPhysics's EndState() has been called."); } } defaultproperties { InitialState=Init }
Meaning BeginPlay() is also called before SetInitialState().Code: Select all
ScriptLog: BeginState() - GotoState('StartPhysics') ScriptLog: StartPhysics's BeginState() has been called.
Of course I would have done it first adding the "auto" modifier to 'Init' state, instead of setting it as the InitialState.
This is the code:
Code: Select all
/*
* Supposed to be done by a community
*/
class Particle extends Effects;
auto state Init {
event BeginState()
{
Log("BeginState() - GotoState('StartPhysics')");
GotoState('StartPhysics');
}
}
state StartPhysics {
event BeginState() {
Log("StartPhysics's BeginState() has been called.");
}
event EndState() {
Log("StartPhysics's EndState() has been called.");
}
}
Code: Select all
ScriptLog: BeginState() - GotoState('StartPhysics')
ScriptLog: StartPhysics's BeginState() has been called.
EDIT 2: Also, this is the beta that now works, cause replaced Spawned() with a new state(called 'Init') and set it as auto: Even if it doesn't work in DedicatedServer, but well... better than nothing XD
Last edited by PrinceOfFunky on Sun Nov 05, 2017 8:37 pm, edited 1 time in total.
"Your stuff is known to be buggy and unfinished/not properly tested"