Emitter not spawned during lanplay or netplay

[rejecht]

Hi again,

Game: Unreal Tournament 2004 (v3369)

I'm using a ScriptedTrigger actor and ACTION_SpawnActor to spawn the ONSMASCannonImplosionEffect, which is basically an Emitter actor with a bunch of emitter properties.

When the map is played from the editor or through instant action, it spawns the particles and plays the sound fine.

When online or through -LANPLAY -SERVER, it doesn't spawn.

In contrast, it does spawn the redeemer explosion fine, both offline and online.

I hope I'm missing something obvious, but I've been trying hard to figure out exactly what that would be. Nothing in the logs to show for it either. I have no choice but to humbly ask for your help.


What I have set up now to test this:

Local server is started like this:
C:\UT2004\System\UT2004.exe created\tests\test?game=xGame.xTeamGame -SERVER -LANPLAY

The map is actually located here:
C:\UT2004\Maps\Created\Tests\test.ut2

The game is started like this..
C:\UT2004\System\UT2004.exe -WINDOWED -LOG

..Join Game, LAN.

Any ideas?

[GreatEmerald]

Spawning Emitters is quite a delicate thing. You see, online they have to be spawned on clients, and not on servers. Usual actors are spawned the other way round - they are mainly on the server, while clients are only updated based on their role. Not sure how you are supposed to spawn emitters in the Editor, usually that happens through UnrealScript.

But looking at the Redeemer emitter, it seems it has RemoteRole=ROLE_DumbProxy, as opposed to almost all emitters that have RemoteRole=ROLE_None. Generally DumbProxy makes it exist on both servers and clients, and while it's not the most optimal thing to do, it makes sure that it appears, while using more bandwidth...

[INIQUITOUS]

hhm strange, try adding these to the defaults of the emitter

RemoteRole=ROLE_SimulatedProxy
bNotOnDedServer=False

[rejecht]

Thanks for your informative replies! It works now. At what cost it works, I will figure out later.

I haven't looked much into replication yet, so that was something I didn't think about too much. In my mind, I figured the clients and the server had the information they needed, because the ScriptedTrigger isn't triggered by any player, but by a randomly selected time, and I assume the random number generator returns the same probability on all clients and the server, which means all sides know the same time. So, it shouldn't need to send updates to the clients, it should only need to spawn the effect.

So, here's what worked:
I copied the ONSMASCannonImplosionEffect contents and made a new file and class called MyONSMASCannonImplosionEffect,
changed its RemoteRole from ROLE_None to ROLE_SimulatedProxy in its defaultproperties,
added to EditPackages,
ran UCC make. etc
Added the class to the ScriptedTrigger actor,
ran the map in LANPLAY, and it spawns, with effects and sound. Perfect!

I haven't set bNotOnDedServer to False yet, however, I will check out the meaning of these settings in detail. I assume it means it won't attempt to spawn the effect if the actor is on a dedicated server etc.

Maybe I could make my own ACTION_SpawnEmitter or something, and have it do the replication stuff, etc, so I don't have to change any of the emitters..

Thanks for the pointers!

[GreatEmerald]

I believe that the emitter doesn't need a role as high as Simulated Proxy. Dumb Proxy should be sufficient, and will save some bandwidth.

[Blade[UG]]

rejecht, never assume that a server, a client, and any other client, all have the same information, unless you have explicitly replicated that information to all of them.

[rejecht]

rejecht, never assume that a server, a client, and any other client, all have the same information, unless you have explicitly replicated that information to all of them.

That sounds like a good generalization.

I've just quickly read through these documents on Unreal's networking approach and replication logic:
http://udn.epicgames.com/Two/Replica...fuscation.html
http://udn.epicgames.com/Two/Network...hitecture.html
/
http://udn.epicgames.com/Three/NetworkingOverview.html

But anyway, to learn something new, you have to make assumptions to get anywhere at the start, or you'll just end up starring at the wall. You have to test your theories against the real (or unreal) world, and then you'll either figure it out, or have to run more tests. So this was not me making any absolute claims, just testing my tentative understanding, questioning what I observed etc.

Any other material on replication beginners should know about?
There's beyondunreal too, of course.

[Blade[UG]]

Seems for most people, it takes a lot of study to understand replication, and you're all confused and stuff, and then one day it just clicks, and you go "OH! THAT's how it works."

[rejecht]

*bump*

OK, so what happened was that the emitter would indeed spawn after being triggered in NETPLAY, which was great, but there was a flaw. It would seemingly only spawn in sync for players in the same zone, or those in visual proximity of the emitter. What would happen was that the explosion would go off for those in the zone at the time, however, a latecomer into the zone might see the emitter effect after the explosion logic had been carried out, as if delayed/lagged. This had no effect on the explosion logic, but would seem confusing and out of sync.

Since then I switched to subclassing the NetworkEmitter (uses simulated function calls and logic to handle the spawn syncing on the clients)--using functionality that is already in place for such use-cases--which in NETPLAY (played locally as said in first post) has worked as expected so far.. I didn't notice that type of Emitter then.

Just a heads up/conclusion in case someone stumbled upon this thread, looking for a possible solution.