PDA

View Full Version : NUKE SIREN!



|uK|kenneth
06-25-2012, 07:38 PM
did anyone else have seen problems with the nuke siren? what i mean is: its going of for 1-3 sec and when the nuker is right in our base the nuke siren stops saying incoming nuker but still flashing. if anyone else have seen this problem please post it here so maybe SilverWing can fix this.

|uK|Grimreaper
06-25-2012, 07:47 PM
yeah i noticed this problem to!

Higor
06-25-2012, 10:21 PM
I believe the Nuke Siren system should be entirely reviewed.
The GameReplicationInfo actor should handle some of the alarm system, by replicating (4 + 1*nukesiren) variables and simulating the remaining code which includes sounds and lights.
The current method doesn't even allow the alarm sound to loop and overflows the screen with messages, blocking timer events.


============
Recommended method:

GRI actor: 4 replicated variables.
bool bRedAlarm, bBlueAlarm, bGreenAlarm, bGoldAlarm;

Nuke siren actor: (if relevant) 1 replicated variable.
bool bAlarmTriggered;

====
Simulation:
On GRI, 2 variables:
PlayerPawn LocalPlayer; (this is the viewport player)
bool bHadAlarm;
On Tick() or Timer(), first find the local player, then compare the bHadAlarm with the corresponding bTeamAlarm (replicated), if they are different, play/stop alarm sounds.
The alarm sound will be played clientside every 7 seconds (which will make it appear it's looping).

Do the same on the NukeSiren actor, and make it change lighting (flashing?) when there is a corresponding alarm event.
Don't simulate light changes on enemy players to avoid detection.

Moskva
06-25-2012, 10:41 PM
I believe the Nuke Siren system should be entirely reviewed.
The GameReplicationInfo actor should handle some of the alarm system, by replicating (4 + 1*nukesiren) variables and simulating the remaining code which includes sounds and lights.
The current method doesn't even allow the alarm sound to loop and overflows the screen with messages, blocking timer events.


============
Recommended method:

GRI actor: 4 replicated variables.
bool bRedAlarm, bBlueAlarm, bGreenAlarm, bGoldAlarm;

Nuke siren actor: (if relevant) 1 replicated variable.
bool bAlarmTriggered;

====
Simulation:
On GRI, 2 variables:
PlayerPawn LocalPlayer; (this is the viewport player)
bool bHadAlarm;
On Tick() or Timer(), first find the local player, then compare the bHadAlarm with the corresponding bTeamAlarm (replicated), if they are different, play/stop alarm sounds.
The alarm sound will be played clientside every 7 seconds (which will make it appear it's looping).

Do the same on the NukeSiren actor, and make it change lighting (flashing?) when there is a corresponding alarm event.
Don't simulate light changes on enemy players to avoid detection.

Could you explain for us in english or spanish please, because its definitely an interesting topic

Higor
06-25-2012, 11:19 PM
So far, notifications are handled via the messaging system, which triggers the alarm sounds.

The messaging system is the one that gives for example, the headshot messages to the player.
This is done via a replicated function call, which is triggered every (1 / game speed scale) seconds by the nuker finding iterator.


This new method involves replicating to all players 4 variables, which are the team nuke states, these variables can only be set as FALSE(default) or TRUE.
The client machine is tasked figure out if his team's alarm state has changed and to either play or stop the sounds.
This is what we call clientside simulation, because the server only tells us the states TRUE or FALSE and is up to the clients to play the sounds and give the local player the INCOMING NUKER messages.

A similar method can be applied to make the Nuke Siren glow on client machines without having the lighting variables sent by the server, this approach is already in use in my new Teleporter code with the spinning.

=========
Also, the Nuke Siren has a bug that will overflow server logs with 'Accessed None' warnings if any player throws his Nuke to the ground, or if any spectator approaches the Siren's detection radius.
This routine should first rule out spectators and then check if the nuke exists in the first place, this will obviously make it slower at some point, but it's better not make the log files grow to tremendous sizes.

In a different point of view (discarding the proposed fixes), the Nuke detection method has become a little faster since it uses FindInventoryType function, which has been hacked in a previous fix (http://www.unrealkillers.com/showthread.php/2058-Code-review-Supplier-%2850-%29-and-WeaponFiding-optimization) to make it faster when it comes to finding ammo-carrying weapons.

.seVered.][
06-26-2012, 12:26 AM
Not only that it Spam's the log with Incoming Nuker messages too.. quite annoying. And I thought that it already flashed when a nuke was incoming.

Moskva
06-26-2012, 12:45 AM
[;31544']Not only that it Spam's the log with Incoming Nuker messages too.. quite annoying. And I thought that it already flashed when a nuke was incoming.

Yeah same with the message that the core is getting hit, console just wont be useful after that

|uK|fleecey
06-28-2012, 12:39 PM
It's not just the nuke siren, it's the emp & neutron sign too, it never shows up.. just at times, but not often. At least in the public server...

SilverWing
06-28-2012, 12:47 PM
The thing is, this never has happened before when we first released the version of Siege and now it happened out of no where... it might be just server side or it could be siege.

nOs*Wildcard
06-28-2012, 03:26 PM
I think the light shold be replicated on both sides or have no light at all. It's silly that the red team sees the light flashing from the nuke siren and the alternate reality the blue team inhabits there is no light flashing which is just silly. I know this is UNREAL tournament and all but sometimes I ask for just a little bit of logic in the gameplay. I understand what you mean and the intensions are good

Higor
06-29-2012, 12:58 PM
Making light stay on both teams will make the new code easier to read and make anyways...

BTW I think I figured out why the Super Containers reappear when they are hit by EMP or fire.
And there is a way to make those stay on sight all the time...

Scourge
07-12-2012, 11:12 AM
At risk of going off topic, do we really want Super Containers to stop disappearing? Hidden SCs have allowed tactical maneuvers that wouldn't otherwise be possible.

I would definitely support allowing all weapons, not just the flak and ripper, to damage "sunken" SCs, but I don't know about un-hiding them.

audiosonic
07-12-2012, 01:46 PM
I agree with Scourge, now we only need hidden super protectors, hidden teleporters, and hidden cores so we can do stuff that has never been done before.

|uK|B|aZe//.
07-12-2012, 04:16 PM
might as well all be invisible and see who really aimbots and doesnt now right?

nOs*Wildcard
07-12-2012, 04:37 PM
This problem would not have happend in the first place if the constructor wasn't modified to allow players to build crap anywhere without checking to make sure the building fit there! This probaly has spawned several similar lame problems. Modifying the constructor to not check to make sure a building fits was a foolish idea :chargrined:

Scourge
07-12-2012, 07:07 PM
I agree with Scourge, now we only need hidden super protectors, hidden teleporters, and hidden cores so we can do stuff that has never been done before.

See though, we're talking about a max of two rather large objects that once hidden can be detected, killed, or even leeched in several ways, not spammed all over the place and suddenly pow you have a billion players and SP shots raining down on your head. You have to look at this on a case-by-case basis; do hidden SCs really break the game? (Even chiseller's favorite tactic in Niven couldn't stop his team from winning once he got switched. This just goes to show that yes, there are counters to seemingly cheap tactics, and you should make every effort to use them.)

Higor
07-12-2012, 07:36 PM
It isn't the Constructor's fault, it's a problem with the building's collision cylinder and properties.

Super containers don't have bCollideWhenPlacing property set to true, problem is, that if you enable it by default, it will then not be able to block some critical doorways like in Clarion.

The way to deal with this is to set this property to True, but reduce collision height and radius to the one of a normal container.
Once placed, before the general event system notifies the game and other buildings that a Super Container was built, reset the collision size back to it's original size.


Changes would be:
Super Container > set bCollideWhenPlacing=True > set CollisionHeight 20 > set CollisionRadius 20.
Super Container's PostBeginPlay(): *taking into account that the general event system and container build linking was already added*

event PostBeginPlay()
{
local sgBuilding sgB;

SetCollisionSize( 80, 80);

Super.PostBeginPlay();

iRelated = 0;
foreach RadiusActors(class'sgBuilding', sgB, 240+(HealRadius*0.25)*Grade)
if ( (sgBaseCore(sgB) == None) && (sgB.Team == Team) && (iRelated < 32) )
sgRelated[iRelated++] = sgB;
}
This way, it is created taking into account a smaller collision cylinder for map location, then it is enlarged to it's original size making it able to block doorways.