.
Printable View
.
I am also very interested in the answer to this.
I suspect the main problem with this code working in multiplayer is synchronising the data across systems. Ie., the map reference that gets called when an object/building is destroyed is referenced by the local system and not transmitted. This is why in a multiplayer mission, the system hosting the code will respond to this script function, but any other system will not. If you host and play in a mission that you let others connect to, the script will let you destroy and track destroyed buildings but it doesn't work for anyone else. This includes if the system is hosted on a dedicated server - no connecting client triggers the script since the map instance is not local (it's only local on the dedicated server and the server obviously isn't doing any bombing of it's own).
The other troublesome part of this involves clients connecting to a map after damage has been done to the map. Imagine the situation where a map has had 30 players in heavy bombers destroy hundreds or thousands of objects on the map. This data has to be stored and then transmitted to any connecting player so that their map is then updated with the map objects destroyed and also so that they cannot 'redo' the destruction (blowing up a fuel tank after it has already been blown up by a player already connected). If this could be done with a reasonable amount of delay added to joining missions, I think it would worth it. I'd gladly add 30 seconds or even a minute or two to loading into a server if this script functioned in MP. I think it's that important.
You can tell I have spent a lot of time thinking about this particular bit of code which I think would completely revitalize CloD for many mission designers.... The code works great for Single Player and could potentially make for some amazing single player campaign style missions - except for the woeful AI at all layers preventing such a thing from being enjoyable.
I don't think that TF will be able to address the above problems, though.
We have ATAG_Oskar looking at this and there is likely a fix.
I also would like to see this operation working for obvious reasons. We added static objects in the area of each target that are destroyable Jerrycans to be specific. Each carries a point value to a total for each target. None are placed inside the Target since we have found them sometimes bomb proof when so located. Each uses the trigger of ground destroyed within that target zone of 66% out of the 100 that are in that area. Populating the map with what amounts to hundreds of objects that would be better served as different objects or even more available targets. This also lets us keep a dictionary of what has and has not been destroyed for players logging in or playing at different times.
More importantly from a gameplay perspective, if this script functioned attack missions would not be restricted to where a mission designer has pre-destined an attack. A player or squadron would simply be able to define their missions organically. The defending players would also not have the benefit of already knowing where an attack has to be directed to score points.
If my team wants to hit train stations, then we can hit train stations. Fuel? Civilian targets? BANKS? Whatever. Everything comes up. All the mission designer need do is define in their mission script what types of targets they want to give points to and how. The OnBuildingKilled() will pass the specific object identifier. A designer could create statistics that would track every object a player ever destroyed.
If I wanted to be the master destroyer of phone booths, or tractors, or lamp posts,..., I could and it could be tracked.
I've written a few SP missions that use this. I have a file of values for various buildings and stationaries and code that adds up all the objects within a given radius of a location. Then when they are knocked out you can get a damage percentage. This way the AI bombers will do realistic damage and players can get in and score by bombing buildings, shooting up vehicles, etc.Quote:
Originally Posted by No.401_Wolverine
I didn't realize that this does not work in MP. Fix should be in next beta test.
.
We understand this... this is one of the reasons why we are not rushing to complete the game.Quote:
Originally Posted by Cassius
We want it to work as it should when released.
Yup, people have been trying to use this for a long while: FEB 26, 2016 https://theairtacticalassaultgroup.c...ad.php?t=21392Quote:
Originally Posted by ATAG_Oskar
I've always assumed that this fix was simply too hard to make, not that the request was just ignored.
Quote:
Originally Posted by Nephilim
If you're saying this is something you can simply throw into the next build, then I'm flabbergasted. All credit to you if those who came before didn't have the skills to fix it, of course. I suppose that's possible. Not sure when you joined the team.Quote:
Originally Posted by Mysticpuma
Anyway...THANK YOU.
I should have said that I forgot about that bug. I read every bug report and feature request.
I just got access to the code a few weeks ago and it takes a little time to understand how it works. And it's huge.
That would definitely be a " game changer" for campaign and mission makers. Not having to place static objects would save so much time. Not to mention open up so may possibilities!
Any word on if this has been fixed for the next mod version?
Yes, this is planned for the next update.Quote:
Originally Posted by No.401_Wolverine
Checking in on this one again because, you know, plans change.
Is this fix still included? Have tests been performed on a possible fix in any build? These sorts of issues don't get as much fanfare as new screens of Spitfires and 109s so I want to make sure it's not forgotten.
It's still the plan.Quote:
Originally Posted by No.401_Wolverine