Announcement

Collapse
No announcement yet.

4.11.0-2883976 does not compile[SOLVED]

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [BUG] 4.11.0-2883976 does not compile[SOLVED]

    ISSUE:
    The current GitHub "release" build version of UT does not compile.

    THE FIX:
    In the file: \UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp

    Comment out lines
    33
    43-44
    70-74
    Build the project (any build configuration) and it will compile and is compatible with the current release of UT


    My Original Post
    The current build version of UT does not compile. I did a completely new download and a clean new setup from GitHub (got the matching version to UT, the 4.11.0-2883976+++depot+UE4-UT-Releases https://github.com/EpicGames/UnrealT...91a0440a110655) and ran setup.bat, etc as I have in the past, this time UT does not compile. Building using the Development Editor config gives ton of errors from the PartyContext.cpp. What to do now Epic?

    Code:
    2>  Module.BlueprintContext.cpp
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(33): error C2653: 'ISocialModule' : is not a class or namespace name
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(33): error C2228: left of '.GetFriendsAndChatManager' must have class/struct/union
    2>          type is 'unknown-type'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(33): error C3861: 'Get': identifier not found
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(43): error C2027: use of undefined type 'IFriendsAndChatManager'
    2>          E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Public\PartyContext.h(55) : see declaration of 'IFriendsAndChatManager'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(43): error C2039: 'GetGameAndPartyService' : is not a member of 'TSharedPtr<IFriendsAndChatManager,0>'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(44): error C2027: use of undefined type 'IGameAndPartyService'
    2>          E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Public\PartyContext.h(9) : see declaration of 'IGameAndPartyService'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(44): error C2039: 'OnFriendsJoinParty' : is not a member of 'TSharedPtr<IGameAndPartyService,0>'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(44): error C2228: left of '.AddUObject' must have class/struct/union
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(70): error C2027: use of undefined type 'IFriendsAndChatManager'
    2>          E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Public\PartyContext.h(55) : see declaration of 'IFriendsAndChatManager'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(70): error C2039: 'GetGameAndPartyService' : is not a member of 'TSharedPtr<IFriendsAndChatManager,0>'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(73): error C2027: use of undefined type 'IGameAndPartyService'
    2>          E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Public\PartyContext.h(9) : see declaration of 'IGameAndPartyService'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(73): error C2039: 'OnFriendsJoinParty' : is not a member of 'TSharedPtr<IGameAndPartyService,0>'
    2>E:\Dev\UnrealTournament-release\UnrealTournament\Source\BlueprintContext\Private\PartyContext.cpp(73): error C2228: left of '.RemoveAll' must have class/struct/union
    Last edited by Snake.Pliskin; 03-10-2016, 07:25 PM. Reason: Added how to fix this issue
    Author: Domination Game Mode (Native UT4 Plug-in)
    Get the Install on ModDB.com
    Source Code available on GitHub

    #2
    I'm running into the same problem.
    Creator of NewNet for UT99

    Comment


      #3
      I'd like to know how their build system (respectively the github branch mirroring) works if the changelist is the same but the master branch has properly moved the related code to WITH_SOCIAL.
      ] Map Scaler Tool | Betrayal for UT4 | No Spawn Protection | No Pickup Timer | BioLauncher (revived) | ForcePickupSpawn | Map cosmetics::P | Safe Spawn::P | Why numbers for Health/Armor suck!::ANALYSIS/CONCEPT
      ] UT3 Addons: NoMoreDemoGuy | PickupRespawnTweak | Mutate Spec | MutePawnSounds | NoPlayerBeacon | Epic FTW | Epic FOCK | TripodSound (... and many more)

      Comment


        #5
        Basically you just need to remove the offending lines from the PartyContext class for now. Sorry I blame myself for not keeping on top of this last week like I had been doing.
        HABOUJI! Ouboudah! Batai d'va!
        BeyondUnreal - Liandri Archives [An extensive repository of Unreal lore.] - Join us on IRC [irc.utchat.com - #beyondunreal]

        Comment


          #6
          Yep, manually fixing the problem always works (had to already in past builds etc.). But currently, I've been waiting for an update/fix regarding that before compiling any version locally. Since the changes might include ones to the header files, the engine fully re-compiles even if it's a seperate module. Only occasionally, it works without having to re-compile everything (which happens automatically by the header/build tool).

          If the official launcher build is not compiled/build from a release branch/repo/revision locally in P4, why does the release branch in Github exist. Also random note, why aren't the tags updated for the actual builds to point to the specific revision for the builds. If such release branch (in P4) is kept on point with the actual working release branch (on GH), it would reduce the possible problems. Sometimes it is also related to the proprietary private modules/code. Not sure if all these things are done manually by Pete, or the mirroring tool does it. One thing I'd also like to see, rebased branch instead of a merged one.

          Another issue with the branches. The master is still on 2771752 where as the release continously updates (currently 2884412). I recently worked on content plugin for a pull request. Initially I created that as a plugin compiled from the Github release branch (using a specific revision). For the pull request, I had to compile the source code from the actual updated master branch. The problem I had with this approach, all the content files were invalid as they are saved with a newer version since the release branch has an updated version even if the master branch is technially ahead to the release branch. Had to re-create everything, luckily the content assets weren't that complex but it was a nice surprise. Not only because of this, I have a very specific opinion about C++ and UT-UE4.
          (if you click the links, it points to the most recent version file of the branches, the version numbers might be updated in the meantime)




          One thing which results from the current non-updated release branch. The version/changelist has already been updated (files have been merged). Therefore a possible fix would either have to revert the version or is conflicting with the current release builds. This happened in the past as well, where the actual editor version was ahead and you had to either hack the version or compile your code with a different revision (although, if the changes are minimal, the hack doesn't mean anything).
          ] Map Scaler Tool | Betrayal for UT4 | No Spawn Protection | No Pickup Timer | BioLauncher (revived) | ForcePickupSpawn | Map cosmetics::P | Safe Spawn::P | Why numbers for Health/Armor suck!::ANALYSIS/CONCEPT
          ] UT3 Addons: NoMoreDemoGuy | PickupRespawnTweak | Mutate Spec | MutePawnSounds | NoPlayerBeacon | Epic FTW | Epic FOCK | TripodSound (... and many more)

          Comment


            #7
            Originally posted by RattleSN4K3 View Post
            I'd like to know how their build system (respectively the github branch mirroring) works if the changelist is the same but the master branch has properly moved the related code to WITH_SOCIAL.
            Well, if the code is missing #if WITH_SOCIAL somewhere they wouldn't necessarily notice, since they are building with it set to 1 and the dependencies available. The MCP and social parts of the source (and maybe others? not sure) are not copied over to github from Epic's internal Perforce repository. So that's how you can have the "same" branch version as the release binaries, but still have a failing build.

            What Epic needs is a CI server for the github repository so they are notified when the build breaks. Currently the builds do get fixed, but it can take up to a week sometimes depending on who has time to fix it.

            Comment


              #8
              Yep, but mentioned in a previous post, the working changes related to the problem are already 5-7 days ago where as the actual release revision (judging from teh changelist) is only 4 days ago. Why are the changes not merged/included in the actual release branch? Really seems like they have to or doing everything regarding the release branch by hand (automated by the Bot occasionally).

              Originally posted by Mattiwatti View Post
              What Epic needs is a CI server for the github repository so they are notified when the build breaks. Currently the builds do get fixed, but it can take up to a week sometimes depending on who has time to fix it.
              Definitely. If they aren't already having something like this. Good ones also exist for local use.
              ] Map Scaler Tool | Betrayal for UT4 | No Spawn Protection | No Pickup Timer | BioLauncher (revived) | ForcePickupSpawn | Map cosmetics::P | Safe Spawn::P | Why numbers for Health/Armor suck!::ANALYSIS/CONCEPT
              ] UT3 Addons: NoMoreDemoGuy | PickupRespawnTweak | Mutate Spec | MutePawnSounds | NoPlayerBeacon | Epic FTW | Epic FOCK | TripodSound (... and many more)

              Comment


                #9
                Originally posted by RattleSN4K3 View Post
                Yep, but mentioned in a previous post, the working changes related to the problem are already 5-7 days ago where as the actual release revision (judging from teh changelist) is only 4 days ago. Why are the changes not merged/included in the actual release branch? Really seems like they have to or doing everything regarding the release branch by hand (automated by the Bot occasionally).

                Definitely. If they aren't already having something like this. Good ones also exist for local use.
                Frankly, because that is not a real world scenario for a test and release cycle. The builds are always significantly behind master when they come out, and they've been "off master" for a while when a build actually releases. Normally from the first QA build, they leave behind the master changes and only merge bug fixes back in to the release. So even though that release commit was checked in only a few days ago, they diverged from master long before that.

                They definitely do need to automate builds from github, at least on master and the release ref. I think Pete mentioned something about doing that but it's a one man show for build automation.

                Also it's about time to rename clean-master back to master now.
                HABOUJI! Ouboudah! Batai d'va!
                BeyondUnreal - Liandri Archives [An extensive repository of Unreal lore.] - Join us on IRC [irc.utchat.com - #beyondunreal]

                Comment


                  #10
                  Note: I'm just curious to know the actual reason of such problem. This is not meant to be offensive. This post is also not meant to expose the possible inobservance of anyone involved in that process. I really like to understand that system. I don't want to highlight problems with that used system. The system is likely good enough or working really well for the whole process of building and releasing the engine, the games and all the marketplace content. I don't want to bad-mouth that system nor anything related.

                  Also, I don't think I have stated everything correctly in here. This is pure assumption.



                  It's just a complex and IMO time-consuming system. The launcher builds (internally likely called Releases) are built from the P4 release branch (UE4-UT-Releases).
                  Code:
                  Version: 4.11.0-2883976+++depot+UE4-UT-Releases
                  API Version: 2883976
                  Compiled (64-bit): Feb 26 2016 16:37:33
                  Build Configuration: Development
                  Branch Name: ++depot+UE4-UT-Releases
                  That specific revision for the changelist of 2883976 from the actual master branch (UE4-UT) has the changelist of 2884581. This is a different counter to the actual master changelist. By judging juding from the master changelist (in commit message) (and compile time), the master branch was between these two commits/revision when they planned to create a release:
                  https://github.com/EpicGames/UnrealT...ef3befac94e67f
                  https://github.com/EpicGames/UnrealT...bafd49e52f2e89

                  However, this does not say everything up to that specific commit has been added to the release. If you check previous commits from the actual release branch (on Github), you see the merges of 2884372, 2884175, 2883799, 2883503, 2883505, 2883096, 2881941, 2880957 and so on. These cangelist merges are not specifically in order. The interesting part would be the changelist merges starting with 2883 and 2881.

                  The latest related commit about fixing the social stuff is 2882032. This changelist isn't merged but several others after and before that specific change (if I understand the stated changelist (CL) in commit messages correctly). Even the following commit by JoeWilcox has updated the module BlueprintContext which is the problematic one on Github ("New Bins for testing"). We know this actual change hasn't been added as the release branch cannot be compiled out of the box. All the merge commits do have Pete as author. It really looks like the changes are selected and merged manually. AFAIK, they are testing the release version before publishing and before that they create these test builds (from master branch?). And I think this is critical, if everything I assumed in here is correct. If changes are merged manually selectively from the master branch to release, how to guarantee if every change has been merged into the release branch (like this issue with the social stuff). Isn't this adding a lot of manual work into the workflow of releasing a build?
                  ] Map Scaler Tool | Betrayal for UT4 | No Spawn Protection | No Pickup Timer | BioLauncher (revived) | ForcePickupSpawn | Map cosmetics::P | Safe Spawn::P | Why numbers for Health/Armor suck!::ANALYSIS/CONCEPT
                  ] UT3 Addons: NoMoreDemoGuy | PickupRespawnTweak | Mutate Spec | MutePawnSounds | NoPlayerBeacon | Epic FTW | Epic FOCK | TripodSound (... and many more)

                  Comment


                    #11
                    You need to think about the release process from their standpoint. I will use obviously fake numbers to help explain this.

                    Imagine you have a master branch, you commit to it regularly. This week you commit versions 111,112,113,114,115,116,117,118,119,120.

                    At version 112 you prepare a release. You merge everything from 112 into your release branch and cut QA builds (these are UE4-UT builds in P4) for your QA team to test. As your QA team tests, they find several bugs. These bugs are fixed in your master branch in versions 121,122,123. So what you end up doing on your release branch is basically a git cherry-pick versions 121,122,123 (it's not exactly but this is the closest thing that exists in git to what they are doing in P4). However, cherry picking those fixes only applies those specific fixes to your releases branch and nothing else about the state of the repository at that moment. Then you cut a new QA build that incorporates fixes from 121,122,123 but you will not have any of the fixes from 113-120 until the next time you start a release cycle.

                    The process includes essentially a code freeze on the release branch. The code freeze means that nothing that isn't identified as a problem by QA on the release branch will get merged into release. I'm sure that the fixes to the social stuff would have been merged if they had known it was an issue on release but I missed several days of checking if master could compile this past week when I had been trying to keep up on it.

                    To answer your question, that does add a lot of manual work to each build, but that's why Epic employs release managers for exactly this sort of thing. I'm sure it could be automated more but I'm guessing this is a process they have been following for many years. Also, it's possible that it is more automated than I am imagining it to be, but the general ideas I've expressed above will still apply to whatever system they are using. Mainly:

                    1) Code freeze on release
                    2) QA builds cut
                    3) only QA reported issues merged in to release from this point
                    4) new QA build cut, repeat 2-4 as necessary
                    5) new release cut from UE4-UT-Releases
                    HABOUJI! Ouboudah! Batai d'va!
                    BeyondUnreal - Liandri Archives [An extensive repository of Unreal lore.] - Join us on IRC [irc.utchat.com - #beyondunreal]

                    Comment


                      #12
                      If the QA team is testing a build and adding an issue entry to Jira (their bug tracking system), they state the affected version with the official build (since they are using that release).

                      Affects Version/s:
                      ++depot+UE4-UT-Releases-CL-2883976

                      Assuming you're right with the cherry-pick (and it is likely the case by juding the commit message related to merge), do they check the actual release branch or the master one in order to track down the problem and implement the fix. In case of the master branch, how to verify if the given code base is really the code the build is compiled from and not a single not-cherry-picked commit is causing the bug, and they check the most recent code up to that changelist. In case of tracking the problem with the release branch, how does that correlate with the most recent master code's revision where they likely have to fix the problem. It seems like a complex process with potential problems and overlooked changes, if you ask me.

                      In your example, how they know if the release build has bugs which are already fixed by a commit in 113-120. Aren't they only checking the revision up to 112 in order to fix the QA build, isn't this potentially risky to overlook changes done in 113-120 which might be overlooked or even reverted by changes done in 121, 122 or 123. For such a small list of changes, it might not be that much of work or problem but with the codebase of the engine/game, it could get worse. Interesting workflow nonetheless.

                      It somehow explains the case for the Github pull requests


                      Are the not cherry-picked/unmerged commits somehow tracked and listed, in order to prevent loosing made changes (in P4 or their custom automation tool)?
                      ] Map Scaler Tool | Betrayal for UT4 | No Spawn Protection | No Pickup Timer | BioLauncher (revived) | ForcePickupSpawn | Map cosmetics::P | Safe Spawn::P | Why numbers for Health/Armor suck!::ANALYSIS/CONCEPT
                      ] UT3 Addons: NoMoreDemoGuy | PickupRespawnTweak | Mutate Spec | MutePawnSounds | NoPlayerBeacon | Epic FTW | Epic FOCK | TripodSound (... and many more)

                      Comment


                        #13
                        I think normally what happens is that they fix the bug on master and merge it into the release. If the bug is already fixed they probably try to find the commit that fixed it and merge that one.

                        That code freeze process has been industry wide for a long time which is why I suspect this is just what they have done for many years.
                        HABOUJI! Ouboudah! Batai d'va!
                        BeyondUnreal - Liandri Archives [An extensive repository of Unreal lore.] - Join us on IRC [irc.utchat.com - #beyondunreal]

                        Comment


                          #14
                          [MENTION=35739]Snake.Pliskin[/MENTION], [MENTION=7442]timbur[/MENTION], [MENTION=192]RattleSN4K3[/MENTION], [MENTION=8813]cafe[/MENTION], [MENTION=3252]Sir_Brizz[/MENTION] - Anyone able to compile yet?

                          Thanks.
                          Another crazy idea brought to you by richardboegli ;P

                          Comment


                            #15
                            Originally posted by richardboegli View Post
                            [MENTION=35739]Snake.Pliskin[/MENTION], [MENTION=7442]timbur[/MENTION], [MENTION=192]RattleSN4K3[/MENTION], [MENTION=8813]cafe[/MENTION], [MENTION=3252]Sir_Brizz[/MENTION] - Anyone able to compile yet?

                            Thanks.
                            master will compile in VS2013. release will compile if you either merge the changes from master into UTPartyContext or comment out the erroring lines.. again only in VS2013. The problem in 2015 is the WebMREcord has some dependencies that are linked stupid. You can disable webmrecord and it will work, too.
                            HABOUJI! Ouboudah! Batai d'va!
                            BeyondUnreal - Liandri Archives [An extensive repository of Unreal lore.] - Join us on IRC [irc.utchat.com - #beyondunreal]

                            Comment

                            Working...
                            X