Since there never has been one reported instance of this bug in the stock mission packs, I was wondering if anyone has done a detailed map of their program structure to see what Taldren did to make them stable?
Yes, the stock missions neither seem to exhibit any dble ftr/weapons bugs (aside from host connection issues) nor do they contain any code that has been employed to resolve these bugs.
Why then do they work?? A good question.
Firstly, we need to know what actually causes the bug in the first place. Something we have always known since the very first host left message was discovered in online play, is that damage by weapons and loadouts are multiplied by the number of players in a dynaverse mission when there is a host left message and this is consistant for all missions ever made (stock and otherwise). The reason for this, as we now know, is that each player has their own version of the script running on each computer, but ceratin tasks are delegated only to the host computer, such as controlling AI. Now, what is supposed to happen, is that the host script overides the script for non-host players, thus we dont see each computer generating a set of AI for each player. However, if a non-host script detects that a host has dropped, a new host is allocated to the reamining players. When there is a connection and the script does not connect with the host, each script then becomes its own host, and thus it will run the mission as if it was the script. If we have 3 players in a mission, and they are all acting as hosts, then each script will fire the weapons of AI, launch fighters etc. so we get three sets of damage and fighters. In worse conditions, a computer acting as a host may have had such a lousy connection at the beginning of the mission that it did not recognise another human player as human, and so this script will also begin controlling the player ship as if it was AI. I'm sure we're all familiar with as well. This too happens in stock missions.
What we do not see in stock missions though, is when there is no host left message or connection issue, yet we still see this anomaly occurring where each player script is acting as a host, although we never see another script actually taking player ships as AI. This is significant. It means then that there must be some other mechanism at work associated with host scripts controlling AI and player ships.
The remedies that have been employed to fix this bug have met with limited success. Firesoul first found a possible solution by only allowing host scripts to register AI ships within a script. This appears to have worked well GSA, but not for the D2. Karnak then put foreward another solution, by removing all code that changed the states of AI Officers running in all scripts on the premise that doing so was in some way instogating non-host scripts to 'activate' their AI code. Again, this works in some cases, but not others.
In fact, both Firesoul and Karnak are both correct in their approaches, but the solution is not yet complete. So, I have combined both approaches building on this and extending it by further restricting all code associated with AI (ie. AI ship generation, all AI commands etc.) only to the host script. This appears to work, as has been reported maybe half of the time, but still is not a complete solution.
Now, interestingly enough, when these missions were first tested, this bug was not seen at all, and did not reappear until the ship AI generation method was changed in order to accomodate the time warping and AI ships being produced out of era. The first method used was, I believe, was the same that Karnak has used. On inspection of the API, it would also appear to be the method of choice, as we can specify the BPV, hull class ranges, and variant percentages of generated AI. This proved to work exactly as it should except for the one deal breaking issue that ships generated using this method ignore the YFA of the ship in question and interestingly enough do not use a metaverse id. These id is necessary to connect the ship in game with the id of the player ship in the server database and the API actually comments that only the method that does use this id is compatible with the metaverse. It should also be noted that in the stock scripts, the non metaverse id methods were actually used and then later commented out (deleted) in favour of the metaverse id version.
The metaverse id version, however, only takes parameters from the server database (or single player database) to create player ships. If the ship being created does not belong to a human player, the function appears to create an AI ship but there are no parameters whatsoever over what ship is actially made. Instead, in the mission script calss, another function is used to set BPV strengths of AI teams which previously appeared not to work, but is now known to work only when with metaverse id version method. This is exactly how the stock scripts work and I switched to this method in order to overcome the timewarp issue.
Unfortunately, using this method presents severe problems when trying to remove AI ships in PvP.AI ships are now being created at the exact same moment as player ships. We do not know if a ship is human controlled or AI controlled until after it is created. Teams are setup in a particular order though, with the host team taking the first slot. Since the host generates AI ships, and it is the first team to be created, it cannot yet evaluate the status of subsequent ships yet to be created, and thus cannot know if there are human opponents at the time of AI ship creation. A possible solution to this might just be to re-evaluate AI ships, say, 5 seconds after the mission begins, and destroy them if human opponents are present (but this is not an ideal solution). Another possibility on my list of experiments is to create the host team last (but may have unknown effects in mission).
In conclusion then, there is still something else hapenning in these scripts that the stock scripts do not do that is causing non-host scripts to 'activate' their AI code. These scripts are more complicated and do employ far more API methods than the stock scripts do which perhaps were never tested with the API under these circumstances. If we had the source code to the client API, the problem could be fixed yesterday. Rather, the world of scripting is more like conducting tests on a black box to see what happens without the code. The API does contain many known bugs which have since been documented and easily fixed if the code was available (my list of API bugs seems to grow with each mission written).
Topic: Please report any instance og the Double Fighter/weapon bug (Read 6353 times)