| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #487616 is a reply to message #487615] |
Fri, 16 May 2014 08:01   |
 |
danpaul88
Messages: 5795
Registered: June 2004
Location: England
Karma: 0
|
General (5 Stars) |
|
|
| Jerad Gray wrote on Fri, 16 May 2014 15:48 |
<snipped nested quotes>
Last time I ran into it was caused by changing the player character on spawn, but that is one of the rare occurrences where I had complete control and could have found a way around it besides just making a flag external to the script to check.
In the wild, I've seen it caused by things ranging from a separate timer doing clean up, to something a player does (for example once I saw a player die while at a PT (due to lag or a lockup which ever the case was they were still in the PT after their char died) and just as the player's character spawned they bought a character from the PT, the destroy flag on the scripts attached to the spawn character were called before the create due to the character being 'destroyed' and replaced with a new character.
Mind you, this is only a problem if your storing an array index, or a pointer in your script (playerId for efficiency, or a pointer to a list being the most common occurance).
Normally I just protect against it now by attaching a dummy script as the final step of create and then checking for the attached script on any classes that I've found can be called before create (Custom, Damaged, Killed, and Destroyed are the ones that come to mind) on any sensitive scripts (in all of ECW I've done this less than 50 times, and that's a good 4.27MB of code.
|
It's good practice to initialize any pointers to NULL in the constructor and then check != NULL in the Destroyed method.
The spawn character change should be safe in 4.1 since the lifecycle had some fixed applied at that time which should ensure the correct ordering of events.
[Updated on: Fri, 16 May 2014 08:02] Report message to a moderator |
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #487618 is a reply to message #487616] |
Fri, 16 May 2014 08:15 |
 |
