Jump to content

Elron

Members
  • Posts

    7
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Elron's Achievements

Newbie

Newbie (1/3)

0

Reputation

  1. Okay I have tested the patch using SQL query now. At the moment it's working for me, if anyone else has tested it, please report. Tested it as I said above in the first post.
  2. Hm okay. Thank you for your testing until now fullburned. Maybe...this function is also called, to reset instances on the usual way. So it is possible that there are no players inside (so the calling of itr->getSource might be the problem), and that might be a reason for crashing. I will try to create a new patch, with more checks to prevent a crash. Edit: Or maybe we could just use an SQL query inside the code....that would be the most accurate solution for our problem I think. Edit 2: New patch is now using SQL query. It should select the instance from DB and if there is an entry for this instance, the instance should not be respawned due to the issue mentioned above. I did not test it by myself yet. Updated first post. Btw: Yeah the pool system seems to be a good idea for being able to link trashs => boss.
  3. Oh yeah, stupid mistake . Thanks, I will correct it and create a new paste. New paste in first post.
  4. Ah okay. Then we might need a bigger patch. So as it seems the (wrong) deleting of respawntimes of bosses (and also trash) in instances with an ID should be handled by the patch above... I will try to test it a bit more, and if it works, we could think about the correction for the trash-non-respawn in case a boss has been killed. If someone is already testing the patch, I would be pleasured about responses, if it worked or not.
  5. First, thank you for your answer. Hm that's a quite interesting point, the trash respawn. I think (I'm not sure) that the "usual" respawn should still be handled by the usual respawn routine. That fix here should only affect the (wrong) deleting of the respawntimes in an instance with an ID. I was just told, that some trashes do not respawn if you have killed a specific boss. For example in Tempest Keep : If you have killed Al'ar, all trashs on the way to that boss should not respawn on retail. Do you maybe know anything concerning this "trash-not-respawn"? If it is that way, I think this needs to be handled by that part of code where the fix is in. Edit: I just thought about the idea mentioned above. If it is actually that way on retail, we might need a new field in the `creature`table, where the trash is linked to the "boss", that needs to be killed so the trash will not respawn again. So this might need a bigger patch if it is really that way on retail.
  6. Hey there. As we know there are currently some problems with the instance/id system, since the creatures DO even respawn if the players have an ID with that instance. I have tried something to stop that respawning of creatures in instances with an ID and since this is the section for discussing code, I would like to know what you think of my try to fix it. First of all, some revisions I am currently using: MaNGOS: 7739 ScriptDev2: 1035 UDB: 371 ACID: 28 How I tested the respawning of creatures in instances with an ID: I used 2 accounts to test it. I just created a raid group with two characters and entered the instance (in my example Zul'Aman). GM mode was OFF and my characters were visible. Then I spawned an instance boss (so I do not need to walk the whole way ). I killed the boss using the ".die" command and my characters were bound to the instance. After that I left the group with one of my characters and the group was disbanded. Then I shut down the server and restarted it. The boss was respawned again. How I got the (following) idea to fix it: I put some debug lines near all places where the SQL command "DELETE FROM creature_respawn" is used. So I noticed, that the function "ObjectMgr:: DeleteRespawnTimeForInstance(instanceId)" is that function that removed the remaining respawntime of my creature. After that I searched all places, where that function is called and I used debug lines again, to get the right function call. The function "InstanceMap::UnloadAll(bool pForce)" called the function for the deleting of the respawntime. And this is the place where my fix is located... The fix: First of all here a link to the patch: New version (SQL): http://paste2.org/p/199545 BUGGED OLD VERSION 2: http://paste2.org/p/199313 BUGGED OLD VERSION: http://paste2.org/p/197700 As you can see, there is a variable called "m_resetAfterUnload" that needs to be true in order to be able to call the deleting function. I added a new variable here "bool instanceHasId". This variable needs to be false, so the deleting function can be called. This variable is first set to false. But it can be set to true, if a player on the instance map has an ID for the instance map he is in. => So the instance's respawntimes will NOT be deleted, if a player on the instance map is bound to the instance. <= I think this could be a correct solution and I would like to know, what you think about this try to fix it. Happy about any responses.
  7. Hey. I think there is something wrong concerning the automatically being flagged for pvp. Revisions: MaNGOS: 7739 ScriptDev2: 1035 Udb: 371 Acid: 28 Bug: How it does work: You are being flagged for pvp in the two nearest zones near the capital city. Example : Capital : Stormwind Zones : Elwynn Forest, Westfall If you enter one of these zones as a horde character you are flagged for pvp. The important thing to mention here is, that this does also happen on a PvE realm. How it should work: According to W0Wwiki you should NOT be flagged in these zones on a PvE realm. This should only happen on PvP realms. On PvE realms you should only be auto flagged for PvP if you enter a capital city of the hostile faction. Fix: Author: Me. What does the fix change? The fix modifies the selection of zones for the automatically flagging. It differentiates between PvP and PvE specific zones of autoflagging. Here's the fix and I hope it will work : http://paste2.org/p/196772
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use