Announcement

Collapse
1 of 2 < >

Privay Policy Update

We’ve updated the Tripwire Privacy Notice under our Policies to be clearer about our use of customer information to come in line with the EU General Data Protection Regulation (GDPR) rules that come into force today (25th May 2018). The following are highlights of our changes:


We’ve incorporated the relevant concepts from the GDPR including joining the EU and Swiss Privacy Shield framework. We’ve added explanations for why and how Tripwire processes customer data and the types of data that we process, as well as information about your data protection rights.



For more information about our privacy practices, please review the new Privacy Policy found here: http://tripwireinteractive.com/policies/privacy-notice
2 of 2 < >

Forum Rules

CHANGES
  • Items changed, or highlighted for future attention, on 20 July 2013 are highlighted in yellow.

Global Rules
  • Forum moderators may or may not be Tripwire Interactive staff members, but either way, please respect them, as they are the authority of the forums. Speaking to them with intentional spite will not be tolerated and may result in the loss of your forum privileges.
  • Any decisions made by any member of staff or moderator are final and not subject to discussion. Doing so may result in a ban from the site. The owners of Tripwire Interactive Forums reserve the right to remove, edit, move or close any thread for any reason, as well as to remove access to the forums for any individuals with or without warning for breaches of the rules.
  • If you have a complaint regarding another user, PM the appropriate moderators, or if you have an administrative issue, [RO]schneidzekk.

