Patch Notes ( v.1.0.1046.7 )
• Phoenix: Added detection for forced InGame states because of the Discord WebHooks
• Phoenix: AFK Handling customized in InstantAction for display on the website
• Phoenix: Made several other touchups for the spectator AFK mode
• BASE: Adjustment made for abandoned maps ( spectators no longer count )
• BASE: Various minor adjustments
... Discord WebHooks
With one of the next builds I will implement the possibility for all server operators to send events to their own Discord servers by defining their own WebHooks. For this initial version, newly started rounds with players will be sent directly to the CryServ.de Discord, so you won't miss a game anymore ๐.
... SSM nTEC 2.0
allows the uncomplicated use of all the additional features included in CryServ, such as vehicles with cloaking devices, customizable original purchase menus, placeable and configurable turrets, the perfectly aligned placement of items, vehicles and objects on the ground and the repositioning of these at any time, an Intelli-Reload system that only loads files that have been changed. It uses all of the by now 200 C++ API extensions that the Phoenix Dll has to offer.
Unlike nTEC 1.0, it is now less an interim solution but by far the most modern and feature-rich SSM that was ever published for Crysis Wars, furthermore, as I fear, it will also somewhat exceed the functional scope of the most private SSM versions ( just a hunch ๐๐๐ค ).
If there is interest within CryServ, I will create another version next year, nTEC 3.0. Note: Nothing from nTEC 1.0 is compatible with nTEC 2.0 because the complete structure, function names, variables and the general functionality has changed.
Only one adjustment in this update and only because it was asked to make it optional. If no action is required, then this was the last DLL update for a while.
With the help of the first function it is possible to spawn objects, items, vehicles and so on perfect aligned to the underground, further information for it can be found in the C++ API documentation. The second returns the actual profile name of the player regardless of any changes made on the server. The remaining two added were previously only available for nTEC, and are now available for all.
The Patch Notes of the new CryServ-Client will follow on the weekend, since the changes with 171 noteworthy points have turned out to be very extensive this time, I should summarize and shorten them a bit first.
As a preliminary information, the function for tagging players, as well as the code for the radar ,the map view, the MiniMap ( Nuclear Weapons Symbol ), the markers for explosives as well as the scoreboard have been almost completely replaced. The game no longer crashes when switching between servers or game modes, some more critical parts have been changed ( original code ), the radar as well as the map view can no longer be abused ... and really much, much more ๐.
More information and videos as always on Discord.
» Available from the 2022-08-17.
Patch Notes ( v.2.0.1046.0 )
• The display texts of the Crosshairs have been extended for the classes: Night Vision, Parachute, Binoculars
• Inventory restriction adjusted for the classes: Night Vision, Parachute, Binoculars ( original game errors )
• Added missing localization for the Night Vision ( original game error )
• The maximum range a player can throw C4 has been increased in Strength-Mode
• Throwing in Strength-Mode from Explosives, now requires a minimum energy and also drains energy
• Fixed that Gun Turrets were marked with the Binoculars without being added to the Radar ( original game error )
• Fixed missing or wrong object in the classes: Night Vision, Parachute, Binoculars ( original game errors )
• Fixed the position of the Detonator in hand in 3'th person view ( thanks to Alex626 for this, original game error )
• Various minor adjustments
The revision of the Crosshair is completed with this version. Players can now see directly in a unified way on all items if they already have them in their inventory, if they can pick up ammo or anything else. In addition, the original bug was fixed that players could pick up or receive certain items without effect infinitely often.
... C4 Throw Distance
Additionally contains a sound and energy management so that this feature fits perfectly into the existing original systems ๐. The sound adapts to the throw distance, with the new default value, it can only be heard quietly. If you increase the value, it is played louder and longer, matching the Nanosuit. Also, depending on the throw distance that the server has set, energy is subtracted for the action. If the Nanosuit is deactivated or has too little energy, the throw is made at standard distance.
» Available from the 2022-07-17.
Patch Notes ( v.1.0.1045.0 )
• Phoenix: Inventory restriction adjusted for the classes: Night Vision, Parachute, Binoculars ( original game error )
• Phoenix: Fixed missing or wrong object in the classes: Night Vision, Parachute, Binoculars ( original game errors )
• Phoenix: The Night Vision, Parachute and Binoculars can now be spawned and used normally like all other items
• Phoenix: Added CVar "g_c4ThrowRangeMultStrengthMode" - The maximum throwing distance of C4
• Phoenix: Unification of some unnecessary duplicate CVars for Single- and Multiplayer
• Phoenix: Version number increased to 1.0.1045
• Phoenix: Phoenix.pak updated
• Phoenix: Server.cfg files updated
• Phoenix: Various minor adjustments
• Phoenix: Lua-API-documentation adapted
» Available from the 2022-07-17.
Patch Notes ( v.2.0.1045.0 )
• The display texts for items have been revised, now players can immediately see what they already have in the inventory
• Added support for additional collectible ammunition for the Rocket Launcher
• Fixed several bugs in the automatic target acquisition system ( original game errors )
• Fixed a bug in the zoom mode of the TAC-Launcher ( target crosshair was not present there, original game error )
• Zoom mode of the TAC-Launcher reactivated
• Various minor adjustments
» Available from the 2022-07-02.
Patch Notes ( v.1.0.1044.0 )
• Phoenix: Added CVar "g_rocketLauncherAutoDrop" - Whether players drop the Rocket Launcher when the ammunition is exhausted
• Phoenix: Added CVar "g_rocketLauncherCapacityLimit" - Maximum munition capacity of the Rocket Launcher
• Phoenix: Added CVar "g_rocketLauncherAmmoCount" - Standard ammunition count of the rocket launcher
• Phoenix: CVar "g_autoAimRocketLauncher" renamed to "g_rocketLauncherAutoAim" - Name harmonization
• Phoenix: Version number increased to 1.0.1044
• Phoenix: Various minor adjustments
• Phoenix: Server.cfg files updated
• Phoenix: Lua-API-documentation adapted
» Available from the 2022-07-02.
Patch Notes ( v.2.0.1044.0 )
• It is now possible to repair vehicles of the opposing team ( nonsensical queries for something nobody does anyway )
• It is now possible to hack Gun Turrets with the "LockpickKit"
• It is now possible to temporarily disable Gun Turrets with EMP attacks
• Gun Turrets now play status sounds when they are repaired or hacked ( when hacking only if they have not been deactivated )
• Damaged Gun Turrets can now be repaired as originally intended ( original game error )
• Repaired Gun Turrets are now also visually displayed correctly ( original game error )
• Gun Turrets now work fully and as intended after a repair ( original game error )
• Sound bug fixed regarding Gun Turrets ( original game error )
• Gun Turrets can now be detected by an automatic homing system ( for example from the rocket launcher )
• Added support for team related SpawnPoint's in TeamAction ( SpawnPoint's with assigned TeamIds )
• Explosives can no longer be unarmed with an "RepairKit" but only with an "LockpickKit"
• SPARC damage value reduced from 400 to 250 per shot
• Various minor adjustments
... Gun Turrets
The Gun Turrets have been extended by some additional possibilities, they now work in all game modes and can also be supplemented by a SSM there afterwards. It is now possible to repair them as originally intended when damaged, even if they were completely destroyed. If there is no manual repair, it will be done automatically after the set time.
Furthermore, it is possible to hack Gun Turrets, in PowerStruggle and TeamAction, these then attack the other team for a limited time. In InstantAction, on the other hand, you can only disable them for a longer period of time. Additionally it is possible to deactivate them for a short time by an EMP attack - This possibility suits the gun turret hacking gameplay, as you can still hack a gun turret that is deactivated in this way. It is always possible to hack the Gun Turret again to restore the previous state. If a Gun Turret was completely destroyed, it will of course function correctly again after repair. More information on this topic can be found in Discord.
All features mentioned here require a corresponding configuration on the server side to be used!
... Disarming Explosives
A "RepairKit" should really only be able to repair things, whereas the "LockpickKit" is already intended in the game to overcome a security device, by breaking into enemy vehicles. It is therefore only logical to use it for unarming explosives as well as for the newly added hacking gameplay. This change also gives this item a little more importance.
» Available from the 2022-06-25.
Patch Notes ( v.1.0.1043.0 )
• Phoenix: Added C++ API Function "g_gameRules.game:DefinedSpawnLocations()"
• Phoenix: Added C++ API Function "entity.item:IsGunTurret()"
• Phoenix: Added C++ API Function "entity.item:IsHackable()"
• Phoenix: Added C++ API Function "entity.item:IsRepairable()"
• Phoenix: Added C++ API Function "entity.item:OnHacked()"
• Phoenix: Added C++ API Function "entity.item:SetOperationDefaults(vehiclesOnly,airVehiclesOnly,searchOnly,surveillance)"
• Phoenix: Added C++ API Function "entity.item:SetRangeLimits(mg,rocket,tac)"
• Phoenix: Added C++ API Function "entity.item:GetTeamId()"
• Phoenix: Added C++ API Function "entity.item:SetTeamId(teamId)"
• Phoenix: Added C++ API Function "entity.item:Activate(enable)"
• Phoenix: Added CVar "g_gunTurretActiveWithoutFaction" - Whether neutral Gun Turrets are active and should attack everyone
• Phoenix: Added CVar "g_gunTurretFindCloaked" - Whether to react to cloaked players, vehicles
• Phoenix: Added CVar "g_gunTurretAimTACShells" - Whether to respond to TAC shelling
• Phoenix: Added CVar "g_gunTurretTACShellsDetectionDelay" - Delay time until reaction
• Phoenix: Added CVar "g_gunTurretMaxHealth" - Gun Turret Health/HitPoints
• Phoenix: Added CVar "g_gunTurretRepairDelay" - Delay until automatic repair of a Gun Turret
• Phoenix: Added CVar "g_gunTurretEMPDowntime" - Downtime after an EMP attack on a Gun Turret
• Phoenix: Added CVar "g_gunTurretHackedResetDelay" - Delay until a hacked Gun Turret will be reset
• Phoenix: Fixed a bug that caused that Gun Turrets could not be spawned and configured server-side ( original game error )
• Phoenix: Fixed a bug that caused Gun Turrets could not be repaired ( original game error )
• Phoenix: Fixed a bug that caused Gun Turrets not to work correctly after repairing them ( original game error )
• Phoenix: Hacking gameplay added, Gun Turrets can now be hacked using the "LockpickKit"
• Phoenix: Explosives can no longer be unarmed with an "RepairKit" but only with an "LockpickKit"
• Phoenix: Added support for team related SpawnPoint's in TeamAction ( SpawnPoint's with assigned TeamIds )
• Phoenix: It is now possible to repair the vehicles of the opposing team
• Phoenix: SPARC damage value reduced from 400 to 250 per shot
• Phoenix: Version number increased to 1.0.1043
• Phoenix: Various minor adjustments
• Phoenix: Phoenix.pak updated
• Phoenix: Server.cfg files updated
• Phoenix: Lua-API-documentation adapted
Almost everything that has been added can be configured via CVars and can also be used independently of an SSM in Vanilla, for example. The default values are preconfigured in C++ so that none of the additional functions are active by default. As always, you can use the advanced features - but you don't have to. If you are looking for more information about the update, it can be found in Discord as usual.
» Available from the 2022-06-25.
Patch Notes ( v.2.0.1043.1 )
• Various minor adjustments and optimizations
The advantages of the new handling are that players have more energy left for trick jumps and also impulse-based mods can now be used with a clear conscience without frustration caused by them.
» The new game client is now available for download.
Patch Notes ( v.1.0.1042.1 )
• Phoenix: Various minor adjustments and optimizations
Introduction
The presented project started already in 2011, at that time still in a pure Lua implementation with many compromises and partly with cumbersome solutions. But now to this version ๐ ...
The goal of this idea was to be able to equip vehicles like the Nanosuit itself with a controllable camouflage function. Whether for strategic moves, as a surprise effect or just to be able to do it for the coolness. This should fit as naturally as possible into the existing gameplay and perhaps even bring additional advantages with it without becoming or seeming unfair.
Basic Functions
The implementation of the actual function took place completely in C++ on the client as well as server side. To allow the users/modders nevertheless different application scenarios, C++ Lua-API functions were added which allow the control of the functionality. I based the implementation on the behavior of the Nanosuit itself, this unification is more transparent for players and also contains, already pragmatic solutions.
If a vehicle is equipped with a cloaking-device, it couples with the driver's Nanosuit and can then be controlled by him. If a shot is fired in the camouflaged state or the vehicle is destroyed, the camouflage is immediately deactivated. The function is energy-dependent, the consumption of this can be configured differentiated via a CVars, the display of which takes place via the energy display of the Nanosuit.
In the cloaked state, in addition to the radar restrictions, it is not possible to lock the vehicle with an automatic targeting device - however, turrets were not considered for strategic reasons. Vehicles with a cloaking device always spawn in a cloaked state, which can make finding them difficult at times.
Applications
The usage described here corresponds to my own integration in SSM iTEC as well as nTEC 2.0, this may well differ from that in other SSM versions and is not predetermined.
It is possible to equip a percentage of vehicles with a cloaking-device set in the configuration, these vehicles are randomly selected and usually differ every round. Furthermore, via the Chat-Command /vehicle vehicles can be spawned directly with such a feature and these can also be permanently added to a map via the LevelSetup-System. There is also a chat command to add or remove a cloaking-device from a vehicle.
Used C++ Lua-API Functions
➔ g_gameRules.game:HasVehicleCloakingDevice( vehicleId )
➔ g_gameRules.game:IsVehicleCloakingDeviceActivated( vehicleId )
➔ g_gameRules.game:IsVehicleCloakingDeviceOwner( vehicleId, playerId )
➔ g_gameRules.game:SetVehicleCloakingDeviceOwner( vehicleId, playerId )
➔ g_gameRules.game:DestroyVehicleCloakingDevice( vehicleId, removeDevice )
➔ g_gameRules.game:UpdateVehicleCloakingDevice( vehicleId, enable )
➔ CVar: g_vehicleCloakEnergyDrainAdjuster < float value >
Development Time
From the first tests to the completion of the actual C++ functionality took about 30 hours. There were some pitfalls in the implementation that required different approaches until a solution was finally found that was free of all vulnerabilities. The Lua integration, on the other hand, was unproblematic and completed in about two hours.
Preface
The presented project here is part of the LevelSetup-System of SSM iTEC. Since this system is very extensively developed in iTEC and already allows a wide range of changes to maps, it was a suitable and also very pragmatic addition to the existing. In short I simply wanted to have this possibility implemented ๐.
Function
Prebuilt groups can be imported directly from the Sandbox2, either statically, assigned to a specified map, or dynamically, spawnable anywhere and on any map. It is possible to create own Prefabs in the game ( temporary for duplication processes or permanent ), to unpack existing ones or to extend them, as well as to adjust the scaling, the position and also rotation arbitrarily and at any time afterwards.
The Prefabs can be identified like objects by means of the additional Silhouette-System implemented in CryServ ( the two originally included ones are not suitable for this ). It is possible to spawn them ( like everything else in iTEC ) automatically aligned based on the ground ( Snap 2 Group ). Additionally all original Prefabs available in the game can be used if imported. Due to the own and optimized spawn system for entities, it was possible to spawn nearly 10.000 entries without causing laggs on the server or client-side in the load test.
Applications
Possible application scenarios considered the simplest possible and most pragmatic expansion and modification of existing maps, as well as the possibility that the static system would make it more difficult for third parties to use the maps unintentionally ( on such a customized map, there is not much more in the download version for players than the Terrain and the ToD ).
Used C++ Lua-API Functions ( additional functions only )
➔ g_gameRules.game:GetWorldPos( posLocal, posGlobal, anglesGlobal, scaleGlobal )
➔ g_gameRules.game:GetWorldAngles( anglesLocal, anglesGlobal )
➔ g_gameRules.game:GetWorldScale( vectorLocal, scaleGlobal )
➔ g_gameRules.game:IsAnglesEquivalent( angles, comparative )
➔ g_gameRules.game:SpawnEntity( params )
➔ g_gameRules.game:MoveEntity( entityId, pos, angles )
➔ g_gameRules.game:IntegrateCustomObject( entityId )
➔ g_gameRules.game:EntitySilhouette( entityId, color )
➔ g_gameRules.game:GetGroupData( file )
➔ g_gameRules.game:GetLevelSpecificGroupData( file )
Development Time
From the first tests to the basic functions took about 30 hours, but all the subtleties and necessary changes that this system entailed, up to the final optimization and polish took another 90 hours, so about 120 hours in total. However, I was able to fall back on some features that are already part of the SSM, otherwise it would have been a few hours more.
Introduction
The presented project is a plugin for the SSM iTEC. The goal of this idea was to be able to spawn a freely placeable platform in every map, that is as close as possible to what one would understand by a real Portal.
Also, all the problems that teleportation causes in the game should be eliminated with this project, problems like the possibility that players can flee directly from the place of battle, the missing possibility that their counterpart can follow them or that you can not get in a group together to the same destination in a way that integrates into the gameplay.
Function
Portals can be permanently added to any map, these teleport one or more players simultaneously to the configured destination portal when they enter it ( the last destination is always saved 10 seconds after the last teleportation, so another player can reach the same destination, if he wants to follow ). The destination can be random or predetermined, and it is also possible to define arrival conditions.
Applications
Possible application scenarios considered were ( of course ) the general overcoming of larger distances and thus the possibility to make larger maps more attractive for smaller game groups as well as a replacement for direct teleportation back to headquarters, with the usual Chat-Command "/base" in Power-Struggle games.
Features
➔ Checking the dimensions when spawning whether it can be placed at all in the place
➔ Check for possible additional interfering factors during spawning like spawn points, players, vehicles
➔ Checking the angle of inclination of the ground when spawning ( to ensure proper function )
➔ Automatic alignment, adjustment to the ground ( Snap 2 Ground )
➔ Anytime subsequent adjustment of the X, Y, Z -axis as well as rotation of an Portal
➔ Several axes can be changed at the same time ( 1-4 variables possible )
➔ Automatic straightening of a Portal when it is placed floating
➔ Different arrival conditions can be set ( Prestige Points, Team related )
➔ Anytime subsequent adjustment of the arrival conditions as well as linkings
➔ Automatic linking in pairs as default configuration
➔ The Portals can be linked together as desired or used only as an arrival platform
➔ All sounds can be heard in the immediate vicinity at a volume corresponding to the distance
➔ All entity types are supported ( Players, Grunts, Items and so on, except Vehicles, because of their size )
➔ Preservation of the last destination for 10 seconds each time after the last teleportation ( Memory-Mode )
➔ The teleportation height is taken as arrival height for small entities like Items as example
➔ The effect size as well as position is always adjusted to the respective entity
➔ Five possible points of arrival at each Portal, which are checked for possible disruptive factors in advance
➔ Defense system against blocking with vehicles
➔ Unproblematic operation even at high speeds, i.e. in Speed-Mode of the Nanosuit or in free fall
➔ Information system for players if no link to a destination is configured
➔ Display of the set values when entering an Portal in protected mode
➔ Listing option of all Portals placed on a map incl. their respective configuration
➔ The database supports the Intelli-Reload system of the SSM
➔ Visual integration into a map by aligning the environment layers ( Frozen, Wet, ... )
➔ Optimized code structure, no unnecessary or cumbersome calculation, generation of tables and so on โฆ
Used C++ Lua-API Functions ( only additional or adapted functions )
➔ g_gameRules.game:GetCurrentLevel()
➔ g_gameRules.game:PurgeAreaOfClaymores( position, radius, teamId )
➔ g_gameRules.game:SoundEvent( entityId, sound, radius=100, volume=10 )
➔ g_gameRules.game:MoveEntity( entityId, pos, angles )
➔ g_gameRules.game:MovePlayer( playerId, pos, angles )
➔ g_gameRules.game:AnglesToVectors( angles )
➔ g_gameRules.game:GetWorldAngles( anglesLocal, anglesGlobal )
➔ g_gameRules.game:IntegrateCustomObject( entityId )
➔ g_gameRules.game:SpawnEntity( params )
Development Time
From the first tests to the final optimization and polish, it took me about 35 hours. However, I was able to fall back on some features that are already part of the SSM, otherwise it would have been a few hours more.
Supplementary
The initial design of the portal consists of several original objects and was spawned as a prefab. Dj Copniker kindly created a suitable and optimized object for this project. Thanks for this support to him ๐.
Patch Notes ( v.2.0.1041.2 )
• The recently added chat and third-person features explained in the PDF documentation
• PDF documentation generally revised
• Various minor adjustments
I will adapt the PDF manual for the client in the next days, so that the additional chat functions as well as these control options for the Third-Person-Mode are also explained in it.
» The new game client is now available for download.
Patch Notes ( v.1.0.1041.1 )
• Phoenix: Changed handling when trying to bypass the master server
• BASE: Predefined anticheat exceptions for maps extended by two entries
Introduction
The presented project is a Plugin for the SSM iTEC. The goal of this idea was to be able to spawn a freely placeable platform in every map, where both the impulse strength and the impulse tilt angle can be adjusted.
Function
Impulse-Pads can be permanently added to any map, which will accelerate a player when he enters it by means of a physical impulse in the respective configured direction with the configured strength.
Applications
Possible application scenarios considered were overcoming chasms, height differences or simply having fun with the jump itself.
Features
➔ Checking the dimensions when spawning whether it can be placed at all in the place
➔ Check for possible additional interfering factors during spawning like spawn points, players, vehicles
➔ Checking the angle of inclination of the ground when spawning ( to ensure proper function )
➔ Automatic alignment, adjustment to the ground ( Snap 2 Ground )
➔ Anytime subsequent adjustment of the X, Y, Z -axis as well as rotation of an Impulse-Pad
➔ Several axes can be changed at the same time ( 1-4 variables possible )
➔ Anytime subsequent adjustment of the impulse strength and impulse tilt angle
➔ Visual animated illustration of the set impulse tilt angle
➔ Detection of the walking direction and thus no faulty triggering
➔ Acoustic feedback in case of wrong walking direction
➔ Acoustic feedback during an impulse
➔ All sounds can be heard in the immediate vicinity at a volume corresponding to the distance
➔ All entity types are supported ( Players, Grunts, Items and so on, except Vehicles, because of their size )
➔ Unproblematic operation even at high speeds, i.e. in the Speed-Mode of the Nanosuit
➔ Information system for players in case of no configuration ( out of order )
➔ Display of the set values when entering an Impulse-Pad in protected mode
➔ Listing option of all Impulse-Pads placed on a map incl. their respective configuration
➔ The database supports the Intelli-Reload system of the SSM
➔ The maximum range achieved with a configured impulse is always the same for all entities
➔ Visual integration into a map by aligning the environment layers ( Frozen, Wet, ... )
➔ Optimized code structure, no unnecessary or cumbersome calculation, generation of tables and so on …
Used C++ Lua-API Functions ( additional functions only )
➔ g_gameRules.game:GetCurrentLevel()
➔ g_gameRules.game:AddImpulse( playerId, direction, impulse, position )
➔ g_gameRules.game:SoundEvent( entityId, sound, radius=100, volume=10 )
➔ g_gameRules.game:GetWorldAngles( anglesLocal, anglesGlobal )
➔ g_gameRules.game:IntegrateCustomObject( entityId )
➔ g_gameRules.game:SpawnEntity( params )
Development Time
From the first tests to the final optimization and polish, it took me about 15 hours. However, I was able to fall back on some features that are already part of the SSM, otherwise it would have been a few hours more.
Why this Project Presentation
CryServ was in the first version from 2014 until the end of 2019 very limited in its modding possibilities. Since this is no longer the case in the new version 2.0, which has been rewritten from scratch, I would simply like to present various projects to show the possibilities with examples.
