Command and Conquer: Renegade Official Forums - RDF feed
C&C: Renegade --> Dying since 2003™, resurrected in 2024!
Scripts 4.2 to enter private beta testing soon, here are some changes in it
Scripts 4.2 is getting closer to being ready to enter private beta testing for Renegade players (I just finished some checking I wanted to do on the saveload code for .ldd files, .lsd files and .ddb files for example) Here is a list of some of the interesting changes in 4.2 (by no means exhaustive, this is just what I can remember or pick up on from reading my notes and stuff) Building Revival support (via console commands and via engine calls). Changes so that stuff flying in when purchased via AirFactory objects cant be shot whilst its flying in. Fix so that objects with their collision mode in LE set to "KILL" work correctly. Extra debugs for detecting certain kinds of network issues including packets that are too large. More to come later, still going through my notes and info looking for changes worth mentioning.
Re: Scripts 4.2 to enter private beta testing soon, here are some changes in it
Awesome
Ok, on with the list of interesting changes in 4.2: New settings under "Global Settings - C&C Mode Settings" that let you have different EVA sounds for power offline (you can now have one that plays for Nod when Nod power goes offline, GDI when Nod power goes offline, Nod when GDI power goes offline and GDI when GDI power goes offline) New collision group DEFAULT_AND_SOLDIER_ONLY_COLLISION_GROUP which collides only with DEFAULT, SOLDIER and SOLDIER_GHOST. Fix a whole bunch of bugs (far too many to list here) Change "construction yard" objects so they will now repair objects of type "simple" if they have their Encyclopedia Type set to "building". Fix to some issues with certain kinds of texture mappers not rendering properly (environment mappers I believe are the main ones affected) Fix some glitches with damageablestatic physics objects Fix an issue that can be caused if you have a TT package containing a dazzle.ini file. Fix some issues with fog. Improve the way NavalFactoryGameObj detects objects blocking the spawn point (it now does it more like VehicleFactoryGameObj) Fix some issues with pathfinding where it wasn't correctly loading certain pieces of pathfinding data. Changes to make Commands->Set_Is_Rendered work over the network for things other than vehicles (it always worked for vehicles). Naturally both client and server need 4.2 for this to work. Fix an issue where the muzzle flash on a vehicle can screw up if its model or weapon is changed. Fix an issue with Commands->Set_Obj_Radar_Blip_Color so it works properly Changes so that spies will always appear on radar with the color of the player object regardless of which team the player is on. Fix so that the "battle info" dialog box displays the correct harvester health on the client. Also fixes the vehicle limit to correctly account for the harvester. Fix an issue where Commands->Create_2D_Sound and Commands->Create_2D_WAV_Sound can cause a crash in certain circumstances. Add a new keyword to server.ini, DisableLogs which disables writing to the normal server log file (useful if you are using SSGM or something and handle the log info some other way) Fix an issue where if a soldier is destroyed (e.g. via suicide, team change or leaving the server) and the soldier was in a vehicle, certain objects weren't being properly destroyed. Fix an issue with certain dialogue that soldiers say (it was mixing up the sounds for "I got shot by friendly"/"I got shot by enemy" and "I got killed by friendly"/"I got killed by enemy" Fix some issues related to ladder collisions. Improve the randomness of spawn point selection. Improve certain math functions to use SSE (makes it slightly faster) Remove sysinfo.txt code and a bunch of related stuff (it didn't support detection logic for modern current hardware anyway) Add a bunch of scripts from Jerad Grey Some fixes to the special Mendoza and Raveshaw boss objects. Fix an issue with movies in single player causing a crash Fix an issue with the single player EVA map dialog causing a crash Added a change so that homing weapons won't target objects that are immovable (that is, anything who's physics type isn't MoveablePhys and that isn't stuck to another object via Attach_To_Object_Bone) Fix an issue with radar in single player Fixes to vehicle dazzles to make them work like stock Code to make the volume of movies (startup movie and mission movies) reflect the setting of the "cinematic" slider in the config options. Improve the randomness of the team remix code New TargetingRange field on Ammo definitions that defines the targeting range (independently of the weapon range). If its set to the default (or not set at all) it will use the normal weapon range. Add a cooldown timer to SH_UndergroundVehicle. Add new custom CUSTOM_EVENT_BUILDING_REVIVED which is sent when a building is revived (to allow any scripts to do things they need to) Fix RA_MAD_Tank_Devolved so it properly destroys the tank when its set off. New script Reborn_IsDeployableTank_4 which is a clone of Reborn_IsDeployableTank_3 except that it will only deploy if you are close enough to the ground. Various fixes to deployable vehicle scripts Fixes to the obelisk and AGT scripts so they wont target the AI-controlled harvester Fix an issue with JFW_Spawn_Zone_Created, JFW_Custom_Spawn_Zone, dp88_Ore_Field, dp88_buildingScripts_functionSpawnTeamZone, dp88_buildingScripts_functionSpawnZone, dp88_conquestControlZone, JFW_Vehicle_Zone and JFW_Building_Zone_Controller where the zone rotation value was being interpreted as radians instead of degrees. Restore M00_BuildingStateSoundSpeaker and M00_BuildingStateSoundController so they work like stock. Add an error message to JFW_Turret_Spawn_3 for if the turret object cant be spawned. New script JFW_Time_Remaining_Sounds_2 which is just like JFW_Time_Remaining_Sounds except per-team New script JFW_Repair_Complete_Sound which will play any time the health or shield strength of the object goes below 100% then comes back to 100%. Fixes to JFW_Time_Remaining_Sounds/JFW_Time_Remaining_Sounds_2 so that they play the sounds properly if the time remaining is changed. Note that each sound will play only once even if the time remaining is increased to the point where the sound would have played again. Change JFW_Attack_Location/JFW_Attack_Object so that they will only immobilize the vehicle if the speed parameter is zero. New script JFW_Airstrike_Cinematic which basically spawns a cinematic at the location of the object JFW_Airstrike_Cinematic is attached to on receiving a specific custom. New script JFW_Ion_Storm_Weather_2 which is able to store the old weather settings before the ion storm starts and restore them after its finished. New script JFW_Spy_Disguise_Target which, when shot with a specific warhead, changes the model of the thing that did the shooting to the model of the object with JFW_Spy_Disguise_Target on it. Its intended so that spies can "target" specific infantry units to disguise themselves as that unit. New script JFW_Warhead_Custom which sends a custom when hit with a specific warhead. Fixes to various scripts (base defenses, construction yard scripts etc) to account for building revival Fix an issue with RA_Gap_Generator_Vehicle not correctly displaying the shroud when you first enter the vehicle. Fix a bug with vehicle name display New engine call Seconds_To_Hms which converts a value in seconds to hours/minutes/seconds. Update various scripts and engine calls so they will now damage/repair objects of type "simple" if they have their Encyclopedia Type set to "building". (this is for things like the Gap Generator in APB that is now a Simple object instead of a vehicle) Improvements to danpaul's veterancy scripts Various netcode fixes Improvements to the chat code Change the mlist console command so it displays all the maps if you don't pass any parameter Hide dazzles on stealthed vehicles Make the NoPowerCostMultiplier and BuildTimeDelay tt.ini keywords usable in the per-map tt.ini files Add tt.ini keywords (usable in the per-map tt.ini files like the rest of the sidebar stuff) for per-team sidebar sounds. Fixes to how the time limit/time remaining changes get sent over the network so they work better. Add a GetTTRevision engine call to get the current build number (the one displayed on the main menu or by the sversion console command) from scripts. Add engine calls Get_Clouds, Get_Lightning, Get_Wind, Get_Rain, Get_Snow, Get_Ash that do exactly what they say. Add an Update_Game_Options engine call to force sending new game options if they have been changed. Add a new engine call Update_Network_Object_Player which is just like Update_Network_Object but per-player. Improvements to the way we detect a missing d3dx dll Some fixes to AI code used for VTOLs. Fixes to sphere and ring primitives Fix some issues in various pieces of saveload code. New Find_Observer function on ScriptableGameObj. Fix so that dead soldiers wont collect powerups New CanRefill flag on soldiers that determines if a soldier can use refills or not. This only works for the sidebar and should not be turned off if your mod/map/etc uses the normal PT dialogs. Fix gamespy master server addresses to point to the new community-run GSA clone now that the official ones are gone. New GDIPurchaseReportID and NodPurchaseReportID on vehicles, these strings (and associated sounds) will be played on vehicle purchase. New CanRepair flag on vehicles, determines if Repair Bay objects (and various repairing scripts) can repair the vehicle or not. New EntryHelpMessage and EntryHelpMessageColor values on vehicles, if this is set then the message will be displayed in the center of the screen when the vehicle is entered. Intended for help messages like "press Q to deploy this vehicle". New flag ApplySurfaceEffectDamage on vehicles which makes vehicles take surface effect damage. New flag DisableSurfaceSounds on vehicles which turns off track/wheel sounds for the vehicle. New Check_If_On_Surface function on vehicles to let you check if a vehicle is touching a given surface type. Fix to dp88_AR_Rocketeer to play the engine stop sound when the jetpack vehicle goes away. Various fixes to dp88_AR_MirageTank. Improvements to the AGT script. Various fixes to dp88_AR_Deployable_Infantry including a new deploy/undeploy sound Various fixes to dp88_Ore_Miner Various fixes to dp88_Ore_Field Various fixes to dp88_Ore_Extractor Various fixes to dp88_RemoteControlConsole Various fixes to dp88_AR_Paradrop Various fixes to dp88_linkHealth Various fixes to dp88_buildingScripts_controller Various fixes to dp88_buildingScripts_functionMoneyTrickle Various fixes to dp88_buildingScripts_functionMoneyGrant Various fixes to danpaul's AI scripts Various fixes to dp88_damageAnimation Various fixes to dp88_conquestController Various fixes to dp88_conquestControlZone Various fixes to dp88_Ammo_Animation Various fixes to dp88_RegenerateHitpoints Thank you to WhiteDragon, Saberhawk, StealthEye, danpaul and Jerad Grey (and anyone I forgot) for their contributions to 4.2
jonwil wrote on Sat, 20 December 2014 16:44 Ok, on with the list of interesting changes in 4.2: New settings under "Global Settings - C&C Mode Settings" that let you have different EVA sounds for power offline (you can now have one that plays for Nod when Nod power goes offline, GDI when Nod power goes offline, Nod when GDI power goes offline and GDI when GDI power goes offline) New collision group DEFAULT_AND_SOLDIER_ONLY_COLLISION_GROUP which collides only with DEFAULT, SOLDIER and SOLDIER_GHOST. Fix a whole bunch of bugs (far too many to list here) Change "construction yard" objects so they will now repair objects of type "simple" if they have their Encyclopedia Type set to "building". Fix to some issues with certain kinds of texture mappers not rendering properly (environment mappers I believe are the main ones affected) Fix some glitches with damageablestatic physics objects Fix an issue that can be caused if you have a TT package containing a dazzle.ini file. Fix some issues with fog. Improve the way NavalFactoryGameObj detects objects blocking the spawn point (it now does it more like VehicleFactoryGameObj) Fix some issues with pathfinding where it wasn't correctly loading certain pieces of pathfinding data. Changes to make Commands->Set_Is_Rendered work over the network for things other than vehicles (it always worked for vehicles). Naturally both client and server need 4.2 for this to work. Fix an issue where the muzzle flash on a vehicle can screw up if its model or weapon is changed. Fix an issue with Commands->Set_Obj_Radar_Blip_Color so it works properly Changes so that spies will always appear on radar with the color of the player object regardless of which team the player is on. Fix so that the "battle info" dialog box displays the correct harvester health on the client. Also fixes the vehicle limit to correctly account for the harvester. Fix an issue where Commands->Create_2D_Sound and Commands->Create_2D_WAV_Sound can cause a crash in certain circumstances. Add a new keyword to server.ini, DisableLogs which disables writing to the normal server log file (useful if you are using SSGM or something and handle the log info some other way) Fix an issue where if a soldier is destroyed (e.g. via suicide, team change or leaving the server) and the soldier was in a vehicle, certain objects weren't being properly destroyed. Fix an issue with certain dialogue that soldiers say (it was mixing up the sounds for "I got shot by friendly"/"I got shot by enemy" and "I got killed by friendly"/"I got killed by enemy" Fix some issues related to ladder collisions. Improve the randomness of spawn point selection. Improve certain math functions to use SSE (makes it slightly faster) Remove sysinfo.txt code and a bunch of related stuff (it didn't support detection logic for modern current hardware anyway) Add a bunch of scripts from Jerad Grey Some fixes to the special Mendoza and Raveshaw boss objects. Fix an issue with movies in single player causing a crash Fix an issue with the single player EVA map dialog causing a crash Added a change so that homing weapons won't target objects that are immovable (that is, anything who's physics type isn't MoveablePhys and that isn't stuck to another object via Attach_To_Object_Bone) Fix an issue with radar in single player Fixes to vehicle dazzles to make them work like stock Code to make the volume of movies (startup movie and mission movies) reflect the setting of the "cinematic" slider in the config options. Improve the randomness of the team remix code New TargetingRange field on Ammo definitions that defines the targeting range (independently of the weapon range). If its set to the default (or not set at all) it will use the normal weapon range. Add a cooldown timer to SH_UndergroundVehicle. Add new custom CUSTOM_EVENT_BUILDING_REVIVED which is sent when a building is revived (to allow any scripts to do things they need to) Fix RA_MAD_Tank_Devolved so it properly destroys the tank when its set off. New script Reborn_IsDeployableTank_4 which is a clone of Reborn_IsDeployableTank_3 except that it will only deploy if you are close enough to the ground. Various fixes to deployable vehicle scripts Fixes to the obelisk and AGT scripts so they wont target the AI-controlled harvester Fix an issue with JFW_Spawn_Zone_Created, JFW_Custom_Spawn_Zone, dp88_Ore_Field, dp88_buildingScripts_functionSpawnTeamZone, dp88_buildingScripts_functionSpawnZone, dp88_conquestControlZone, JFW_Vehicle_Zone and JFW_Building_Zone_Controller where the zone rotation value was being interpreted as radians instead of degrees. Restore M00_BuildingStateSoundSpeaker and M00_BuildingStateSoundController so they work like stock. Add an error message to JFW_Turret_Spawn_3 for if the turret object cant be spawned. New script JFW_Time_Remaining_Sounds_2 which is just like JFW_Time_Remaining_Sounds except per-team New script JFW_Repair_Complete_Sound which will play any time the health or shield strength of the object goes below 100% then comes back to 100%. Fixes to JFW_Time_Remaining_Sounds/JFW_Time_Remaining_Sounds_2 so that they play the sounds properly if the time remaining is changed. Note that each sound will play only once even if the time remaining is increased to the point where the sound would have played again. Change JFW_Attack_Location/JFW_Attack_Object so that they will only immobilize the vehicle if the speed parameter is zero. New script JFW_Airstrike_Cinematic which basically spawns a cinematic at the location of the object JFW_Airstrike_Cinematic is attached to on receiving a specific custom. New script JFW_Ion_Storm_Weather_2 which is able to store the old weather settings before the ion storm starts and restore them after its finished. New script JFW_Spy_Disguise_Target which, when shot with a specific warhead, changes the model of the thing that did the shooting to the model of the object with JFW_Spy_Disguise_Target on it. Its intended so that spies can "target" specific infantry units to disguise themselves as that unit. New script JFW_Warhead_Custom which sends a custom when hit with a specific warhead. Fixes to various scripts (base defenses, construction yard scripts etc) to account for building revival Fix an issue with RA_Gap_Generator_Vehicle not correctly displaying the shroud when you first enter the vehicle. Fix a bug with vehicle name display New engine call Seconds_To_Hms which converts a value in seconds to hours/minutes/seconds. Update various scripts and engine calls so they will now damage/repair objects of type "simple" if they have their Encyclopedia Type set to "building". (this is for things like the Gap Generator in APB that is now a Simple object instead of a vehicle) Improvements to danpaul's veterancy scripts Various netcode fixes Improvements to the chat code Change the mlist console command so it displays all the maps if you don't pass any parameter Hide dazzles on stealthed vehicles Make the NoPowerCostMultiplier and BuildTimeDelay tt.ini keywords usable in the per-map tt.ini files Add tt.ini keywords (usable in the per-map tt.ini files like the rest of the sidebar stuff) for per-team sidebar sounds. Fixes to how the time limit/time remaining changes get sent over the network so they work better. Add a GetTTRevision engine call to get the current build number (the one displayed on the main menu or by the sversion console command) from scripts. Add engine calls Get_Clouds, Get_Lightning, Get_Wind, Get_Rain, Get_Snow, Get_Ash that do exactly what they say. Add an Update_Game_Options engine call to force sending new game options if they have been changed. Add a new engine call Update_Network_Object_Player which is just like Update_Network_Object but per-player. Improvements to the way we detect a missing d3dx dll Some fixes to AI code used for VTOLs. Fixes to sphere and ring primitives Fix some issues in various pieces of saveload code. New Find_Observer function on ScriptableGameObj. Fix so that dead soldiers wont collect powerups New CanRefill flag on soldiers that determines if a soldier can use refills or not. This only works for the sidebar and should not be turned off if your mod/map/etc uses the normal PT dialogs. Fix gamespy master server addresses to point to the new community-run GSA clone now that the official ones are gone. New GDIPurchaseReportID and NodPurchaseReportID on vehicles, these strings (and associated sounds) will be played on vehicle purchase. New CanRepair flag on vehicles, determines if Repair Bay objects (and various repairing scripts) can repair the vehicle or not. New EntryHelpMessage and EntryHelpMessageColor values on vehicles, if this is set then the message will be displayed in the center of the screen when the vehicle is entered. Intended for help messages like "press Q to deploy this vehicle". New flag ApplySurfaceEffectDamage on vehicles which makes vehicles take surface effect damage. New flag DisableSurfaceSounds on vehicles which turns off track/wheel sounds for the vehicle. New Check_If_On_Surface function on vehicles to let you check if a vehicle is touching a given surface type. Fix to dp88_AR_Rocketeer to play the engine stop sound when the jetpack vehicle goes away. Various fixes to dp88_AR_MirageTank. Improvements to the AGT script. Various fixes to dp88_AR_Deployable_Infantry including a new deploy/undeploy sound Various fixes to dp88_Ore_Miner Various fixes to dp88_Ore_Field Various fixes to dp88_Ore_Extractor Various fixes to dp88_RemoteControlConsole Various fixes to dp88_AR_Paradrop Various fixes to dp88_linkHealth Various fixes to dp88_buildingScripts_controller Various fixes to dp88_buildingScripts_functionMoneyTrickle Various fixes to dp88_buildingScripts_functionMoneyGrant Various fixes to danpaul's AI scripts Various fixes to dp88_damageAnimation Various fixes to dp88_conquestController Various fixes to dp88_conquestControlZone Various fixes to dp88_Ammo_Animation Various fixes to dp88_RegenerateHitpoints Thank you to WhiteDragon, Saberhawk, StealthEye, danpaul and Jerad Grey (and anyone I forgot) for their contributions to 4.2 Great news. Glad to see a lot of the stuff I suggested and even provided code for made it in. Super glad that my suggestion about immovable objects and homing was implemented.
Nice work guys
Very nice, thank you again for all you do jonwil and the tt team!
For the benefit of those testing 4.2 RC1, here is a list of known bugs: 1.There are some glitches with ai-controlled VTOLa (including the gunboat on the island mission where you escape in the sub at the end which is rigged as a VTOL for reasons only westwood would know). I dont yer know what is causing these issues (my last tests made things more confusing) 2.There are a number of memory leaks that we havent yet found the cause of yet. 3.Its possible for repeated playing of single player/skirmish to cause a netcode crash. We have reproduction steps for it but we donr know the actual cause yet. if anyone experiences any crashes with the 4.2 RC1 test build, i want to know.
Is there a fix for the client update when the server stops a continious sound? For example: int soundID = Commands->Create_Sound("some sound preset which has loop checked", some position); Commands->Stop_Sound(soundID); This will only work server-side. Clients which are in-game will have to rejoin in order to not hear the sound anymore. Also Commands->Monitor_Sound(soundID); does not work at all. EDIT: in fact im not even sure if any of this works with non-looping sound either. I highly doubt it.
I suspect monitor sound doesn't work server side because the server doesn't actually open the .wav / .mp3 / etc file at all and thus has no clue how long it actually is and therefore doesn't know when to fire the sound ended event. Also, since clients could, in theory, replace sound effects with longer / shorter ones then any server side looping solution would result in gaps / early restarting for those clients.
No I have no fix to make Stop_Sound work over the network. Not sure why Monitor_Sound isnt working, investigating it is on my todo list.
Sorry wasn't clear on the matter, monitor_sound does not work on any sound at all, including non-presets, 2d and 3d sounds. Jonwil, are there any plans om doing something about the stop_sound or does this bring too many complications on the release of 4.2?
Making stop_sound work over the network is too hard.
What about a workaround. Maybe a way to have a simplegameobj have a sound that loops when it is on the map. Add an ambient sound setting to simplegameobjs definition. If you get destroy the object the sound stops playing. Sort of like the beacon beeping sound or an engine sound. Then you could also make an script that you can attach to a Daves arrow that spawns the simple object on creation, destroys it on building destruction and spawns it again on restore. That would make the building state sounds work client side. Being able to attach ambient sounds to simplegameobjs would have a lot of other uses as well so this functionality would benefit more than just building state sounds. The sound playing and the looping would all be handled client side so it should be possible to do without too much hassle compared to having to deal with handling this over the network. This wouldn't necessarily help for existing maps but it definitely would work for new maps. Just make simplegameobj presets for each ambient sound you want. Maybe make it work with twiddlers as well.
dblaney1 wrote on Wed, 24 December 2014 14:36 What about a workaround. Maybe a way to have a simplegameobj have a sound that loops when it is on the map. Add an ambient sound setting to simplegameobjs definition. If you get destroy the object the sound stops playing. Sort of like the beacon beeping sound or an engine sound. Then you could also make an script that you can attach to a Daves arrow that spawns the simple object on creation, destroys it on building destruction and spawns it again on restore. That would make the building state sounds work client side. Being able to attach ambient sounds to simplegameobjs would have a lot of other uses as well so this functionality would benefit more than just building state sounds. The sound playing and the looping would all be handled client side so it should be possible to do without too much hassle compared to having to deal with handling this over the network. This wouldn't necessarily help for existing maps but it definitely would work for new maps. Just make simplegameobj presets for each ambient sound you want. Maybe make it work with twiddlers as well. I think the work required to do this "work-around" could be just as much as implementing the real fix itself. EDIT: Besides I don't think JonWil likes ugly work-arounds, I know I wouldn't lol. EDIT #2: But still +1 for coming up with an alternate solution, better than nothing.
Neijwiert wrote on Wed, 24 December 2014 18:00 dblaney1 wrote on Wed, 24 December 2014 14:36 What about a workaround. Maybe a way to have a simplegameobj have a sound that loops when it is on the map. Add an ambient sound setting to simplegameobjs definition. If you get destroy the object the sound stops playing. Sort of like the beacon beeping sound or an engine sound. Then you could also make an script that you can attach to a Daves arrow that spawns the simple object on creation, destroys it on building destruction and spawns it again on restore. That would make the building state sounds work client side. Being able to attach ambient sounds to simplegameobjs would have a lot of other uses as well so this functionality would benefit more than just building state sounds. The sound playing and the looping would all be handled client side so it should be possible to do without too much hassle compared to having to deal with handling this over the network. This wouldn't necessarily help for existing maps but it definitely would work for new maps. Just make simplegameobj presets for each ambient sound you want. Maybe make it work with twiddlers as well. I think the work required to do this "work-around" could be just as much as implementing the real fix itself. EDIT: Besides I don't think JonWil likes ugly work-arounds, I know I wouldn't lol. EDIT #2: But still +1 for coming up with an alternate solution, better than nothing. An ambient sound for an object would have a lot of useful purposes outside of the building states sounds anyway. I could think of dozens of uses for it right off the top of my head. Would be worth implementing regardless. The only thing TT would really have to do is implement the ambient sound part. The rest could actually be done by server owners in scripts.dll although having a script built-in to the scripts.dll release would make it standardized for mappers and make it work on any server running 4.2.
Its not as simple as it sounds due to some limits in the audio system.
dblaney1 wrote on Sat, 20 December 2014 17:10 Great news. Glad to see a lot of the stuff I suggested and even provided code for made it in. Super glad that my suggestion about immovable objects and homing was implemented. I still disagree with the change as it's probably going to break homing on things like visible drivers and other mod specific features but we'll see how it plays out. jonwil wrote on Sat, 20 December 2014 08:34 New collision group DEFAULT_AND_SOLDIER_ONLY_COLLISION_GROUP which collides only with DEFAULT, SOLDIER and SOLDIER_GHOST. We might want to consider adding a new collision group of SOLDIER_LADDER at some point. When I was fixing the ladder code (so soldiers no longer become collidable when climbing ladders) I noticed that the Ren code was simply checking if the soldier was set for SOLDIER_GHOST. If it was SOLDIER_GHOST the game would simply turn the collision back to normal at the end of a jump, so my fix simply makes sure you aren't on a ladder before it lets your collisions be flipped back. Obviously this still means that you have to keep setting a soldier to soldier ghost if you want them to stay as a spectator. jonwil wrote on Sat, 20 December 2014 08:34 Fixes to sphere and ring primitives Only fixed the ion cannons ring primitive, sphere primitives still do that thing where if you aren't looking at them they appear at your feet. jonwil wrote on Sat, 20 December 2014 08:34 New EntryHelpMessage and EntryHelpMessageColor values on vehicles, if this is set then the message will be displayed in the center of the screen when the vehicle is entered. Intended for help messages like "press Q to deploy this vehicle". If we're already doing that for vehicles why not make it so we can trigger the message on custom so we can make objective messages appear and so forth? jonwil wrote on Sat, 20 December 2014 08:34 Jerad Grey Gray
Jerad Gray wrote on Fri, 26 December 2014 13:53 dblaney1 wrote on Sat, 20 December 2014 17:10 Great news. Glad to see a lot of the stuff I suggested and even provided code for made it in. Super glad that my suggestion about immovable objects and homing was implemented. I still disagree with the change as it's probably going to break homing on things like visible drivers and other mod specific features but we'll see how it plays out. Yes, I had reservations too... one result of our internal discussions was a change such that homing is ALWAYS enabled for any object that is attached to another object, even if that object is immovable. Still not convinced it's a good idea though.
danpaul88 wrote on Fri, 26 December 2014 07:38 Jerad Gray wrote on Fri, 26 December 2014 13:53 dblaney1 wrote on Sat, 20 December 2014 17:10 Great news. Glad to see a lot of the stuff I suggested and even provided code for made it in. Super glad that my suggestion about immovable objects and homing was implemented. I still disagree with the change as it's probably going to break homing on things like visible drivers and other mod specific features but we'll see how it plays out. Yes, I had reservations too... one result of our internal discussions was a change such that homing is ALWAYS enabled for any object that is attached to another object, even if that object is immovable. Still not convinced it's a good idea though. Wish I'd been on that discussion, I think a checkbox in the LE setings would be a better idea.
I thought you were in on it? It was on the Trello board.
Make the default behavior the new behavior and add a dropdown in leveledit to override the behavior. So default behavior, force no homing, and force homing would be ideal. I would like the ability to disable the homing on an object such as a shield generator attached to an object as well which in 4.1 is not available, and as 4.2 is currently set up is not available as well. Adding the ability to override the behavior would allow this. I do think that immovable objects should default to no homing as it currently is implemented in 4.2.
As implemented the feature will ignore (for tracking purposes) any buildings and any physical objects that are not MoveablePhysClass (i.e. cant move) and are not attached to an object (it checks via PhysicalGameObj::Is_Attached_To_An_Object). So things like vehicle drivers and other attachments are still valid targets for tracking weapons.
jonwil wrote on Fri, 26 December 2014 13:29 As implemented the feature will ignore (for tracking purposes) any buildings and any physical objects that are not MoveablePhysClass (i.e. cant move) and are not attached to an object (it checks via PhysicalGameObj::Is_Attached_To_An_Object). So things like vehicle drivers and other attachments are still valid targets for tracking weapons. Can we get a checkbox to force disable the homing as well even if its attached. Not a big deal if we can't, but for things like a mobile shield generator it would be nice not to have things homing to it when trying to aim at objects that in front of it. This issue already exists in 4.1 since the homing is always on so the 4.2 change isn't making anything worse so I am not against that at all.
Should be possible to add an "ignore this for tracking purposes" flag.
jonwil wrote on Fri, 26 December 2014 13:52 Should be possible to add an "ignore this for tracking purposes" flag. Yeah, that would be awesome. I definitely like the new behavior much better.
I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected.
Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. (any maps with the beta guard tower have this issue) The only objects that get their tracking disabled in 4.2 right now are ones that can't move. (homing is useless on them, just makes you miss if an object is in the way like a hill) Objects attached to other objects behave identical to stock when dealing with homing. I don't really see it breaking too much.
dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues.
Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Can you give me a map or single player mission where you have spotted an issue?
dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object.
Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well.
dblaney1 wrote on Fri, 26 December 2014 15:16 Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well. I don't think its worth the risk of breaking legacy maps and mods just for the people that didn't give two shits to fix their turrets and center their origin in the model. As I've said, the ideas that come to mind is cinematics and visible drivers, maybe mirage models on the mirage tank.
Jerad Gray wrote on Fri, 26 December 2014 15:17 dblaney1 wrote on Fri, 26 December 2014 15:16 Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well. I don't think its worth the risk of breaking legacy maps and mods just for the people that didn't give two shits to fix their turrets and center their origin in the model. I don't see how disabling homing on non-moveable objects would break maps. These objects don't move. Any ai controlled objects are gonna shoot at the origin anyway. This fixes a lot more than it breaks. Try shooting a guard tower from inside a tunnel. It doesn't matter where you put the origin. Its gonna not work from certain spots. Jonwil said that if it is attached to another object it will still home.
dblaney1 wrote on Fri, 26 December 2014 15:19 Jerad Gray wrote on Fri, 26 December 2014 15:17 dblaney1 wrote on Fri, 26 December 2014 15:16 Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well. I don't think its worth the risk of breaking legacy maps and mods just for the people that didn't give two shits to fix their turrets and center their origin in the model. I don't see how disabling homing on non-moveable objects would break maps. These objects don't move. Any ai controlled objects are gonna shoot at the origin anyway. This fixes a lot more than it breaks. Try shooting a guard tower from inside a tunnel. It doesn't matter where you put the origin. Its gonna not work from certain spots. I center the origin of my guard towers. As I've said, the ideas that come to mind is cinematics and visible drivers, maybe mirage models on the mirage tank. Also player homing makes use of the bullseye offset in LE so they could have adjusted that at the very least if they were too lazy to fix the 3d model.
Jerad Gray wrote on Fri, 26 December 2014 15:19 dblaney1 wrote on Fri, 26 December 2014 15:19 Jerad Gray wrote on Fri, 26 December 2014 15:17 dblaney1 wrote on Fri, 26 December 2014 15:16 Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well. I don't think its worth the risk of breaking legacy maps and mods just for the people that didn't give two shits to fix their turrets and center their origin in the model. I don't see how disabling homing on non-moveable objects would break maps. These objects don't move. Any ai controlled objects are gonna shoot at the origin anyway. This fixes a lot more than it breaks. Try shooting a guard tower from inside a tunnel. It doesn't matter where you put the origin. Its gonna not work from certain spots. I center the origin of my guard towers. As I've said, the ideas that come to mind is cinematics and visible drivers, maybe mirage models on the mirage tank. Also player homing makes use of the bullseye offset in LE. I just tested attaching a turret to a vehicle with "JFW_Turret_Spawn_3" "nod_turret_mp_improved,TURRET" and it homed like jonwil said it would. So it is checking if its attached to an object.
dblaney1 wrote on Fri, 26 December 2014 15:23 Jerad Gray wrote on Fri, 26 December 2014 15:19 dblaney1 wrote on Fri, 26 December 2014 15:19 Jerad Gray wrote on Fri, 26 December 2014 15:17 dblaney1 wrote on Fri, 26 December 2014 15:16 Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well. I don't think its worth the risk of breaking legacy maps and mods just for the people that didn't give two shits to fix their turrets and center their origin in the model. I don't see how disabling homing on non-moveable objects would break maps. These objects don't move. Any ai controlled objects are gonna shoot at the origin anyway. This fixes a lot more than it breaks. Try shooting a guard tower from inside a tunnel. It doesn't matter where you put the origin. Its gonna not work from certain spots. I center the origin of my guard towers. As I've said, the ideas that come to mind is cinematics and visible drivers, maybe mirage models on the mirage tank. Also player homing makes use of the bullseye offset in LE. I just tested attaching a turret to a vehicle with "JFW_Turret_Spawn_3" "nod_turret_mp_improved,TURRET" and it homed like jonwil said it would. So it is checking if its attached to an object. Now test the same thing with a cinematic so you know it didn't actually home on the object you attached it to, and then you can test it with the AI just in case the change I looked at is only for the player lock on stuff.
Jerad Gray wrote on Fri, 26 December 2014 15:24 dblaney1 wrote on Fri, 26 December 2014 15:23 Jerad Gray wrote on Fri, 26 December 2014 15:19 dblaney1 wrote on Fri, 26 December 2014 15:19 Jerad Gray wrote on Fri, 26 December 2014 15:17 dblaney1 wrote on Fri, 26 December 2014 15:16 Jerad Gray wrote on Fri, 26 December 2014 15:15 dblaney1 wrote on Fri, 26 December 2014 15:13 Jerad Gray wrote on Fri, 26 December 2014 15:12 dblaney1 wrote on Fri, 26 December 2014 15:09 Jerad Gray wrote on Fri, 26 December 2014 15:04 I think the best choice is to make it use Renegade original behavior that way we know special cinematic objects will be tracked correctly, and it won't potentially break any legacy mod/maps. Then we should add a checkbox in LE that would make that preset ignored by tracking. Least chance of breaking stock functionality that way and only newly added stuff would be affected. I gotta disagree on this. The new behavior is much better and fixes tons of maps with turrets that have their origin at the bottom. The only objects that get their tracking disabled in 4.2 right now are ones that can't move. Objects attached to other objects behave identical to stock when dealing with homing. The current logic isn't checking if objects are attached which tells me you have yet to test it against many cinematic objects otherwise you'd be noticing issues. Jonwil said its checking if its attached. Maybe its not working correctly, but if it does what he said it shouldn't be an issue. Code was changed 22 days ago, its checking if its a building object or (if its a physical game object and if its not a movable object) The original code just checked if it was a building object. Can you give me an example where there is an issue. I wanna test it. I have the 4.2 test version as well. I don't think its worth the risk of breaking legacy maps and mods just for the people that didn't give two shits to fix their turrets and center their origin in the model. I don't see how disabling homing on non-moveable objects would break maps. These objects don't move. Any ai controlled objects are gonna shoot at the origin anyway. This fixes a lot more than it breaks. Try shooting a guard tower from inside a tunnel. It doesn't matter where you put the origin. Its gonna not work from certain spots. I center the origin of my guard towers. As I've said, the ideas that come to mind is cinematics and visible drivers, maybe mirage models on the mirage tank. Also player homing makes use of the bullseye offset in LE. I just tested attaching a turret to a vehicle with "JFW_Turret_Spawn_3" "nod_turret_mp_improved,TURRET" and it homed like jonwil said it would. So it is checking if its attached to an object. Now test the same thing with a cinematic so you know it didn't actually home on the object you attached it to, and then you can test it with the AI just in case the change I looked at is only for the player lock on stuff. Just posted a screenshot proving that it homed in my last post.
Just did it with a cinematic as well. It homes just like it should. Tested it with me shooting it and also having the agt shoot at it. I had a chinook drop a turret in a cinematic. Agt homed onto the turret just like its supposed to. Tested it several times.
dblaney1 wrote on Fri, 26 December 2014 15:32 Just did it with a cinematic as well. It homes just like it should. Tested it with me shooting it and also having the agt shoot at it. I had a chinook drop a turret in a cinematic. Agt homed onto the turret just like its supposed to. Tested it several times. Jonwil has a change 6 days ago that checks for attached units, so I guess you can scratch my complaint about attachments.
Jerad Gray wrote on Fri, 26 December 2014 15:47 dblaney1 wrote on Fri, 26 December 2014 15:32 Just did it with a cinematic as well. It homes just like it should. Tested it with me shooting it and also having the agt shoot at it. I had a chinook drop a turret in a cinematic. Agt homed onto the turret just like its supposed to. Tested it several times. Jonwil has a change 6 days ago that checks for attached units, so I guess you can scratch my complaint about attachments. Yup. It works perfectly.
dblaney1 wrote on Fri, 26 December 2014 15:50 Jerad Gray wrote on Fri, 26 December 2014 15:47 dblaney1 wrote on Fri, 26 December 2014 15:32 Just did it with a cinematic as well. It homes just like it should. Tested it with me shooting it and also having the agt shoot at it. I had a chinook drop a turret in a cinematic. Agt homed onto the turret just like its supposed to. Tested it several times. Jonwil has a change 6 days ago that checks for attached units, so I guess you can scratch my complaint about attachments. Yup. It works perfectly. Testing one of my made up scenarios hardly tests all the possible things it could break.
If someone can show a case where an object has an immovable physics type AND isn't attached to another object via Commands->Attach_To_Object_Bone AND where having homing rockets affect it is desirable, (and can show why this object needs to have homing missiles affect it) I will consider further changes beyond the already announced "ignore this object for tracking purposes" flag
Would anyone else like to see a view distance slider or is it just me?
An important note is any map that is saved in the 4.2 LE won't be backward compatible with any 4.1 players and below. Anyone running 4.1, or lets say, 3.4.4 renumbered to look like 4.1, well not see vehicles moving on that map. Personally I consider this a feature, as it should get rid of the last of the people still using trigger bot in 3.4.4.
view distance is actually server side, since the server will only send you netcode objects for things inside your view range. If you modify it client side you'll end up not getting updates for all the objects you should be able to see, which causes a lot of side effects like ghost vehicles in the wrong places etc.
danpaul88 wrote on Sat, 27 December 2014 12:53 view distance is actually server side, since the server will only send you netcode objects for things inside your view range. If you modify it client side you'll end up not getting updates for all the objects you should be able to see, which causes a lot of side effects like ghost vehicles in the wrong places etc. Oh I know, ECW already deals with all that, but the Ren clients can still modify it via tt.ini so its not like we're giving them something they can't already do, just making it easier to do.
Changes made since the test build was pushed: New script JMG_Send_Custom_When_Custom_Sequence_Matched Add a flag to allow objects that would otherwise be tracking targets to be ignored for tracking purposes Clear the image set by Set_Info_Texture on map load Fix an issue with some netcode debugs Things I have on my todo list: Fix issues with AI VTOLs (I now have a good testcase for this thanks to Jerad) Fix an issue with team name changing (once Jerad gives me some reproduction steps) Fix an issue with the weapon chart (once Jerad gives me some reproduction steps) Fix some issues caused if you repeatedly play single player/skirmish in certain circumstances (I have reproduction steps for this)
Jerad Gray wrote on Sun, 28 December 2014 21:21 danpaul88 wrote on Sat, 27 December 2014 12:53 view distance is actually server side, since the server will only send you netcode objects for things inside your view range. If you modify it client side you'll end up not getting updates for all the objects you should be able to see, which causes a lot of side effects like ghost vehicles in the wrong places etc. Oh I know, ECW already deals with all that, but the Ren clients can still modify it via tt.ini so its not like we're giving them something they can't already do, just making it easier to do. tt.ini is cheat checked, modifying it on a client to change your view distance would trigger the anti cheat to boot you from the game. Since ghost vehicles can be abused (shooting at and damaging things that aren't really in that location) this is a good thing.
danpaul88 wrote on Mon, 29 December 2014 06:46 Jerad Gray wrote on Sun, 28 December 2014 21:21 danpaul88 wrote on Sat, 27 December 2014 12:53 view distance is actually server side, since the server will only send you netcode objects for things inside your view range. If you modify it client side you'll end up not getting updates for all the objects you should be able to see, which causes a lot of side effects like ghost vehicles in the wrong places etc. Oh I know, ECW already deals with all that, but the Ren clients can still modify it via tt.ini so its not like we're giving them something they can't already do, just making it easier to do. tt.ini is cheat checked, modifying it on a client to change your view distance would trigger the anti cheat to boot you from the game. Since ghost vehicles can be abused (shooting at and damaging things that aren't really in that location) this is a good thing. Then its a useless configuration setting that shouldn't have been added in the first place.
View distance would be nice, however I would like to be able to set the lodbudget above 10000. Right now it just resets back to 10000. On larger maps even with vis a lot of characters even when close go to the lowest detail level. Especially PIC sydney even when its your own character. Looks terrible. Also does having a tt.ini in a package work now?. Not talking about the map specific ones. Just the plain tt.ini . If not could you make it work?
It was added because there are mods that change it. Its not useless, just not useful for the things you think it should be useful for. As for lod budget, its limited to that value because of limitations (that we cant fix) elsewhere in the engine. And no, tt.ini in a package will never work as tt.ini is read once on game startup and never read again (hence why the per-map tt.ini stuff was created)
jonwil wrote on Mon, 29 December 2014 13:50 It was added because there are mods that change it. Its not useless, just not useful for the things you think it should be useful for. As for lod budget, its limited to that value because of limitations (that we cant fix) elsewhere in the engine. And no, tt.ini in a package will never work as tt.ini is read once on game startup and never read again (hence why the per-map tt.ini stuff was created) Can you make a server-tt.ini file then that gets loaded when a player joins. (just want the stuff that can be changed in the per map tt.ini) I just want a tt.ini that is loaded on all the maps on the server. I don't see any reason why this couldn't be done. These config files were created by the tt team. Also for the per map config files, could you add a setting that enables the secret (extras) purchase terminal slots by default. Edit: so this works globally in the tt.ini with UseExtraPTPages. Not sure if it works per map. I'll test it. Edit2: Tested it in a per-map-tt.ini. It didn't work. Would really appreciate if this could be fixed.
Jerad Gray wrote on Mon, 29 December 2014 20:07 danpaul88 wrote on Mon, 29 December 2014 06:46 Jerad Gray wrote on Sun, 28 December 2014 21:21 danpaul88 wrote on Sat, 27 December 2014 12:53 view distance is actually server side, since the server will only send you netcode objects for things inside your view range. If you modify it client side you'll end up not getting updates for all the objects you should be able to see, which causes a lot of side effects like ghost vehicles in the wrong places etc. Oh I know, ECW already deals with all that, but the Ren clients can still modify it via tt.ini so its not like we're giving them something they can't already do, just making it easier to do. tt.ini is cheat checked, modifying it on a client to change your view distance would trigger the anti cheat to boot you from the game. Since ghost vehicles can be abused (shooting at and damaging things that aren't really in that location) this is a good thing. Then its a useless configuration setting that shouldn't have been added in the first place. The settings in tt.ini are mainly for use by AR, APB etc that update both the client and servers at the same time. You can use it in ECW too as long as you patch the servers and client together.
danpaul88 wrote on Tue, 30 December 2014 02:45 Jerad Gray wrote on Mon, 29 December 2014 20:07 danpaul88 wrote on Mon, 29 December 2014 06:46 Jerad Gray wrote on Sun, 28 December 2014 21:21 danpaul88 wrote on Sat, 27 December 2014 12:53 view distance is actually server side, since the server will only send you netcode objects for things inside your view range. If you modify it client side you'll end up not getting updates for all the objects you should be able to see, which causes a lot of side effects like ghost vehicles in the wrong places etc. Oh I know, ECW already deals with all that, but the Ren clients can still modify it via tt.ini so its not like we're giving them something they can't already do, just making it easier to do. tt.ini is cheat checked, modifying it on a client to change your view distance would trigger the anti cheat to boot you from the game. Since ghost vehicles can be abused (shooting at and damaging things that aren't really in that location) this is a good thing. Then its a useless configuration setting that shouldn't have been added in the first place. The settings in tt.ini are mainly for use by AR, APB etc that update both the client and servers at the same time. You can use it in ECW too as long as you patch the servers and client together. As I said, I'm talking more about my Renegade maps and other people's Renegade maps which are big enough you can see the max render distance.
jonwil wrote on Mon, 29 December 2014 13:50 As for lod budget, its limited to that value because of limitations (that we cant fix) elsewhere in the engine. Actually I hex edited ECW's .exe and sliding the slider for the Geometry slider up in game to max actually disables LOD, granted, what ever change I made I didn't sink with the RenConfig, so RenConfig always misreads it and thinks the LOD settings are lower than they actually are...
Hex editing things wont work in 4.2, all that stuff is handled by scripts now
jonwil wrote on Tue, 30 December 2014 13:58 Hex editing things wont work in 4.2, all that stuff is handled by scripts now Well then we should be able to fix it correctly... Which was the point I was getting at lol.
[quote title=Jerad2142 wrote on Fri, 26 December 2014 23:53]jonwil wrote on Sat, 20 December 2014 08:34 New EntryHelpMessage and EntryHelpMessageColor values on vehicles, if this is set then the message will be displayed in the center of the screen when the vehicle is entered. Intended for help messages like "press Q to deploy this vehicle". If we're already doing that for vehicles why not make it so we can trigger the message on custom so we can make objective messages appear and so forth? /quote] Doing what has been done with vehicles is easy because its handled by the vehicle code on client and server meaning no new netcode is needed. Doing what you ask needs new netcode.
[quote title=jonwil wrote on Mon, 05 January 2015 05:36] Jerad Gray wrote on Fri, 26 December 2014 23:53 jonwil wrote on Sat, 20 December 2014 08:34 New EntryHelpMessage and EntryHelpMessageColor values on vehicles, if this is set then the message will be displayed in the center of the screen when the vehicle is entered. Intended for help messages like "press Q to deploy this vehicle". If we're already doing that for vehicles why not make it so we can trigger the message on custom so we can make objective messages appear and so forth? /quote] Doing what has been done with vehicles is easy because its handled by the vehicle code on client and server meaning no new netcode is needed. Doing what you ask needs new netcode. Its just hard for me to imagine it would require much work as I did it hackly in ECW through shaders beings I didn't have access to bhs.dll. Seems like it would be so easy to do it correctly if we already have the code for networking open to us...