General Behaviour
  • Use the search function before posting. Chances are your question has already been answered.
  • Use a title that describes the content of your post. Don't use all caps or special characters to draw attention either in the title or the body of the post.
  • Up to 10 emoticons are allowed in a post
  • Political discussions are prohibited.
  • Flaming - We do not tolerate abusive, malicious, personal attacks. You will be banned if you persist in this behavior.
  • Trolls - Anyone deliberately antagonizing other forum users by posting 'flame bait' type messages is not welcome. You will be banned (possibly without warning depending on the severity of the issue) if you persist in this behavior.
  • Personal insults (directed at anyone) will result in a ban. If the behavior is not corrected, it will be made more permanent.
  • Constructive criticism is welcome. However keep in mind we (and other forums goers) may not agree with you. If you can't keep the conversation civil, you will be removed from the forums.
  • The use of hyperbole, one liners, and images as part of a forum debate is likely to get you infracted. You have many ways to participate and be a constructive part of this community, even when you disagree.
  • To make the highlighted bits above 100% clear to everyone, the following WILL NOT BE TOLERATED:
    1. Personal attacks, insults, antagonism of any forum-goers, moderators or Tripwire Interactive staff.
    2. Name Shaming and Public "Witch Hunts" are also not allowed.
    3. Breaches of confidentiality and privacy of any sort.
    4. Any form of racism, bigotry or attacks on race, creed or color.
    5. Linking to posts on other forums related to ANY of the above, whether you are the originator or not, without exception.

  • There has been too much in the way of abhorrent personal behaviors in the past. These will cease. It doesn't matter who started it or who reacted to it - it will all result in moderator action. If you have to indulge your hatreds, for whatever reason, go do it elsewhere - and do not try and drag our forum-goers over to enjoy your hatreds.
  • We understand that people have strong feelings about our games, what we do for a living and how we respond (or don't) to comments on the forums. We all aren't going to agree about everything. So, BE CIVIL in your disagreements!

DO NOTs
  • DO NOT Transmit any message, information, data, text, software or graphic files, or other materials ("Content") that is unlawful (including illegal drug usage), harmful, threatening, abusive, harassing, defamatory, vulgar, obscene, libelous, hateful or racially, ethnically, sexually or otherwise objectionable. This includes publicizing private information, such as individual's real names, IP addresses and anything else that might be used to identify them to the freakier members of the internet. This also means you may NOT publically share private communications (PM, email or anything else) without the original poster's permission.
  • DO NOT Post or transmit any Content that contains a virus, Trojan horse or other mischievous Content.
  • DO NOT Post or transmit any unsolicited advertising, promotional materials, "junk mail", "spam", "chain letters", "pyramid schemes" or any other form of solicitation.
  • DO NOT link to posts on any other forums, or any other form of media, that breaches our rules. It will be treated just the same as if you had posted it here.
  • DO NOT Double Post, cross Post, "necro post" or restart closed threads.
  • DO NOT Intentionally or unintentionally violate any applicable local, state, national or international law, rule or regulation.
  • DO NOT Upload or transmit any Content that infringes any patent, trademark, trade secret, copyright or other proprietary rights ("Rights") of any party.
  • DO NOT post cheats or exploits; THIS INCLUDES ALL/ANY REFERENCES TO HACKING, PIRATED SOFTWARE etc.
  • DO NOT complain about being banned from a server and DO NOT complain about other players on servers - that is between you and the admin, no need to get the community involved.

Username, Avatar and Signature Rules
  • Multiple registrations result in a ban.
  • No offensive user names
  • Avatars:
    Avatars are disabled.
  • All signatures should not exceed the following size limits, you can have both text and images
  • - For text signatures: 4 lines normal size, 8 lines small size and up to 100 chars per line. Font sizes above 2 are not allowed. (Blank lines count as lines.)
  • - For images in signatures: 1 image up to 400 pixels wide, 150 pixels tall and 100kb in size plus 2 lines normal size text and up to 100 chars per line
Netiquette: Written text has no inflection, and, as such, you should be careful how you write your messages as interpretation will vary from person to person. Please take advantage of the built-in emoticons to add such expression to your words. Please remember the golden rule: to treat other forum users the way you would like to be treated. Please use common courtesy, and enjoy using Red Orchestra's forums
Offensive material
The following is a list of some things that MAY be considered "offensive" by the moderators and the team. This is NOT an exclusive list and it does depend very much on context.

Crossing the line into "offensive" territory is likely to get you asked to change your name, sig or avatar or to withdraw/delete posts. This will be done politely by the moderators. If you refuse to comply further action WILL be taken once started, ultimately leading to banning from the forums.

A key point: please attempt to use your brains. What is mild humour to you may well be deeply offensive to others. While we have no intention of acting as politically-correct "thought police", we are on the lookout for those things that can cause offense and, in some cases, are actually still illegal in some jurisdictions.
  1. Names recalling notorious war criminals or personalities.
  2. Names recalling atrocities and war crimes in general, or units with particularly odious histories.
  3. Use of obscenities and expletives.
  4. Blatant racism, mysogynism or many other "ism"s.
  5. Use of symbolism and regalia recalling Nazism or Fascism; this does not include pics of soldiers who happen to have such symbols on their uniform, unless we feel this has been done to provoke. Please note that many Nazi symbols (including the Swastika) are still illegal in Germany and other countries and considered deeply offensive by many Europeans.
  6. Use of symbolism and regalia recalling Stalinism.
  7. On both the previous two, the moderators' views on the intention and impact of use of such symbols will be final - not yours. Please be understanding if you are advised to change something.
  8. In general, if a sig/avatar represents your allegiances in-game and is clearly "in part", it is likely to be fine; if the moderators feel you are trying to demonstrate unpalatable political allegiances, or to use it in an attempt to ridicule or provoke others you WILL be asked to change it. RO is NOT the place to make any extremist political statements of any kind.

Examples:
So people get the idea, some examples that would be considered offensive, numbered as above:
  1. "Hitler", "Beria"
  2. "NKVD Blocking Detachment", "Einsatzgruppen"
  3. This one should be pretty obvious...
  4. So should this - and it includes calling all Germans "Nazis" and all Soviets/Russians "Commies". It got boring 50 years ago, so stop it.
  5. Use of swastikas, fasces, SS-runes and so on for the Axis.
  6. There is actually very little overt symbolism from the Stalinist era; the hammer-and-sickle isn't offensive per se.

A simple rule-of-thumb: many Europeans find Nazi symbolism of any sort offensive; many Americans still find Soviet symbolism offensive. Engage your brain before using.




Final Note: this is NOT open to debate, so please do NOT start whining and moaning if a moderator asks you to change something. They will advise at first, giving reasons, then, if you take no notice, they will step up the pressure through to banning.
See more
See less

[Tutorial] Multiplayer Mutators

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • [Tutorial] Multiplayer Mutators

    Multiplayer Mutators

    I'm not going to fully explain how networking works in Unreal Engine since there are too many intricate details to cover in a lightweight tutorial, so for those not too familiar with it I would recommend reading this. You need to have a basic grasp on the following concepts:

    • Actor roles - Describes what level of control a client may have over an actor.
    • Actor relevance - Whether an actor should have its information replicated to other clients.
    • Variable replication - Where the server (or client) sends a copy of a variable to the other end.


    As I want to keep this tutorial short I'll just explain how these concepts pertain to writing mutators that can run client-side.

    Server-side mutators

    A server-side mutator is one that executes exclusively on the server, where it has control over the major elements of the game. Since the server is the authority on everything important to the game (such as spawning enemies, deciding who takes damage) a server-side mutator can alter these elements to spawn more enemies, alter weapon damage, and more. However, elements that are local the client (such as the HUD and local effects) cannot be altered by the server since they are managed exclusively by the client. If you want to write a mutator that (for example) adds nightvision or makes certain objects stand out it must execute on the client.

    Client-side mutators

    Strictly speaking there is no such thing as a mutator that is only client-side, since a mutator is part of the game, which of course is managed by the server. However, you can create a mutator that executes on client machines and then use some logic to prevent the server from running the same code. For example, you may wish to spawn a local effect such as a muzzle flash - the server doesn't need to spawn such superficial actors, so you can add some logic to prevent the server from executing this code.

    Now, a little bit of theory on the previously mentioned concepts:

    Actor roles

    Every actor has a pair of role attributes associated with it, which describe who owns the actor and how the other side should manage it. When writing a mutator that needs to execute client-side you must use the simulated proxy role which allows functions marked with the simulated keyword to be executed. Simply, the idea behind this concept is that the client can perform simulation of certain actors (for instance, physics simulation for projectiles) by calling the actor's functions locally. If the client couldn't do simulation the movement of such actors would be very jagged and laggy since you'd be simply viewing them at each set of coordinates that the server sends you, instead of being able to smoothly interpolate between them.

    These are the default role attributes for a mutator:

    Code:
    defaultattributes
    {
    	Role=ROLE_Authority
    	RemoteRole=ROLE_None
    }
    And here are the roles you want if your mutator needs to execute client-side:

    Code:
    defaultattributes
    {
    	Role=ROLE_Authority
    	RemoteRole=ROLE_SimulatedProxy
    }
    Note that it's not necessary to specify the Role attribute since this is the default.

    When you set role attributes for an actor you set them from the perspective of whoever spawns that actor. For example, if the server spawns this actor they will be the authority, and the client will have no role (meaning it doesn't interact with the mutator at all). See here for more details on actor roles.

    Actor relevance

    For the sake of bandwidth the client doesn't work with any actors that aren't relevant to it. For example, if another player is on the other side of the map and you can't seem them, there's no need to know where they are and perform simulation on their movement. As a mutator is never 'seen' in the world it will never be considered relevant to other players, which is why you must force it to be relevant by setting this in the mutator's default attributes:

    Code:
    bAlwaysRelevant=true
    Otherwise the mutator will be never considered relevant to clients, and they won't be able to execute any of its functions. See here for more details on actor relevancy.

    Variable replication

    Replication is where the server (or client) gives a copy of a variable to a client (or server) in order to match the state of the actor on both machines. For example, player health is calculated and managed by the server, so when the health variable changes the server will send an updated copy of this variable to the client. By default a variable isn't replicated - you have to explicitely write some logic to show which are, and which direction they are replicated in (either from client to server, or server to client, but never both for the same variable). It's very important to remember this, since if you want to write a mutator that changes (for example) the maximum health of a player you must change it on the server. Conversely, if you want to change a client-local actor such as a HUD element it must be done on the client. It's important to note whether a variable is replicated or not when working with them. To see if a variable of a particular class is replicated, look for the replication statements in the source file where the variable is declared.

    Writing a client-executable mutator

    Example

    Rather than giving a long-winded explanation on all the details of writing a mutator that may execute client-side, I'm going to show you an example and give a brief explanation on how it works. The following example writes a string to both the server's log and the client's log.

    Code:
    class ExampleMutator extends Mutator;
    
    simulated function PostBeginPlay()
    {
    	Log("PostBeginPlay() was called");
    }
    
    defaultproperties
    {
    	GroupName="KFExampleMutator"
    	FriendlyName="Example Mutator"
    	Description="Mutator description here"
    
    	RemoteRole=ROLE_SimulatedProxy
    	bAlwaysRelevant=true
    	bAddToServerPackages=true
    }
    Explanation from top to bottom:

    Code:
    simulated function PostBeginPlay()
    The simulated keyword indicates that the function should be allowed to execute on the client. It's often used for actors that require local simulation (such as interpolation of other players on the screen). It can be applied to existing functions and your own functions. If a simulated function calls a non-simulated function, the latter function won't execute on the client. Additionally, functions declared with the keywords final or native will execute on the client.

    Code:
    {
    	Log("PostBeginPlay() was called");
    }
    Calling the log function writes a string to the log (either killingfloor.log or server.log depending on whether the client or server executes it). It's very useful for debugging.

    Code:
    defaultproperties
    {
    	GroupName="KFExampleMutator"
    	FriendlyName="Example Mutator"
    	Description="Mutator description here"
    Standard mutator attributes.

    Code:
    	RemoteRole=ROLE_SimulatedProxy
    	bAlwaysRelevant=true
    	bAddToServerPackages=true
    }
    These three lines are very important if you want to execute functions client-side.

    The first line indicates that the actor's role on the client is that of a "simulated proxy", meaning we can call functions on it to handle local simulation. This is used for anything that the client needs to create a smooth simulation of - projectiles, the movement of other players, etc.

    The second line indicates that the actor is always relevant, meaning its functions will always be called by every client, and any replicated variables will always be transmitted to all clients. When an actor (such as a projectile) is in view of a player it is considered relevant since the player needs information on the actor's coordinates and it may need to handle local simulation of its movement. As a mutator isn't 'viewed' by a player it'll never be considered relevant, so we use the bAlwaysRelevant attribute to force it to always be relevant to all clients.

    The third line indicates that the mutator package should be included as a standard server package, meaning clients will download it when they connect.

    Writing a client-only section of code

    If you are writing a piece of client-specific code that you don't want the server to execute, you can simply check the NetMode variable:

    Code:
    if (Level.NetMode != NM_DedicatedServer)
    {
    	// Execute client-only code here
    }
    Examples

    Client-side functions

    Code:
    class ExampleMutator extends Mutator;
    
    simulated function Tick(float dt)
    {
    	local RedWhisp RW;
    	
    	foreach DynamicActors(class'KFMod.RedWhisp', RW)
    	{
    		RW.mColorRange[0] = class'Canvas'.static.MakeColor(rand(255),rand(255),rand(255),255);
    		RW.mColorRange[1] = class'Canvas'.static.MakeColor(rand(255),rand(255),rand(255),255);
    	}
    }
    
    defaultproperties
    {
    	GroupName="KFExampleMutator"
    	FriendlyName="Example Mutator"
    	Description="Mutator description here"
    
    	RemoteRole=ROLE_SimulatedProxy
    	bAlwaysRelevant=true
    	bAddToServerPackages=true
    }
    The 'RedWhisp' effect is spawned locally on the client, meaning if we want to change any of its values we must do so on the client.

    Client-side functions II

    Code:
    class ExampleMutator extends Mutator;
    
    simulated function PostBeginPlay()
    {
    	if (Level.NetMode != NM_DedicatedServer)
    		class'KFChar.ZombieClot'.default.AmbientGlow = 255;
    }
    
    defaultproperties
    {
    	GroupName="KFExampleMutator"
    	FriendlyName="Example Mutator"
    	Description="Mutator description here"
    
    	RemoteRole=ROLE_SimulatedProxy
    	bAlwaysRelevant=true
    	bAddToServerPackages=true
    }
    Since the AmbientGlow variable isn't replicated from the server unless the server changes it, we can change it locally and it won't be overwritten by the server's copy.

    Variable replication

    Code:
    class ExampleMutator extends Mutator;
    
    var color TrailColor;
    
    function PostBeginPlay()
    {
    	SetTimer(1, true);
    }
    
    function Timer()
    {
    	TrailColor = class'Canvas'.static.MakeColor(rand(255),rand(255),rand(255),255);
    }
    
    simulated function PostNetReceive()
    {
    	local RedWhisp RW;
    	
    	foreach DynamicActors(class'KFMod.RedWhisp', RW)
    	{
    		RW.mColorRange[0] = TrailColor;
    		RW.mColorRange[1] = TrailColor;
    	}
    }
    
    replication
    {
    	unreliable if (Role == ROLE_Authority)
    		TrailColor;
    }
    
    defaultproperties
    {
    	GroupName="KFExampleMutator"
    	FriendlyName="Example Mutator"
    	Description="Mutator description here"
    
    	RemoteRole=ROLE_SimulatedProxy
    	bAlwaysRelevant=true
    	bAddToServerPackages=true
    	bNetNotify=true
    }
    Here we enable bNetNotify and handle client-side updating of the effect by using the PostNetReceive function which is called after variables have been received.
    Last edited by Benjamin; 10-21-2010, 08:57 PM.

  • #2
    IJC Weapon Pack White V2.7 - server

    How i can use this mod that weapons with IJC Weapon Pack White V2.7 to make it all time in server (and can get achievements)? How code? Thanks for help.

    Comment


    • #3


      How i can use this mod that weapons with IJC Weapon Pack White V2.7 to make it all time in server (and can get achievements)? How code? Thanks for help.

      Comment


      • #4
        good tutorial, thank France.
        [COLOR="Silver"]I'am: ICQ: 411141181 | Skype: dave_scream | vk: [URL="http://vk.com/id4340838"]id4340838[/URL]
        We are: Dr.Killjoy | 3xzet | LLIePLLIeHb | Dave_Scream
        [COLOR="Red"]Our chat:[/COLOR] [URL="http://www.commfort.com/download/commfort_client.zip"]client[/URL] (5.8mb) | server: [U]cs.mod.lt[/U] | channel: [U]KFModding[/U][/COLOR]

        Comment


        • #5
          where can I find a coding reference for killing floor? I was able to find anything under the KillingFloor SDK.
          [URL="https://twitter.com/wbakunis"]Twitter[/URL]
          [URL="http://www.twitch.tv/ionizedreactor"]Twitch channel[/URL]

          Comment


          • #6
            Originally posted by wbakunis View Post
            where can I find a coding reference for killing floor? I was able to find anything under the KillingFloor SDK.
            Try this link http://udn.epicgames.com/Three/UnrealScriptHome.html.

            It's mainly geared towards UE3, but most of the information should be relevant to the current engine.

            Comment

            Working...
            X