Home » Tiberian Technologies / Blackhand Studios » Tiberian Technologies Forum » Syncing or changing BuildingGameObj 'IsDetroyed' state for clients
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488114 is a reply to message #488071] |
Sun, 29 June 2014 15:20 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
StealthEye wrote on Sat, 28 June 2014 12:20 | I think it is valid for adding/changing game modes. (I doubt if I would like them, but that's another story.) I would integrate this fix if there would be a next TT scripts.dll release for Renegade, as I do not think it breaks anything for servers that do not attempt to revive buildings. (This wasn't so clear to me in August 2013 when it was originally requested, and I meant to investigate it but never got around to it. Sorry for that.)
|
Glad someone that was on the team has a reasonable response to this topic.
|
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488142 is a reply to message #488093] |
Mon, 30 June 2014 07:31 |
|
Xpert
Messages: 1588 Registered: December 2005 Location: New York City
Karma: 0
|
General (1 Star) |
|
|
EvilWhiteDragon wrote on Sun, 29 June 2014 04:57 |
Xpert wrote on Sun, 29 June 2014 00:29 |
EvilWhiteDragon wrote on Sat, 28 June 2014 11:45 | How do you illegally destroy a building?
|
Tunnel Beacon
Building Hopping
Ledge Beaconing on Glacier_Flying
Killing the AGT above the map on Under
Need I say more?
I'm against building revival in terms of game modes, but the idea of having building revival incase one of the above occurs - I don't see why this is such a big deal. Iran even made the patch already.
|
If you want the above, wouldn't it make more sense to fix/block these things rather than, as a workaround for when a mod is available, revive buildings?
|
Ya, wouldn't it make sense that the TT team fix/blocked these things?
Creator of NetGuard, an IRC network regulator.
Developer of the CloudyServ 0.982-X project.
Developer of the CloudyServ Ren-X bot.
Part time streamer - https://twitch.tv/gg_wonder
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488143 is a reply to message #488142] |
Mon, 30 June 2014 09:13 |
|
EvilWhiteDragon
Messages: 3751 Registered: October 2005 Location: The Netherlands
Karma: 0
|
General (3 Stars) |
|
|
Xpert wrote on Mon, 30 June 2014 16:31 |
EvilWhiteDragon wrote on Sun, 29 June 2014 04:57 |
Xpert wrote on Sun, 29 June 2014 00:29 |
EvilWhiteDragon wrote on Sat, 28 June 2014 11:45 | How do you illegally destroy a building?
|
Tunnel Beacon
Building Hopping
Ledge Beaconing on Glacier_Flying
Killing the AGT above the map on Under
Need I say more?
I'm against building revival in terms of game modes, but the idea of having building revival incase one of the above occurs - I don't see why this is such a big deal. Iran even made the patch already.
|
If you want the above, wouldn't it make more sense to fix/block these things rather than, as a workaround for when a mod is available, revive buildings?
|
Ya, wouldn't it make sense that the TT team fix/blocked these things?
|
Well, since I resigned of the TT team, I can't say for sure, but at the time the stance was to change bugs rather than possible gameplay. Tunnel beacon might have been intentional, and the other things could've been fixed when the TT team made some mapfixes. Apparently, public beta-testing didn't find these bugs when we were actively developing. As for building hopping I'm not sure what you mean btw.
Oh and you seem to be quite angry at a team that consist of people who are (were) fixing Renegade in their free time. If you really need to be angry, then direct it at EA. When did they last showed any kind of support for Renegade?
BlackIntel admin/founder/PR dude (not a coder)
Please visit http://www.blackintel.org/
V, V for Vendetta | People should not be afraid of their governments.
Governments should be afraid of their people.
|
|
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488154 is a reply to message #482894] |
Mon, 30 June 2014 14:58 |
StealthEye
Messages: 2518 Registered: May 2006 Location: The Netherlands
Karma: 0
|
General (2 Stars) |
|
|
The most likely reason for the issues Xpert mentioned is that TT mostly has/had coders, and not much mappers. I do not think the issues can be solved properly in code (only with very nasty map-specific checks or such to avoid side-effects). I agree that, ideally, TT would fix issues like these.
Like I said, that does not go for the IsDestroyed thing; I was planning to integrate that, because although it is not a technically perfect solution to building revival, it does not do any harm either.
I think jonwil rejected the change originally because it is hard to determine from the code whether the actions that are performed on building destruction are reverted correctly when the building is revived: it appears that they are not. Before making a change, we normally check the impact on other parts, to avoid breaking them, which in this case is quite time consuming and error prone: a quick glance at the related code raises a lot of questions on whether everything will be properly synchronized. A proper solution would most likely require a significant time investment. I am still not convinced that buildings can be revived "perfectly" - including all announcements, sound changes, etc. - and safely - without introducing other bugs, with the IsDestroyed change alone. I wouldn't be until I had done that research, and I wouldn't do that because there were more stressing issues. Therefore, I would normally reject the change. Yet, as pointed out in this topic, the exact side effects are less important, because all servers not attempting building revival will be unaffected anyway. This is much easier to check (I checked it when I wrote my previous post in this topic). That is the reason why I would still implement the change, even though I am not sure of the exact impact it has.
BlackIntel admin/founder/coder
Please visit http://www.blackintel.org/
[Updated on: Mon, 30 June 2014 14:59] Report message to a moderator
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488155 is a reply to message #488154] |
Mon, 30 June 2014 15:05 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
StealthEye wrote on Mon, 30 June 2014 14:58 | The most likely reason for the issues Xpert mentioned is that TT mostly has/had coders, and not much mappers. I do not think the issues can be solved properly in code (only with very nasty map-specific checks or such to avoid side-effects). I agree that, ideally, TT would fix issues like these.
Like I said, that does not go for the IsDestroyed thing; I was planning to integrate that, because although it is not a technically perfect solution to building revival, it does not do any harm either.
I think jonwil rejected the change originally because it is hard to determine from the code whether the actions that are performed on building destruction are reverted correctly when the building is revived: it appears that they are not. Before making a change, we normally check the impact on other parts, to avoid breaking them, which in this case is quite time consuming and error prone: a quick glance at the related code raises a lot of questions on whether everything will be properly synchronized. A proper solution would most likely require a significant time investment. I am still not convinced that buildings can be revived "perfectly" - including all announcements, sound changes, etc. - and safely - without introducing other bugs, with the IsDestroyed change alone. I wouldn't be until I had done that research, and I wouldn't do that because there were more stressing issues. Therefore, I would normally reject the change. Yet, as pointed out in this topic, the exact side effects are less important, because all servers not attempting building revival will be unaffected anyway. This is much easier to check (I checked it when I wrote my previous post in this topic). That is the reason why I would still implement the change, even though I am not sure of the exact impact it has.
|
With the change it is possible to get a state as if the building had never been destroyed at all. I have tested it extensively. Everything including the announcements, the construction of vehicles, even custom death animations like on the map seaside canyon revert properly. My restore plugin even handles radar coming back properly as well as rebuilding harvesters, and restoring power to other buildings when a Power Plant is revived. I have done extensive testing and for the most part its entirely bug free (I have yet to find any bugs). My veterency plugin works properly without modification as well. The killed event is called successfully even after being restored and veteran points are awarded.
Hopefully something can be worked out about the future of stock renegade as its definitely quite obvious that many are not satisfied with the current situation regarding development.
[Updated on: Mon, 30 June 2014 15:21] Report message to a moderator
|
|
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488164 is a reply to message #482894] |
Mon, 30 June 2014 18:41 |
|
IF I was going to implement this (for Renegade or otherwise) I would be implementing this by a separate piece of netcode and other logic that specifically existed to "revive buildings" and undo whatever normally happened when a building died (with each building having its own separate logic to undo everything) rather than implementing it by modifying the current logic that sets the IsDestroyed flag.
I would do it that way because a specific "hey, bring this building back to life" flag (and engine call) that did all the right things would ensure the buildings are brought back to life properly and every step required is taken (there are things that happen as a result of building destruction that aren't immediately obvious).
Note that this doesn't imply I will be working on this feature, just that that is how I would implement it if I did work on it and how I would expect it to be implemented by anyone else who ended up doing scripts work for Renegade (if that should happen in the future)
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 #488165 is a reply to message #488164] |
Mon, 30 June 2014 19:12 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
That sounds nice but a way to set just the isdestroyed flag would be nice as well. Both options have their advantages and disadvantages. I do have building specific code in my restore plugin, such as the refinery requesting a new harvester from the base controller and the communications center reenabling radar when restored. The power plant also turns base power back on when restored. Base Defenses just reattach their appropriate script. The Weapons Factory, Airstrip, Barracks, and Hand of Nod actually don't need anything special. Just the isdestroyed flag set on the clients is needed for them to work properly. Probably best to reset cangeneratevehicles as well though. If the harvester was dead before the restore and there is a still a refinery it automatically builds the harvester.
Ultimately its up to you how it would be done of course.
Anyway, here's some examples of some of the revive commands code.
class CommandREVIVENODPP :
public ConsoleFunctionClass
{
public:
const char* Get_Name()
{
return "revivenodpp";
}
const char* Get_Help()
{
return "REVIVENODPP - Revives the Nod Power Plant.";
}
void Activate(const char* argumentsString)
{
Revive_Building(Find_Power_Plant(NOD));
Commands->Set_Building_Power(Find_Power_Plant(NOD), true);
BaseControllerClass* base = BaseControllerClass::Find_Base(NOD);
if (base)
{
base->Power_Base(true);
}
}
};
class CommandREVIVEGDIREF :
public ConsoleFunctionClass
{
public:
const char* Get_Name()
{
return "revivegdiref";
}
const char* Get_Help()
{
return "REVIVEGDIREF - Revives the GDI Refinery.";
}
void Activate(const char* argumentsString)
{
Revive_Building(Find_Refinery(GDI));
Find_Refinery(GDI)->As_BuildingGameObj()->As_RefineryGameObj()->Allow_Harvester_Spawn();
}
};
[Updated on: Mon, 30 June 2014 20:57] Report message to a moderator
|
|
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488178 is a reply to message #482894] |
Tue, 01 July 2014 01:43 |
|
The following events happen in the On_Destroyed event (called when a building is destroyed):
BuildingGameObj IsDestroyed is set to true, BaseControllerClass::On_Building_Destroyed is called (this plays the "building destroyed" sound and sets the "base destroyed" flag if all buildings are dead), BaseControllerClass::Check_Prerequisites is called (this goes with the prerequisite logic where stuff you buy from the sidebar can have a flag that says "this building must exist/must be alive for the object to be purchasable") and the building is made visible in the single player encyclopedia.
AirFactoryGameObj BaseControllerClass::Check_Vehicle_Factory is called (this sets the CanGenerateVehicles flag appropriately based on the buildings that are present and alive)
ComCenterGameObj BaseControllerClass::Check_Radar is called (this toggles the radar depending on what buildings exist/are alive)
NavalFactoryGameObj BaseControllerClass::Check_Vehicle_Factory is called (this sets the CanGenerateVehicles flag appropriately based on the buildings that are present and alive)
PowerPlantGameObj BaseControllerClass::Check_Base_Power is called (this sets the base power as appropriate based on the buildings that are present and alive)
RefineryGameObj Destroys any instances of the harvester preset, also disables any spawners that would spawn the harvester preset (said spawners are used for maps that have a refinery but no weapons factory)
SoldierFactoryGameObj Sets the CanGenerateSoldiers flag to off.
WeaponsFactoryGameObj BaseControllerClass::Check_Vehicle_Factory is called (this sets the CanGenerateVehicles flag appropriately based on the buildings that are present and alive)
So yes more happens than just toggling the flag and any engine feature that might be added in the future would be undoing those other things that happen (e.g. turning CanGenerateSoldiers back on for a SoldierFactoryGameObj, restoring the harvester spawners for a RefineryGameObj etc)
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 #488180 is a reply to message #482894] |
Tue, 01 July 2014 01:53 |
iRANian
Messages: 4308 Registered: April 2011
Karma: 0
|
General (4 Stars) |
|
|
danpaul88 wrote on Tue, 01 July 2014 01:14 | Also, given that you've just admitted you need a plugin to undo some of the effects tells us that simply setting the flag is NOT enough, despite the fact you keep insisting that it is. Thus there is more work required to properly revive a building at an engine level without requiring additional plugins to fix the state of various things.
|
The flag that needs fixing only needs fixing client-side, when you revive a building the flag is SET properly server-side but clients don't update the flag.
The other things that are needed like updating power to the building, allowing Harvester to repsawn and allowing infantry/vehicle purchases have been known and have worked properly for about 6 years or so now.
So I'm not really sure why it's being brought up.
Long time and well respected Renegade community member, programmer, modder and tester.
Scripts 4.0 private beta tester since May 2011.
My Renegade server plugins releases
[Updated on: Tue, 01 July 2014 01:54] Report message to a moderator
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488190 is a reply to message #488178] |
Tue, 01 July 2014 05:46 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
jonwil wrote on Tue, 01 July 2014 01:43 | The following events happen in the On_Destroyed event (called when a building is destroyed):
BuildingGameObj IsDestroyed is set to true, BaseControllerClass::On_Building_Destroyed is called (this plays the "building destroyed" sound and sets the "base destroyed" flag if all buildings are dead), BaseControllerClass::Check_Prerequisites is called (this goes with the prerequisite logic where stuff you buy from the sidebar can have a flag that says "this building must exist/must be alive for the object to be purchasable") and the building is made visible in the single player encyclopedia.
AirFactoryGameObj BaseControllerClass::Check_Vehicle_Factory is called (this sets the CanGenerateVehicles flag appropriately based on the buildings that are present and alive)
ComCenterGameObj BaseControllerClass::Check_Radar is called (this toggles the radar depending on what buildings exist/are alive)
NavalFactoryGameObj BaseControllerClass::Check_Vehicle_Factory is called (this sets the CanGenerateVehicles flag appropriately based on the buildings that are present and alive)
PowerPlantGameObj BaseControllerClass::Check_Base_Power is called (this sets the base power as appropriate based on the buildings that are present and alive)
RefineryGameObj Destroys any instances of the harvester preset, also disables any spawners that would spawn the harvester preset (said spawners are used for maps that have a refinery but no weapons factory)
SoldierFactoryGameObj Sets the CanGenerateSoldiers flag to off.
WeaponsFactoryGameObj BaseControllerClass::Check_Vehicle_Factory is called (this sets the CanGenerateVehicles flag appropriately based on the buildings that are present and alive)
So yes more happens than just toggling the flag and any engine feature that might be added in the future would be undoing those other things that happen (e.g. turning CanGenerateSoldiers back on for a SoldierFactoryGameObj, restoring the harvester spawners for a RefineryGameObj etc)
|
Everything you put there can be already be done. It works properly already. The only thing that doesn't work is syncing the client isdestroyed flag. Thats why it is confusing that you would want to write an entirely new netcode/engine feature for something that already works except for one thing.
[Updated on: Tue, 01 July 2014 05:57] Report message to a moderator
|
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488194 is a reply to message #488192] |
Tue, 01 July 2014 07:20 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
danpaul88 wrote on Tue, 01 July 2014 06:03 | If you need to call 5 or 6 other things and have a load of logic depending on the type of building then it is *not* working properly in the engine itself.
A correct implementation of a revive building function in the engine would undo all the effects of building destruction without loads of other function calls being necessary. It would also allow new features added in future to be hooked into the revival code as necessary.
|
The building specific revival code could be put into the base scripts code. There actually already is a revive building function in the scripts but it just resets the health and sets isdestroyed on the server to false. That way if a server operator wants to make specific changes to the revival behavior they would still be able to do so. I don't see a real reason to make this behavior hardcoded into the engine. Simply syncing the isdestroyed flag and providing a built in function in the scripts that handles the revive behavior properly would be the safest way to do this in my opinion. It doesn't involve substantial changes to the engine and wouldn't affect servers that don't use restores. Making large changes to the engine on the other hand, definitely could have adverse effects.
[Updated on: Tue, 01 July 2014 07:26] Report message to a moderator
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488196 is a reply to message #482894] |
Tue, 01 July 2014 07:29 |
iRANian
Messages: 4308 Registered: April 2011
Karma: 0
|
General (4 Stars) |
|
|
The current situation in regards to building revival on the server is fine; the building revival console commands plugin contains a full open-source implementation to revive all buildings and to set their state correctly and I know numerous people have already used the code, including dblaney1 and Xpert.
The fact that the Revive_Building() command provided by scripts 4.0 only sets the IsDestroyed flag to false and does some other basic things is desirable over it implementing all the stuff to revive a building properly. For example you might want to add special logic to handle the Harvester when the Refinery or Weapons Factory get restored in your own mod, or you want base power to stay offline after restoring the Power Plant. Or you might want to attach your own custom scripts on a base defense after it has been revived. Not exactly common use cases but people might desire them.
Long time and well respected Renegade community member, programmer, modder and tester.
Scripts 4.0 private beta tester since May 2011.
My Renegade server plugins releases
[Updated on: Tue, 01 July 2014 07:33] Report message to a moderator
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488197 is a reply to message #488196] |
Tue, 01 July 2014 07:31 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
iRANian wrote on Tue, 01 July 2014 07:29 | The current situation in regards to building revival on the server is fine; the building revival console commands plugin contains a full open-source implementation to revive all buildings and to set their state correctly and I know numerous people have already used the code, including dblaney1 and Xpert.
|
Exactly, no huge engine changes are needed, just a simple one to sync the client states. With that fix, the destroyed announcements and the ability to build units from a factory is fixed for clients which are the only things that currently are not working. Things like rebuilding harvesters, setting base power, the restarting of the refineries credit tick, etc work already.
[Updated on: Tue, 01 July 2014 07:34] Report message to a moderator
|
|
|
|
Re: Syncing or changing BuildingGameObj 'IsDetroyed' state for clients [message #488202 is a reply to message #488201] |
Tue, 01 July 2014 09:31 |
dblaney1
Messages: 358 Registered: March 2014 Location: United States
Karma: 0
|
Commander |
|
|
Ethenal wrote on Tue, 01 July 2014 08:49 | TT team wants a proper fix, the random programmers want a hacky fix
obviously TT wins
|
There is nothing hacky about what we are doing. Everything we are using is right in the scripts api. We prefer it this way as it not only provides more flexibility, it also is less likely to break other parts of then completely changing the way the engine handles building controllers.
[Updated on: Tue, 01 July 2014 09:36] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Sat Nov 23 16:14:10 MST 2024
Total time taken to generate the page: 0.02015 seconds
|