Jerad2142
Messages: 3805
Registered: July 2006
Location: USA
Karma: 6
|
General (3 Stars) |
|
|
| danpaul88 wrote on Fri, 16 May 2014 09:01 |
| Jerad Gray wrote on Fri, 16 May 2014 15:48 |
<snipped nested quotes>
Last time I ran into it was caused by changing the player character on spawn, but that is one of the rare occurrences where I had complete control and could have found a way around it besides just making a flag external to the script to check.
In the wild, I've seen it caused by things ranging from a separate timer doing clean up, to something a player does (for example once I saw a player die while at a PT (due to lag or a lockup which ever the case was they were still in the PT after their char died) and just as the player's character spawned they bought a character from the PT, the destroy flag on the scripts attached to the spawn character were called before the create due to the character being 'destroyed' and replaced with a new character.
Mind you, this is only a problem if your storing an array index, or a pointer in your script (playerId for efficiency, or a pointer to a list being the most common occurance).
Normally I just protect against it now by attaching a dummy script as the final step of create and then checking for the attached script on any classes that I've found can be called before create (Custom, Damaged, Killed, and Destroyed are the ones that come to mind) on any sensitive scripts (in all of ECW I've done this less than 50 times, and that's a good 4.27MB of code.
|
It's good practice to initialize any pointers to NULL in the constructor and then check != NULL in the Destroyed method.
The spawn character change should be safe in 4.1 since the lifecycle had some fixed applied at that time which should ensure the correct ordering of events.
|
Misread, never thought of it, not sure how the scripts are actually put together in the background. I've seen game engines where the script classes were just used to make the definitions, so the constructors were called once for a class on gameEngine load, not per attachment on each object. Guess I imagined that ren was the same so I never bothered with it.
[Updated on: Fri, 16 May 2014 08:21] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #487726 is a reply to message #487717] |
Thu, 29 May 2014 18:32 |
dblaney1
Messages: 358
Registered: March 2014
Location: United States
Karma: 0
|
Commander |
|
|
| danpaul88 wrote on Thu, 29 May 2014 01:20 |
As has already been stated countless times, there will be no more scripts releases for Renegade other than any bug fix releases required to fix bugs / crashes / anti-cheat.
|
We don't want a new scripts release, we just want this file distributed through the auto updater. I don't know why you guys are resisting this so much. I have been running the patched bandtest.dll for over a month now without a single crash.
[Updated on: Thu, 29 May 2014 18:34] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #487732 is a reply to message #487731] |
Thu, 29 May 2014 22:41 |
dblaney1
Messages: 358
Registered: March 2014
Location: United States
Karma: 0
|
Commander |
|
|
| roszek wrote on Thu, 29 May 2014 22:34 |
| dblaney1 wrote on Thu, 29 May 2014 22:25 |
| Mauler wrote on Thu, 29 May 2014 21:18 |
| dblaney1 wrote on Thu, 29 May 2014 19:32 |
| danpaul88 wrote on Thu, 29 May 2014 01:20 |
As has already been stated countless times, there will be no more scripts releases for Renegade other than any bug fix releases required to fix bugs / crashes / anti-cheat.
|
We don't want a new scripts release, we just want this file distributed through the auto updater. I don't know why you guys are resisting this so much. I have been running the patched bandtest.dll for over a month now without a single crash.
|
make a few little mods to your server and you think you know what's best for all of us....  
|
It would be good if you actually understood that this is a Client Side patch, so servers have absolutely nothing to do with this at all. The file in question doesn't even exist on the server.
|
I believe what my good friend is saying is that because you wrote some pedestrian code you think you know more than the tt devs 
|
I only have two college degrees in Computer science/Software Engineering and Network Engineering, and contribute to several major open source projects with actual code that has been merged and used by millions of devices.
[Updated on: Thu, 29 May 2014 22:42] Report message to a moderator |
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #487733 is a reply to message #482894] |
Fri, 30 May 2014 01:42 |
|
danpaul88
Messages: 5795
Registered: June 2004
Location: England
Karma: 0
|
General (5 Stars) |
|
|
Lots of people have degrees in computing. In my experience that doesn't necessarily mean they know the first thing about computing... degrees just mean you memorized what you needed to know to pass a test, they're useful for getting your foot in the door as a graduate but beyond that you need to prove yourself in battle with the compiler and prove you know your stuff.
But that's by the by, just saying that I'm not impressed by anyone who thinks quoting their degrees somehow indicates their level of competency.
And, for the record, no, we will not be pushing an unverified third party file which wasn't generated by our build server to the patching system.
[Updated on: Fri, 30 May 2014 01:42] Report message to a moderator |
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #487734 is a reply to message #482894] |
Fri, 30 May 2014 04:59 |
|
|
As the guy who is (at this point) basically in charge of any future scripts releases for Renegade, I am going to say that this feature will NOT be included (regardless of whether any future releases get made or not). Continuing to ask for it will not help, it will just make me even less likely to care about your feature.
As of now, we have NO plans to push any further scripts builds in any case (if bugs show up that are game-breaking, we MAY consider a new build but as of right now there are no game-breaking bugs that we need to deal with)
Jonathan Wilson aka Jonwil
Creator and Lead Coder of the Custom scripts.dll
Renegade Engine Guru
Creator and Lead Coder of TT.DLL
Official member of Tiberian Technologies
|
|
|
|
|
|
|
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488032 is a reply to message #487734] |
Fri, 27 June 2014 04:07 |
 |
reborn
Messages: 3231
Registered: September 2004
Location: uk - london
Karma: 0
|
General (3 Stars) |
|
|
| jonwil wrote on Fri, 30 May 2014 07:59 |
As the guy who is (at this point) basically in charge of any future scripts releases for Renegade, I am going to say that this feature will NOT be included (regardless of whether any future releases get made or not). Continuing to ask for it will not help, it will just make me even less likely to care about your feature.
|
Don't ask for it to go in, because the answer will be even more of a no? lol...
| zunnie wrote on Sun, 22 June 2014 13:11 |
If this were requested for APB, it would'be been done yesterday lol.
|
Yeah, he's kinda right.
|
|
|
|
| Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488042 is a reply to message #487974] |
Fri, 27 June 2014 16:40 |
|
|
| zunnie wrote on Mon, 23 June 2014 01:11 |
If this were requested for APB, it would'be been done yesterday lol.
|
Actually no, I wouldn't add this feature for APB. At least not in the way that people are asking for here.
Jonathan Wilson aka Jonwil
Creator and Lead Coder of the Custom scripts.dll
Renegade Engine Guru
Creator and Lead Coder of TT.DLL
Official member of Tiberian Technologies
|
|
|
|
|
|
|
|
|
|
Search
Help
Members
Register
Login
Home
