Welcome to AC Web.
Results 1 to 13 of 13
  1. #1

    Open doors in an instance when two or more bosses are killed?


    REGISTER! (FREE)
    Registered members see less ads
    and also gain access to other great features.
    Hai! i'm having trouble finding the right way to require to kill for example first and second boss to open an door
    i know how i can open the door only for 1 boss, but i cant find the way to do for two or more bosses as i stated in the title, i tried to search in bosses scripts but all the scripts seem very diferentm maybe someone know a easy way to do it sorry for the incovenience; (

  2. #2
    Create a counter variable in the instance script and a function to increment it. When you hit two you can just open the door...?

  3. #3
    Quote Originally Posted by Mathix View Post
    Create a counter variable in the instance script and a function to increment it. When you hit two you can just open the door...?
    Way too complicated and inefficient. If you handle bosses properly you can check the state of bosses via GetBossState(boss_data_type)
    You can handle the door inside void Instance::SetBossState(uint32 data, EncounterState state);
    If state == DONE just check for the other boss states as well and if all your wanted bosses are defeated just access the gameobject and activate it.

    Lemme give you an example:
    Code:
                bool SetBossState(uint32 type, EncounterState state) override
                {
                    if (!InstanceScript::SetBossState(type, state))
                        return false;
    
                    switch (type)
                    {
                        case DATA_MAGMAW:
                            if (state == DONE && GetBossState(DATA_OMNOTRON_DEFENSE_SYSTEM) == DONE)
                                if (GameObject* door = GetGameObject(DATA_INNER_CHAMBER_DOOR))
                                    door->SetGoState(GO_STATE_ACTIVE);
                            break;
    Last edited by Dreadii; 05-24-2019 at 11:29 AM.

  4. #4
    Quote Originally Posted by Dreadii View Post
    Way too complicated and inefficient. If you handle bosses properly you can check the state of bosses via GetBossState(boss_data_type)
    You can handle the door inside void Instance::SetBossState(uint32 data, EncounterState state);
    If state == DONE just check for the other boss states as well and if all your wanted bosses are defeated just access the gameobject and activate it.

    Lemme give you an example:
    Code:
                bool SetBossState(uint32 type, EncounterState state) override
                {
                    if (!InstanceScript::SetBossState(type, state))
                        return false;
    
                    switch (type)
                    {
                        case DATA_MAGMAW:
                            if (state == DONE && GetBossState(DATA_OMNOTRON_DEFENSE_SYSTEM) == DONE)
                                if (GameObject* door = GetGameObject(DATA_INNER_CHAMBER_DOOR))
                                    door->SetGoState(GO_STATE_ACTIVE);
                            break;
    So basically what I said? Thanks. I don't think you understand the word inefficient though, might wanna open a book or something? And inefficiency here is not really a problem (borderline retarded to bring up for this small of a function) but since you chose to use that word I'm going to tell you that your implementation is going to cost O(1) + O(log n) since you use both a switch and a map lookup while the implementation I suggested would run in O(1).
    Last edited by Mathix; 05-24-2019 at 11:44 AM.

  5. #5
    <NovusCore>

    Join Date
    Jan 2011
    Location
    https://github.com/novuscore/NovusCore
    Posts
    3,431
    Quote Originally Posted by Mathix View Post
    So basically what I said? Thanks. I don't think you understand the word inefficient though, might wanna open a book or something? And inefficiency here is not really a problem (borderline retarded to bring up for this small of a function) but since you chose to use that word I'm going to tell you that your implementation is going to cost O(1) + O(log n) since you use both a switch and a map lookup while the implementation I suggested would run in O(1).
    r/MurderedByWords
    Last edited by Lightning Blade; 05-24-2019 at 11:44 AM.

  6. #6
    Well man, If a Tauren Warrior can not open a fucking door then blizzard should be remaking this game

  7. #7
    Quote Originally Posted by Mathix View Post
    So basically what I said? Thanks. I don't think you understand the word inefficient though, might wanna open a book or something? And inefficiency here is not really a problem (borderline retarded to bring up for this small of a function) but since you chose to use that word I'm going to tell you that your implementation is going to cost O(1) + O(log n) since you use both a switch and a map lookup while the implementation I suggested would run in O(1).
    Hey sweetie, if you're going to come with cool technical words then at least use them in a correct setting. Your ego is absurd for no good reason. Make sure you know what you're talking about before trying to bad mouth someone because you'll just embarrass yourself if you don't.


    First off, the way Dreadii explained it is how it's done in existing scripts already scripted by TC/whatever core maintainer. It's clean and it doesn't require a lot of self-implementation.

    Your implementation requires a bit more handling of which boss comes when etc.

    That being said, your implementation might be a couple of nanoseconds faster on naive non-optimized builds & weird ABIs.

    In the real world, with an actual decent compiler such as ICC, MSVC, GCC or Clang on -O3 there's no tangible difference when it comes to performance. Both take a couple of clock cycles on x86-64 which is less than a few nanoseconds, so then it comes down to readability and project style which clearly Dreadii wins.

    ------------------------------------------

    Now on to the actual bullshit of your post:

    Quote Originally Posted by Mathix View Post
    I'm going to tell you that your implementation is going to cost O(1) + O(log n) since you use both a switch and a map lookup while the implementation I suggested would run in O(1).
    Big O efficiency is relative, it has absolutely nothing to do with the absolute efficiency of a piece of code, especially in this setting.

    #1
    Code:
    int i = N;
    ++i;
    #2
    Code:
    int i = N;
    std::this_thread_sleep_for(std::chrono::seconds{5});
    ++i;
    Both #1 and #2 are O(1) in that changing N doesn't make them run slower, but #2 is still a hell of a lot slower because of the sleep obviously.

    Big O only makes sense if there's a particular value to test for, in this case there is no value.

    The code is completely O(1), the switch is O(1), GetBossState() uses a vector internally, vector lookups are also O(1).

    I suggest you yourself open a book or something?
    Last edited by Lemons; 05-24-2019 at 03:47 PM.

  8. #8
    <NovusCore>

    Join Date
    Jan 2011
    Location
    https://github.com/novuscore/NovusCore
    Posts
    3,431
    Quote Originally Posted by Lemons View Post
    Hey sweetie, if you're going to come with cool technical words then at least use them in a correct setting. Your ego is absurd for no good reason. Make sure you know what you're talking about before trying to bad mouth someone because you'll just embarrass yourself if you don't.


    First off, the way Dreadii explained it is how it's done in existing scripts already scripted by TC/whatever core maintainer. It's clean and it doesn't require a lot of self-implementation.

    Your implementation requires a bit more handling of which boss comes when etc.

    That being said, your implementation might be a couple of nanoseconds faster on naive non-optimized builds & weird ABIs.

    In the real world, with an actual decent compiler such as ICC, MSVC, GCC or Clang on -O3 there's no tangible difference when it comes to performance. Both take a couple of clock cycles on x86-64 which is less than a few nanoseconds, so then it comes down to readability and project style which clearly Dreadii wins.

    ------------------------------------------

    Now on to the actual bullshit of your post:



    Big O efficiency is relative, it has absolutely nothing to do with the absolute efficiency of a piece of code, especially in this setting.

    #1
    Code:
    int i = N;
    ++i;
    #2
    Code:
    int i = N;
    std::this_thread_sleep_for(std::chrono::seconds{5});
    ++i;
    Both #1 and #2 are O(1) in that changing N doesn't make them run slower, but #2 is still a hell of a lot slower because of the sleep obviously.

    Big O only makes sense if there's a particular value to test for, in this case there is no value.

    The code is completely O(1), the switch is O(1), GetBossState() uses a vector internally, vector lookups are also O(1).

    I suggest you yourself open a book or something?
    Imagine being so dense you don't understand what you're replying to.

  9. #9
    Quote Originally Posted by Lemons View Post
    Hey sweetie, if you're going to come with cool technical words then at least use them in a correct setting. Your ego is absurd for no good reason. Make sure you know what you're talking about before trying to bad mouth someone because you'll just embarrass yourself if you don't.


    First off, the way Dreadii explained it is how it's done in existing scripts already scripted by TC/whatever core maintainer. It's clean and it doesn't require a lot of self-implementation.

    Your implementation requires a bit more handling of which boss comes when etc.

    That being said, your implementation might be a couple of nanoseconds faster on naive non-optimized builds & weird ABIs.

    In the real world, with an actual decent compiler such as ICC, MSVC, GCC or Clang on -O3 there's no tangible difference when it comes to performance. Both take a couple of clock cycles on x86-64 which is less than a few nanoseconds, so then it comes down to readability and project style which clearly Dreadii wins.

    ------------------------------------------

    Now on to the actual bullshit of your post:



    Big O efficiency is relative, it has absolutely nothing to do with the absolute efficiency of a piece of code, especially in this setting.

    #1
    Code:
    int i = N;
    ++i;
    #2
    Code:
    int i = N;
    std::this_thread_sleep_for(std::chrono::seconds{5});
    ++i;
    Both #1 and #2 are O(1) in that changing N doesn't make them run slower, but #2 is still a hell of a lot slower because of the sleep obviously.

    Big O only makes sense if there's a particular value to test for, in this case there is no value.

    The code is completely O(1), the switch is O(1), GetBossState() uses a vector internally, vector lookups are also O(1).

    I suggest you yourself open a book or something?
    I agree with your post but you're missing my point. No reason to try to show off like that, "sweetie" xD

    My point is that it doesn't matter whether he uses that or the other way as it's literally nanoseconds we're talking about. Saying that my way is inefficient and complicated is simply wrong
    Last edited by Mathix; 05-24-2019 at 04:26 PM.

  10. #10
    Quote Originally Posted by Lightning Blade View Post
    Imagine being so dense you don't understand what you're replying to.
    Imagine feeling attacked whenever your BFF is the subject of conversation. I'm not talking to you.

    Quote Originally Posted by Mathix View Post
    I agree with your post but you're missing my point. No reason to try to show off like that, "sweetie" xD

    My point is that it doesn't matter whether he uses that or the other way as it's literally nanoseconds we're talking about. Saying that my way is inefficient and complicated is simply wrong
    Right, it's not inefficient or complicated, you're right. That wasn't my problem with your post, my problem was that you were trying to show off by throwing around terms which make no sense in the context of the post. I wouldn't have quoted you if you stopped after your third sentence.
    Last edited by Lemons; 05-24-2019 at 04:55 PM.

  11. #11
    <NovusCore>

    Join Date
    Jan 2011
    Location
    https://github.com/novuscore/NovusCore
    Posts
    3,431
    Quote Originally Posted by Lemons View Post
    Imagine feeling attacked whenever your BFF is the subject of conversation. I'm not talking to you.



    Right, it's not inefficient or complicated, you're right. That wasn't my problem with your post, my problem was that you were trying to show off by throwing around terms which make no sense in the context of the post. I wouldn't have quoted you if you stopped after your third sentence.
    But I was talking to you.

  12. #12


    Join Date
    Apr 2008
    Location
    Security supervisor
    Posts
    974
    Can you guys just give the guy a solution and go argue elsewhere. like jesus.

  13. #13

    REGISTER! (FREE)
    Registered members see less ads
    and also gain access to other great features.
    Quote Originally Posted by Dreadii View Post
    Way too complicated and inefficient. If you handle bosses properly you can check the state of bosses via GetBossState(boss_data_type)
    You can handle the door inside void Instance::SetBossState(uint32 data, EncounterState state);
    If state == DONE just check for the other boss states as well and if all your wanted bosses are defeated just access the gameobject and activate it.

    Lemme give you an example:
    Code:
                bool SetBossState(uint32 type, EncounterState state) override
                {
                    if (!InstanceScript::SetBossState(type, state))
                        return false;
    
                    switch (type)
                    {
                        case DATA_MAGMAW:
                            if (state == DONE && GetBossState(DATA_OMNOTRON_DEFENSE_SYSTEM) == DONE)
                                if (GameObject* door = GetGameObject(DATA_INNER_CHAMBER_DOOR))
                                    door->SetGoState(GO_STATE_ACTIVE);
                            break;
    sorry for replying too late i will try it, later and i will come back
    i was already triyng this since 1 week ago, but nvm it worked i figured the problem, was becausee i was using DOOR_TYPE_ROOM instead of DOOR_TYPE_PASSAGE i wasted 1 week and the problem was very simple gg i never readed the description of the types of door thanks guys anyway <3
    Last edited by Thiagoch; 05-26-2019 at 11:35 PM.

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •