Algumas notas:

• o jogo usa Battleye Anti-Cheat - é aparentemente obrigatório, mesmo se você quiser apenas jogar um jogador. Não faço ideia se existe um parâmetro de inicialização que o desativa.

Você pode renomear dois arquivos .exe em / Mount & Blade II Bannerlord / bin / Win64_Shipping_Client /

• renomeie "TaleWorlds.MountAndBlade.Launcher.exe" para "TaleWorlds.MountAndBlade.Launcher.exe_backup" (ou algo semelhante - só não é permitido manter seu nome original)

• renomeie "Bannerlord.exe" para "TaleWorlds.MountAndBlade.Launcher.exe"

para pelo menos fazer o jogo começar, ver as telas iniciais e então eu chego ao ponto que tenho que interagir com o jogo pela primeira vez (alterar as configurações de brilho), ponto em que minha CPU e GPU ficam totalmente descontroladas e eu não consigo interagir com o jogo.

Posso confirmar que ignorar o iniciador (movendo TaleWorlds.MountAndBlade.Launcher.exe para fora do caminho e substituindo-o por uma cópia de Bannerlord.exe ) leva-o pelo menos para a tela de calibração de brilho (ou como tanto quanto o menu principal se eu definir brightness_calibrated = 1 em $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Configs/engine_config.txt ).

No entanto, parece que há um bug com a entrada do mouse; o cursor se move e fica visível, mas as opções do menu não são destacadas ao se mover sobre elas e o jogo não responde aos cliques (e naturalmente não há navegação no teclado ...). O problema persiste com cada permutação de V-sync, iniciando em uma área de trabalho virtual, desativando a sobreposição do Steam, etc.

De particular interesse em steam-261550.log é o spamming de fixme:win:GetMouseMovePointsEx (24 0x3c87f298 0x3c87f2b0 64 1) stub . Possivelmente relacionado ao bug 36873 do Wine ?

Discussão adicional no fórum da TaleWorlds: https://forums.taleworlds.com/index.php?threads/linux.385761/page -2 e https://forums.taleworlds.com/index.php?threads/b0 -8 -9-cliques do mouse-não-registrado-no-linux.395650 /

EDIT: tentei conectar um controlador, e isso me permitiu navegar pelo menu. Vou ver até onde consigo ir, mas ... progresso!

Para mim, o jogo ainda estava travando no lançamento depois de executar Bannerlord.exe vez de TaleWorlds.MountAndBlade.Launcher.exe . Usando protontricks, instalei o dotnet4.8 e o vcrun2015 - o jogo ainda trava, mas pelo menos consigo admirar a tela de carregamento do jogo.

Posso confirmar que estou tendo o mesmo problema com entradas de mouse, no Manjaro com Proton 5.0-5. Eu estava no beta fechado e o jogo estava funcionando bem antes da última atualização, então estou bastante confiante de que o resto do jogo deve estar funcionando assim que consertarmos esse problema de navegação.

Então, depois de tentar encontrar um personagem criado inteiramente por meio de um gamepad da Logitech, parece que encontrei outro obstáculo na forma de um travamento forte na tela de carregamento logo após a criação do personagem (entrada relevante de steam-261550.log : wine: Call from 0x7b00fc3e to unimplemented function api-ms-win-crt-private-l1-1 -0.dll._o___stdio_common_vswprintf, aborting ). Isso persiste mesmo depois de executar protontricks 261550 vcrun2015 e protontricks 261550 vcrun2017 .

Apenas uma rápida pesquisa no Google, já que não consigo mesmo testá-lo agora (ainda estou baixando), mas um problema semelhante aparentemente afetou o BNet Launcher em algum ponto e foi corrigido adicionando ucrtbase e api-msi-win etc etc dll como substituições via winecfg.

As batalhas personalizadas funcionam quando você navega até elas usando o gamepad e, quando no jogo real, você pode usar o mouse para lutar.

No entanto, o jogo para mim parecia incrivelmente desbotado e brilhante enquanto eu jogava e alterar as configurações travava o jogo metade do tempo, junto com definir tudo para baixo trava o jogo.
Aqui está um registro da falha ao salvar as configurações.
steam-261550.log

Editar: alterar as configurações para baixo fez com que os costumes parassem de funcionar, então evite fazer isso.

Certo, fiz algumas leituras, pesquisas, baixei o jogo três vezes, e mais pesquisas, e acho que descobri.

Bannerlord está usando o Battleye, que é um software Kernel Anti-Cheat. Como a instância do Proton-Wine não é o kernel do Linux básico, mas sim o kernel do Windows, o Battleye é incapaz de interceptar a entrada do mouse direto da porta USB para verificar se é real e, em seguida, deixá-lo entrar no jogo, ou é confundir a entrada do mouse do Wine como uma entrada de mouse artificial baseada em programa, o que significa que o sistema Anti-Cheat entra em ação.

Lembro-me de ter lido em algum lugar que o Battleye não joga bem com o Linux, mas esse comentário era de ... 3 anos atrás? Então, eu realmente não sei o estado atual do software anti-cheat. Portanto, as opções são, eu acho, pedir ao TaleWorlds para configurar o Battleye para funcionar bem com o Proton, desabilitá-lo para o Proton até que uma versão Linux adequada possa ser feita e, em seguida, reativá-lo lá (eles estão usando Mono para alguma coisa. Parecia o inicializador?) Espere até que o jogo seja lançado corretamente, porque as chances são de que eles provavelmente irão adiar o suporte a vários sistemas operacionais até mais tarde no Acesso antecipado, então é 10 vezes mais fácil distribuir atualizações ... Ou descobrir como deixe um Window Executable Battleye ir direto para o kernel baseado em Linux para que ele possa verificar tudo o que quiser e nos deixe fazer entradas no jogo sem acionar o anti-cheat ...

Acho que estamos esperando um pouco mais pelo Bannerlord.

Certo, fiz algumas leituras, pesquisas, baixei o jogo três vezes, e mais pesquisas, e acho que descobri.

Bannerlord está usando o Battleye, que é um software Kernel Anti-Cheat. Como a instância do Proton-Wine não é o kernel do Linux básico, mas sim o kernel do Windows, o Battleye é incapaz de interceptar a entrada do mouse direto da porta USB para verificar se é real e, em seguida, deixá-lo entrar no jogo, ou é confundir a entrada do mouse do Wine como uma entrada de mouse artificial baseada em programa, o que significa que o sistema Anti-Cheat entra em ação.

Lembro-me de ter lido em algum lugar que o Battleye não joga bem com o Linux, mas esse comentário era de ... 3 anos atrás? Então, eu realmente não sei o estado atual do software anti-cheat. Portanto, as opções são, eu acho, pedir ao TaleWorlds para configurar o Battleye para funcionar bem com o Proton, desabilitá-lo para o Proton até que uma versão Linux adequada possa ser feita e, em seguida, reativá-lo lá (eles estão usando Mono para alguma coisa. Parecia o inicializador?) Espere até que o jogo seja lançado corretamente, porque as chances são de que eles provavelmente irão adiar o suporte a vários sistemas operacionais até mais tarde no Acesso antecipado, então é 10 vezes mais fácil distribuir atualizações ... Ou descobrir como deixe um Window Executable Battleye ir direto para o kernel baseado em Linux para que ele possa verificar tudo o que quiser e nos deixe fazer entradas no jogo sem acionar o anti-cheat ...

Acho que estamos esperando um pouco mais pelo Bannerlord.

Eu não estou acreditando nisso. Se Battleye está causando problemas com o cursor, por que não veríamos o mesmo problema ao usar um gamepad?

Battleye não é o problema, é uma instalação opcional e necessária apenas para o modo multijogador.

Battleye não é o problema, é uma instalação opcional e necessária apenas para o modo multijogador.

Para expandir a postagem de tkamat, eu também estava no beta fechado e o jogo ainda funcionou por alguns patches depois que o Battleeye foi atualizado para o beta. Pelo que entendi, eles o tornaram opcional na época, você poderia simplesmente ignorar o cancelamento da instalação do Battle Eye na primeira execução e ele não o expulsaria dos jogos por não usá-lo.

Cerca de duas semanas atrás, houve um patch que quebrou a capacidade de vários usuários do Windows de jogar, aparentemente tinha algo a ver com ter um controlador ou joystick conectado enquanto tentava jogar com teclado / mouse. Eles corrigiram o problema alguns dias depois, mas todos os usuários do Linux no fórum relataram que não havia entrada de mouse, independentemente de haver ou não um controlador conectado, mesmo após a atualização.

Estávamos especulando no fórum que poderia ser um problema com o Steamplay apresentar um controlador virtual para o jogo no nível do driver, mas nunca confirmamos isso. Quanto à falha no início de uma campanha, nunca chegamos tão longe, já que era um beta multijogador.

Battleye não é o problema, é uma instalação opcional e necessária apenas para o modo multijogador.

Para expandir a postagem de tkamat, eu também estava no beta fechado e o jogo ainda funcionou por alguns patches depois que o Battleeye foi atualizado para o beta. Pelo que entendi, eles o tornaram opcional na época, você poderia simplesmente ignorar o cancelamento da instalação do Battle Eye na primeira execução e ele não o expulsaria dos jogos por não usá-lo.

Cerca de duas semanas atrás, houve um patch que quebrou a capacidade de vários usuários do Windows de jogar, aparentemente tinha algo a ver com ter um controlador ou joystick conectado enquanto tentava jogar com teclado / mouse. Eles corrigiram o problema alguns dias depois, mas todos os usuários do Linux no fórum relataram que não havia entrada de mouse, independentemente de haver ou não um controlador conectado, mesmo após a atualização.

Estávamos especulando no fórum que poderia ser um problema com o Steamplay apresentar um controlador virtual para o jogo no nível do driver, mas nunca confirmamos isso. Quanto à falha no início de uma campanha, nunca chegamos tão longe, já que era um beta multijogador.

O jogo rodou bem no Linux antes do battleye? Eu estava no Windows durante o beta, então nunca tentei usar o próton.

Battleye não é o problema, é uma instalação opcional e necessária apenas para o modo multijogador.

Para expandir a postagem de tkamat, eu também estava no beta fechado e o jogo ainda funcionou por alguns patches depois que o Battleeye foi atualizado para o beta. Pelo que entendi, eles o tornaram opcional na época, você poderia simplesmente ignorar o cancelamento da instalação do Battle Eye na primeira execução e ele não o expulsaria dos jogos por não usá-lo.
Cerca de duas semanas atrás, houve um patch que quebrou a capacidade de vários usuários do Windows de jogar, aparentemente tinha algo a ver com ter um controlador ou joystick conectado enquanto tentava jogar com teclado / mouse. Eles corrigiram o problema alguns dias depois, mas todos os usuários do Linux no fórum relataram que não havia entrada de mouse, independentemente de haver ou não um controlador conectado, mesmo após a atualização.
Estávamos especulando no fórum que poderia ser um problema com o Steamplay apresentar um controlador virtual para o jogo no nível do driver, mas nunca confirmamos isso. Quanto à falha no início de uma campanha, nunca chegamos tão longe, já que era um beta multijogador.

O jogo rodou bem no Linux antes do battleye? Eu estava no Windows durante o beta, então nunca tentei usar o próton.

Ele começou a trabalhar no Linux por volta de dezembro, travava de vez em quando, mas o desempenho era aceitável depois que terminava de compilar os shaders para cada mapa. Eu também estava em uma placa de vídeo relativamente fraca (rx 480) na época, então acho que em termos de desempenho o jogo ficará bem no Linux se conseguirmos uma pequena ajuda da taleworlds para corrigir esses problemas. Obtivemos uma resposta do desenvolvedor sobre o problema do mouse que estávamos enfrentando, então parece que eles não são, no mínimo, hostis em considerar os usuários Linux e prótons.

Que dia não conseguir encontrar meu controlador! Eu realmente consegui algo funcionando! Segui as renomeações acima e tentei conectar meu switch Joy-Cons usando este prático driver .

Quando o joy-cons é reconhecido como um controlador profissional, posso clicar em coisas com o mouse depois de usar o controle esquerdo para posicionar o cursor. Mire e clique do mouse funcionam bem em minhas batalhas de teste rápido, então o problema pode estar relacionado ao menu. Não tenho certeza se isso funcionará com outros controladores, ou se tem algo a ver com a maneira que o driver é implementado.

Apenas uma rápida pesquisa no Google, já que não consigo mesmo testá-lo agora (ainda estou baixando), mas um problema semelhante aparentemente afetou o BNet Launcher em algum ponto e foi corrigido adicionando ucrtbase e api-msi-win etc etc dll como substituições via winecfg.

Adicionar esses como substituições ainda resultou em um travamento, mas fui capaz de aplicar força bruta seguindo as etapas de um problema semelhante: Age of Empires 2: Definitive Edition :

cd /home/$USER/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10

O que me levou muito mais longe:

O mouse continua inutilizável para diálogos e o menu de pausa (você pode "Clicar para continuar" aqui, então ele obviamente reconhece os cliques do mouse, mas não sabe se o mouse está ou não sobre algo, a menos que você mova o cursor com o controlador). Funciona bem para movimento e combate. Passei por alguns dos objetivos do tutorial antes de travar novamente (desta vez por causa de um eventfd: Too many open files ; vou reiniciar com um ulimit -Hn bombeado e tente novamente).

EDITAR com referência a: BattlEye:

Bannerlord está usando o Battleye, que é um software Kernel Anti-Cheat. Como a instância do Proton-Wine não é o kernel do Linux básico, mas sim o kernel do Windows, o Battleye é incapaz de interceptar a entrada do mouse direto da porta USB para verificar se é real e, em seguida, deixá-lo entrar no jogo, ou é confundir a entrada do mouse do Wine como uma entrada de mouse artificial baseada em programa, o que significa que o sistema Anti-Cheat entra em ação.

Isso parece improvável. Se fosse relacionado ao anti-cheat, eu esperaria o oposto dos sintomas atuais (ou seja, mouse funcionando bem em menus / caixas de diálogo, mas não para movimento / combate). Eu também esperaria que teclados e controladores fossem afetados da mesma forma (o que não parece ser o caso).

O BattlEye certamente vai atrapalhar as coisas para o multijogador, mas deve ser totalmente desnecessário para o modo singleplayer (e de fato, outros jogos BattlEye com modos singleplayer funcionam razoavelmente bem no Proton, por exemplo, Conan: Exiles).

@YellowApple Você pode ver se o seguinte patch corrige a falha sem vcredist? (ou seja, defina ucrtbase e api-ms-win-crt-private-l1-1-0 para incorporar ao testar)

https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce

Seria legal se pudesse ser consertado upstream sem a necessidade de substituições :) Não tenho o jogo no momento, então não posso testar.

@YellowApple Eu tentei reproduzir sua solução, mas infelizmente não está funcionando para mim, e a campanha está quebrando após a criação do personagem. Os arquivos de log ainda parecem apontar para api-ms-win-crt-private-l1-1-0.dll._o___stdio_common_vswprintf como o problema. Você executou alguma outra etapa, como reinstalar o vcrun-2017 ou outra coisa?

Portanto, aumentar meu ulimit -Hn ajudou, e consegui chegar até o mapa principal, mas notei que qualquer tentativa de salvar o jogo fará com que o jogo congele temporariamente por alguns minutos enquanto conecta todos os núcleos / thread na minha CPU (alguns sons continuam a tocar em segundo plano, no entanto). Suspeito que haja uma função de salvamento automático que está acionando congelamentos semelhantes também (aconteceu depois de trapacear em algum inventário e aconteceu novamente quando estava ocioso por um tempo).

Além disso, parece que as caixas de diálogo pop-up farão com que o cursor do mouse acionado pelo joystick desapareça (não determinou se isso sempre acontece ou não; com bastante movimento, consegui fazer com que o botão "OK" fosse destacado brevemente, então acho o cursor está invisível).

Também posso confirmar que os botões do mouse e a roda de rolagem funcionam totalmente nos menus / caixas de diálogo; você só precisa usar o controlador para mover o cursor até o item que deseja clicar ou rolar. Portanto, o que quer que esteja causando esse bug tem a ver puramente com para onde o jogo pensa que o mouse está apontando.

@YellowApple Você pode ver se o seguinte patch corrige a falha sem vcredist? (ou seja, defina ucrtbase e api-ms-win-crt-private-l1-1-0 para embutidos durante o teste)

Farei @qsniyg (assim que eu conseguir que o Vagrant coopere). Essas funções estão todas implementadas, mas eliminadas ou algo assim?

@YellowApple Eu tentei reproduzir sua solução, mas infelizmente não está funcionando para mim, e a campanha está quebrando após a criação do personagem. Os arquivos de log ainda parecem apontar para api-ms-win-crt-private-l1-1-0.dll._o ___ stdio_common_vswprintf como o problema. Você executou alguma outra etapa, como reinstalar o vcrun-2017 ou outra coisa?

@tkamat : Passos exatos que dei (até onde me lembro):

• protontricks 261550 vcrun2015 (e executou o jogo; travou)
• protontricks 261550 vcrun2017 (e executou o jogo; travou)
• Adicionadas substituições nativas para ucrtbase e api-ms-win-crt-private-l1-1-0 via winecfg (e executou o jogo; travou)
• Fiz toda a coisa de "dar um golpe em um VC redist EXE com cabextract " (e rodar o jogo; funcionou)

@YellowApple talvez seja um tiro cego - mas você pode tentar instalar o dotnet 4.8 via protontricks também? Consegui usar o mouse na tela inicial / de carregamento.

@YellowApple

Farei @qsniyg (assim que eu conseguir que o Vagrant coopere). Essas funções estão todas implementadas, mas eliminadas ou algo assim?

Eles estão implementados, mas o Windows usa essas api-ms-win-... dlls que basicamente importam de outras dlls (advapi32, kernel32, ucrtbase, etc.). Acho que o wine adiciona as funções a essas dlls conforme a necessidade, a fim de garantir que estejam corretas.

É possível que o jogo trave novamente em alguma outra função não implementada de uma dessas api dlls. Sinta-se à vontade para adicioná-los você mesmo ou me avisar. Esperançosamente, após um pouco de iteração, seremos capazes de encontrar quais funções são necessárias e, em seguida, enviá-las para o wine :)

@Yarwin @tkamat Tenho um palpite de que a instalação do protontricks do dotnet4.8 pode estar causando o problema (embora pareça que ele me permitiu usar o inicializador pretendido, o mouse teve que ser controlado pelo controlador no jogo real). Eu instalei isso também e não consegui fazer a solução da
Acabei excluindo $COMPATDATA/2615501 completamente e passei pelo processo de verificação de arquivos para Proton 5.0 e Bannerlord. Depois disso, o método cabextract funcionou (não se esqueça que você terá que editar $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Configs/engine_config.txt novamente para definir brightness_calibrated = 1 ). Isso pode resolver o seu problema, seja qual for a causa.

+1 para o travamento causado ao salvar. Eu também consegui terminar o tutorial até que um travamento me fez fechá-lo, agora uma nova pasta apareceu em $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Game Saves .

@YellowApple talvez seja um tiro cego - mas você pode tentar instalar o dotnet 4.8 via protontricks também? Consegui usar o mouse na tela inicial / de carregamento.

Não parece ter feito nenhum efeito para mim.

+1 para o travamento causado ao salvar. Eu também consegui terminar o tutorial até que um travamento me fez fechá-lo, agora uma nova pasta apareceu em $COMPATDATA/261550/pfx/drive_c/users/steamuser/My Documents/Mount and Blade II Bannerlord/Game Saves .

Sim, também encontrei aquele travamento pós-tutorial. Meio que me chutando por não apenas esperar e ver se ele teria se desarranjado eventualmente, como esses outros save-hangs parecem fazer.

@ChemiKyle obrigado pela dica, acabei de terminar o tutorial, mas agora estou preso na tela de notificação porque o cursor do mouse desapareceu. Passei alguns minutos mexendo no joystick para ver se ele estava invisível, mas não estava funcionando lol. Acho que o problema do mouse não deve ser muito difícil de corrigir em geral, considerando que a entrada do controlador tem funcionado bem. Meus logs do Steam têm um aviso sobre GetMouseMovePointsEx enviado por spam várias vezes, mas pelo que posso dizer essa função já está implementada no wine.

@YellowApple @tkamat Eu criei um patch de hacky para GetMouseMovePointsEx, não testei, pode estar errado, mas você se importaria de

https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce#file -getmousemovepointsex-patch

Ele é escrito em relação ao wine staging, então você pode precisar aplicá-lo manualmente.

@qsniyg Tentei um novo prefixo com os dois patches; nenhum dado com qualquer um. A entrada do mouse ainda está danificada e ainda trava devido à mesma função não implementada. Logs da execução corrigida.

EDIT: ah, parece que o patch foi para v f wprintf enquanto a falha é devido a v s wprintf. Deixe-me ver se consigo consertar isso ...

@YellowApple Droga, bem, pelo menos valeu a pena +rawinput,+win,+cursor,+dinput,+xinput provavelmente forneceria muitos insights sobre o problema (embora você possa precisar compactar o log .gz ... :)

De qualquer forma, aqui está o patch vswprintf: https://gist.github.com/qsniyg/4ba247c7398e3a1926988e3f6ca252ce#file -vswprintf-patch

Droga, isso funcionou (embora eu tenha corrigido como _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr) , já que estava tentando comparar os documentos da Microsoft o mais próximo possível; acho que um ponteiro é um ponteiro, mas quem sabe com Wine, lol).

Vou tentar obter alguns logs com esses sinalizadores para que possamos ter algum progresso neste problema do mouse.

Bom saber! Enviou-os :)

https://source.winehq.org/patches/data/182375
https://source.winehq.org/patches/data/182376

Também não sei por que o wine fez dessa forma, apenas copiei como eles declararam vswprintf de uma declaração anterior no arquivo :)

Olá, adicionei o aplicativo ao Wine AppDB: https://appdb.winehq.org/objectManager.php?sClass=version&iId=38834&iTestingId=107964

@qsniyg Deseja vincular os bugs ao aplicativo ou devo?

@tomhobson Vá em frente! (Eu não faço parte da equipe de desenvolvimento de vinhos, eu apenas escrevo patches e me envergonho na lista de e-mails devido a sempre errar algo haha)

@tomhobson Vá em frente! (Eu não faço parte da equipe de desenvolvimento de vinhos, eu apenas escrevo patches e me envergonho na lista de e-mails devido a sempre errar algo haha)

Se você escreve patches, parece que você faz parte da equipe de desenvolvimento de vinhos :)

Ok, vinculei o bug: https://bugs.winehq.org/show_bug.cgi?id=36873

Não tenho certeza de como / se você vincular os patches de volta ao bug. Mas quando eles se fundem, podemos cuidar do próximo.

Há algum bug que esqueci?

Portanto, o "estado da arte" com todos os patches aqui ainda requer essencialmente um gamepad de algum tipo para controlar os menus. Isso está certo? Basta verificar se o problema do mouse nunca foi superado, mesmo experimentalmente.

@allquixotic : correto.

Oi pessoal! Não estou jogando no Linux nem no Wine, mas tive um problema semelhante: o gamepad estava ok para o cursor do mouse, mas não o mouse real.

Eu jogo no Shadow (computador distante) e quando ative o "cursor de captura", o problema simplesmente desaparece. Não sei como funciona o Wine exatamente, mas talvez se esta opção também estiver disponível, você pode experimentá-la.

Felicidades

Oi pessoal! Não estou jogando no Linux nem no Wine, mas tive um problema semelhante: o gamepad estava ok para o cursor do mouse, mas não o mouse real.

Eu jogo no Shadow (computador distante) e quando ative o "cursor de captura", o problema simplesmente desaparece. Não sei como funciona o Wine exatamente, mas talvez se esta opção também estiver disponível, você pode experimentá-la.

Felicidades

Obrigado pela informação. Esta configuração de cursor de captura está dentro do bannerlord?

Obrigado pela informação. Esta configuração de cursor de captura está dentro do bannerlord?

Eu acredito que ele se refere à solução de streaming. Pode valer a pena tentar testar se permitir que o Wine assuma o controle exclusivo do mouse pode funcionar.

As únicas configurações relacionadas ao mouse em engine_config.txt parecem ser as seguintes:

invert_mouse = 0
mouse_sensitivity_coefficient = 0.5000
control_mouse_movement_y_scale = 1.5000
control_mouse_movement_max_accumulation = 40.0000
control_mouse_movement_accumulation_decay_speed = 100.0000

Sem surpresa, modificá-los não parece ajudar com o problema.

Obrigado pela informação. Esta configuração de cursor de captura está dentro do bannerlord?

Eu acredito que ele se refere à solução de streaming. Pode valer a pena tentar testar se permitir que o Wine assuma o controle exclusivo do mouse pode funcionar.

sim, eu quis dizer exatamente isso.

@ElCaconym, desculpe se não ajudar :(

Se alguém estiver disponível para testar (ainda estou trabalhando)

Encontrei algo que pode ser útil aqui:
https://askubuntu.com/questions/968252/ubuntu-17-10-mouse-problem-in-wine

Se alguém estiver disponível para testar (ainda estou trabalhando)
Encontrei algo que pode ser útil aqui:
https://askubuntu.com/questions/968252/ubuntu-17-10-mouse-problem-in-wine

Essa foi a ideia que acabei de ter. Habilitar esta opção pode ajudar,
Automatically capture the mouse in full-screen windows
como me lembro de outros jogos tendo pelo menos problemas comparáveis ​​com cursores de mouse no Wine.

@tomhobson : já tentei isso; sem sorte.

As mensagens " aqui :

Começamos a usar GetMouseMovePointsEx para algumas entradas de movimento do mouse. Talvez isso não esteja implementado no WINE? Porém, não é usado para cliques do mouse.

Executar com + rawinput, + win, + cursor, + dinput, + xinput não parece produzir nenhum registro esclarecedor, pelo menos à primeira vista; notavelmente, ao clicar, você obtém o de costume:

0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) up
0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) down

(dependendo se você usa o botão esquerdo ou direito)

@ElCaconym Você poderia compartilhar o log? O log completo pode conter mais informações que podem ajudar a depurar o problema :)

Claro; em anexo. WINEDEBUG: + err, + fixme, + rawinput, + win, + cursor, + dinput, + xinput.

Não estou usando próton, lembre-se: é wine-staging 5.4 com todos os patches de teste, sem patches personalizados (nem mesmo aquele referenciado acima - eu queria corrigir o problema do mouse antes de aplicar o patch vfwprintf / vswprintf) e dxvk 1.6 . Winetricks: vcrun2010, vcrun2015 e dotnet48 (apenas o último pode ser necessário).

Iniciei o jogo e para não poluir os registros evitei mover o mouse até chegar à tela de seleção gama. Em seguida, movi o cursor sobre o botão "Aceitar" e cliquei com o botão esquerdo. Então, eu matei o jogo de outro mandato.

O arquivo:

stderr_bannerlord.log.gz

@ElCaconym Talvez eles estejam verificando se o mouse está na tela.

Esta função está sendo usada no menu. Eu ficaria surpreso se isso não estivesse relacionado ao problema do menu.

Você está executando multi monitor ou único?

Monitor único.

@ElCaconym Huh interessante, também está cortando o cursor a cada quadro, como em AoT2. Será que esse patch ajudaria? https://source.winehq.org/patches/data/181257 Pretendia corrigir um problema com o movimento do cursor do mouse sendo registrado indevidamente, não cliques, então pode ser inútil neste caso, mas quem sabe, não deveria embora não machuque :)

0014:trace:cursor:X11DRV_RawButtonEvent raw button 0 (raw: 1) down
0014:trace:cursor:X11DRV_EnterNotify hwnd 0x10020/7000008 pos 1116,1057 detail 1
004b:trace:cursor:X11DRV_EnterNotify hwnd 0x30052/a600001 pos 1116,1057 detail 1
004b:trace:cursor:X11DRV_ButtonPress hwnd 0x30052/a600001 button 0 pos 1116,1057
004b:trace:cursor:clip_fullscreen_window win 0x30052 clipping fullscreen
004b:trace:win:WIN_CreateWindowEx (null) L"Message" ex=00000000 style=00000000 0,0 0x0 parent=0xfffffffffffffffd menu=(nil) inst=0x140000000 params=(nil)
004b:trace:win:dump_window_styles style:
004b:trace:win:dump_window_styles exstyle:
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(0,0)
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(0,0)
004b:trace:win:WINPOS_GetMinMaxInfo 106 106 / -3 -3 / 1932 1092 / 112 27
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(112,27)
004b:trace:win:invalidate_dce 0x20094 parent 0x10026 (0,0)-(112,27) ((0,0)-(0,0))
004b:trace:win:invalidate_dce 0x70058: hwnd 0x30052 dcx 00000012 Cache 
004b:trace:win:invalidate_dce 0x1005a: hwnd 0x30052 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x12004c: hwnd 0x10020 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x33004a: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:invalidate_dce 0x40041: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:set_window_pos win 0x20094 surface (nil) -> (nil)
004b:trace:win:WIN_CreateWindowEx hwnd 0x20094 cs 0,0 0x0 (0,0)-(112,27)
004b:trace:win:GetWindowRect hwnd 0x20094 (0,0)-(112,27)
004b:trace:win:invalidate_dce 0x20094 parent 0x10026 (0,0)-(112,27) ((0,0)-(112,27))
004b:trace:win:invalidate_dce 0x70058: hwnd 0x30052 dcx 00000012 Cache 
004b:trace:win:invalidate_dce 0x1005a: hwnd 0x30052 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x12004c: hwnd 0x10020 dcx 00000013 Cache 
004b:trace:win:invalidate_dce 0x33004a: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:invalidate_dce 0x40041: hwnd 0x10020 dcx 00000013 Cache InUse
004b:trace:win:set_window_pos win 0x20094 surface (nil) -> (nil)
004b:trace:win:WIN_CreateWindowEx created window 0x20094
004b:trace:cursor:X11DRV_XInput2_Enable XInput2 v2.1 available
004b:trace:cursor:grab_clipping_window clipping to (0,0)-(1920,1080) win 7000001
0014:trace:cursor:clip_cursor_notify clip hwnd changed from (nil) to 0x20094
004b:trace:cursor:X11DRV_EnterNotify hwnd 0x30052/a600001 pos 1116,1057 detail 2
004b:trace:cursor:X11DRV_EnterNotify pos 1116,1057 old serial 24052, ignoring
004b:trace:win:WINPOS_WindowFromPoint scope 0x10020 (1116,1057) returning 0x30052
004b:trace:cursor:SetCursor 0x20070
004b:trace:win:WINPOS_WindowFromPoint scope 0x10020 (1116,1057) returning 0x30052
004b:trace:win:GetWindowRect hwnd 0x30052 (0,0)-(1920,1080)
004b:trace:cursor:ClipCursor Clipping to (null)

Com esse patch, os cliques do mouse ainda estão sendo ignorados. E eu ainda recebo a seguinte sequência regularmente:

004b:trace:cursor:ClipCursor Clipping to (null)
004b:trace:cursor:ungrab_clipping_window no longer clipping

... o que meio que me fez duvidar que o patch foi aplicado corretamente, então eu recompilei o wine totalmente do zero (em vez de usar meu diretório de compilação anterior) e usei outro prefixo (prefixo de instalação de autotools, quero dizer, não um prefixo de vinho) apenas caso também. Os logs em questão persistem - embora isso seja esperado?

Ah ok, faz sentido. Foi um pouco distante haha.

Por precaução, você poderia experimentar com vinho sozinho, em vez de degustar vinho? Wine-staging tem um patch rawinput que evita clicar em jogos como Mass Effect: Andromeda. Alternativamente, você pode apenas recompilar o teste de vinho sem o patch rawinput.

Eu estou apenas tirando as coisas da cartola aqui, porém, isso pode muito bem não funcionar também.

Experimentado com vinho sem patches de preparação: sem alterações. Os registros mudam um pouco, é claro; por exemplo, agora recebo:

004c:trace:cursor:X11DRV_ButtonPress hwnd 0x3003a/a000001 button 2 pos 163,1067

... em cliques do mouse em vez das linhas X11DRV_RawButtonEvent anteriores, mas além disso, os cliques ainda são ignorados. Este novo teste não incluiu o patch acima, lembre-se (vou tentar isso agora para garantir).

Eu estou apenas tirando as coisas da cartola aqui, porém, isso pode muito bem não funcionar também.

Claro - obrigado por tentar! :-)

Pode ser que esse patch realmente tenha um efeito, pois acredito que o problema não reside na detecção de entrada, mas sim um problema com onde o cursor é exibido e onde o jogo acredita que o cursor está localizado.

Se for esse o caso, o jogo deve pensar que o ponteiro está travado em uma posição muito específica (talvez no canto superior esquerdo?) Porque o jogo não parece reagir de forma alguma, não importa para onde você mova o ponteiro. Alguns outros jogos produzem problemas no wine onde o ponteiro é exibido em um lugar diferente de onde o jogo pensa que está, mas ainda há alguma correlação entre onde o jogo pensa que está e onde realmente está; por exemplo, pode ser aumentado algumas dezenas de pixels ou algo parecido.

O ponteiro "real" parece estar onde você o deixou quando usou o gamepad pela última vez. Se você alternar do gamepad para o mouse e de volta para o gamepad, o cursor vai para o último local quando o usou.

Se você mover o cursor para um botão com o gamepad e clicar com o mouse, ele será registrado?

Tentei com vinho de baunilha (sem patches de teste) _and_ patch do qsniyg e sem alterações.

@ Krypton-Nova: Não posso testar isso pessoalmente, sem gamepad. Embora eu imagine que se houvesse uma ferramenta que pudesse ser usada para simular um gamepad virtual e mapeá-lo para o mouse / teclado (o contrário de algo como essa ferramenta ), ela poderia funcionar como um desvio do problema do mouse.

Edit: possivelmente MoltenGamepad ?

Eu tenho um gamepad e funcionou para mim. Apenas curioso para saber se serve para os outros :)

@ Krypton-Nova Sim, posso confirmar que mover o cursor com o gamepad e clicar com o mouse realmente funciona. Parece sugerir que o problema está relacionado ao rastreamento do mouse durante o movimento do mouse, e não aos próprios cliques do mouse.

O mouse sozinho também funciona enquanto controla o personagem. O jogo pode detectar o _movimento_ do mouse, mas a _posição_ do cursor não é atualizada - uma educação básica em física sugere que esse problema não tem solução . O Steam tem uma captura de mouse embutida, acredito, posso tentar quando sair do trabalho, se ninguém fizer isso.

Com base nisso, e sem gamepad conectado, adicionei o registro do segundo parâmetro passado pelo jogo para GetMouseMovePointsEx ( lppt ) e ele atualiza:

0084:fixme:win:GetMouseMovePointsEx GetMouseMovePointsEx lppt: [736][694]

E mais abaixo, na mesma tela:

0084:fixme:win:GetMouseMovePointsEx GetMouseMovePointsEx lppt: [1042][656]

Isso sugere que o jogo _sabe_ onde o cursor está em algum nível; torna ainda mais estranho que mover o cursor com um gamepad funcione, mas com um mouse não funciona.

Talvez a função GetMouseMovePointsEx seja usada para suavização do mouse e precise de mais alguns pontos retornados para interpolação?
O hack de @qsniyg retornou apenas um ponto, alguém deve tentar com dois ou mais pontos.

Não consigo nem colocar o jogo no menu principal, só travo quando acerto a tela de carregamento.

Não consigo nem colocar o jogo no menu principal, só travo quando acerto a tela de carregamento.

Mesmo. Eu tentei todos os diferentes lançamentos de Proton e alguns lançamentos GloriousEggroll.

Acho que estou curioso para saber o que exatamente Bannerlord está fazendo com o resultado. Meu palpite é que - como com o bug OpenTk - o spam de log GetMouseMovePointsEx é uma pista falsa, e qualquer código que esteja lidando com a resposta (seja falha ou pontos retornados reais) está funcionando silenciosamente. É difícil dizer sem ver o código-fonte do Bannerlord, no entanto.

Talvez a função GetMouseMovePointsEx seja usada para suavização do mouse e precise de mais alguns pontos retornados para interpolação?
O hack de @qsniyg retornou apenas um ponto, alguém deve tentar com dois ou mais pontos.

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
    FIXME("    Input: %d %d\n", ptin->x, ptin->y);

    if (count > 0) {
        POINT pos;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;
        FIXME("    Output 0: %d %d\n", pos.x, pos.y);

        if (count > 1) {
            ptout[1].x = pos.x;
            ptout[1].y = pos.y;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
            return 2;
        }

        return 1;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

Não consigo nem colocar o jogo no menu principal, só travo quando acerto a tela de carregamento.

@giantrat , @NovenTheHero : PROTON_LOG=1 às suas opções de lançamento (por exemplo, PROTON_LOG=1 %command% ) e fornecer o ~/steam-261550.log resultante (de preferência como um link para, por exemplo, Pastebin ou Github Essência)?

Aqui está: Essência

@NovenTheHero exclua seu prefixo de vinho e siga estas etapas:

1. Renomeie Bannerlord.exe e Bannerlord_BE.exe para ManagedStarter.exe e ManagedStarter_BE.exe
2. executar protontricks 261550 vcrun2015
3. execute protontricks 261550 vcrun2017
4. Adicionar substituições nativas para ucrtbase e api-ms-win-crt-private-l1-1-0 via winecfg
5. Execute estes comandos:
   cd /home/$USER/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10
6. Inicie o jogo e use um controlador para menus. Isso deve ser o suficiente para colocá-lo em batalhas personalizadas e iniciar a campanha, embora provavelmente você tenha alguns problemas de entrada e congele ao salvar.

@NovenTheHero Se você ainda não estiver contornando o inicializador, tente fazer isso (ou seja, cd "~/.steam/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client" && mv TaleWorlds.MountAndBlade.Launcher.exe TaleWorlds.MountAndBlade.Launcher.exe.old && cp Bannerlord.exe TaleWorlds.MountAndBlade.Launcher.exe ). Alternativamente (se o iniciador funcionar para você e você quiser usá-lo), tente apenas copiar Bannerlord.exe para ManagedStarter.exe .

Esse erro ManagedStarter é porque TaleWorlds mudou o nome do EXE sem necessariamente recompilar (se eu entendi desde quando li isso nos fóruns).

steam-261550.log
aqui está, obrigado por essa opção de lançamento!

@giantrat Parece que você só precisa construir um Wine / Proton personalizado com o patch do qsniyg mais adiante ou então seguir os passos de override nativo (veja o comentário de @tkamat acima).

A atualização mais recente (e1.0.1) parece ter corrigido o problema do iniciador para mim. Infelizmente, mesmo depois de seguir todas as etapas mencionadas, não consigo nem fazer o controlador funcionar (eu tenho um controlador de vapor, não um típico, poderia ser ele?)

Eu também tentei meu Controlador Steam e ele não funcionou. Acho que é porque o Controlador Steam imita um mouse.

bem com o comentário de tkamat, o iniciador agora funciona, mas ainda travo após a introdução do taleworlds.

NVM, comece a calibração de brilho depois de executá-lo novamente! Pog.

@NovenTheHero certifique-se de que o joystick esquerdo do seu controlador esteja configurado para o movimento do joystick, NÃO para o movimento do mouse. Isso deve funcionar.

oh nenhuma entrada de mouse na tela de brilho, parece ruim. tentará os scripts acima.

@tkamat presumindo que você está se referindo ao controlador de vapor, todos os eixos estão configurados como movimento de joystick, nenhum está funcionando atualmente ... Eu também tentei todos os eixos loucos possíveis em um joystick HOTAS sem resultado.

Adicionar um segundo ponto idêntico à saída de GetMouseMovePointsEx não teve efeito. Também é aparente (consistente com as descobertas de @ElCaconym ) que a função está sendo chamada com posições válidas do mouse (ou seja, o jogo sabe claramente onde o mouse está em algum nível); Eu até tentei mover o mouse para cada um dos quatro cantos da minha tela e realmente obtive resultados correspondentes às dimensões da minha tela.

Teoria Selvagem.

OpenTK, que presumo ser uma biblioteca que a TaleWorlds está usando para a GUI, não suporta alto DPI. Este é um problema do SLD2, que também é usado pelo winebus.sys, que é a interface HID dentro do wine. Meu pensamento é que o alto padrão de DPI está sobrecarregando SLD2 / winebus com entrada e não é capaz de alcançá-lo. Portanto, é possível que se pudermos alterar o DPI do mouse na configuração para algo mais baixo, o jogo irá captar o movimento do mouse.

Por outro lado, a execução de hid_test.exe (encontrado em test.winehq.org) em cmd no prefixo wine para Bannerlord mostra que há um Mouse Wine HID detectado e meu receptor sem fio, mas nada mais. Isso pode estar do meu lado devido às regras do udev, mas estou me perguntando se, novamente, devido à minha incapacidade de alterar meu DPI padrão do mouse (Droga, Asus! Faça uma ferramenta de configuração do Linux já!) Então, novamente, SLD2 está sendo sobrecarregado com informações. Ou não está percebendo.

int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res);

    static LPMOUSEMOVEPOINT prev;

    if (count > 0) {
        POINT pos;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;
        FIXME("    Output 0: %d %d\n", pos.x, pos.y);

        if (count > 1) {
            ptout[1].x = pos.x + 1;
            ptout[1].y = pos.y + 1;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            FIXME("    Output 1: %d %d\n", pos.x + 1, pos.y + 1);
            return 2;
        }
        return 1;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

(ou talvez tenha sido o patch que foi lançado algumas horas atrás, não tenho certeza se testei antes de alterar o código)

EDIT: Não era devido ao patch, este código de fato corrigiu

Doce! Reconstruindo com isso agora.

Obtendo algumas falhas estranhas, mas conseguiu terminar uma luta 1v1 contra AI, então parece promissor.

Até agora, tudo bem com esse ajuste. Conseguiu mexer nos menus, criar um personagem, pular o tutorial, voltar ao campo de treinamento e completar todos os objetivos do treinamento com todas as armas. O único problema que notei até agora é que girar o mapa com o botão direito do mouse só funciona em uma direção (ou seja, como um Zoolander inverso, o mapa só vai virar para a esquerda, lol).

Acho que o único aborrecimento restante aqui é a longa espera ao salvar, e não tenho nenhuma pista para descobrir o que está causando isso, infelizmente.

Até agora, tudo bem com esse ajuste. Conseguiu mexer nos menus, criar um personagem, pular o tutorial, voltar ao campo de treinamento e completar todos os objetivos do treinamento com todas as armas. O único problema que notei até agora é que girar o mapa com o botão direito do mouse só funciona em uma direção (ou seja, como Zoolander, o mapa se recusa a virar à esquerda, lol).

Acho que o único aborrecimento restante aqui é a longa espera ao salvar, e não tenho nenhuma pista para descobrir o que está causando isso, infelizmente.

O mouse está funcionando agora ou você ainda está usando um gamepad?

Alguém já encontrou esse problema?

Assertion: should not be reached at /vagrant/mono/mono/utils/mono-threads.c:1066

O jogo continua congelando em mim logo após a criação do personagem, com isso como minha única pista antes de ser forçado a matá-lo.

O mouse está funcionando agora ou você ainda está usando um gamepad?

: mouse: Game pad nem está conectado.

@YellowApple , você poderia tentar armazenar o ponto da chamada anterior da função em uma variável estática e, em seguida, passá-lo como o ponto no índice 1. Acho que eles estão usando os dois pontos para calcular algum tipo de delta do mouse.
Vou dormir agora.

Definitivamente vale a pena tentar. Vou usar esse código e ver se consigo preparar algo nesse sentido. A solução de longo prazo seria, em última análise, ter um buffer estático de até 64 deles e circular continuamente entre eles (ou seja: implementar totalmente a chamada de API em vez da abordagem atual hackeada, lol).

Isso me lembra de um problema, no ano passado (foi corrigido no jogo desde então), o Naval Action tinha problemas no próton em que não detectava o posicionamento do cursor após alterar o contexto de análise do mouse (de mouselook para um menu), e se você tivesse o menu aberto, alt-tab fora e volta novamente, iria detectá-lo e o menu funcionaria. Parece uma coisa simples, mas alguém já experimentou?

Eu não tinha pensado em tentar o alt-tab, mas eu apenas tentei e infelizmente não adiantou nada. : desapontado:

Alguém sabe se aquele erro vagrant mono que está me congelando está relacionado ao Steam ou ao Mount and Blade?

@YellowApple Você se importa em explicar como e onde você corrigiu esse código no wine? Eu sou muito novo na compilação de wine (mas há anos estou interessado em fazer vários jogos funcionarem no Linux) e não entendi direito aonde deveria chegar. Eu tenho uma amiga minha que mudou para o Linux em tempo integral algumas semanas atrás e ela estava realmente ansiosa por este jogo, então seria ótimo se eu pudesse fazê-lo funcionar para ela. Eu não acho que ela vai voltar para o Windows tão cedo, mas também não quero que ela fique desapontada por não poder jogar o único jogo pelo qual ela está ansiosa.

A alteração da versão do próton começou a baixar de 0% e removeu o download de 31 GB duas vezes consecutivas. Quase tive um ataque cardíaco.

Ok, tenho dificuldade em mantê-lo no disco, pois o Steam o remove toda vez que eu o instalo totalmente. Estou triste.

Eu amo a colaboração brilhante que está acontecendo aqui e está me impedindo de reembolsá-la no Steam. Eu não sou muito experiente em tecnologia, mas posso ver que há um progresso acontecendo aqui. Com as coisas simples acima, eu sou capaz de fazer quase todo o caminho através da criação de personagens antes que o jogo bloqueie, fazendo-me reiniciar fisicamente o meu computador, mas todos vocês me dão esperança =).

Para salvar o jogo, talvez tenhamos de envolver os Codeweavers (basicamente os principais mantenedores do Wine). Esperamos que eles percebam o quão popular este jogo é e trabalhem nele. Mesmo que o suporte ao mouse funcione, salvar o travamento ainda é uma razão para este jogo ser classificado como Lixo.

O controlador não estava ajudando, ainda não conseguiu iniciar o jogo, acho que estou esperando um dia.

@giantrat Você tentou renomear? O lançador que o Steam tenta iniciar por padrão não gosta de funcionar para muitos de nós.

@coltondrg O arquivo de origem em questão é dlls/user32/input.c . Você gostaria de encontrar a definição da função para GetMouseMovePointsEx e substituí-la pelo seguinte:

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
    FIXME("    Input: %d %d\n", ptin->x, ptin->y);

    if (count > 0) {
        POINT pos;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;
        FIXME("    Output 0: %d %d\n", pos.x, pos.y);

        if (count > 1) {
            ptout[1].x = pos.x + 1;
            ptout[1].y = pos.y + 1;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
            return 2;
        }

        return 1;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

Se você estiver construindo a mesma versão do Wine que o Proton está usando, você pode salvar o seguinte em um arquivo (digamos, butterlord.patch ), cd na árvore de origem do Wine e executar git apply path/to/butterlord.patch (isso também inclui os patches para corrigir a falha pós-criação de personagem):

diff --git a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec
index 668b8c02fb..58f23257e0 100644
--- a/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec
+++ b/dlls/api-ms-win-crt-private-l1-1-0/api-ms-win-crt-private-l1-1-0.spec
@@ -150,7 +150,8 @@
 @ stub _o___stdio_common_vfprintf_p
 @ stub _o___stdio_common_vfprintf_s
 @ stub _o___stdio_common_vfscanf
-@ stub _o___stdio_common_vfwprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vfwprintf(int64 ptr wstr ptr ptr) ucrtbase._o___stdio_common_vfwprintf
 @ stub _o___stdio_common_vfwprintf_p
 @ stub _o___stdio_common_vfwprintf_s
 @ stub _o___stdio_common_vfwscanf
@@ -160,7 +161,8 @@
 @ stub _o___stdio_common_vsprintf_p
 @ cdecl _o___stdio_common_vsprintf_s(int64 ptr long str ptr ptr) ucrtbase._o___stdio_common_vsprintf_s
 @ stub _o___stdio_common_vsscanf
-@ stub _o___stdio_common_vswprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr) ucrtbase._o___stdio_common_vswprintf
 @ stub _o___stdio_common_vswprintf_p
 @ stub _o___stdio_common_vswprintf_s
 @ stub _o___stdio_common_vswscanf
diff --git a/dlls/ucrtbase/ucrtbase.spec b/dlls/ucrtbase/ucrtbase.spec
index 2251f9f56a..281e2e7c9e 100644
--- a/dlls/ucrtbase/ucrtbase.spec
+++ b/dlls/ucrtbase/ucrtbase.spec
@@ -814,7 +814,8 @@
 @ stub _o___stdio_common_vfprintf_p
 @ stub _o___stdio_common_vfprintf_s
 @ stub _o___stdio_common_vfscanf
-@ stub _o___stdio_common_vfwprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vfwprintf(int64 ptr wstr ptr ptr) MSVCRT__stdio_common_vfwprintf
 @ stub _o___stdio_common_vfwprintf_p
 @ stub _o___stdio_common_vfwprintf_s
 @ stub _o___stdio_common_vfwscanf
@@ -824,7 +825,8 @@
 @ stub _o___stdio_common_vsprintf_p
 @ cdecl _o___stdio_common_vsprintf_s(int64 ptr long str ptr ptr) MSVCRT__stdio_common_vsprintf_s
 @ stub _o___stdio_common_vsscanf
-@ stub _o___stdio_common_vswprintf
+# PATCHED:
+@ cdecl _o___stdio_common_vswprintf(int64 wstr long wstr ptr ptr) MSVCRT__stdio_common_vswprintf
 @ stub _o___stdio_common_vswprintf_p
 @ stub _o___stdio_common_vswprintf_s
 @ stub _o___stdio_common_vswscanf
diff --git a/dlls/user32/input.c b/dlls/user32/input.c
index 46f78cbce8..40ed0f4692 100644
--- a/dlls/user32/input.c
+++ b/dlls/user32/input.c
@@ -1280,7 +1280,30 @@ int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOI
         return -1;
     }

-    FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res);
+    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
+    FIXME("    Input: %d %d\n", ptin->x, ptin->y);
+
+    if (count > 0) {
+        POINT pos;
+        GetCursorPos(&pos);
+
+        ptout[0].x = pos.x;
+        ptout[0].y = pos.y;
+        ptout[0].time = GetTickCount();
+        ptout[0].dwExtraInfo = 0;
+        FIXME("    Output 0: %d %d\n", pos.x, pos.y);
+
+        if (count > 1) {
+            ptout[1].x = pos.x + 1;
+            ptout[1].y = pos.y + 1;
+            ptout[1].time = GetTickCount();
+            ptout[1].dwExtraInfo = 0;
+            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
+            return 2;
+        }
+        
+        return 1;
+    }

     SetLastError(ERROR_POINT_NOT_FOUND);
     return -1;

Isso vai consertar seu Wine de forma que seja exatamente idêntico ao que estou usando.

@giantrat Você tentou renomear? O lançador que o Steam tenta iniciar por padrão não gosta de funcionar para muitos de nós.

sim, e agora estou recebendo a maldita tela de carregamento travar, mesmo depois de aplicar o que ajudou da última vez.

@YellowApple Você é incrível. O arquivo de patch que você colou inclui os patches anteriores para travamento também, certo? (esquece, eu posso ler) Eu já tinha conseguido fazer uma compilação com esses patches, mas o jogo não estava detectando o controlador no meu computador, então eu não fui capaz de ir longe o suficiente para ver se isso era realmente eficaz. Além disso, não tenho certeza se isso faz alguma diferença, mas estou compilando minhas compilações usando o script proton-tkg (do wine-tkg-git), então posso simplesmente arrastar os arquivos de patch personalizados e fazer o script cuspir um Proton agradável para eu arrastar para o compatibletools.d. Eu acho que isso significa que minha construção tem todos os patches tkg também, que eu espero que não sejam conflitantes ou possam quebrar alguma outra coisa.

Só queria atualizar, depois de aplicar o patch do @YellowApple acima, o jogo agora está funcionando totalmente para mim, incluindo entradas de mouse! O primeiro salvamento da campanha congelou o jogo por alguns minutos e acabou travando no final, mas depois de reabrir o jogo o salvamento foi carregado com sucesso. Os salvamentos subsequentes fazem o jogo travar por alguns segundos, mas eles não travam, então ainda consigo jogar sem problemas! Eu tenho um Ryzen 2600, RX 580 e um SSD sata, especificações de médio porte, o que também é encorajador. Muito obrigado a todos neste tópico que contribuíram para a solução e fique à vontade para me perguntar qualquer outra coisa :). Esperançosamente, isso pode ser empurrado para o vinho anterior, então não teremos que construir nós mesmos.

EDIT: Então, depois de jogar cerca de uma hora de campanha, parece que pode haver um vazamento de memória, já que o jogo continua usando mais e mais memória RAM enquanto o desempenho começa a degradar. Isso pode muito bem ser um problema com o jogo em si, considerando que vi alguns usuários do Windows também reclamando de problemas de desempenho. Eu tenho 8 GB de memória RAM, então pode ser interessante ver se isso acontece com pessoas com mais memória.

E aqui está a versão ligeiramente aprimorada de GetMouseMovePointsEx , que corrige o bug de rotação reversa do mapa do Zoolander e - embora ainda esteja repleta de hackeamentos - é provavelmente Good Enough ™ para enviar no upstream:

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {
    static INT last_x = 0;
    static INT last_y = 0;

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    if (count > 0) {
        POINT pos;
        INT out_count = 1;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;

        if (count > 1) {
            ptout[1].x = last_x;
            ptout[1].y = last_y;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            out_count = 2;
        }

        last_x = pos.x;
        last_y = pos.y;

        return out_count;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

@qsniyg : Quer fazer as honras e enviar?

Não tenho o jogo no momento, então não posso testar, mas alguém tem algum resultado do crashlog para o travamento do jogo salvo? Quase parece aquele problema que tivemos com as permissões de arquivo.

@YellowApple , você se importaria de criar um guia de "como fazer o jogo funcionar do zero para idiotas"?

Não tenho o jogo no momento, então não posso testar, mas alguém tem algum resultado do crashlog para o travamento do jogo salvo? Quase parece aquele problema que tivemos com as permissões de arquivo.

Eu duvido que seja um problema de permissões. O jogo está conseguindo salvar, mas está demorando cerca de 5 a 10 minutos para salvar e apenas trava até terminar. Não seria um empecilho para mim jogar, exceto que o salvamento automático dispara toda vez que você inicia uma batalha e na maioria das outras grandes mudanças de cena

@YellowApple , você se importaria de criar um guia de "como fazer o jogo funcionar do zero para idiotas"?

A abordagem mais amigável "para idiotas":

• Baixe a compilação exata do Proton que estou usando: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz
• Cole-o em ~/.steam/root/compatibilitytools.d
• Extraia ( cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz )
• Reinicie o Steam
• Clique com o botão direito do mouse em Bannerlord em sua biblioteca, clique em Propriedades e altere a versão do Proton para "proton_5.0-local"
• ???
• Lucro

Obviamente, você faz isso por sua própria conta e risco, com o entendimento de que baixar, instalar e executar binários aleatórios da Internet é um assunto arriscado repleto de perigos. Caveat emptor. Você é fortemente encorajado a tentar clonar o repositório Proton, aplicando os patches você mesmo e construindo o Proton em sua própria máquina (e embora sim, essa não é exatamente a abordagem mais amigável, é muito mais seguro do que confiar na Internet estranhos para não beber do seu crânio, lol).

Esperançosamente, podemos fazer o upstream desses patches mais cedo ou mais tarde, para evitar a necessidade dessas compilações personalizadas únicas e precárias, lol

Esperançosamente, podemos fazer o upstream desses patches mais cedo ou mais tarde, para evitar a necessidade dessas compilações personalizadas únicas e precárias, lol

No mínimo, contanto que esses patches não quebrem outras coisas, talvez eles possam ser colocados nas compilações de Proton populares de terceiros, como tkg ou GE por enquanto? : 3 @GloriousEggroll?

@YellowApple , você se importaria de criar um guia de "como fazer o jogo funcionar do zero para idiotas"?

A abordagem mais amigável "para idiotas":

* Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz

* Stick it in `~/.steam/root/compatibilitytools.d`

* Extract it (`cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz`)

* Restart Steam

* Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"

* ???

* Profit

Obviamente, você faz isso por sua própria conta e risco, com o entendimento de que baixar, instalar e executar binários aleatórios da Internet é um assunto arriscado repleto de perigos. Caveat emptor. Você é fortemente encorajado a tentar clonar o repositório Proton, aplicando os patches você mesmo e construindo o Proton em sua própria máquina (e embora sim, essa não é exatamente a abordagem mais amigável, é muito mais seguro do que confiar na Internet estranhos para não beber do seu crânio, lol).

Esperançosamente, podemos fazer o upstream desses patches mais cedo ou mais tarde, para evitar a necessidade dessas compilações personalizadas únicas e precárias, lol

O problema é que quando eu mudo a versão de prótons, Bannerlord inteiro é removido e começa a baixar novamente. 😤

Isso não deveria acontecer, ele deveria excluir a pasta compatdata se você fizer o downgrade do Proton, mas nunca deve excluir o jogo inteiro. De qualquer forma, você deve ser capaz de ignorar o novo download fazendo backup dos arquivos do jogo e restaurando-os após alterar a versão do Proton. Você pode fazer isso literalmente fazendo uma cópia da pasta de instalação do jogo ou em Steam> Fazer Backup e Restaurar Jogos

O atraso ao salvar o jogo é brutal. Posso confirmar que ele aumenta a utilização da CPU para 100% em todas as 12 CPUs lógicas do meu sistema por vários segundos (até cerca de 1 minuto para mim). O disco R / W durante esse tempo está baixo / inexistente, então parece estar girando em outra coisa. Não vejo nada impresso no console ao executar o Steam a partir dele enquanto isso está acontecendo .. há alguma outra maneira de habilitar mais log de próton / vinho que pode ajudar a diagnosticar o problema aqui?

Atualmente construindo uma versão corrigida do GE Proton. Informarei se funciona com o patch postado aqui :)

@YellowApple

Quais patches você aplicou exatamente?
Aplicar o patch git do seu post é o suficiente? (ainda estou baixando Bannerlord, então não consegui testá-lo ainda)

Além disso, ainda precisamos ignorar o iniciador com este patch?

YellowApple

Quais patches você aplicou exatamente?
Aplicar o patch git do seu post é o suficiente? (ainda estou baixando Bannerlord, então não consegui testá-lo ainda)

Além disso, ainda precisamos ignorar o iniciador com este patch?

@elovin

Parece que o problema do gerenciador de partida foi corrigido agora com o patch mais recente. Então não.

Em qualquer um dos casos, ignorar o inicializador era desnecessário. Se você renomeou Bannerlord.exe para ManagedStarter.exe, o inicializador funcionaria bem.

@YellowApple @tomhobson
Posso aplicar o patch ao wine stable, mas não ao wine master porque agora existe um patch conflitante (parece ser o seu patch, mas com uma ordem de argumentos diferente?) ,
seu patch já foi mesclado?

EDITAR:
ok o patch de entrada ainda é necessário.

@YellowApple , você se importaria de criar um guia de "como fazer o jogo funcionar do zero para idiotas"?

A abordagem mais amigável "para idiotas":

* Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz

* Stick it in `~/.steam/root/compatibilitytools.d`

* Extract it (`cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz`)

* Restart Steam

* Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"

* ???

* Profit

Obviamente, você faz isso por sua própria conta e risco, com o entendimento de que baixar, instalar e executar binários aleatórios da Internet é um assunto arriscado repleto de perigos. Caveat emptor. Você é fortemente encorajado a tentar clonar o repositório Proton, aplicando os patches você mesmo e construindo o Proton em sua própria máquina (e embora sim, essa não é exatamente a abordagem mais amigável, é muito mais seguro do que confiar na Internet estranhos para não beber do seu crânio, lol).

Esperançosamente, podemos fazer o upstream desses patches mais cedo ou mais tarde, para evitar a necessidade dessas compilações personalizadas únicas e precárias, lol

Funciona com meu manjaro.

Olá a todos,

Esperei tanto por este jogo. Este jogo pode ser jogado agora?

@YellowApple , você se importaria de criar um guia de "como fazer o jogo funcionar do zero para idiotas"?

A abordagem mais amigável "para idiotas":

* Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz

* Stick it in `~/.steam/root/compatibilitytools.d`

* Extract it (`cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz`)

* Restart Steam

* Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"

* ???

* Profit

Obviamente, você faz isso por sua própria conta e risco, com o entendimento de que baixar, instalar e executar binários aleatórios da Internet é um assunto arriscado repleto de perigos. Caveat emptor. Você é fortemente encorajado a tentar clonar o repositório Proton, aplicando os patches você mesmo e construindo o Proton em sua própria máquina (e embora sim, essa não é exatamente a abordagem mais amigável, é muito mais seguro do que confiar na Internet estranhos para não beber do seu crânio, lol).

Esperançosamente, podemos fazer o upstream desses patches mais cedo ou mais tarde, para evitar a necessidade dessas compilações personalizadas únicas e precárias, lol

Funciona no Mint 19.2. O único problema que parece persistir no momento é o tempo brutal (geralmente um minuto para mim) que leva sempre que o jogo é salvo.

Olá a todos,

Esperei tanto por este jogo. Este jogo pode ser jogado agora?

@Przygi É jogável - mas o tempo de espera (devido à economia) no minuto é diabólico. Isso precisará ser melhorado antes que o jogo seja agradável.

@ Rogue-Factor há alguma opção de início especial para registro extra? Estou trabalhando para obter um registro aqui agora.

Rogue-Factor, há alguma opção de início especial para registro extra? Estou trabalhando para obter um registro aqui agora.

@sdegrace

No Steam, se você for ao jogo, clique com o botão direito e vá para propriedades.

Em seguida, clique em definir opções de inicialização.

Insira PROTON_LOG=1 %command%

Comece o jogo normalmente.

Um log aparecerá em seu diretório inicial chamado steam-{appid}.log .

Nota a todos, você ainda precisa renomear os arquivos exe além de aplicar o patch ao proton!

• Ignorando o lançador

  Algumas notas:

  the game uses Battleye Anti-Cheat - it's seemingly mandatory even if you just want to play single player. No idea if there is a launch parameter that disables it.
  

  Você pode renomear dois arquivos .exe em / Mount & Blade II Bannerlord / bin / Win64_Shipping_Client /

  rename "TaleWorlds.MountAndBlade.Launcher.exe" to "TaleWorlds.MountAndBlade.Launcher.exe_backup" (or something similar - it's just not allowed to keep its original name)
  
  rename "Bannerlord.exe" to "TaleWorlds.MountAndBlade.Launcher.exe"
  

  para pelo menos fazer o jogo começar, ver as telas iniciais e então eu chego ao ponto que tenho que interagir com o jogo pela primeira vez (alterar as configurações de brilho), ponto em que minha CPU e GPU ficam totalmente descontroladas e eu não consigo interagir com o jogo.

• E então patching Proton

  A abordagem mais amigável "para idiotas":

  Download the exact Proton build I'm using: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz
  Stick it in ~/.steam/root/compatibilitytools.d
  Extract it (cd ~/.steam/root/compatibilitytools.d && tar xvf proton_5.0-local.tar.gz)
  Restart Steam
  Right-click Bannerlord in your library, click Properties, and change the Proton version to "proton_5.0-local"
  ???
  Profit
  

  Obviamente, você faz isso por sua própria conta e risco, com o entendimento de que baixar, instalar e executar binários aleatórios da Internet é um assunto arriscado repleto de perigos. Caveat emptor. Você é fortemente encorajado a tentar clonar o repositório Proton, aplicando os patches você mesmo e construindo o Proton em sua própria máquina (e embora sim, essa não é exatamente a abordagem mais amigável, é muito mais seguro do que confiar na Internet estranhos para não beber do seu crânio, lol).

Obrigado a todos neste tópico :)

@SylvainSoKette

O Launcher funciona bem para mim!

@tomhobson você fez algo específico para fazê-lo funcionar ou apenas rodar com o Proton corrigido deve funcionar?

Obrigado por todo o trabalho neste tópico! A inicialização foi dupla desde que o jogo foi lançado, mas estou feliz que tenha havido progresso aqui!

Meus testes:

• Executando Manjaro 19.0.2
• Arquivos exe renomeados devido ao problema do inicializador que ainda está ocorrendo para mim.
• Seguiu o guia @YellowApple e carregou o jogo com o Proton editado.
• Falha ao ajustar o áudio, mas as configurações foram salvas.
• Bater ao sair do tutorial após a criação de personagem com sucesso.
• Conseguiu pular o tutorial na segunda tentativa e chegar ao mapa da campanha.
• Algumas pequenas quedas de desempenho em comparação com o Windows, mas funciona bem no geral.
• Recurso de salvar testado e como discutido jogo trava durante isso. CPU atinge cerca de 90% no meu 9700k. Salvar levou cerca de 35 segundos.

@tomhobson você fez algo específico para fazê-lo funcionar ou apenas rodar com o Proton corrigido deve funcionar?

@kelytha Eu usei o próton corrigido. mas renomeei Bannerlord_BE.exe e Bannerlord.exe como ManagedStarter_BE.exe e ManagedStarter.exe respectivamente.

Não seria melhor usar links chamados ManagedStarter.exe e ManagedStarter_BE.exe, caso eles atualizem os executáveis?

@ O novo arquivo de log Rogue-Factor tem mais de 10 GB: / Vou tentar novamente em alguns instantes.

@sdegrace deve compactar muito bem. Tente gz'ing

Olá a todos,
Esperei tanto por este jogo. Este jogo pode ser jogado agora?

@Przygi É jogável - mas o tempo de espera (devido à economia) no minuto é diabólico. Isso precisará ser melhorado antes que o jogo seja agradável.

Obrigado pela resposta !!! Ótimo trabalho pessoal !!!

Infelizmente para mim, impossível de jogar, trava toda vez que eu mudo as configurações gráficas e às vezes trava quando precisa desenhar / carregar uma cena 3D complexa (tela de menu ou tela de criação de personagem).
"Falha no aplicativo: o aplicativo enfrentou um problema. Precisamos coletar os arquivos necessários para corrigir o problema. Deseja fazer upload desses arquivos agora?"

A única vez que cheguei à tela de criação de personagem, o desempenho foi horrível.
Mas eu acho que é provavelmente um problema de driver da minha parte, já que estou no Ubuntu 18.04 sem ppa exótico ou sem nenhum driver instalado manualmente.

Ubuntu 18.04, core i7 6700, 16go ddr4, gtx 1060 3go (nvidia-driver-435)

Algo a se observar: recebi 2 monitores, um conectado na placa de vídeo e o outro na saída da placa-mãe (gerenciado pelos gráficos intel hd). O monitor principal é conectado à placa de vídeo nvidia e o jogo é renderizado no monitor principal.

Atualização: consegui mudar as configurações gráficas, alterando-as uma a uma sem travar. Mas ainda travando muito na tela de criação de personagem: /

Ok, eu construo proton-tkg que usa o wine master mais recente que só precisa da parte de entrada (input.c) do patch fornecido por @YellowApple .
Em seguida, adicionei links simbólicos para fazer o iniciador funcionar conforme sugerido por

O jogo funciona até agora usando RADV com ACO e o salvamento leva cerca de 15 segundos.
Alterar as configurações, no entanto, trava o jogo (pelo menos as alterações nas configurações estão sendo salvas)

CPU 3700X
GPU Vega 56
RAM 32gb
SSD samsung 860 evo 1 TB

Distro:
Arch Linux

Núcleo:
5.5.13-zen2-1-zen

Driver GPU:
mesa-20.0.2

Atualização 2:

Ok, depois de rodar o jogo por 1 hora, o desempenho é realmente muito bom (em comparação com o Windows), eu obtenho cerca de 70 fps quando na arena e tempos de quadros muito bons, no mapa mundial são cerca de 50-60pfs com tempos de quadros de até 50ms, na cidade, são cerca de 50-60 pfs com tempos de quadros de até 10 ms e durante uma batalha real eu recebo cerca de 60-80 pfs (dependendo do mapa) com bons tempos de quadros, mas picos ocasionais de até> 100 ms (provavelmente compilação de shader).

Eu jogo em WQHD com configurações em "muito alto" por sinal.

Hmm ... Então tentei construir o remendado enquanto dormia, não funcionou. Acabei de tentar baixar sua versão, @YellowApple , e também não funciona! : sob: (Por não funciona, quero dizer, meu mouse ainda não me deixa mover E clicar nos menus, não tentei um controlador ainda)

Eu sou o único para quem não funcionou?

Pode confirmar o mesmo para GE Proton trabalhando com o patch. O único problema que tenho é que a cada segundo lançamento ou então o mouse não funcionará novamente. Tem que reiniciar o jogo mais uma vez para que volte a funcionar corretamente.

@YellowApple Ótimo trabalho !! :) Pessoalmente, acho que o patch seria mais adequado para a preparação do vinho do que para o vinho (em seguida, enviá-lo para os garfos, como próton-ge etc.), já que o vinho é bastante rígido em garantir que a função funcione o mais próximo possível para janelas.

Para enviar para o wine-staging, veja aqui: https://wiki.winehq.org/Wine-Staging_Development. Basicamente, anexe o patch a https://bugs.winehq.org/show_bug.cgi?id=36873 , explique por que você acha que deveria ir para wine-staging sobre o vinho, então CC Alistair e Zebediah (mantenedores do wine-staging) para eles examinam e adicionam ao vinho.

Enquanto isso, vou tentar ver se consigo implementar um que espelhe a implementação da função do Windows :)

@ Rogue-Factor
https://www.dropbox.com/s/e25za0261pdco0t/steam-261550.log.gz?dl=0

Neste log eu abri Bannerlord, abri um save existente, salvei o jogo, salvei e saí do jogo. Aparentemente, há um limite máximo para o número de núcleos necessários ao salvar - para mim, é 14/16. Demora um pouco menos de um minuto para mim. Nenhum outro problema foi experimentado ainda.

O patch do YellowApple funciona para mim! Agora vou tentar fazer um personagem e o tutorial.

Já que pareço ser o único para quem não está funcionando, vou fazer uma atualização completa do sistema e, em seguida, tentar construir novamente ... talvez experimentar o próton GE. Eu tenho uma ideia de um teclado muito básico para um controlador virtual, então vou tentar fazer isso se a reconstrução não fizer meu mouse funcionar.

@elovin Você pode listar todos os patches necessários? Quero tentar construir prótons com base na recomendação da YellowApple. Não que eu não confie neles, mas quero ser capaz de fazer isso e ajudar a contribuir. Havia muitos patches no tópico, então se você não se importar em listar os que usou, tentarei fazer isso.

@elovin Você pode listar todos os patches necessários? Quero tentar construir prótons com base na recomendação da YellowApple. Não que eu não confie neles, mas quero ser capaz de fazer isso e ajudar a contribuir. Havia muitos patches no tópico, então se você não se importar em listar os que usou, tentarei fazer isso.

/***********************************************************************
 * GetMouseMovePointsEx [USER32]
 *
 * RETURNS
 *     Success: count of point set in the buffer
 *     Failure: -1
 */
int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOINT ptout, int count, DWORD res) {
    static INT last_x = 0;
    static INT last_y = 0;

    if((size != sizeof(MOUSEMOVEPOINT)) || (count < 0) || (count > 64)) {
        SetLastError(ERROR_INVALID_PARAMETER);
        return -1;
    }

    if(!ptin || (!ptout && count)) {
        SetLastError(ERROR_NOACCESS);
        return -1;
    }

    if (count > 0) {
        POINT pos;
        INT out_count = 1;
        GetCursorPos(&pos);

        ptout[0].x = pos.x;
        ptout[0].y = pos.y;
        ptout[0].time = GetTickCount();
        ptout[0].dwExtraInfo = 0;

        if (count > 1) {
            ptout[1].x = last_x;
            ptout[1].y = last_y;
            ptout[1].time = GetTickCount();
            ptout[1].dwExtraInfo = 0;
            out_count = 2;
        }

        last_x = pos.x;
        last_y = pos.y;

        return out_count;
    }

    SetLastError(ERROR_POINT_NOT_FOUND);
    return -1;
}

O patch da @YellowApple funciona para mim também, muito obrigado cara.

Os tempos de carregamento ainda são horríveis, mas o jogo parece funcionar, pelo menos um pouco. O que pode parecer um travamento, às vezes é apenas uma tela de carregamento que leva uma eternidade lol.

Funciona muito bem no manjaro, salvar leva cerca de 5 a 10 segundos, mas a computação do shader parece travar o jogo (cerca de 1/5 das chances) quando carrego um mapa pela primeira vez. algumas configurações travam, mas são aplicadas após travar, então é isso. OBRIGADO PELO SEU TRABALHO!

@elovin Você pode listar todos os patches necessários? Quero tentar construir prótons com base na recomendação da YellowApple. Não que eu não confie neles, mas quero ser capaz de fazer isso e ajudar a contribuir. Havia muitos patches no tópico, então se você não se importar em listar os que usou, tentarei fazer isso.

Eu usei o script de compilação do proton-tkg (clone o repo PKGBUILD tkg ) e adicionei o patch ao wine-tkg-git / wine-tkg-userpatches / bannerlord.mypatch (tkg irá procurar pela extensão de arquivo "mypatch" então sim, você tem que nomeá-lo como YOUR_PATCH_NAME.mypatch)

bannerlord.mypatch contém apenas o patch para input.c de @YellowApple e esse é o único patch

diff --git a/dlls/user32/input.c b/dlls/user32/input.c
index 46f78cbce8..40ed0f4692 100644
--- a/dlls/user32/input.c
+++ b/dlls/user32/input.c
@@ -1280,7 +1280,30 @@ int WINAPI GetMouseMovePointsEx(UINT size, LPMOUSEMOVEPOINT ptin, LPMOUSEMOVEPOI
         return -1;
     }

-    FIXME("(%d %p %p %d %d) stub\n", size, ptin, ptout, count, res);
+    FIXME("(%d %p %p %d %d) hack\n", size, ptin, ptout, count, res);
+    FIXME("    Input: %d %d\n", ptin->x, ptin->y);
+
+    if (count > 0) {
+        POINT pos;
+        GetCursorPos(&pos);
+
+        ptout[0].x = pos.x;
+        ptout[0].y = pos.y;
+        ptout[0].time = GetTickCount();
+        ptout[0].dwExtraInfo = 0;
+        FIXME("    Output 0: %d %d\n", pos.x, pos.y);
+
+        if (count > 1) {
+            ptout[1].x = pos.x + 1;
+            ptout[1].y = pos.y + 1;
+            ptout[1].time = GetTickCount();
+            ptout[1].dwExtraInfo = 0;
+            FIXME("    Output 1: %d %d\n", pos.x, pos.y);
+            return 2;
+        }
+        
+        return 1;
+    }

     SetLastError(ERROR_POINT_NOT_FOUND);
     return -1;

OK, para futuros intrépidos, observe que o método @elovin tem o seguinte requisito (de acordo com a página TKG)

"PKGBUILDs só funcionarão em distros com acesso a pacman e makepkg" então isso pode não ser adequado para distro baseada em debian a menos que você esteja disposto a ir além para personalizá-lo.

Vou tentar sem ele.

Eu comprei o jogo e instalei e usei o método na descrição (baixando o próton especial, sim, eu sei, não seguro, mas testando), configurei para usar o novo local e ainda não vou chegar ao inicializador .
Vejo que outras pessoas têm o iniciador funcionando sem renomear nada para ignorá-lo ... mas talvez eles tenham outras correções aplicadas anteriormente, esta é uma nova. o que estou perdendo (e podemos adicionar isso à solução alternativa até agora no topo)

@aradapilot Ainda é necessário renomear, pelo que eu saiba, pelo menos para a maioria das pessoas, mas não é mais a primeira renomeação a ignorar o iniciador.
Esta renomeação ainda usa o iniciador:
Renomeie Bannerlord.exe e Bannerlord_BE.exe para ManagedStarter.exe e ManagedStarter_BE.exe.

Nota para todos os interessados: finalmente consegui "funcionar" com o exe renomeado e o próton atualizado. Acontece que o nvidia-driver-440 era obrigatório, já que o nvidia-driver-435 travava quase 95% do tempo na tela de criação de personagem. As performances ainda são horríveis, mas eu não tentei no Windows ainda, então não sei se é relacionado ao Linux ou apenas o meu computador que é um lixo total :)

Para enviar para o wine-staging, veja aqui: https://wiki.winehq.org/Wine-Staging_Development. Basicamente, anexe o patch a https://bugs.winehq.org/show_bug.cgi?id=36873 , explique por que você acha que deveria ir para wine-staging sobre o vinho, então CC Alistair e Zebediah (mantenedores do wine-staging) para eles examinam e adicionam ao vinho.

Feito. Obrigado!

Enquanto isso, vou tentar ver se consigo implementar um que espelhe a implementação da função do Windows :)

Doce. Eu pesquisei um pouco sobre isso antes, mas estou tendo problemas para entender exatamente como o Wine obtém a entrada do mouse (e onde isso poderia ser armazenado de uma forma que seja útil para GetMouseMovePointsEx). Também não tenho certeza se o X11 (ou Wayland ou Quartz ou a miríade de outros sistemas de exibição usados ​​com o Wine) têm funcionalidade equivalente.

O desempenho é bastante bom para mim com Mesa 20.0, RADV + ACO em placa de vídeo AMD RX 580 (algumas falhas, por exemplo, ao passar para uma nova cena, mas desaparece rápido). O único problema que encontrei com isso até agora depois de corrigir para fazer a entrada do mouse funcionar é o atraso do jogo salvo.

@craftyguy Quanta RAM você tem? O jogo funciona bem para mim por cerca de 30 minutos, mas depois disso o desempenho começa a diminuir rapidamente e o uso de RAM começa a aumentar. Tenho apenas 8 GB, então estou tentando descobrir se esse é o problema.

@tkamat Percebi que o "estado estacionário" para o uso de RAM do jogo parece ser de aproximadamente 19-20 GB na minha máquina (que tem 32 GB). Isso independe das configurações gráficas (tentei tanto o mais alto quanto o mais baixo absoluto).

OK, para futuros intrépidos, observe que o método @elovin tem o seguinte requisito (de acordo com a página TKG)

"PKGBUILDs só funcionarão em distros com acesso a pacman e makepkg" então isso pode não ser adequado para distro baseada em debian a menos que você esteja disposto a ir além para personalizá-lo.

Vou tentar sem ele.

Você pode executar makepkg dentro de um contêiner do arch linux docker (talvez eu faça um script simples para isso) e então descompacte a versão proton do tar ball resultante (os pacotes do arch são apenas tar balls).
Eu mesmo desempacoto a versão do próton e não a instalo em todo o sistema.

@tkamat Eu concordo com o comentário de

Portanto, parece que seus problemas de desempenho estão relacionados à RAM disponível. Isso parece fora do assunto, pois é provavelmente um problema com o jogo em si e não é específico para prótons / vinho.

Portanto, parece que protontricks 261550 dotnet48 melhora significativamente o salvamento do travamento (o jogo trava por alguns segundos em vez de vários minutos). Agradecimentos ao usuário do reddit / u / TheCaconym pelo relatório!

Além disso, em algum momento o Steam atualizou o jogo e explodiu meus renomeações, mas o inicializador funcionou fora da caixa, no entanto. Nem mesmo precisou fazer uma Bannerlord.exe → ManagedStarter.exe renomear.

Estamos há menos de uma semana na Harvesting Season ™ e o Bannerlord já está próximo da paridade entre o Linux e o Windows. Huzzah!

Uma vez que esses patches estejam colocados, a manteiga deve fluir livremente.

@YellowApple

Estou tendo problemas para entender exatamente como o Wine obtém a entrada do mouse

Ele o envia para o servidor, geralmente por meio de send_hardware_message em dlls / user32 / message.c, e a posição do cursor será enviada para update_desktop_cursor_pos . Provavelmente é aqui que devemos adicionar a implementação, talvez em uma nova função (provavelmente usando um buffer de anel estático para armazenar as 64 entradas?).

A parte chata seria declarar uma nova solicitação do servidor para recuperar as posições do cursor. Eu não fiz isso antes, mas acho que é uma questão de criá-lo em queue.c + request.h, declarando em protocol.def e, em seguida, executar tools/make_requests ?

Em seguida, surge a questão de a tarefa de filtrar as posições do cursor ser delegada ao servidor ou no espaço do usuário? Eu pessoalmente escolheria o último, mas como são algumas entradas (provavelmente cerca de 1 KB ou mais de dados para enviar), e o código de filtragem não seria muito complexo, pode valer a pena fazer isso no servidor.

Posso confirmar que o dotnet48 acelera o salvamento.
Eu fui um dos sortudos onde o salvamento demorou apenas cerca de 10 segundos, mas agora demora cerca de 2 segundos.

@ albin-engstrom é instalado em um SSD ou HDD para você? Percebi alguns tempos de carregamento muito longos entre as cenas às vezes. Atualmente instalando dotnet48.

O desempenho diminui muito quanto mais tempo eu jogo. Espero que seja apenas um bug no jogo.

A degradação do desempenho à medida que você joga é um problema no Windows também (vazamentos de memória - confirmados pelo devs IIRC).

@nilleairbar Em um SSD NVMe, então é bastante rápido. Mas não parece que pelo menos o tempo de economia seja devido a leituras ou gravações, é a CPU que funciona. Ele passou de cerca de 30% de carga durante o jogo para 60% durante a economia.
Portanto, pode ser mais uma CPU poderosa (3900X) que levou aos curtos tempos de salvamento até certo ponto.

@albin-engstrom pode ser isso. Com dotnet48 e um i7 8700K, salvar também leva menos de dois segundos aqui.

Estou em um 1700X e agora depois de instalar o dotnet48, o salvamento leva cerca de 20 a 30 segundos em vez de 2 a 3 minutos, mas agora o desempenho diminui por um tempo após salvar.

Estou obtendo resultados semelhantes em um i5 antigo, cerca de 30 segundos para salvar agora

Então, de repente, estou tendo um travamento ( wine: Unhandled page fault on execute access to 00000000007501C8 at address 00000000007501C8 (thread 0042), starting debugger... ) assim que chego à tela Prisioneiros após uma batalha. Ainda não tenho certeza se é o resultado do uso de dotnet48 . Também não tenho certeza se está afetando todas as batalhas ou apenas algumas com este grupo específico de Saqueadores (ou com Saqueadores em geral). Depois de restringir as coisas, vou colocar alguns logs.

@YellowApple Eu lutei várias batalhas contra saqueadores e isso não me causou um crash. (dotnet 48 ainda não está instalado)

A abordagem mais amigável "para idiotas":

• Baixe a compilação exata do Proton que estou usando: https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz
  ....

Eu fiz exatamente essas etapas, o jogo inicia, porém quando me pede para deslizar os controles deslizantes de brilho na primeira inicialização, não registra nenhuma entrada (além do movimento do mouse) ....

O jogo funciona bem até eu tentar alternar a configuração "mostrar direção de ataque" no menu.
O jogo trava imediatamente após fechar o menu, a mensagem "você encontrou um erro, carregue seus logs" aparece. Quando a janela fecha, o Steam ainda pensa que o jogo está rodando, então não posso iniciar novamente pelo Steam.

Estou usando https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz para próton

Informação do sistema:
KERNEL: 5.5.13-arch2-1
SO: Arch Linux
CPU: AMD Ryzen 7 3700X 8 núcleos
GPU: AMD NAVI10
DRIVER GPU: 4.6 Mesa 20.0.2
RAM: 32 GB

O jogo funciona bem até eu tentar alternar a configuração "mostrar direção de ataque" no menu.
O jogo trava imediatamente após fechar o menu, a mensagem "você encontrou um erro, carregue seus logs" aparece. Quando a janela fecha, o Steam ainda pensa que o jogo está rodando, então não posso iniciar novamente pelo Steam.

Estou usando https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz para próton

Informação do sistema:
KERNEL: 5.5.13-arch2-1
SO: Arch Linux
CPU: AMD Ryzen 7 3700X 8 núcleos
GPU: AMD NAVI10
DRIVER GPU: 4.6 Mesa 20.0.2
RAM: 32 GB

Tive várias falhas no início ao alterar as configurações de vídeo, apenas interrompa o processo e inicie o jogo novamente.

Relatório: O jogo está funcionando bem e economizando em cerca de 1 minuto na minha máquina. Usando a solução alternativa e renomeia para "Gerenciado". Na tela de brilho, selecionei boas configurações para mim e saí do jogo no menu principal. Então eu passei pelo tutorial, mudei algumas configurações adicionais, e a maioria das configurações gráficas estão em alta + ainda. O desempenho é razoável (provavelmente em torno de 30-40 FPS). Não tive nenhum acidente até agora, mas acabei de sair do tutorial e encontrei refugiados. Obrigado a todos, dev, testers, Valve e Taleworlds por nos trazerem aqui.

Informação do sistema:
SO: Debian 10 (buster)
RAM: 16 GB
CPU: Ryzen 2700X
GPU: AMD 580X
Driver: Debian 10 (Mesa 18.3.6)

O jogo funciona bem até eu tentar alternar a configuração "mostrar direção de ataque" no menu.
O jogo trava imediatamente após fechar o menu, a mensagem "você encontrou um erro, carregue seus logs" aparece. Quando a janela fecha, o Steam ainda pensa que o jogo está rodando, então não posso iniciar novamente pelo Steam.
Estou usando https://yellowapple-misc.s3-us-west-2.amazonaws.com/proton_5.0-local.tar.gz para próton
Informação do sistema:
KERNEL: 5.5.13-arch2-1
SO: Arch Linux
CPU: AMD Ryzen 7 3700X 8 núcleos
GPU: AMD NAVI10
DRIVER GPU: 4.6 Mesa 20.0.2
RAM: 32 GB

Tive várias falhas no início ao alterar as configurações de vídeo, apenas interrompa o processo e inicie o jogo novamente.

Eu desliguei o processo de vapor e comecei o bannerlord novamente, surpreendentemente a configuração que eu mudei permaneceu alterada.

@elovin Acabou de tentar contra um grupo de Mountain Bandits e steam-261550.log (exclui +seh porque com dotnet48 isso estava enviando spam para todo tipo de coisa).

Vou tentar um novo prefixo com o mesmo salvamento e sem dotnet48 e ver se o problema persiste. Do contrário, acho que teremos que solucionar o problema do .NET ou voltaremos à prancheta com aqueles longos tempos de salvamento.

@ onodera-punpun Se você puder adicionar PROTON_LOG=1 às suas opções de lançamento e fornecer o ~/steam-261550.log resultante, isso seria útil.

@YellowApple https://camille.sh/rAM1.log

@YellowApple após instalar o dotnet48 com winetricks, recebo uma mensagem ao carregar meu último jogo "Carregar jogo salvo com módulos diferentes" ou algo parecido, então talvez um novo jogo funcione.

O tempo de economia não melhorou para mim, ainda são cerca de 15 segundos e nenhuma falha até agora lutando contra saqueadores

@elovin essa é a mensagem padrão após carregar um salvamento 1.0.0 após uma atualização para 1.0.1; talvez essa seja a origem (apenas relevante se você tiver carregado um save 1.0.0 após dotnet48, e você já atualizou para 1.0.1)?

@YellowApple pelo que vale a pena, com meu prefixo dotnet48 não estou tendo nenhum travamento ao chegar à tela de prisioneiros depois de uma batalha (fiz várias batalhas com muitos prisioneiros). A maioria das minhas batalhas até agora foi com saqueadores, nenhum bandido da montanha ainda.

@ onodera-punpun Estranho, nada se sobressai. Você não tem nenhum controlador conectado ou qualquer outra coisa que possa interferir, certo?

@elovin Acho que tem a ver com as versões atualizadas do jogo (1.0.2 acabou de cair).

@ElCaconym É bom saber. O mesmo salvamento sob um novo prefixo não dotnet48 falha nas mesmas condições, então pelo menos posso descartar isso. Provavelmente apenas um salvamento corrompido (o que parece ser um problema comum até mesmo no Windows, se os fóruns forem úteis). (EDITAR: e de fato, em um novo jogo com dotnet48 posso fazer prisioneiros sem bater, pelo menos por agora)

@YellowApple Achei que poderia ser meu gerenciador de janelas, então tentei rodar o jogo em uma instância do X sem qualquer WM, mas isso não corrigiu o problema. Só tenho um teclado e mouse USB normais, nada mais.

EDITAR: Eu defino brightness_calibrated na configuração do motor como 1 para pular direto para o menu, e também aí clicar não faz nada.

EDIT2: Eu desliguei enable steam play for all other titles , isso parecia consertar. De alguma forma, isso substituiu o uso do meu próton personalizado definido à força ....

Alguém mais experimentou o problema de login malsucedido em qualquer tentativa de execução no modo multijogador? Depois de longos períodos de espera, ele continua jogando mensagens de "falha de login".

@YellowApple @ElCaconym Sim, você está certo por causa da atualização.

Alguém mais experimentou o problema de login malsucedido em qualquer tentativa de execução no modo multijogador? Depois de longos períodos de espera, ele continua jogando mensagens de "falha de login".

Eu não ouvi nenhum relato de alguém sendo capaz de executar o modo multijogador desde que adicionaram Batlleye no início do beta.

Quais são as chances de termos o modo multiplayer rodando no Bannerlord? Eu costumava jogar Warband online o tempo todo no Ubuntu naquela época.

entao eu vi a nota sobre dotnet48 e instalei, ao mesmo tempo percebi que o Steam atualizou o jogo para 1.0.2, e agora ele esta gaguejando em qualquer coisa acima dos gráficos min (tem um 1070) e travando constantemente apenas se movendo em mundo aberto. annnnd porque duas variáveis ​​aqui não posso dizer se foi o patch ou a coisa dotnet que causou isso. alguma pista sobre o que procurar? ou como redefinir meu env proton sem dotnet para testar?

@aradapilot : Estou funcionando bem no dotnet48 + 1.0.2 (jogo por 30 minutos ou mais sem problemas). Possivelmente um problema de salvar corrupção? talvez tente um novo jogo temporariamente para confirmar? 1070 aqui também.

@aradapilot sim, acabei de fazer alguns testes e parece que enquanto o dotnet48 reduz drasticamente a economia de tempo, ele também introduz uma grande quantidade de gagueira após salvar, e isso dura até você reiniciar o jogo. Considerando que, sem o dotnet48, o jogo funciona muito bem para mim antes e depois de salvar. IDK se este problema afetará apenas pessoas com sistemas menos poderosos / apenas 8 GB de RAM, mas sim, é super estranho.

Ok, depois que um pc reiniciar o jogo trava no final de qualquer luta e os tempos de carregamento estão melhores agora, o wine-server não fecha se você sair do jogo?

@tkamat tem 32G aqui, sem falta de memória, ou em qualquer lugar em termos de hardware. Eu preciso descobrir como remover protontricks do jogo agora, minhas defesas não eram tão lentas antes, mas nenhuma página de manual e -h não diz nada sobre remoção

@aradapilot eu tenho o mesmo problema
@ElCaconym Existem outras modificações feitas além de renomear, o patch hackish e adicionar dotnet480?
@tkamat Sim, a primeira vez que entrar no jogo antes de salvá-lo pela primeira vez, ele será executado conforme o esperado. Eu tenho um sistema poderoso de 32 GB e ele ainda começa a engasgar com configurações muito baixas, então não acho que seu sistema esteja causando isso

@tkamat Também percebi isso. Parece estar confinado principalmente à visualização do mapa; brigas, andar em cidades / vilas, etc. parecem ser melhores.

@elovin Interessante. Este foi um salvamento existente ou uma nova campanha?

@aradapilot Infelizmente, não há uma maneira fácil de reverter algo instalado por meio de protontricks . A melhor aposta é fazer backup de seus salvamentos, excluir ou renomear ~/.steam/steam/steamapps/compatdata/261550 , executar o jogo uma vez para regenerar tudo e copiar seus salvamentos de volta.

@elovin wineerver _should_ stop eventualmente; ocasionalmente não (especialmente quando ocorre uma falha / um aplicativo trava ao sair). Fazer "killall wineerver" ou alternativamente "wineerver -k" (com o WINEPREFIX correto definido no último caso) pode ser usado para ter certeza disso.

@ simi2525 nada que venha à mente; prefixo vinho limpo, usando apenas dotnet48. Estou usando vinho diretamente em vez de próton, mas isso não deve causar impacto.

Alguém mais experimentou o problema de login malsucedido em qualquer tentativa de execução no modo multijogador? Depois de longos períodos de espera, ele continua jogando mensagens de "falha de login".

Eu não ouvi nenhum relato de alguém sendo capaz de executar o modo multijogador desde que adicionaram Batlleye no início do beta.

Quais são as chances de termos o modo multiplayer rodando no Bannerlord? Eu costumava jogar Warband online o tempo todo no Ubuntu naquela época.

O jogo funcionou por alguns patches depois que o battleye foi adicionado porque eles ainda permitem que você entre em jogos sem ele habilitado. Nas últimas duas semanas, o beta fechado parou de funcionar no Linux, provavelmente coincidindo com o fato de tornarem o Battleye obrigatório. Acho que o melhor que podemos esperar de uma versão nativa do Linux é taleworlds substituindo a verificação do olho de batalha para instalações do wine ou mudando para VAC. A compatibilidade de prótons do Battleye provavelmente não está nas cartas, uma vez que faz alguma bruxaria no espaço do kernel.

@YellowApple era um save existente, comecei um novo jogo agora e ele não trava mais.

Alguma ideia de onde estão os arquivos salvos, haha?

@NovenTheHero .steam / steam / steamapps / compatdata / 261550 / pfx / drive_c / users / steamuser / My \ Documents / Mount \ and \ Blade \ II \ Bannerlord / Game \ Saves / Native /

Eu escrevi alguns scripts rápidos para automatizar os vários ajustes discutidos aqui e no ProtonDB , certificando-se de dar crédito (via URL) para cada ajuste.

• config-bannerlord-for-linux.bash
• config-steam-for-bannerlord.bash (@YellowApple)

@YellowApple WineHQ pensa que essa é a causa do problema de entrada; se foi isso que você consertou, você pode postar lá?
EDIT: Esqueça, parece que você já o fez. :)

A correção do cursor do mouse agora está em wine-staging .

Antes que as pessoas removam seus prefixos de prótons, certifique-se de que nenhum jogo esteja configurado para usar esse prefixo, pois, se bem me lembro, isso causará problemas.

Obrigado a todos por seu trabalho nisso. É ótimo ver como a comunidade Linux é capaz de solucionar problemas rapidamente e enviar patches para o upstream! Compilei uma versão modificada do próton com base em um tutorial postado anteriormente e funciona muito bem.

Para mim, salvar também demorou um pouco sem o dotnet48, enquanto a instalação dessa biblioteca corrigiu isso para mim também. Eu encontrei alguns problemas de desempenho já discutidos por outros. Ontem à noite, percebi que meu arquivo xorg-session.log estava crescendo excessivamente, até 25 GB. Não consegui testar se esse problema está relacionado ao Bannerlord. Testará mais à noite.

Eu escrevi alguns scripts rápidos para automatizar os vários ajustes discutidos aqui e no ProtonDB , certificando-se de dar crédito (via URL) para cada ajuste.

* [config-bannerlord-for-linux.bash](https://github.com/MilesBHuff/Misc-code/blob/master/code/setup/wine/config-bannerlord-for-linux.bash)

* [config-steam-for-bannerlord.bash](https://github.com/MilesBHuff/Misc-code/blob/master/code/setup/wine/config-steam-for-bannerlord.bash) (@YellowApple)

O brilho da tela não seria corrigido com o ajuste do cursor do mouse? Foi para mim, pelo menos.

Talvez alguém possa testar isso, mas agora, visitar qualquer ferreiro resulta em um savegame corrompido, de modo que obtenho uma média de 15 fps, mas apenas no mapa da campanha, todo o resto funciona bem.

Editar: Isso persiste após reiniciar o jogo ou computador.

Visitei uma ferraria e nada de notável aconteceu.
(Usando a construção de prótons da maçã amarela e tem 32 GB de RAM)

EDIT2: Eu desliguei enable steam play for all other titles , parecia ter resolvido De alguma forma, isso substituiu o uso do meu próton personalizado definido à força ....

Puta merda ... Esse foi o meu problema o tempo todo! Agora os patches estão funcionando para mim! Eu até deixo meus arquivos serem validados durante a noite para livrar-me dos meus renomeados, e até mesmo o inicializador funciona.

Eu tentei Proton da YellowApple, instalando dotnet48, mas ainda está travando meu WM após a criação do personagem.

/editar
Aqui está o erro de travamento do WM que encontrei relacionado a ele. As vezes que não trava meu WM, todo o sistema congela. i5-3570k, AMD RX 580 e 32 GB de RAM

kernel: [34245.701791] [ drm: amdgpu_job_timedout [amdgpu]] ERROR ring gfx timeout, but soft recuperado

Posso confirmar que adicionar dotnet48 corrigiu meu problema de economia de tempo. Passou de 60s no início para 90s + depois de algumas horas de jogo com o uso máximo da CPU para <20 segundos e a CPU não está mais no máximo enquanto salva.

Agora que existe um microestimulante persistente no mapa da campanha que não existia antes, as batalhas parecem não ter problemas. Irritante, mas definitivamente jogável neste estado. 32 GB de RAM / 1070ti, provavelmente não são especificações, mas vou tentar brincar com algumas opções mais tarde.

@evopls é basicamente o mesmo problema que estou enfrentando. Fps e microestível ruins no mapa da campanha, com todas as outras cenas basicamente sem problemas. Estou em um 1070 com 16 GB de RAM.

Edit: Ok, fiz uma nova versão do Proton via wine-tkg com o patch incluído no wine-staging, funciona fora da caixa agora. Sem dotnet48 instalado, tudo é amanteigado, exceto para salvar (as questões já discutidas). Vou instalar o dotnet48 agora para ver se este é o culpado pela experiência de gagueira no mapa da campanha.

@nilleairbar Percebi que a gagueira desaparece quando eu reinicio o jogo, mas a primeira vez que salvar (manualmente ou por meio de salvamento automático) o ativa novamente. As opções de desempenho não fizeram diferença.

@ekaats

O brilho da tela não seria corrigido com o ajuste do cursor do mouse? Foi para mim, pelo menos.

Sim é. As três linhas de configuração que modifico com config-bannerlord-for-linux.bash eram de antes da correção de entrada estar disponível. Vou comentar as partes obsoletas do script.

Obrigado pelo script @MilesBHuff , muito útil e me leva ao menu principal.
Tentei reunir informações, ainda é impossível jogar o Campaign, certo? Algumas pessoas conseguiram fazer isso, é sobre os patches mais recentes?

@ Haywire-dev é completamente possível jogar Campaign. O maior problema é o "bug" do savegame que faz com que o salvamento demore vários minutos. Instalar o dotnet48 por meio de protontricks ou aliviamos isso, mas possivelmente leva a alguns problemas de desempenho no mapa da campanha (veja minhas postagens ou evopls).

Edit: Ah, e esqueci de mencionar, é claro que você precisa de uma versão do Proton que inclua o patch wine mencionado nesta edição ou seja baseada na versão mais recente do wine-staging que vem com o patch aplicado.

@nilleairbar

Edit: Ah, e esqueci de mencionar, é claro que você precisa de uma versão do Proton que inclua o patch wine mencionado nesta edição ou seja baseada na versão mais recente do wine-staging que vem com o patch aplicado.

Tenho certeza de que vou ser criticado por isso, mas como exatamente posso ter certeza de que tenho o próton certo? Cheguei até a criação de personagens antes do jogo / WM / computador travar. Estou supondo que o 5.0-local do OP / YellowApple NÃO tem isso incluído (ainda)?

Também estou tendo travamentos ocasionais ao navegar pelos menus / criação de personagens. No final das contas, parece funcionar, de uma forma bem instável, e o mouse não está funcionando obviamente, pelo menos nos menus. Não testei no jogo ainda.

Tenho certeza de que vou ser criticado por isso, mas como exatamente posso ter certeza de que tenho o próton certo? Cheguei até a criação de personagens antes do jogo / WM / computador travar.

No momento, a versão mais fácil seria usar a versão do Proton @YellowApple compartilhado. A opção mais segura seria construí-lo você mesmo usando algo como https://github.com/Frogging-Family/wine-tkg-git

No momento, a versão mais fácil seria usar a versão do Proton @YellowApple compartilhado. A opção mais segura seria construí-lo você mesmo usando algo como https://github.com/Frogging-Family/wine-tkg-git

Sim, atualmente estou usando o Proton do YellowApple e renomeei os dois .exe, mas ainda não consigo passar da criação do personagem. Estou investigando o assunto do vinho tkg agora, talvez isso ajude.

Caso contrário, estou apenas de olho aqui para qualquer outra coisa para tentar.

@evopls , caso você esteja interessado, fiz alguns testes agora e a gagueira é aparentemente causada por dotnet48. Vou jogar sem ele por enquanto e terei tempos de economia bastante longos, em vez daquela gagueira no mapa da campanha.

Dotnet48 destrói completamente para mim ... Não consigo nem iniciar o jogo mais. Eu desinstalei, mas ainda estou enfrentando os mesmos problemas de tela da campanha que os outros.

Só por curiosidade @ Foobar1923, que driver gráfico você está usando?

Eu comprei uma placa nvidia, então isso pode ser diferente para você, mas eu tive que atualizar o driver da minha placa de vídeo, embora o que eu estava usando fosse bem recente. Na maioria das vezes, passei de total travamento para jogável, mas com problemas de taxa de quadros em algumas telas (todas as telas em que você tem um close-up de um personagem, talvez seja relacionado ao espalhamento de subsuperfície?).

@SylvainSoKette

Estou usando amdgpu de estoque. Eu atualizei meu wine / winetricks / wine-staging etc e mesa (deve) estar atualizado, bem como vulkan.

Alguma suposição de quanto tempo vai demorar até que esses patches sejam puxados para o Proton, agora que um pouco dele está começando a chegar ao vinho corrente?

@CrafterSvK Tenho certeza de que esse é o padrão no Proton 5.0, não?

@CrafterSvK Tenho certeza de que esse é o padrão no Proton 5.0, não?

Sim, esqueci. De qualquer forma, toda vez que clico em continuar no final da batalha, o jogo trava.

Além disso, não vejo nenhuma menção ao modo de segurança neste tópico. Meu jogo trava sempre que abro o menu "festa", mas ao reiniciar ele me pergunta se desejo iniciar no modo de segurança e, se disser que sim, ele não trava mais.

Todo mundo aqui usa o modo de segurança?

Ainda não experimentei o modo de segurança; O que isso realmente faz? Minha suposição seria que (como a maioria dos jogos) ele apenas diminuiria as configurações gráficas, mas agora você me fez imaginar se também está fazendo algum tratamento de exceção extra ou verificação de segurança de tempo de execução.

EDIT: foi em frente e tentei. Parece que ele apenas redefine engine_config.txt para os padrões. Nem mesmo desabilita mods.

Além disso, não vejo nenhuma menção ao modo de segurança neste tópico. Meu jogo trava sempre que abro o menu "festa", mas ao reiniciar ele me pergunta se desejo iniciar no modo de segurança e, se disser que sim, ele não trava mais.

Todo mundo aqui usa o modo de segurança?

Eu daria pelo menos uma tentativa, mas não tenho essa opção. Apenas o travamento do WM / PC.

Tenho testado algumas coisas e até agora cheguei às mesmas conclusões que o resto. dotnet48 parece resolver o problema de salvar, mas torna o resto do jogo muito menos estável.

Com dotnet48 tive travamentos ao salvar, carregar, entrar em batalhas e cidades. Alguns deles foram travamentos no desktop, outros travaram o processo.

Sem o dotnet48, consegui jogar sem muitos problemas adicionais, apenas quando a economia de uso da CPU chega a 100% por 1:40 minutos (em um Ryzen 1700). Depois tudo voltou ao normal e posso continuar bem.

Observe que o jogo salva em alguns momentos específicos. Percebi que ele salva ao entrar em uma batalha (antes de mostrar a tela onde você escolhe lutar sozinho ou deixar que os dados decidam), às vezes também depois de deixar uma cidade ou ao entregar uma missão.

Agora estou testando o Redistributable for Visual Studio 2017 instalado. Até agora, não parece ter nenhuma importância.

Minhas configurações gráficas são as mais altas e o modo de segurança não as altera.
Não vejo diferença além da falta de travamento.
(não estou usando o dotnet48 porque o jogo nem mesmo iniciava)

Bem, ele trava da mesma forma com o modo de segurança na minha máquina.

@Xxdzs Eu também os tenho, pois estou usando o dotnet48, mas apenas se abrir imediatamente o menu após o carregamento. Se eu jogar um pouco primeiro, parece muito estável.

No geral, a ligeira oscilação no mapa da campanha parece muito melhor para mim do que os tempos de salvamento cada vez mais longos sem dotnet48, mas essa é provavelmente a preferência pessoal. Não tenho certeza de qual desses dois problemas seria mais fácil de corrigir.

Fiz alguns testes sem dotnet48 e contornando o launcher.

Definitivamente, alguns menus ainda travam, o salvamento ocasionalmente ainda trava após levar mais de 45 segundos. O mapa de campanha funciona muito bem, com pouco ou nenhum atraso, embora haja definitivamente algo estranho acontecendo quando o jogo carrega certos recursos e menus. Um amigo também experimentou em sua CPU Intel e ambos observamos pequenos picos no uso da CPU tentando acessar certos menus junto com os atrasos habituais.

Desativar o Subspace Scattering parece ajudar certas áreas com dotnet48, embora ter essa correção definitivamente pareça mais estável quando comparado a sem dotnet48.

EDIT: Bem-vindo, deixa pra lá, ao mesmo tempo que ajuda um pouco com a estabilidade, o jogo ainda é uma bagunça instável para mim na maior parte. Após cerca de 4-5 diálogos no jogo, o jogo trava e falha.

41819.290:0035:00c4:trace:seh:dump_unwind_info     handler 0x64478533758 data at 0x64478648688
41837.875:0035:00c6:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41837.875:0035:00cb:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41837.876:0035:00c9:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.732:0035:00c7:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.733:0035:00c1:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.829:0035:00bd:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.830:0035:00ca:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.925:0035:00c2:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41838.925:0035:00be:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.022:0035:00cc:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.023:0035:00bf:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.023:0035:00c3:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.119:0035:00cd:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.122:0035:00c5:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.122:0035:00ce:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.312:0035:00ba:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.312:0035:00c4:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.313:0035:00bc:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41839.313:0035:00c8:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
41849.393:0024:0028:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\WineUsd.sys" : builtin
41849.396:001c:0020:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
41849.396:001c:0020:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
41849.397:001c:0020:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
41849.521:007b:007c:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
41849.541:0074:0075:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
pid 155001 != 155000, skipping destruction (fork without exec?)

2ª EDIT:

Depois de mudar algumas coisas e corrigir o tkg, estou trabalhando muito bem em estabilidade, embora meu desempenho no mapa da campanha seja na adolescência, com gagueira severa 80% do tempo, não importa quais configurações gráficas inferiores sejam escolhidas.

Parece que as coisas se acalmaram aqui, o que deve significar que a maioria de nós está gostando do jogo. Estou executando em um equipamento bastante robusto sem dotnet48 e, exceto tempos de salvamento de ~ 30 segundos, não experimentei nenhuma falha.

Deve ser bom, pelo que tenho visto, porém, há um monte de pessoas que estão ficando com gagueira severa no mapa da campanha, menus de diálogo / salvamento estão causando CTDs e salvamentos corrompidos e alguns selecionados não podem entrar na ferraria.

Para mim, falar com os bandidos resulta em um CTD 10% do tempo, fico com gagueira severa no mapa de campanha, mas as batalhas correm mais suavemente do que a máquina Windows do meu amigo, com exceção de soluços de vez em quando.

As coisas devem ser resolvidas com o passar do tempo, porém, com acesso antecipado. Afinal, estamos vendo vários desses problemas no Windows também. Portanto, estou surpreso que Bannerlord funcione tão bem no WINE quanto agora.

O jogo funciona bem, mas fico preso em telas de carregamento infinitas e recebo este erro

Parece que as coisas se acalmaram aqui, o que deve significar que a maioria de nós está gostando do jogo. Estou executando em um equipamento bastante robusto sem dotnet48 e, exceto tempos de salvamento de ~ 30 segundos, não experimentei nenhuma falha.

Deve ser bom, pelo que tenho visto, porém, há um monte de pessoas que estão ficando com gagueira severa no mapa da campanha, menus de diálogo / salvamento estão causando CTDs e salvamentos corrompidos e alguns selecionados não podem entrar na ferraria.

Para mim, falar com os bandidos resulta em um CTD 10% do tempo, fico com gagueira severa no mapa de campanha, mas as batalhas correm mais suavemente do que a máquina Windows do meu amigo, com exceção de soluços de vez em quando.

As coisas devem ser resolvidas com o passar do tempo, porém, com acesso antecipado. Afinal, estamos vendo vários desses problemas no Windows também. Portanto, estou surpreso que Bannerlord funcione tão bem no WINE quanto agora.

Você já tentou testar com um ambiente de prótons completamente limpo? Você pode, executando protontricks 261550 annihilate . Isso não removerá seus salvos. Minhas desculpas, se este conselho for semelhante a 'você tentou desligar e ligar novamente', no entanto, ajudou para mim.

Não tive travamentos ao jogar sem o dotnet48, exceto ao tentar alterar as configurações, o que levou a um travamento imediato.

@ mjm2000 O jogo possui vários bugs. Já enfrentei telas de carregamento infinitas no Windows 10 também

@montyubuntu o jogo foi corrigido para a versão mais recente? Problemas com o ManagedStarter estavam aparecendo apenas para mim e outros (eu acredito) na versão e1.0.0.0

@montyubuntu o jogo foi corrigido para a versão mais recente? Problemas com o ManagedStarter estavam aparecendo apenas para mim e outros (eu acredito) na versão e1.0.0.0

Acabei de verificar e a correção do mouse agora está incluída no wine-staging. O iniciador ainda não funciona para mim, então eu precisei substituir o executável do iniciador pelo executável do jogo real.

Recomendo pedir ajuda nos fóruns - vamos continuar investigando os problemas apenas com o jogo, não com o suporte também. Muitas pessoas o têm funcionando agora, então é provável que algo esteja diferente com sua configuração.

Curiosamente, há este problema conhecido relatado (no Windows, quero dizer) nos fóruns oficiais da taleworlds:

Stuttering camera movement on the Campaign Map is under investigation.

O que pode sugerir que o problema que algumas pessoas têm com o dotnet48 não está - ou não é inteiramente - relacionado ao vinho. Existem também inúmeros relatos de que o jogo engasgou mais conforme uma campanha está em andamento, especialmente se você salva e recarrega com frequência; até 1.0.2, recarregar e salvar 45 vezes também garantiria que qualquer nova recarga do salvamento em questão travaria o jogo. Embora o 1.0.3 supostamente tenha corrigido o problema de inchaço / corrupção do savegame, também há muitos relatando que não (uma determinada campanha dura um pouco mais com o 1.0.3, mas é só isso, aparentemente).

Ok, então pode ser que eu tenha encontrado a solução para a gagueira da campanha. Claro, precisaria de um tamanho de amostra maior do que apenas eu. Veja como corrigi-lo em um novo prefixo:

• Construir minha própria versão do Proton (tkg) a partir do código-fonte com a mais nova construção de teste de vinho que inclui a correção do cursor do mouse
• Dotnet40 instalado via protontricks
• Vcrun2015 instalado (consulte https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Dotnet 48 instalado
• Vcrun2017 instalado (consulte novamente https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Agora não tenho gagueira no mapa da campanha, um cursor do mouse fixo e salvando leva alguns segundos. Pode valer a pena tentar para qualquer outra pessoa.

Ok, então pode ser que eu tenha encontrado a solução para a gagueira da campanha. Claro, precisaria de um tamanho de amostra maior do que apenas eu. Veja como corrigi-lo em um novo prefixo:

• Construir minha própria versão do Proton (tkg) a partir do código-fonte com a mais nova construção de teste de vinho que inclui a correção do cursor do mouse
• Dotnet40 instalado via protontricks
• Vcrun2015 instalado (consulte https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Dotnet 48 instalado
• Vcrun2017 instalado (consulte novamente https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Agora não tenho gagueira no mapa da campanha, um cursor do mouse fixo e salvando leva alguns segundos. Pode valer a pena tentar para qualquer outra pessoa.

Eu tentei isso, com 1.0.3, e o desempenho foi pior em algumas áreas, melhor em outras.

depois de atualizar para 1.0.4, todo o jogo funciona perfeitamente, é incrível.

@nilleairbar Acabei de tentar isso e toda a gagueira se foi para mim, com menos de 3 segundos de salvamento! Você é um gênio, obrigado por descobrir isso. Estranhamente, eu tinha todos esses pacotes instalados no meu último prefixo, mas não usei proton-tkg e os instalei em uma ordem diferente, então talvez uma dessas coisas faça a diferença. De qualquer forma, esse tem sido um dos problemas mais estranhos que vejo há algum tempo, e espero que essas correções possam ser enviadas para vinho / próton no futuro.

Ok, então pode ser que eu tenha encontrado a solução para a gagueira da campanha. Claro, precisaria de um tamanho de amostra maior do que apenas eu. Veja como corrigi-lo em um novo prefixo:

• Construir minha própria versão do Proton (tkg) a partir do código-fonte com a mais nova construção de teste de vinho que inclui a correção do cursor do mouse
• Dotnet40 instalado via protontricks
• Vcrun2015 instalado (consulte https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Dotnet 48 instalado
• Vcrun2017 instalado (consulte novamente https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Agora não tenho gagueira no mapa da campanha, um cursor do mouse fixo e salvando leva alguns segundos. Pode valer a pena tentar para qualquer outra pessoa.

Eu tentei isso, com 1.0.3, e o desempenho foi pior em algumas áreas, melhor em outras.

depois de atualizar para 1.0.4, todo o jogo funciona perfeitamente, é incrível.

Como você instala 2017 após 2015? Recebo erros no instalador de 2017 dizendo que outra versão já está instalada. Eu nem tenho certeza de como desinstalar o 2015 agora.

Parece que o Steam (pelo menos via Proton) pré-instala os tempos de execução do VC de 2015 e 2017. Também recebo esses erros agora (embora já faça algum tempo desde que tentei).

Por outro lado, parece que para mim a atualização para 1.0.4 piorou substancialmente as coisas em termos de taxa de quadros do mapa (EDITAR: esqueci de esclarecer que é apenas quando o tempo está passando; quando pausado, ele roda em torno de 30fps). Parece ser algo quebrado com multithreading; A GPU está com 1% de utilização de acordo com o DXVK HUD, e apenas um núcleo parece estar pegando de cada vez. Além disso, aparentemente htop reporta o jogo usando 1,2 TB de RAM agora, o que é horrível e fascinante:

Pode ser um mod, no entanto (já que estou testando esses). Também pode ser algo ganho com meu jogo salvo novamente. Os registros não mostram nenhuma arma fumegante específica ali.

EDITAR: Acontece que a gagueira era do mod ClanTweaker. Algumas outras pessoas reclamaram das quedas na taxa de quadros também, embora não tanto quanto eu experimentei.

O tamanho da memória virtual de 1,2 TB é um pouco preocupante e pode indicar um vazamento de memória, mas quase nada disso é realmente _mapeado_ para páginas físicas (ou seja, RAM real) - você está usando apenas 17 dos 32 GB de RAM. Portanto, de certa forma, isso é inofensivo, a menos que o processo continue solicitando mais memória virtual, ele pode ficar sem endereços de 64 bits e travar.

Parece que o Steam (pelo menos via Proton) pré-instala os tempos de execução do VC de 2015 e 2017. Também recebo esses erros agora (embora já faça algum tempo desde que tentei).

Por outro lado, parece que para mim a atualização para 1.0.4 piorou substancialmente as coisas em termos de taxa de quadros do mapa. Parece ser algo quebrado com multithreading; A GPU está com 1% de utilização de acordo com o DXVK HUD, e apenas um núcleo parece estar pegando de cada vez. Além disso, aparentemente htop reporta o jogo usando 1,2 TB de RAM agora, o que é horrível e fascinante:

Pode ser um mod, no entanto (já que estou testando esses). Também pode ser algo ganho com meu jogo salvo novamente. Os registros não mostram nenhuma arma fumegante específica ali.

Acabei de notar este comentário no reddit:

"Sim, aconteceu comigo também, ele mudou para minha inteligência em vez de Nvidia (e mesmo isso me dá cerca de 128 MB de energia apenas, como wtf?) E eu não posso mudar de volta.
Lamento saber que isso acontece com você também, amigo, mas por outro lado, me sinto muito melhor do que minha Nvidia não queimou o xD. "

Parece que o jogo está tentando usar os gráficos integrados no processador deste usuário. Interessante

Esta máquina não tem nenhuma GPU integrada, então isso não parece ser um provável culpado no meu caso.

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

Minha falta de conhecimento sobre linux está aparecendo, mas esta solução é apenas para usuários de arch, certo? A única coisa que achei para "Proton version (tkg)" é isso e se refere a PKGBUILDS que são uma coisa do arco, certo? Existe uma maneira de fazer a mesma coisa no kde neon (ubuntu 18.04 base)?

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

Minha falta de conhecimento sobre linux está aparecendo, mas esta solução é apenas para usuários de arch, certo? A única coisa que achei para "Proton version (tkg)" é isso e se refere a PKGBUILDS que são uma coisa do arco, certo? Existe uma maneira de fazer a mesma coisa no kde neon (ubuntu 18.04 base)?

Sim, é uma coisa arqueada. Reparei no readme que ele disse que era possível sem o arco, apenas talvez um pouco mais complexo.

Além disso, algumas horas atrás, havia um bug com proton-tkg que o tornava incapaz de construir de qualquer maneira.

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

Minha falta de conhecimento sobre linux está aparecendo, mas esta solução é apenas para usuários de arch, certo? A única coisa que achei para "Proton version (tkg)" é isso e se refere a PKGBUILDS que são uma coisa do arco, certo? Existe uma maneira de fazer a mesma coisa no kde neon (ubuntu 18.04 base)?

Sim, é uma coisa arqueada. Reparei no readme que ele disse que era possível sem o arco, apenas talvez um pouco mais complexo.

Além disso, algumas horas atrás, havia um bug com proton-tkg que o tornava incapaz de construir de qualquer maneira.

É uma coisa do arco, mas o executável apenas cria um tarball que você pode extrair de onde quiser (por exemplo, no diretório sugerido no comentário principal, em "solução alternativa atual"). Se você tiver o arco, ele pode fazer isso automaticamente por você, mas não é um grande passo. O problema foi resolvido em uma hora e agora está funcionando bem.

Oi,
graças ao trabalho do @YellowApple , consegui compilar um proton-tkg funcional no ubuntu, segui os passos do @nilleairbar e posso jogar o jogo.

nvidia gtx 1070 consegue-me cerca de 30 fps a 3840x2160 em terra e em pequenas escaramuças, conversas em tabernas ou aldeias, etc.

lutas maiores cerca de 20vs20, conversas no mapa terrestre, lojas, forja, às vezes gagueira de estoque em cerca de 2 ~ 3 fps

travamentos ainda acontecem para mim, mas raramente

editar: definir as configurações para médio resolve o problema de 2 ~ 3 fps, salvando leva cerca de 3 segundos no máximo

* Build my own Proton version (tkg) from source with the newest wine-staging build that includes the mouse cursor fix

Minha falta de conhecimento sobre linux está aparecendo, mas esta solução é apenas para usuários de arch, certo? A única coisa que achei para "Proton version (tkg)" é isso e se refere a PKGBUILDS que são uma coisa do arco, certo? Existe uma maneira de fazer a mesma coisa no kde neon (ubuntu 18.04 base)?

Sim, é uma coisa arqueada. Reparei no readme que ele disse que era possível sem o arco, apenas talvez um pouco mais complexo.
Além disso, algumas horas atrás, havia um bug com proton-tkg que o tornava incapaz de construir de qualquer maneira.

É uma coisa do arco, mas o executável apenas cria um tarball que você pode extrair de onde quiser (por exemplo, no diretório sugerido no comentário principal, em "solução alternativa atual"). Se você tiver o arco, ele pode fazer isso automaticamente por você, mas não é um grande passo. O problema foi resolvido em uma hora e agora está funcionando bem.

Há alguma mudança nova no vinho estável que parece beneficiar o Bannerlord? Já tenho um build personalizado apenas com as alterações do YellowApple, apenas me perguntando se valeria a pena fazer um novo a partir do teste.

Ok, então pode ser que eu tenha encontrado a solução para a gagueira da campanha. Claro, precisaria de um tamanho de amostra maior do que apenas eu. Veja como corrigi-lo em um novo prefixo:

• Construir minha própria versão do Proton (tkg) a partir do código-fonte com a mais nova construção de teste de vinho que inclui a correção do cursor do mouse
• Dotnet40 instalado via protontricks
• Vcrun2015 instalado (consulte https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Dotnet 48 instalado
• Vcrun2017 instalado (consulte novamente https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Agora não tenho gagueira no mapa da campanha, um cursor do mouse fixo e salvando leva alguns segundos. Pode valer a pena tentar para qualquer outra pessoa.

Eu tentei isso, mas agora o jogo parece querer usar um gráfico integrado Intel que eu nem tenho? O jogo é muito lento e não parece uma opção para trocar a placa de vídeo.

Ok, então pode ser que eu tenha encontrado a solução para a gagueira da campanha. Claro, precisaria de um tamanho de amostra maior do que apenas eu. Veja como corrigi-lo em um novo prefixo:

• Construir minha própria versão do Proton (tkg) a partir do código-fonte com a mais nova construção de teste de vinho que inclui a correção do cursor do mouse
• Dotnet40 instalado via protontricks
• Vcrun2015 instalado (consulte https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Dotnet 48 instalado
• Vcrun2017 instalado (consulte novamente https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Agora não tenho gagueira no mapa da campanha, um cursor do mouse fixo e salvando leva alguns segundos. Pode valer a pena tentar para qualquer outra pessoa.

Eu tentei isso, com 1.0.3, e o desempenho foi pior em algumas áreas, melhor em outras.
depois de atualizar para 1.0.4, todo o jogo funciona perfeitamente, é incrível.

Como você instala 2017 após 2015? Recebo erros no instalador de 2017 dizendo que outra versão já está instalada. Eu nem tenho certeza de como desinstalar o 2015 agora.

Eu tenho o mesmo problema. O jogo, entretanto, funciona bem, exceto por alguns congelamentos de vez em quando. Estou executando em um 1080ti no arco.

Ok, então pode ser que eu tenha encontrado a solução para a gagueira da campanha. Claro, precisaria de um tamanho de amostra maior do que apenas eu. Veja como corrigi-lo em um novo prefixo:

• Construir minha própria versão do Proton (tkg) a partir do código-fonte com a mais nova construção de teste de vinho que inclui a correção do cursor do mouse
• Dotnet40 instalado via protontricks
• Vcrun2015 instalado (consulte https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)
• Dotnet 48 instalado
• Vcrun2017 instalado (consulte novamente https://steamcommunity.com/app/261550/discussions/0/2149847049318759493/)

Agora não tenho gagueira no mapa da campanha, um cursor do mouse fixo e salvando leva alguns segundos. Pode valer a pena tentar para qualquer outra pessoa.

Eu tentei isso, com 1.0.3, e o desempenho foi pior em algumas áreas, melhor em outras.
depois de atualizar para 1.0.4, todo o jogo funciona perfeitamente, é incrível.

Como você instala 2017 após 2015? Recebo erros no instalador de 2017 dizendo que outra versão já está instalada. Eu nem tenho certeza de como desinstalar o 2015 agora.

Tive o mesmo problema desde o início. Basta usar protontricks 261550 uninstaller .
Infelizmente o dotnet torna o jogo muito pior para mim, mas economizar tempo é realmente mais rápido, leva cerca de 30 segundos.

Você precisa de um prefixo novo (não criado pelo Steam) para instalar vcrun2015 e vcrun2017 (e dotnet40?). Eu instalei esses e depois o dotnet48 conforme as instruções, mas os salvamentos mais rápidos (ainda) têm o preço de uma irritante instabilidade da taxa de quadros (gagueira rápida). Para mim, quase prefiro fazer uma pausa enquanto ele está salvando e fazer outra coisa para ter problemas de desempenho, mas sou só eu.

Alguém mais está tendo travamentos muito frequentes ao fazer algo que envolva um cerco? Parece menos provável se a IA está liderando o cerco, mas quando estou atacando ou, especialmente, defendendo, é muito provável que o jogo trave (várias vezes). Posso fazer upload de alguns logs mais tarde, só queria saber se isso era algo que outras pessoas também estavam experimentando.

Alguém mais está tendo travamentos muito frequentes ao fazer algo que envolva um cerco? Parece menos provável se a IA está liderando o cerco, mas quando estou atacando ou, especialmente, defendendo, é muito provável que o jogo trave (várias vezes). Posso fazer upload de alguns logs mais tarde, só queria saber se isso era algo que outras pessoas também estavam experimentando.

Sim; bem, estou tendo mais travamentos freqüesnt desde e1.0.4, e cercos parecem ser um gatilho. Para mim; AIs lideram todos os segmentos porque sou muito pequeno

Alguém mais está tendo travamentos muito frequentes ao fazer algo que envolva um cerco? Parece menos provável se a IA está liderando o cerco, mas quando estou atacando ou, especialmente, defendendo, é muito provável que o jogo trave (várias vezes). Posso fazer upload de alguns logs mais tarde, só queria saber se isso era algo que outras pessoas também estavam experimentando.

Eu tenho um jogo seguro no meio de um cerco e ele trava após alguns segundos 100% do tempo. O mesmo jogo salvo funciona bem no Windows. Depois de carregar um save anterior, porém, passei por alguns cercos como parte de um exército e não caiu

Não houve travamentos durante os cercos, mas quando você inicia e está implantando um, o mouse fica vacilante, piscando constantemente e não registra cliques. A tecla Alt-tab para dentro e para fora faz com que ele registre um clique, para que você possa passar da tela de implantação.

O patch pré-compilado na postagem original não está mais funcionando?

@ Ryan-Vablet Funciona, pelo menos deveria, tanto quanto eu sei. Embora alguns pareçam ter uma experiência melhor com sua própria versão do proton-tkg (e outras coisas mencionadas neste comentário ).

O notável é que instalar o dotnet48 torna o salvamento muito mais rápido, algo que leva minutos para alguns, mas causa problemas de desempenho em alguns casos. As outras coisas no comentário podem resolver os problemas de desempenho, mais uma vez em alguns casos.

Mas no final não sabemos de nada específico com proton-tkg que ajude ou se realmente ajuda, ele está mais atualizado, então pode muito bem haver algo útil nele. Atualizar raramente dói, pelo menos.

Para as falhas, ao que parece, não temos nenhuma correção sólida. Mas é possível que sejam simplesmente problemas com o jogo em si, pode ser o caso com alguns dos problemas de desempenho também.

Eu instalei o Bannerlord hoje (e1.0.5) e joguei com proton-tkg por 5 horas. Esta é minha experiência:

Primeiro tentei jogar Bannerlord sem instalar os pacotes dotnet. Tive muita gagueira e também tempos de salvamento muito longos, como esperado. Eu também experimentei longos tempos de carregamento.

Então instalei os pacotes dotnet40 e dotnet48 via protontricks. Economize tempos e tempos de carregamento significativamente reduzidos. A gagueira também foi ligeiramente reduzida. O jogo era bastante jogável neste ponto. Também tentei instalar o vcrun2015 e o vcrun2017, mas não consegui porque eles já estavam instalados (provavelmente automaticamente pelo Steam).

Porém, depois de algumas horas, comecei a ter travamentos cada vez mais frequentes, geralmente quando esperava na cidade. Com base no que li aqui até agora, acho que as falhas estão relacionadas ao fato de eu ter apenas 8 GB de RAM. A escolha da predefinição de configuração média parece ter corrigido (não houve travamentos desde então) e também resultou em menos gagueira.

OS: Arch Linux
KERNEL: 5.5.13-arch2-1
CPU: AMD Ryzen 5 2600 Six-Core
GPU: Radeon RX Vega 56
GPU DRIVER: 4.6 Mesa 20.0.4
RAM: 8 GB

atualizar até 1.0.5 (ubuntu 19.10)
ele funciona perfeitamente, sem problemas de desempenho ou travamento, com renomeação do managedstarter, mas sem nenhum protontricks; usando o próton personalizado da maçã amarela (na descrição do problema)
se eu instalar o dotnet40 + 48 para contornar o problema de salvamento, o desempenho é uma porcaria e o jogo não pode ser jogado de verdade. Eu adoraria tentar essa solução alternativa tkg, mas aparentemente isso é uma coisa arquitectónica única? ambos os vcruns são instalados por padrão.

Consegui passar por um cerco ou dois (liderado pela IA) no patch mais recente com as etapas descritas por YellowApple acima. Vou editar este comentário quando eu jogar de novo e fizer um cerco liderado por um jogador.

Depois de atualizar para 1.05 (usando YellowApple proton, sem instalações dotnet), comecei a travar na tela de loot após lutar contra saqueadores e no início de uma grande batalha de campo. O primeiro aconteceu cerca de 3 vezes, o último uma vez (parei de tentar depois). Ocorreram alguns novos erros no registro e, após travamentos, o jogo ainda estava em execução (também o relator de travamentos travou):

[000000000000004A:] EXCEPTION handling: System.IO.FileNotFoundException: Could not load the file 'TaleWorlds.PSAI.XmlSerializers'.
...
[000000000000003F:] EXCEPTION handling: System.PlatformNotSupportedException: System.Management currently is only supported for Windows desktop applications.

Atualizar:
Eu reiniciei meu computador, ganhei uma luta em um salvamento anterior, recarreguei o que estava travando e entrei em uma luta diferente sem problemas.

atualizar até 1.0.5 (ubuntu 19.10)
ele funciona perfeitamente, sem problemas de desempenho ou travamento, _com_ o managedstarter renomeia, mas _sem_ qualquer protontricks; usando o próton personalizado da maçã amarela (na descrição do problema)
se eu instalar o dotnet40 + 48 para contornar o problema de salvamento, o desempenho é uma porcaria e o jogo não pode ser jogado de verdade. Eu adoraria tentar essa solução alternativa tkg, mas aparentemente isso é uma coisa arquitectónica única? ambos os vcruns são instalados por padrão.

@aradapilot O script de construção proton-tkg também funciona bem em sistemas que não sejam de arquitetura. Apenas certifique-se de instalar as dependências do wine-tkg.

Eu comecei a configurar um pouco usando a construção Proton do @YellowApple . Eu instalei dotnet40 e, em seguida, dotnet48 (que parece substituir a versão anterior), o que eu acho que acelerou a economia, mas o desempenho foi razoável, especialmente no mapa da campanha. Uma observação interessante, tentei desinstalar os verbos dotnet, mas o jogo me informou que exigia pelo menos dotnet 4.0. Reinstalar dotnet40 não foi suficiente para iniciar o jogo corretamente e, de alguma forma, deixou protontricks pensando que a versão 4.8 ainda está instalada. Desinstalei dotnet40 mas isso não resolveu. No final, eu annihilate d o ambiente e não instalei o dotnet, que tem um desempenho muito melhor, pelo menos, embora minhas configurações sejam baixas para minhas especificações, eu acho. Salvar leva talvez 60 segundos em vez de 30 segundos com dotnet.

Outra coisa a observar é o limitador de quadro! Achei que estava gaguejando mesmo em configurações baixas, mas descobri que minha taxa de quadros era maior do que o meu monitor (60 Hz), mas muito instável. O limite para monitorar a taxa de atualização ajudou muito.

Especificações:
R5 2600
RX 580 4gb
16 gb RAM
Linux Mint 19.3 com kernel 5.5
Mesa 20.1 do Oibaf PPA

EDIT: As coisas também parecem significativamente mais estáveis ​​sem dotnet, então acho que vou ficar com ele. Além disso, o modo de segurança parece apenas redefinir o teste de brilho e as configurações gráficas e não notei nenhuma melhora na estabilidade, então não me incomodei em ativá-lo após uma falha.

Portanto, não sei se era protontricks 261550 vcrun2019 ou se estava usando o Proton-GE mais recente, mas um ou ambos erradicaram quase totalmente qualquer gagueira restante para mim. Os salvamentos manuais levam alguns segundos, enquanto os salvamentos automáticos parecem ser instantâneos; nem causa qualquer tipo de atraso residual. Também estou obtendo 10 × o FPS na tela de inventário (anteriormente era muito atroz).

Então, sim, para qualquer um que ainda esteja usando minha construção: vá pegar o GloriousEggroll ; deve funcionar pelo menos tão bem quanto o meu, senão melhor (já que incorpora uma série de outros aprimoramentos para outros jogos também) e é substancialmente menos provável que beba de seu crânio ou coma seu fígado. E também considere tentar protontricks 261550 vcrun2019 se você ainda está tendo gagueira relacionada a dotnet48 .

Você usa o vcrun2019 com ou sem dotnet48?

Você usa o vcrun2019 com ou sem dotnet48?

Com.

Minha ordem exata de operações para o prefixo atual que estou usando:

• Executei o iniciador pelo menos uma vez em minha construção (para gerar um prefixo)
• protontricks 261550 uninstall e desinstale tudo
• protontricks 261550 dotnet40
• protontricks 261550 vcrun2015
• protontricks 261550 dotnet48
• protontricks 261550 vcrun2017
• Executei o jogo novamente pelo menos uma vez sob minha construção
• Comutado para Proton 5.5-GE-1
• protontricks 261550 --force vcrun2019 (uma vez que está tecnicamente em conflito com vcrun2015 )
• Executou o jogo novamente e observei uma melhora acentuada

Eu não testei o caminho mais simples de protontricks 261550 doetnet48 && protontricks 261550 vcrun2019 em um novo prefixo ainda. Minha esperança é que funcione perfeitamente.

Já que não consigo sair do inferno da dependência para compilar os builds do tkg, esses pré-compilados são uma bênção para mim pessoalmente.

Minhas abordagens anteriores:

• Use a construção personalizada do Proton da YellowApples
  ---> Jogo suave, mas os anos 60 economizam tempo para um novo jogo. ~ 90s após 10h ou mais no savegame.

• Instale dotnet48
  ---> Pequenas falhas no mapa da campanha e tempos de economia de aproximadamente 30 segundos. Absolutamente jogável para mim.

Acabei de trocar para o Proton 5.5-GE-1 e não fiz nenhuma modificação adicional, tudo funcionou imediatamente. A gagueira no mapa da campanha acabou e o tempo de salvamento é de aproximadamente 3s.

Com tudo isso dito, ainda experimento travamentos aqui e ali (o jogo travou enquanto eu clicava em alt-tab e escrevia este comentário), mas isso pode estar relacionado ao acesso antecipado. É hora de esperar que isso funcione perfeitamente para todos os outros. <3

@evopls Pode ser o mesmo problema que eu tive:
https://www.reddit.com/r/linuxquestions/comments/fun9qr/did_i_bork_protontkg/

Depois de construir meu próton, tive ~ 5 segundos de tempo de salvamento, não brinquei totalmente com o novo 5.5 GE-1 de economia de tempo ainda, mas cara, esse jogo ainda está quebrando uma tonelada de coisas aleatórias mais tarde no jogo. Mesmo no Windows é uma bagunça genuína, ainda há esperança, já que é o acesso antecipado e estamos essencialmente jogando uma (o que parece uma versão beta inicial).

Estou realmente impressionado porque, apesar dos erros, o jogo funciona muito bem. O último patch parece ter manipulado o CTD instantâneo para certos diálogos e entrar na ferraria e o patch antes disso ajudou significativamente a gagueira no mapa de campanha.

Eu ainda tenho problemas com apenas dotnet48 com Proton-GE ou não, mas com vcrun2019 é mais estável.

Não precisei das outras etapas que Proton-GE + dotnet48 + vcrun2019 funciona para mim

protontricks 261550 dotnet48

protontricks 261550 --force vcrun2019

vcrun2019 sozinho não foi suficiente Eu precisava de dotnet48 + vcrun2019

Não parece que vcrun2019 esteja disponível para instalar. Acabei de reinstalar o protontricks-git de aur , então deve ser a versão mais recente. Como faço para instalar vcrun2019 e / ou disponibilizá-lo para instalação a partir do protontricks?

@yarbelk É de winetricks, atualize winetricks com

# protontricks will pass --self-update to winetricks
protontricks 261550 --self-update

editar: Eu não acho que tive que fazer a atualização quando reinstalei o prefixo, talvez tente reinstalar com o Steam

- self-update irá obter o mais recente de git / master see
https://github.com/Winetricks/winetricks/blob/master/src/winetricks#L1148

O último winetricks é 20191224 (https://github.com/Winetricks/winetricks/releases) que é o que eu instalei. Estou no NixOS, então winetricks - self-update não funciona (e nem protontricks funcionaria). Ainda não tenho um vcrun2019 disponível.

O último winetricks é 20191224 (https://github.com/Winetricks/winetricks/releases) que é o que eu instalei. Estou no NixOS, então winetricks - self-update não funciona (e nem protontricks funcionaria). Ainda não tenho um vcrun2019 disponível.

Por que estar no NixOS impede que winetricks --self-update funcione? Talvez execute-o como root - estou no Ubuntu e sudo winetricks --self-update funcionou.

De qualquer forma, você pode pegar o código mais recente do winetricks git. A versão vcrun2019 para mim é 20191224-next - sha256sum: 472eba29dbf056c87afd39a70426886064040e0bc2c3b63c17baf469b0bf2be2 . Parece que o vcrun2019 não está em nenhuma versão lançada de winetricks, mas --self-update definitivamente pega o mais recente (do git, não dos lançamentos).

Aqui está o commit na versão "-next" (atualmente não lançada) que tem vcrun2019: https://github.com/Winetricks/winetricks/commit/94edaddc039c205a98c2a620399a741c7a70ce02

Por que estar no NixOS impede que winetricks --self-update funcione? Talvez execute-o como root - estou no Ubuntu e sudo winetricks --self-update funcionou.

É porque o NixOS é um sistema operacional declarativo e não usa a hierarquia do sistema de arquivos Unix padrão. Ele usa um ambiente chroot especial para aplicativos como o Steam, que fazem suposições e desejam controlar seu próprio ambiente. O pacote winetricks é instalado em um caminho somente leitura em /nix/store/ onde todos os pacotes são isolados com base em seu hash. É impossível se atualizar.

De qualquer forma, você pode pegar o código mais recente do winetricks git

Vou tentar atualizar a revisão do pacote e ver se funciona. Obrigado!

Edit: funcionou na medida em que existe vcrun2019, mas ao tentar instalá-lo recebo a soma de verificação errada:

sha256sum mismatch! Rename /home/ludvig-new/.cache/winetricks/vcrun2019/vc_redist.x86.exe and try again.

@lboklin se você não quiser remover coisas de volta do diretório em cache

mv ~/.cache/winetricks/{,bak.}vcrun2019

então tente instalar

@lboklin se você não quiser remover coisas de volta do diretório em cache

mv ~/.cache/winetricks/{,bak.}vcrun2019

então tente instalar

Tentei sem sucesso, mas executei com wine (acho que instalei corretamente? Eu defini todas as variáveis ​​env que pude pensar), mas estou divagando. Isso é específico para o meu sistema e não quero bagunçar este tópico. Eu vou descobrir.

Eu continuo entendendo agora:

d3d_device_->CreateTexture2D at
rglGPU_device::create_texture_from_image
failed!
Invalid parameter.

Last Executed Marker: Only supported with nVidia
Gpus and Windows 10.

(quebra de linha bizarra adicionada para verossimilhança extra)

Estou executando dotnet48 vcrun2019 (obrigado @chrisrhayden) e o próton ge-5.5

Eu tenho um 1080ti, que suspeito fortemente se qualificar como nVidia.

É estranho porque qualquer um que está recebendo esse erro no Windows está desativando o Nvidia / Radeon Sharpening para uma possível correção, a única coisa que eu sei que está remotamente perto em nosso painel Nvidia é o Conformant Texture Clamping para texturas 2d sem borda, que não está sendo usado ATÉ ONDE SEI.

Alguns estão dizendo para voltar para e1.0.3 para evitar o problema por enquanto. Você pode selecionar isso em Propriedades-> BETAS-> Selecionar e1.0.3 no menu suspenso. Eu diria que tente, tenho recebido erros cada vez mais estranhos desde a última atualização, enquanto joguei por 3 horas inteiras no patch anterior. Não estou dizendo que essa é a causa, mas não custa verificar.

Experimentei o lançamento mais recente da GE com e sem dotnet48 e vcrun19 . Parece travar na primeira tela de carregamento com estes erros:

[0405/100010.058616:ERROR:frame_sink_video_capturer_impl.cc(206)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
eventfd: Too many open files

Às vezes, as compilações GE ou YellowApple me informam sobre o seguinte:

Mas depois de descartar o diálogo 2 a 3 vezes, o jogo ainda é iniciado e executado normalmente. Dizer sim não parece fornecer nenhuma informação adicional?

Voltando à compilação do YellowApple com esses dois verbos instalados, tem um bom desempenho e economia de aproximadamente 10-15 segundos, ainda não testei muito a estabilidade, mas acho que vou continuar com ela por enquanto.

Não consigo mais instalar o dotnet48 enquanto antes ... Recebo este pop-up:

Por que isso aconteceria agora?

Edit: Criando um novo prefixo manualmente e depois instalando dotnet48 e 2019 antes de lançar via Steam funcionou.

Olá @ Gyrfalcon5 , execute ulimit -Hn e verifique se ele fornece um valor alto e não 4096.

Olá @ Gyrfalcon5 , execute ulimit -Hn e verifique se ele fornece um valor alto e não 4096.

Isso me dá 4096. Isso é um problema? Acho que vi algo aqui sobre aumentar um valor como esse, mas não tenho certeza.

Sim, forneça https://github.com/zfigura/wine/blob/esync/README.esync uma leitura.

Usei as instruções do YellowApple acima e o jogo funciona bem, mas ainda não tenho um cursor do mouse funcionando. Existe uma etapa essencial que eu perdi talvez? Eu estava resignado a usar meu controlador apenas para menus, mas assim que chego ao mapa após a criação do personagem, recebo uma notificação de que não posso clicar com meu controlador.

Usei as instruções do YellowApple acima e o jogo funciona bem, mas ainda não tenho um cursor do mouse funcionando. Existe uma etapa essencial que eu perdi talvez? Eu estava resignado a usar meu controlador apenas para menus, mas assim que chego ao mapa após a criação do personagem, recebo uma notificação de que não posso clicar com meu controlador.

Em outro sistema, às vezes funciona e às vezes não. Reiniciar o jogo corrigiu o problema. dar de ombros

Usei as instruções do YellowApple acima e o jogo funciona bem, mas ainda não tenho um cursor do mouse funcionando. Existe uma etapa essencial que eu perdi talvez? Eu estava resignado a usar meu controlador apenas para menus, mas assim que chego ao mapa após a criação do personagem, recebo uma notificação de que não posso clicar com meu controlador.

Sim, por algum motivo, o mouse também não funciona no meu sistema na primeira vez que inicio o jogo depois de entrar no Steam. Se eu reiniciar o jogo, ele começará a funcionar.

Usei as instruções do YellowApple acima e o jogo funciona bem, mas ainda não tenho um cursor do mouse funcionando. Existe uma etapa essencial que eu perdi talvez? Eu estava resignado a usar meu controlador apenas para menus, mas assim que chego ao mapa após a criação do personagem, recebo uma notificação de que não posso clicar com meu controlador.

Sim, por algum motivo, o mouse também não funciona no meu sistema na primeira vez que inicio o jogo depois de entrar no Steam. Se eu reiniciar o jogo, ele começará a funcionar.

Que diabos? Tudo bem, sim. É apenas a primeira vez após iniciar o Steam. Que curioso.

Atualização: Tive que deletar e recriar o prefixo manualmente sem o Steam para instalar o dotnet48 e o vcrun2019. Eu poderia então iniciar via Steam e tanto o desempenho quanto a economia parecem funcionar bem (testado apenas por um minuto até agora). Isso é com Proton-GE e winetricks construídos a partir desta revisão .

Sim, forneça https://github.com/zfigura/wine/blob/esync/README.esync uma leitura.

Seguiu as orientações lá e a Proton GE está trabalhando com desempenho muito melhor! No entanto, a estabilidade poderia dar certo, eu tive um travamento ao procurar um personagem depois de um ou dois minutos. Posso tentar limpar meu prefixo e reinstalar o material para ver se isso ajuda, embora eu saiba que o jogo em si está muito instável agora.

EDITAR: Procurar um personagem é uma falha super consistente, com o seguinte resultado quando executo o Steam na linha de comando:

mesa: for the   --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the   --global-isel-abort option: may only occur zero or one times!
ERROR: ld.so: object '/home/roland/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 5460 for game ID 261550
ERROR: ld.so: object '/home/roland/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
>>> Adding process 5468 for game ID 261550
wine: Unhandled page fault on execute access to 000000001E770198 at address 000000001E770198 (thread 0035), starting debugger...
ERROR: ld.so: object '/home/roland/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

EDIT2: Mais informações sobre a falha de um ambiente Proton-GE novo:

=================================================================
    Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
    Managed Stacktrace:
=================================================================
domain required for stack walk
=================================================================

EDIT 3: Testing dotnet48 novamente para ver se isso resolverá o erro de informação extra.

EDIT 4: Reclamações sobre mono se foram, mas os problemas de estabilidade com a enciclopédia, bem como a classificação da arena são persistentes. Acho que tem algo a ver com o diálogo extra vindo do mapa da campanha, mas não tenho certeza.

Como instalar o vcrun2019? quando eu corro protontricks 261550 vcrun2019
Sempre recebo "Unknown arg vcrun2019"
(estou usando os protontricks mais recentes)

Como instalar o vcrun2019? quando eu corro protontricks 261550 vcrun2019
Sempre recebo "Unknown arg vcrun2019"
(estou usando os protontricks mais recentes)

Você também atualizou winetricks? Acho que as pessoas estavam tendo problemas com protontricks para estarem atualizados, mas conversando com um winetricks desatualizado antes. Deve ser suficiente apenas fazer winetricks --self-update , você pode precisar do sudo.

Recebendo muitos travamentos com proton-GE, dotnet48 e vcrun2019.
Saída no terminal:

wine: Unhandled exception 0xe0434352 in thread 3f at address 000000007B00FDCE (thread 003f), starting debugger...

Editar:
Acho que ativar o modo de segurança (ele pergunta quando você inicia novamente depois que ele travou) ajudou a evitar um travamento inevitável em minha campanha (algum evento provavelmente o acionou).

Editar 2:
Aumentar muito o zoom no mapa da campanha geralmente causa um travamento (aconteceu pelo menos 3 vezes na última hora).

Editar 3:
É basicamente impossível de jogar. Teve mais de 5 falhas na última meia hora. Não vendo nada de útil na saída; somente

wine: Unhandled exception 0xe0434352 in thread 74 at address 7B00DE67 (thread 0074), starting debugger...

Editar 3:
Ok, agora eu travei no menu de configurações:

wine: Unhandled page fault on execute access to 0000000000000000 at address 0000000000000000 (thread 003b), starting debugger...

Como o jogo de repente se esquecia e se recusava a salvar minhas configurações, adicionei permissões de leitura do diretório de salvamentos e configurações ao grupo (mantenho o link simbólico fora do prefixo para não apagá-lo acidentalmente). Depois disso, o jogo lembrou minhas configurações. Pode estar relacionado à última falha no menu de configurações.

@lboklin
Eu também tenho travamentos a cada poucos minutos 5-30 ao usar dotnet48 e vcrun2019 e está sempre no mapa mundial.
próton-GE e próton-tkg têm esse problema, próton-GE não melhorou nada para mim.

@craftyguy Exceto se você quiser que winetricks se atualize, depende de como você o instalou originalmente.

$ winetricks --self-update
------------------------------------------------------
You don't have the proper permissions to run this command. Try again with sudo or as root.
------------------------------------------------------

Se você o obteve de seu gerenciador de pacotes, então provavelmente ele reside em /usr/bin , e você _do_ precisa de acesso root para atualizá-lo lá.

Apenas uma sugestão. Se alguém está exigindo permissões de root para atualizar winetricks. Use sudo -E para preservar seu meio ambiente.

@lboklin

Vou tentar atualizar a revisão do pacote e ver se funciona. Obrigado!

Olá colega usuário de nixos - como você fez isso?

"como atualizar winetricks" na distribuição de sua escolha parece fora do assunto aqui. Vá perguntar no fórum público da sua distribuição ou instale Winetricks localmente para o seu usuário.

@lboklin

Vou tentar atualizar a revisão do pacote e ver se funciona. Obrigado!

Olá colega usuário de nixos - como você fez isso?

Embora eu concorde que é offtopic, vou demorar um pouco para responder para economizar seu tempo.

1. clonar o repositório nixpkgs
2. cd nele
3. edite pkgs / misc / emulators / wine / sources.nix como abaixo
4. nix-env -f . -iA winetricks

diff --git a/pkgs/misc/emulators/wine/sources.nix b/pkgs/misc/emulators/wine/sources.nix
index 0e3eb2ce698..aeb0cdef883 100644
--- a/pkgs/misc/emulators/wine/sources.nix
+++ b/pkgs/misc/emulators/wine/sources.nix
@@ -56,10 +56,10 @@ in rec {

   winetricks = fetchFromGitHub rec {
     # https://github.com/Winetricks/winetricks/releases
-    version = "20191224";
-    sha256 = "07q3zh2i3xqzpg46ljarhq3a4ha9zwpc6jqzvly0kfglkh3b3v66";
+    version = "20191229";
+    sha256 = "0vzb9fxnrmbv1x86q7ri0xx4slvmbyjsf59y9hl48gxyr5kld68q";
     owner = "Winetricks";
     repo = "winetricks";
-    rev = version;
+    rev = "94edaddc039c205a98c2a620399a741c7a70ce02";
   };
 }

Eu tenho um novo sistema com:

Bannerlord recém-instalado a partir do Steam
vinho recém-instalado
winetricks recém-construídos da fonte
protontricks fresco instalar usando os winetricks acima

❯ wine --version
wine-5.0
❯ winetricks --version
20191224-next - sha256sum: f183161a93a92f2fe38ec90b723055d5a2ca691c85400874879b0ef779a7f46e
❯ protontricks --version
protontricks (1.4.1)
❯ rm -rf ~/.steam/steam/steamapps/compatdata/261550
❯ rm -rf ~/.wine

Instalei a versão 5.5-GE-1 do próton e movi para .steam/root/compatibilitytools.d

Então eu corri:

❯ steam # Launched game from steam with Proton-5.5-GE-1 selected
...
Proton: Upgrading prefix from None to 5.5-GE-1 ($HOME/.local/share/Steam/steamapps/compatdata/261550/)
...
Unhandled Exception:
System.IO.FileNotFoundException: Could not load file or assembly 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
File name: 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'ManagedStarter, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

❯ cp ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/Bannerlord.exe ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/ManagedStarter.exe
❯ cp ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/Bannerlord_BE.exe ~/.steam/steam/steamapps/common/Mount\ \&\ Blade\ II\ Bannerlord/bin/Win64_Shipping_Client/ManagedStarter_BE.exe

Neste ponto, o jogo inicia

❯ killall wineserver
❯ protontricks 261550 dotnet48
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Using winetricks 20191224-next - sha256sum: 21f89159ef089f5e8c70568b34c40973f6cdc7de04832f3d79c9b74fcbfc32ed with wine-5.0 and WINEARCH=win64
Executing w_do_call dotnet48
# ..... fails

Preciso de alguma forma dizer que a versão é de 32 bits? O diretório é criado pelo Steam, preciso criá-lo manualmente com winecfg usando WINEARCH = win32? Parece que o bannerlord é de 64 bits, então não tenho certeza de como isso funcionaria.

@TannerYoung parece que você está executando a versão 1.0.0 do jogo.

Você pode atualizar o jogo para a versão mais recente ou renomear ManagedStarter.exe para ManagedStarter.exe.old (ou qualquer coisa realmente) e então copiar / symlink / renomear Bannerlord.exe para ManagedStarter.exe para corrigir o problema.

Para as pessoas que ainda têm problemas de travamento após instalar as várias versões do vcrun, verifique a versão do Windows no winecfg. O meu foi configurado para WinXP durante uma das instalações e voltar para o Windows 10 corrigiu muitos dos meus travamentos.

Tive muita sorte até agora com o dotnet472 e não com o dotnet48:

protontricks 261550 dotnet472

Estou usando o Proton da Valve (@ proton_5.0-next tag), com o patch @YellowApple do wine-staging aplicado, e não esses builds aleatórios do Proton que as pessoas estão distribuindo. Eu também não instalei o vcrun2019.

Salvar leva cerca de 5 segundos para mim, e o jogo não travou para mim desde que usei esta configuração (estou executando a versão mais recente do jogo com o hotfix de hoje).

Vale ressaltar que as dependências do jogo postadas no fórum por Taleworlds são .NET 4.7.2, vcrun 2015 e 2017: https://forums.taleworlds.com/index.php?threads/installing -missing-needed-dependencies. 407126 /

Não há nada sobre ter .NET 4.8 ou vcrun 2019 ..

@craftyguy : muito obrigado por isso! com o dotnet48, o jogo estava funcionando bem, mas todas as campanhas acabariam por travar / congelar, ao ponto em que jogar mais adiante era quase impossível. Com o dotnet472, esse problema parece estar completamente resolvido. Além disso, agora estou vendo notificações à direita da tela (como quando alguém está levantando um exército em algum lugar), o que não era o caso com dotnet48 - nem sabia que o recurso existia.

Também não estou vendo gagueira no mapa (embora nunca tenha visto, mesmo com dotnet48).

Pode confirmar as descobertas de @craftyguy ; Proton 5.5-GE-1 e protontricks 261550 dotnet472 são suficientes para corrigir a gagueira e os longos tempos de salvamento. Boa pegada!

Estou percebendo que estou tendo um travamento reproduzível de forma consistente ao visualizar a página da enciclopédia de uma cidade em um salvamento existente e travamentos intermitentes na tela de inventário, ambos em meu prefixo anterior (com vcrun201(5|7|9) e dotnet48 ) e o atual (com apenas dotnet472 ). Vou tentar um novo jogo ( suspiro ) e ver se persiste.

Não tenho certeza do que fazer com o que está acontecendo, do meu lado. Eu sinto que estou de volta à estaca zero, onde a entrada do mouse é completamente não funcional, não importa a versão do próton que eu execute, não importa quais pacotes do Windows eu instale. Mesmo a versão antiga do YellowApple, que estava funcionando bem antes, não funciona.

Vou ter que tentar este dotnet472, veja se isso ajuda a resolver meus problemas com essas falhas aleatórias em um novo jogo. Achei que meu antigo jogo acabou de funcionar, já que passou por várias atualizações agora. Fiquei jogando por algumas horas e alguns de meus amigos no Windows estão relatando as mesmas falhas em salvamentos mais antigos.

Com o dotnet472 também posso confirmar que salvar é rápido, mas travei antes de ser capaz de fazer qualquer observação substancial sobre o desempenho, por isso parece tão inutilizável travamento como com vcrun2019 e dotnet48.

Atualizar:
Ele tem um bom desempenho e a economia é rápida, conforme observado, mas, na verdade, a estabilidade não é grande. Muitas falhas no mapa da campanha.

Offtopic, mas quero ajudar rapidamente qualquer usuário NixOS compartilhando este script para minha configuração de prefixo atual: https://gist.github.com/lboklin/c735c867a00fbb2d30bb89dbcd910c03

Deveria ter mencionado: meu jogo sem travamentos foi apenas depois de iniciar uma nova campanha em 1.0.5 (antes do seguinte hotfix, mas após a atualização 1.0.5 real). Também notei tempos de carregamento um pouco mais longos (+ ~ 50%) entre as cenas com dotnet472 em comparação com dotnet8, o que realmente não é grande coisa, dada a estabilidade amplamente aumentada.

@Ampsersanddd, outras pessoas mencionaram isso, mas é comum que o jogo não responda à entrada do mouse, mesmo após a correção na primeira inicialização por algum motivo; reiniciá-lo corrige. Talvez seja esse o seu problema?

dotnet472 falha com salvar arquivos de 1.0.4 (no entanto, levou cerca de 10 minutos enquanto eu estava no menu da cidade), mas também oferece um desempenho muito bom (testado com próton-GE). Vou testar mais tarde se isso também é verdade para um novo jogo usando 1.0.5.

ATUALIZAR:

Joguei cerca de 30 minutos com um novo jogo até que ele travou ao abrir o menu da cidade.

Mesmo com uma nova campanha, é muito complicado para mim. Na maioria das vezes recebo o código de exceção 0000000c, embora a falha mais recente (mais uma anterior hoje) tenha sido o código de exceção 6ba.

No lado positivo, porém, pelo menos fui capaz de confirmar que a área de transferência funciona (usando bannerlord.party para fazer um banner legal ). Então você sabe, não pode ser tão ruim.

Alguém descobriu uma maneira de obter um registro gerado pelo jogo? Há menção de arquivos de log (nomeadamente rgl_log.txt ou algo assim) nos fóruns, mas não consigo encontrá-los em lugar nenhum. A ferramenta de relatório de travamento também parece totalmente sobrecarregada e os logs do Proton não fornecem rastreamentos de pilha significativos.

Acho que pode ser útil saber como remover completamente um prefixo para próton. Eu sei que é um pouco fora do assunto, mas dada a quantidade de vezes que as pessoas estão fazendo isso, pode reduzir os relatórios de erros causados ​​por kruft.

Sei que não tenho certeza do que estou fazendo: mas estou excluindo o diretório ~/.steam/steam/steamapps/compatdata/261550/ e executando o jogo novamente para recriá-lo. isso é suficiente?

Sei que não tenho certeza do que estou fazendo: mas estou excluindo o diretório ~/.steam/steam/steamapps/compatdata/261550/ e executando o jogo novamente para recriá-lo. isso é suficiente?

Sim, isso é tudo que há para fazer. Pessoalmente, gosto de renomear, para poder alternar entre os prefixos e testar as coisas rapidamente (e também para tornar mais fácil retirar meus salvamentos e configurações), mas você faz você.

E por falar nisso: parece que um prefixo novo (sem qualquer protontricks ) é menos problemático para mim, mas ainda tem o bug de salvamento de vários minutos e reintroduz um pouco de gagueira no mapa da campanha. Você ganha alguns você perde alguns, eu acho, lol

Varias coisas:

1) Agora estou em um estado estranho que, com um novo prefixo, não consigo nem mesmo fazer o iniciador iniciar mais. Também estou suspeitando que alguns recursos não estão sendo limpos corretamente quando ele trava (devido a um aumento suspeito no uso de memória que eu não tentei depurar ativamente além de ps aux | grep Mount e ps aux | grep wine e tentando para fazer com que eles saiam corretamente. Reiniciará o sistema, mas quero escrever isso antes de fazer isso.

2) ao instalar os pacotes donet e vcrun, continuo vendo 'não parece que o mono está instalado', que é (6.4, arch linux); isso está quebrando em protontricks ou comportamento esperado?

3) não digite enquanto o protontricks estiver em execução. você pressionará enter quando ele perguntar 'instale essa coisa que demorou uma eternidade para fazer' e você cancelará.

4) @YellowApple eu poderia jurar que vi um log dxvk na saída: você está usando uma versão específica do dito dxvk? Dados os need nvidia card bugs estranhos quando estou executando uma placa nvidia ... Eu me pergunto se há algo lá que estou perdendo.

@yarbelk O problema "preciso da placa nvidia ou do Windows 10" foi facilmente corrigido para mim, alterando a versão do Windows no winecfg de volta para o Windows 10, conforme descrito aqui: https://github.com/ValveSoftware/Proton/issues/3706#issuecomment -609480224

Dito isso, agora também estou recebendo travamentos frequentes do mapa da campanha. As únicas coisas que mudei foram a configuração acima e o patch M&B em si. Não tenho certeza se foi 1.0.3 ou 1.0.4 onde funcionou bem, mas esses travamentos de campanha são completamente novos para mim. Dotnet472 ou dotnet480 também não fizeram diferença.

Para as pessoas que estão tendo muitos problemas estranhos de instabilidade, acho que você só precisa excluir o prefixo do vinho Bannerlord, verificar os arquivos do jogo (certifique-se de estar atualizado) e instalar o vcrun2019 e o dotnet48. Além disso, certifique-se de não ter a substituição global para o conjunto SteamPlay (página principal de Configurações do Steam -> SteamPlay) e use a versão mais recente do Proton-GE.

Se você fizer tudo isso e ainda tiver problemas, atualize também o driver gráfico. Para Nvidia, você deve estar executando a versão binária mais recente da nvidia.com; se já estiver empacotado para sua distribuição, ótimo. Para AMD, você deve estar executando os binários Catalyst mais recentes ou uma versão git recente do mesa / libdrm / AMD DDX e um kernel Linux recente.

O jogo está funcionando perfeitamente, sem grandes problemas para mim. Eu tenho problemas de 1-2 segundos na primeira vez que uma animação de combate ou novo equipamento é carregado no campo, mas isso pausa o jogo inteiro, então não é como se eu lutasse em desvantagem quando isso acontecesse, e não se repetisse se eu mantivesse lutando contra os mesmos inimigos. Provavelmente algum tipo de cache de sombreador relacionado a efeitos de pano realistas.

Poste também qual GPU você possui ao relatar problemas. Estou em um 2080 Ti. Consegui jogar sem parar por 4 horas sem travar e com bom desempenho.

@YellowApple

Os registros do jogo são encontrados no prefixo do vinho aqui: </261550 prefix>/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/logs/

por exemplo, ~/.steam/steam/steamapps/compatdata/261550/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/logs

Se o uploader travado funcionasse (o que é realmente uma pena que não ...), parece que ele carregaria os artefatos encontrados aqui: <261550 prefix>/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/crashes/

Parece que o jogo cria um diretório no diretório crashes cada vez que trava, e inclui alguns registros diferentes + o jogo salvo da falha.

Bem, eu fui mais longe com a compilação mais recente do Proton-GE e a instalação do dotnet472 (que instalou retroativamente cerca de 5 a 6 versões anteriores).

Pego o inicializador agora, mas o jogo ainda está travando o computador inteiro após a criação do personagem. Posso ouvir música / sons de fundo, mas nada. Eu o deixei parado por um tempo, pensando que só precisava recuperar o atraso. Nada. O desligamento forçado é a única solução.

Bem, eu fui mais longe com a compilação mais recente do Proton-GE e a instalação do dotnet472 (que instalou retroativamente cerca de 5 a 6 versões anteriores).

Pego o inicializador agora, mas o jogo ainda está travando o computador inteiro após a criação do personagem. Posso ouvir música / sons de fundo, mas nada. Eu o deixei parado por um tempo, pensando que só precisava recuperar o atraso. Nada. O desligamento forçado é a única solução.

Qual distro, GPU e versão do driver gráfico?

Ubuntu 18.04, RX 580 e drivers amd de estoque / padrão. Eu também tenho wine / winetricks / mesa / vulkan atualizados.

É apenas este jogo, atualmente, que não funciona, mas isso não significa que não seja o meu sistema, apenas jogando-o para fora.

Ubuntu 18.04, RX 580 e drivers de estoque / padrão amd. Eu também tenho wine / winetricks / mesa / vulkan atualizados.

É apenas este jogo, atualmente, que não funciona, mas isso não significa que não seja o meu sistema, apenas jogando-o para fora.

Ubuntu 18.04 está usando drivers Mesa (código aberto) bastante antigos agora. Você pode tentar mudar para os drivers AMD Adrenaline (anteriormente conhecidos como Catalyst ou fglrx)?

Se você quiser ficar com a pilha de gráficos de código aberto, também pode experimentar o PPA gráfico do oibaf: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

A pilha de gráficos de código aberto envelhece muito mal. Isso se deve em grande parte ao ritmo extremamente rápido de melhorias. Um driver gráfico de código aberto de 1 ano de idade é como um carro de 80 anos. Completamente e totalmente obsoleto. Neste ponto, estou pensando seriamente que o problema é com a pilha de gráficos de código aberto.

Estou no Ubuntu 20.04 (que é mais semelhante ao 18.04 em muitos aspectos, na verdade) e a principal diferença é que estou executando os drivers binários da Nvidia. O jogo corre muito bem. Se a atualização da pilha de gráficos de código aberto do oibaf não corrigir isso para você, eu tentaria o driver binário Adrenaline.

A pilha de gráficos de código aberto envelhece muito mal.

Não culpe o Mesa por uma distro de merda (ubuntu) distribuindo versões antigas dele. Existem PPAs públicos que permitirão que você instale um Mesa mais novo em sua distro antiga e desatualizada.

Estou executando um RX 580 no Mesa 20.0 (e até mesmo no ramo master do Mesa) sem travamentos gráficos como eles descreveram.

Estou executando um RX 580 no Mesa 20.0 (e até mesmo no ramo master do Mesa) sem travamentos gráficos como eles descreveram.

Mostro estar no Mesa 20.0.0-devel, mas se essa for a versão errada e houver uma diferente / melhor, não sou de ignorar os conselhos dos outros. Também estou verificando o outro PPA, porque pensei que já tinha, mas posso ter removido há algum tempo.

A pilha de gráficos de código aberto envelhece muito mal.

Não culpe o Mesa por uma distro de merda (ubuntu) distribuindo versões antigas dele. Existem PPAs públicos que permitirão que você instale um Mesa mais novo em sua distro antiga e desatualizada.

Estou executando um RX 580 no Mesa 20.0 (e até mesmo no ramo master do Mesa) sem travamentos gráficos como eles descreveram.

Oh, eu não estou culpando Mesa de forma alguma. O fato é que o Mesa de hoje é 1000% melhor (mais funcional e completo) do que o Mesa de um ano atrás. Isso tem sido verdade em todos os anos de existência da pilha de gráficos de código aberto. Eu estava simplesmente justificando por que não é certo confiar em qualquer versão "estável" (também conhecida como _stale_) do Mesa que uma distro LTS é lançada, enquanto tento jogar jogos de última geração.

Edit: Então, novamente, eu nunca tive muito sucesso executando jogos "reais" (ou seja, qualquer coisa com mais detalhes gráficos do que Stellaris ou Team Fortress 2) com a pilha de gráficos de código aberto. Eu tentei um git master build de March do PPA do oibaf com uma Radeon VII com Kingdom Come: Deliverance, Elder Scrolls Online, PULSAR: Lost Colony, Stellaris e vários outros jogos. O desempenho foi aceitável no ESO e Stellaris, mas insuportavelmente lento nos outros (5 fps ou pior). Troquei a eGPU de uma Radeon VII para uma 2080 Ti e usei o driver binário da Nvidia e, de repente, o desempenho está bem acima de 60 fps em todas as cenas e mais de 100 frequentemente. Noite e dia.

Se você estiver usando a pilha gráfica de código aberto, estará praticamente limitado a jogar quaisquer jogos que ela suporte bem, o que é provavelmente cerca de 20-50% de todos os jogos existentes (estimativa aproximada). Se você estiver usando os drivers binários da Nvidia, cerca de 95% dos jogos funcionam bem. Espero que os drivers de código aberto cheguem ao ponto em que sejam tão bons ou melhores que os binários algum dia, mas isso não é hoje.

Então eu percebi isso , na seção de suporte dos fóruns, dizendo que às vezes o Steam não está instalando todos os recursos necessários.

Não sei se o .net Core está incluído (ou deveria estar) com dotnet472 , mas usei o link desse post para instalar essa versão específica e parece que a maioria dos meus travamentos sumiram! Eu ainda fico travado ocasionalmente, especialmente quando coisas como texturas são carregadas pela primeira vez em cada sessão, mas posso até mesmo puxar a notória tabela de classificação da arena sem bater agora!

Para aqueles que gostariam de experimentar, fiz algo como o seguinte:

$ wget https://download.visualstudio.microsoft.com/download/pr/cd223083-8c0e-4963-9fcd-fcf01a55e56c/15500e764899442ed6e014687caa34e9/dotnet-runtime-2.1.17-win-x64.exe

$ export STEAM_COMPAT_DATA_PATH=/games/steamapps/compatdata/261550/

$ cd ~/.steam/steam/compatibilitytools.d/proton_butterlord/

$ ./proton run ~/dotnet-runtime-2.1.17-win-x64.exe

onde o caminho compatdata seria o caminho para sua pasta compatdata bannerlord e o cd é para qualquer diretório que o próton que você está usando esteja contido.

Se você quiser ficar com a pilha de gráficos de código aberto, também pode experimentar o PPA gráfico do oibaf: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers

Bem, puta merda, se reinstalar aqueles não parecia funcionar! Na verdade, cheguei ao primeiro diálogo após a criação do personagem! Vou testar mais, mas só queria jogar fora, pode ter sido o conserto (bate na madeira).

/editar
Gostaria apenas de agradecer de um estranho aleatório da Internet a todos que estão solucionando problemas e apresentando soluções para isso!

@Aliervo - Então, após o último comando e parece falhar com isso -

ProtonFixes [12023] INFO: Executando protonfixes
ProtonFixes [12023] INFO: Verificações em execução
ProtonFixes [12023] INFO: Todas as verificações bem-sucedidas
ProtonFixes [12023] INFO: Nenhum protonfix encontrado para UNKNOWN (261550)

@yarbelk O problema "preciso da placa nvidia ou do Windows 10" foi facilmente corrigido para mim alterando a versão do Windows no winecfg de volta para o Windows 10, conforme descrito aqui: # 3706 (comentário)

Dito isso, agora também estou recebendo travamentos frequentes do mapa da campanha. As únicas coisas que mudei foram a configuração acima e o patch M&B em si. Não tenho certeza se foi 1.0.3 ou 1.0.4 onde funcionou bem, mas esses travamentos de campanha são completamente novos para mim. Dotnet472 ou dotnet480 também não fizeram diferença.

Infelizmente; configurar o windows 10 não impediu a falha da nvidia para mim (com o prefixo vazio também)
no início do novo jogo antes da criação do personagem: nvida crash. reiniciar. logo após vencer o tornement: crash da nvidia (10 minutos).

@jake-hedges Caiu no prompt depois disso? Lembro-me de ter visto aqueles, mas depois de um segundo, ele foi executado e abriu o instalador.

Edit: Apenas tentei novamente em um prefixo limpo, eu consegui

ProtonFixes[32252] INFO: Running protonfixes
ProtonFixes[32252] INFO: Running checks
ProtonFixes[32252] INFO: All checks successful
ProtonFixes[32252] INFO: No protonfix found for UNKNOWN (261550)
ProtonFixes[32252] INFO: Creating MS Core font links in /games/Steam/steamapps/compatdata/261550/pfx/drive_c/windows/Fonts

mas então, após alguns segundos, a caixa de diálogo de instalação apareceu e me permitiu instalar.

Verifique novamente /your/path/to/compatdata/261550/pfx/drive_c/Program\ Files/ para uma pasta dotnet no caso de uma instalação silenciosa. Se não houver nada lá, tente executá-lo novamente e espere um ou dois minutos para ver se a janela de instalação aparece.

@Aliervo - Então, após o último comando e parece falhar com isso -

ProtonFixes [12023] INFO: Executando protonfixes
ProtonFixes [12023] INFO: Verificações em execução
ProtonFixes [12023] INFO: Todas as verificações bem-sucedidas
ProtonFixes [12023] INFO: Nenhum protonfix encontrado para UNKNOWN (261550)

Também recebi este erro, mas funcionou adicionar "pfx /" ao final

$ export STEAM_COMPAT_DATA_PATH = / games / steamapps / compatdata / 261550 / pfx /

Isso não fez nada para mim, no entanto. Obtendo as mesmas falhas aleatórias.

Edit: NVM eu falei mal. Eu pensei que tinha resolvido, mas eu li errado
Erro ao usar 261550 /

ProtonFixes [25930] INFO: Executando protonfixes
ProtonFixes [25930] INFO: Verificações em execução
ProtonFixes [25930] INFO: Todas as verificações bem-sucedidas
ProtonFixes [25930] INFO: Nenhum protonfix encontrado para UNKNOWN (261550)

Erro ao usar 261550 / pfx /

./proton run ~ / dotnet-runtime-2.1.17-win-x64.exe Proton: prefixo de atualização de nenhum para 5.5-GE-1 (/ run / media / m / 850EVO / Games / SteamLibrary / steamapps / compatdata / 261550 / pfx //)
ProtonFixes [25999] INFO: Executando protonfixes
ProtonFixes [25999] INFO: Verificações em execução
ProtonFixes [25999] INFO: Todas as verificações foram bem-sucedidas
ProtonFixes [25999] INFO: Nenhum protonfix encontrado para UNKNOWN (261550)
ProtonFixes [25999] INFO: Criação de links de fonte MS Core em / run / media / m / 850EVO / Games / SteamLibrary / steamapps / compatdata / 261550 / pfx / pfx / drive_c / windows / Fonts
Por algum motivo, ele adicionou os links de fonte do MS Core quando usei o pfx, mas o instalador não foi iniciado.

Sem dotnet472 ou dotnet48, o inicializador não funcionará, e eu tenho que renomear o jogo .exe como sugerido no início do tópico para iniciar o jogo sem o inicializador, mas cada salvamento leva de 30 a 90 segundos. Parece um pouco mais estável, mas o jogo é salvo automaticamente com muita frequência, me forçando a esperar mais de um minuto a cada 5-10 minutos, especialmente no início do jogo.

Com o dotnet, o inicializador funciona e o salvamento leva de 1 a 5 segundos, mas pode travar aleatoriamente no mapa do jogo ou antes de iniciar conversas ou batalhas. No entanto, é principalmente jogável. De vez em quando, consigo jogar uma hora ou mais antes que meu FPS caia para 0,5 em conversas e batalhas (que uma reinicialização corrige) ou que trave.

@EmquCC Verifique

Um dos scripts vcrun o define como XP e o outro como 7. Lembro-me de travar muito quando meu prefixo foi definido como XP e há relatórios nos fóruns de problemas com o Windows 7, então recomendo o 10.

Além disso, 1.0.6 acabou de cair, então vou lançar um novo prefixo e ter certeza de que tudo ainda está funcionando.

@EmquCC Verifique

Um dos scripts vcrun o define como XP e o outro como 7. Lembro-me de travar muito quando meu prefixo foi definido como XP e há relatórios nos fóruns de problemas com o Windows 7, então recomendo o 10.

Além disso, 1.0.6 acabou de cair, então vou lançar um novo prefixo e ter certeza de que tudo ainda está funcionando.

Obrigado :) Mudei para o Windows 10 ontem, mas esqueci de verificar hoje. Eu editei minha postagem, pois li errado. Quando adicionei o pfx, ele fez alguns links para as fontes do MS Core, mas o instalador não iniciou. Vou fazer um novo prefixo e tentar novamente com 1.0.6 e entrarei em contato com você

Edit: Novo RC para Proton 5.0.6 descartado ao mesmo tempo que 1.0.6. Não vejo nenhum changelog para ele ainda, mas vou tentar também. Para aqueles que desejam experimentar as compilações de teste do Proton, clique com o botão direito do mouse em Proton 5.0 na biblioteca do Steam> propriedades> Betas> opte por "próximo -"

. Para aqueles que desejam experimentar as compilações de teste do Proton, clique com o botão direito do mouse em Proton 5.0 na biblioteca do Steam> propriedades> Betas> opte por "próximo -"

A menos que tenham adicionado o patch de entrada do mouse no 5.0.6, você precisará corrigi-lo sozinho ou perderá a capacidade de clicar com o mouse.

@craftyguy Sim, tive que tentar, pois ainda não há changelog para o Proton 5.0.6 RC2. O patch de entrada do mouse não foi adicionado ao RC2.

@Aliervo @ jake-hedges Ainda não consegui instalar o dotnet-runtime-2.1.17-win-x64 com esse comando. No entanto, consegui instalá-lo usando protontricks --gui , depois "Executar o explorer" e executar o .exe a partir do explorer. Vou testar agora

Edit: Agora meu jogo trava antes de chegar à tela do menu. Reiniciando com um novo prefixo novamente ^^

Edit 2: Carregado agora em um novo prefixo com dotnet-runtime instalado. Provavelmente foi um erro do usuário da minha parte :)

Apenas um aviso , o mais recente

Apenas um aviso , o mais recente

Usando essas correções, ainda estou conseguindo controle do mouse, talvez 1 em cada 10 inicializações.

Apenas um aviso , o mais recente

Usando essas correções, ainda estou conseguindo controle do mouse, talvez 1 em cada 10 inicializações.

Isso é realmente estranho, depois de corrigir o vinho um tempo atrás, eu obtenho o controle do mouse 100% do tempo. Alguém mais está enfrentando o mesmo problema quando os patches não funcionam?

@jaynus : você tentou usar um prefixo novo (execute protontricks 261550 annihilate )? Não deve fazer nenhuma diferença, mas talvez você tenha algumas modificações estranhas de antes, ou ??

Apenas um aviso , o mais recente

Usando essas correções, ainda estou conseguindo controle do mouse, talvez 1 em cada 10 inicializações.

Isso é realmente estranho, depois de corrigir o vinho um tempo atrás, eu obtenho o controle do mouse 100% do tempo. Alguém mais está enfrentando o mesmo problema em que os patches _não_ funcionam?

@jaynus : você tentou usar um prefixo novo (execute protontricks 261550 annihilate )? Não deve fazer nenhuma diferença, mas talvez você tenha algumas modificações estranhas de antes, ou ??

Sim! Apaguei o prefixo inteiro e comecei do zero, ainda é muito esporádico

Tive a chance de testar um pouco em um novo prefixo agora. Teve exatamente 2 falhas. Um quando mudei as configurações imediatamente (como antes, travou, mas salvei as alterações nas configurações). A outra foi quando tentei passar da tela do inventário para a tela da festa. Quando tentei reproduzi-lo, as telas mudaram bem, com apenas um leve travamento para que as coisas carregassem, então estou assumindo que foi um erro de carregamento ocasional.

Também prestei mais atenção ao que a instalação de vcrun2019 realmente faz, o instalador que aparece diz que é o 2015-2019 redistribuível, então provavelmente não faz nada melhor do que instalar vcrun2015 e vcrun2017 independentemente, é apenas uma etapa conveniente.

Adicionar o .net Core que vinculei anteriormente (usando a linha de comando como postei ou protontricks 261550 --gui seguido por "Executar Explorer" como @EmquCC apontou) completa nossa lista de dependências necessárias conforme listado aqui , então, teoricamente , a maioria dos travamentos restantes são causados ​​por bugs no próprio jogo e logo serão corrigidos!

então, teoricamente, a maioria das falhas restantes são causadas por bugs no próprio jogo e logo serão corrigidas!

Eu não sei, há uma longa história sangrenta de componentes do Windows que falham no vinho por vários motivos, então eu não descartaria completamente que não há mais insetos do vinho aqui.

É realmente lamentável que o carregador de travamento do jogo não funcione. Pode haver classe (s) de bugs do jogo que só nos afetam no Wine e que Taleworlds pode resolver, se eles soubessem sobre eles!

É realmente lamentável que o carregador de travamento do jogo não funcione. Pode haver classe (s) de bugs do jogo que só nos afetam no Wine e que Taleworlds pode resolver, se eles soubessem sobre eles!

Não suponha que haja uma maneira conveniente de depurar? :língua para fora olhos fechados:

Percebi algo estranho, toda vez que fecho o jogo, ou ele trava, se vou iniciá-lo novamente, preciso reiniciar também o Steam, caso contrário nada acontece.

OK, então o que fiz até agora com um novo prefixo é:

• vcrun2019
• o extra do dotnet core depende
• dotnet48

Executando debian busters 18.3 mesa Joguei por cerca de uma hora antes de enfrentar bandidos de montanha. Por outro lado, o jogo foi muito bom e muito agradável. Livrou-se completamente dos tempos de espera para salvar, o que eu acho que estou bem. Só preciso adquirir o hábito de economizar com mais frequência, para garantir.

Estou bem com esta configuração por agora!

Estou jogando há 3 horas e "apenas" teve 3 travamentos, usando a mesma configuração que @jake-hedges acabou de escrever. Dotnet core + 1.0.6 parece ter resolvido a maioria dos problemas.
Caiu uma vez depois de ganhar um torneio e duas vezes seguidas ao verificar a mesma página da enciclopédia. Na segunda vez em que ganhei o torneio, ele não travou e a enciclopédia não travou o jogo quando tentei acessá-la em um lugar e tempo diferentes no jogo.

Estou muito feliz com a configuração. Ainda não houve nenhuma queda de FPS de longa duração

Também estou funcionando bem, embora ainda tenha algumas pequenas travas de vez em quando. Tenho certeza de que é apenas porque faço coisas bobas como habilitar a compactação transparente em minhas unidades e reproduzir um disco rígido em vez de um SSD.

Estarei por aqui ou pelos fóruns se algo começar a quebrar ... Até então, boa colheita!

A execução de protontricks 261550 dotnet472, que instalou .NET 4.0, 4.5, 4.6, 4.6.1, 4.6.2 e 4.7.2, reduziu o tempo de salvamento para alguns segundos, mas também não parece melhorar a estabilidade de forma alguma.

@ptkato Tente instalar o dotnet Core (consulte https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-609959973 e https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-610022040 para maneiras de faça isso).

Além disso, verifique se seu prefixo não foi definido como WinXP ou Win7, pois ambos têm problemas conhecidos. Eu recomendo o Windows 10 para o prefixo.

Depois de seguir a solução alternativa atual (Proton 5.5-GE https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.5-GE-1 + protontricks 261550 dotnet472 , prefixo definido para Windows 10) o o jogo funciona sem problemas, mesmo em grandes tamanhos de batalha (400+).

No entanto, sempre que entro em um cerco, o jogo gagueja e congela como um louco. Alguém mais tendo isso? (Você pode testar cercos rapidamente em Custom Battle e alterar o tipo de batalha). Instalar o dotnet core não ajudou.

@dufuspaelli Eu tive o mesmo problema com a gagueira. Para mim foi relacionado ao afogamento térmico da GPU, ao baixar a tampa do quadro eu obtive uma suavidade muito melhor. (Pode ou não ser o mesmo para você).

Qualquer ajuda para travar no início com nada, mas o seguinte erro para mostrar para ele? Bem, pelo menos é o que é registrado antes de um stacktrace massivo.

  218 38705.528:0030:0031:fixme:reg:GetEnabledXStateFeatures
  219 38705.531:0030:0031:trace:loaddll:load_native_dll Loaded L"C:\\windows\\Microsoft.NET\\Framework64\\v4.0.30319\\clrjit.dll" at 0x1a7e0000: native
  220 38705.532:0030:0031:fixme:ntdll:EtwEventRegister ({319dc449-ada5-50f7-428e-957db6791668}, 0x1a8c2bc0, 0x1a8eb8a0, 0x1a8eb8c0) stub.
  221 38705.532:0030:0031:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x1a8d7e91, 28) stub
  222 38705.535:0030:0031:fixme:path:parse_url failed to parse L"TaleWorlds.Library"
  223 38705.537:0030:0031:fixme:path:parse_url failed to parse L"netstandard"
  224 38705.540:0030:0031:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\bcrypt.dll" at 0x7f0bfdf90000: builtin
  225 38705.542:0030:0031:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\crypt32.dll" at 0x7f0bfde90000: builtin
  226 38705.542:0030:0031:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\rsaenh.dll" at 0x66500000: PE builtin
  227 38705.556:0030:0031:fixme:path:parse_url failed to parse L"System.Core"
  228 38705.566:0030:0031:fixme:path:parse_url failed to parse L"TaleWorlds.TwoDimension.Standalone"
  229 38705.567:0030:0031:fixme:path:parse_url failed to parse L"ManagedStarter"

Executando proton-5.5-GE-1 com protontricks 261550 dotnet472 e win10.

Depois de seguir a solução alternativa atual (Proton 5.5-GE https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.5-GE-1 + protontricks 261550 dotnet472 , prefixo definido para Windows 10) o o jogo funciona sem problemas, mesmo em grandes tamanhos de batalha (400+).

No entanto, sempre que entro em um cerco, o jogo gagueja e congela como um louco. Alguém mais tendo isso? (Você pode testar cercos rapidamente em Custom Battle e alterar o tipo de batalha). Instalar o dotnet core não ajudou.

Ok, depois de experimentar diferentes configurações gráficas, descobri.

Isso pode ser útil para pessoas que executam em configurações altas e encontram lag / gagueira em grandes batalhas: Reduza sua configuração Texture Streaming Budget nas configurações do jogo.

No meu RTX 2060, um grande Castle Siege (mais de 400 unidades) consome cerca de 4,7 GB de VRAM quando o Texture Streaming Budget está definido como baixo. Então, basicamente, ir para um orçamento de streaming mais alto consome todo o meu VRAM e, portanto, resulta em enormes falhas. Não tenho certeza se isso é um bug ou comportamento esperado desta configuração.

@Evilbits Meu instinto diz que talvez algo tenha sido corrompido, você se importaria de compartilhar o registro completo?

Além disso, você pode não estar usando a versão mais recente do jogo. Vi ManagedStarter lá, que acredito ter sido removido em uma das atualizações mais recentes.

@dufuspaelli acredito que seja esse o comportamento pretendido. Basicamente, o Texture Streaming Budget informa ao jogo quanto vram deve ser economizado para colocar todas as texturas em todas as coisas, então, se você definir muito alto, ficará sem vram para coisas como mostrar animações e, assim, ficará gaguejando enquanto essas coisas tentam render.

Então, por algum milagre, o relator de falha começou a trabalhar para mim (com dotnet472 e aquele download do .NET Core):

Não tenho certeza se ele realmente enviou o relatório com sucesso, ou se a TaleWorlds seria capaz de fazer algo útil com ele mesmo que o fizesse (exceto se realmente nos apoiassem ativamente senhores da manteiga que usam prótons, o que seria uma surpresa, mas bem-vinda), mas hey, não custa nada experimentar, certo?

Enfim, pelo menos uma fonte de instabilidade contínua para mim (e o que levou a essa descoberta incidental) parece ser um System.AccessViolationException que destrói System.Text.RegularExpressions.RegexRunner.Scan ao tentar mostrar / atualizar a placa de identificação de uma festa (I estou assumindo, com base no nome do método SandBox.ViewModelCollection.Nameplate.PartyNameplateVM.RefreshDynamicProperties ). Normalmente, eu escreveria isso como "bem, alguma outra coisa está provavelmente destruindo a memória e esta função estava no lugar errado na hora errada", mas esta é a segunda vez que esse método exato disparou essa exceção de acesso à memória, que é, portanto, um pouco suspeito.

Ainda não tenho certeza de quais serão as próximas etapas para solucionar isso (além de jogar +heap no meu WINEDEBUG , o que parece ser doloroso em termos de desempenho).

De qualquer forma,
aqui está steam-261550.log , rgl_log_42.txt e rgl_log_errors_42.txt , para o bem da posteridade.

@Yarwin

Percebi que você editou o principal comentário inicial para recomendar a instalação de algum build aleatório do Proton para "contornar" esse problema, mas não acho que seja uma boa ideia recomendar builds aleatórios do Proton de pessoas aleatórias na internet, sem entrar em um grande debate sobre os (des) méritos de rodar binários de pessoas aleatórias (por exemplo, o wine tem acesso ao sistema de arquivos para todo o seu diretório pessoal, por exemplo). Provavelmente também não será útil para a Valve se a 'solução alternativa' for executar alguma coisa bifurcada do Proton com um grande número de alterações.

A solução atual para problemas de entrada é construir o Proton a partir desse repositório com o patch de teste de vinho upstream aplicado.

@YellowApple , tentando recriar sua queda, mas não tenho nada até agora ... Quando você diz placa de identificação, está se referindo à placa do mapa mundial com o nome do exército e informações da tropa?

Ver ele passar por todas as coisas de localização antes de chegar a Sandbox.ViewModelCollection.Nameplate.PartyNameplateVM.RefreshDynamicProperties me lembrou deste tópico . É uma chance remota, mas você pode tentar remover os dados de localização em chinês conforme descrito lá.

@craftyguy , pelo que vale a pena, GloriousEggroll é um contribuidor tanto para wine-staging quanto para lutris. Eu pessoalmente não considero isso uma "pessoa aleatória da Internet", mas entendo o que você quer dizer. Talvez um aviso de isenção seja mais apropriado com informações adicionais para aqueles que se sentiriam melhor construindo seus próprios.

Finalmente, @Yarwin , uma vez que o OP foi mencionado, você pode considerar adicionar o novo material .net Core, pois parece reduzir travamentos e agora temos um relatório do relator de travamento trabalhando depois de instalado!

@Yarwin

Percebi que você editou o principal comentário inicial para recomendar a instalação de algum build aleatório do Proton para "contornar" esse problema, mas não acho que seja uma boa ideia recomendar builds aleatórios do Proton de pessoas aleatórias na internet, sem entrar em um grande debate sobre os (des) méritos de rodar binários de pessoas aleatórias (por exemplo, o wine tem acesso ao sistema de arquivos para todo o seu diretório pessoal, por exemplo). Provavelmente também não será útil para a Valve se a 'solução alternativa' for executar alguma coisa bifurcada do Proton com um grande número de alterações.

A solução atual para problemas de entrada é construir o Proton a partir desse repositório com o patch de teste de vinho upstream aplicado.

GloriousEggroll não é "aleatório" mais do que o próprio Proton é aleatório, ou Mozilla Firefox, ou qualquer software de código aberto na Internet que é fornecido gratuitamente sem garantia ou indenização.

Gastar 15 minutos lendo as diferenças de commit do repositório do GloriousEggroll mostra muito claramente que ele está fazendo um ótimo trabalho para fornecer as últimas correções e recursos de uma construção do Proton incorporando o código de desenvolvimento do Wine mais recente e muitas correções específicas do jogo que ainda não chegaram ao Vinho. Ele não é um chapéu preto "aleatório" que fornece binários apenas com a intenção de minerar seus dados ou executar um rootkit em seu sistema. Ele trabalha muito para manter uma bifurcação de Proton muito boa.

A maioria dos jogadores de Linux honestamente não tem habilidade técnica ou paciência para construir todo o seu software a partir do código fonte. E mesmo se você fizer isso, a menos que também esteja auditando esse código, não é _realmente_ melhor do que baixar binários. Se você for realmente paranóico, deve jogar em um sistema isolado que não possui dados pessoais e nenhum acesso a quaisquer recursos de rede privilegiados ou uma VM configurada de forma semelhante. Sabe-se que os próprios jogos de código fechado carregam uma quantidade assustadora de dados sobre seus usuários para o desenvolvedor do jogo, e rodá-los sob o Wine provavelmente não mudará isso.

No geral, acho que você está exagerando grosseiramente sobre considerar a GE não confiável ou "aleatória". Se você está seriamente paranóico, você deve apenas rodar software verdadeiramente livre e de código aberto (que por definição exclui M&B II: Bannerlord!), O qual você auditou manualmente cada linha de código-fonte. Ah, e também não execute um BIOS proprietário - isso significa que você precisa comprar uma CPU e uma placa-mãe com microcódigo aberto.

Quanto à Valve, eles não parecem estar muito envolvidos no trabalho com a comunidade de usuários do Proton para ajudar a melhorar o Proton. Só posso assumir que a posição deles é (a) não nos importamos com o Proton em geral, ou (b) só nos preocupamos com questões que _nós_ nos importamos, não com as queixas de nossos usuários. Eu não vi nenhum funcionário da Valve participando deste relatório de bug, você viu?

A Valve provavelmente está satisfeita em permitir que a comunidade em torno deste jogo muito popular encontre soluções para Bannerlord e faça o upstream no _Wine_. Honestamente, isso dá menos trabalho para eles, então faz sentido. A menos que haja algo específico para o que o _Proton_ faz que não possa ser corrigido no _Wine_, eles quase definitivamente irão ignorar este relatório de problema e esperar que o Wine conserte o problema.

A construção Proton-GE é a maneira mais conveniente de jogar Bannerlord hoje para jogadores de Linux não muito técnicos. Para aqueles que não confiam na construção, mas não têm as habilidades para compilar a partir do código-fonte, podem esperar até que a Valve atualize a versão estável do SteamPlay do cliente Steam oficial com uma versão do Wine que contém as correções do Bannerlord. Com base na experiência anterior, isso pode levar de várias semanas a vários meses.

GloriousEggroll não é "aleatório" mais do que o próprio Proton é aleatório, ou Mozilla Firefox, ou qualquer software de código aberto na Internet que é fornecido gratuitamente sem garantia ou indenização.

Mozilla e Valve são muito mais confiáveis ​​do que alguns indivíduos que fornecem binários na Internet. As primeiras são empresas responsáveis, as últimas não.

E, novamente, quase certamente ajuda menos a Valve se os dados que eles têm para este jogo estiverem usando algum fork de Proton que não está nem perto do que eles estão liberando. Porque não vamos nos enganar, o objetivo desse problema neste repositório é promover o objetivo de fazer este jogo funcionar com o lançamento de Proton da Valve, e não com eggroll ou qualquer outro fork do Proton. E este não é um fórum geral de suporte para jogos (há um no site da Taleworld).

Para mim (Fedora 32 KDE Beta), os .exes ainda precisam ser renomeados. Não é possível entrar no jogo apenas com a solução alternativa atual (5.5-GE-1 + protontricks 261550 dotnet472).
Portanto, renomeando Mount & Blade II Bannerlord / bin / Win64_Shipping_Client /
Bannerlord.exe
para
TaleWorlds.MountAndBlade.Launcher.exe

@craftyguy Ele é literalmente um contribuidor de preparação de vinhos. Você argumentando de uma posição de ignorância. E este também não é o seu blog.

GloriousEggroll não é "aleatório" mais do que o próprio Proton é aleatório, ou Mozilla Firefox, ou qualquer software de código aberto na Internet que é fornecido gratuitamente sem garantia ou indenização.

Mozilla e Valve são muito mais confiáveis ​​do que alguns indivíduos que fornecem binários na Internet. As primeiras são empresas responsáveis, as últimas não.

E, novamente, é quase certo que ajudará a Valve _less_ se os dados que eles têm para este jogo estiverem usando algum fork do Proton que não está nem perto do que eles estão lançando. Porque não vamos nos enganar, o objetivo desse problema neste repositório é promover o objetivo de fazer este jogo funcionar com o lançamento de Proton da Valve, e não com eggroll ou qualquer outro fork do Proton. E este não é um fórum geral de suporte para jogos (há um no site da Taleworld).

Existem forks de Proton especificamente porque obter contribuições aceitas para esses projetos upstream (Proton e Wine) é historicamente difícil e um processo muito lento e trabalhoso.

• A Valve não responde à comunidade. Quando novos títulos importantes são lançados, eles não fazem nenhum esforço para se envolver com a comunidade, para anunciar "estamos trabalhando nisso" ou "nos ajude e iremos incorporar suas correções ao Proton" ou qualquer coisa do tipo. O Proton é basicamente executado como um repositório comercial de código aberto do GitHub "torre de marfim". As solicitações pull permanecem por meses ou anos com pouco ou nenhum feedback.
• A Valve (e freqüentemente, o Wine upstream) às vezes rejeita contribuições práticas e úteis e, em vez disso, insiste em uma solução "perfeita" que é muito mais difícil de desenvolver. Ao tentar colocar um jogo ou software em execução, geralmente é fácil fazer uma "solução rápida" que resolve o problema imediato. Você pode até mesmo definir o escopo dessa correção para um nome de processo específico para evitar que afete outro software. Mas os upstreams com os quais estamos lidando - Valve / Proton e Wine - muitas vezes relutam em aceitar essas contribuições, ao invés disso, insistem que o código subjacente seja completamente redesenhado ou retrabalhado com perfeição antes que uma contribuição possa ser aceita. Essas refatorações principais geralmente estão fora do conjunto de habilidades das pessoas que podem contribuir com soluções rápidas; mesmo que estejam dentro de suas habilidades, pode levar meses ou anos para concluir essas mudanças importantes. Enquanto isso, não teríamos compatibilidade com o software / jogo quebrado sem uma solução rápida. É por isso que compilações de correção para Proton (e Wine antes dele) são tão populares e úteis.
• As empresas que trabalham neste software às vezes são bastante hipócritas quanto às soluções alternativas. Uma das principais empresas envolvidas no Wine / Proton é Codeweavers. Eles distribuem uma distribuição comercial paga do Wine chamada CrossOver Linux (e CrossOver Mac também). Embora estes sejam fortemente baseados no Wine upstream, não é incomum para eles implementar hacks, soluções alternativas e outras medidas "práticas" para corrigir um título principal ou parte importante do software (na maioria das vezes Microsoft Office) em seu produto comercial, sem fundir a mesma solução alternativa para o código-fonte aberto upstream. Portanto, as soluções alternativas são adequadas se fizerem com que o produto tenha uma aparência melhor, mas não serão adequadas se outras pessoas estiverem contribuindo com as soluções alternativas.
• O upstreaming já está acontecendo! Há uma postagem anterior neste tópico com evidência direta de que a correção do cursor do mouse para Bannerlord foi aceita pelo wine-staging, que é o upstream do Proton. A única coisa que impede que o patch seja puxado para uma versão estável do Proton é o tempo. Muito e muito tempo - semanas ou meses, provavelmente. Portanto, não há trabalho real a ser feito para que essas coisas sejam implementadas agora. Meus pontos anteriores sobre a dificuldade de colocar as coisas no upstream referem-se principalmente a outros jogos e outros tipos de soluções alternativas que não são tão claras como este. O fork do Proton da GE contém muitas soluções práticas para jogos que podem demorar meses, ou nunca, a chegar ao wine upstream.

@YellowApple , recebo essa exceção se usar o back-end do compilador de sombreador ACO para mesa,
desde que mudei de volta para o llvm, os travamentos têm sido menos frequentes e, em vez desta exceção, o jogo apenas congela (tenho sido muito preguiçoso até agora para registrar o que está acontecendo lá, mas farei isso nos próximos dias).

Software usado:
mais recente próton-ge
dotnet472
mesa git (llvm 9)
linux-zen 5.6.2

Hardware usado:
Vega 56
3700X

Atualizar:
Eu estava errado ao mudar para llvm apenas parecia melhor.

Estou seguindo a solução alternativa atual de: Proton 5.5-GE + protontricks 261550 dotnet472, garantindo que defini o Win 10 como o sistema operacional.

Estou encontrando uma falha a cada poucos minutos, com aproximadamente os mesmos módulos carregados. Não consigo entender o log totalmente, esperando que alguém o faça.
backtrace.txt

1060Ti 6GB (driver nvidia 440) com CPU Ryzen 1800x

Bom trabalho a todos na solução deste problema e torná-lo jogável para as massas!

@Demannu Tente instalar o dotnet Core se não tiver. Fiz um novo prefixo ontem e passei de travamento a cada poucos minutos para a cada 1-2 horas. Ele travou duas vezes seguidas quando comecei o jogo esta manhã, mas funcionou na terceira tentativa.

Como instalar: Terminal Protontricks /

Certifique-se também de que seu prefixo esteja definido como Windows 10 e não WinXP, para o qual, aparentemente, um dos scripts dotnet muda.

As únicas coisas que fiz com meu novo prefixo foi;

• Use Proton 5.5-GE-1
• Instale dotnet48
• Instalar vcrun2019
• Instale o dotnet Core manualmente
• Verifique se o prefixo está definido para Windows 10

Usei protontricks --gui para instalar tudo e definir o prefixo para Win10.

Editar: Se você estiver usando mods, certifique-se de verificar se há atualizações todos os dias também e tente desativá-los se você estiver travando. Após o lançamento do 1.0.6, meu jogo começou a travar na arena, mas descobri que eram os mods da arena que eu estava usando

Então, como uma atualização:

Com um novo prefixo, configure nesta ordem:

• Inicie o Bannerlord uma vez com Proton-5.5-GE-1 definido como camada compatível no vapor
• protontricks 261550 vcrun2019
• Instale o dotnet core através do método GUI e faça o download neste tópico
• protontricks 261550 dotnet48

Eu ainda pareço ter os seguintes problemas:

• O mouse ainda parece não funcionar, talvez 70% do tempo. Tenho que reiniciar várias vezes até que funcione. Este não é o caso do meu laptop, apenas meu desktop.
• dotnet472 e dotnet48 não parecem estar resolvendo o problema de salvar travamento. Ainda parece que estou levando mais de 90 segundos para salvar. Como foi determinado se era .NET? O que devo pesquisar para ver por que isso ainda não está funcionando?

Em um tópico diferente, alguém começou a mexer no lado multiplayer do jogo? Sei que o Battleye será difícil, mas há relatos de jogos do Battleye funcionando no Linux.

O erro atual é algo como:
Erro 31: erro de driver

Em um tópico diferente, alguém começou a mexer no lado multiplayer do jogo? Sei que o Battleye será difícil, mas há relatos de jogos do Battleye funcionando no Linux.

O erro atual é algo como:
Erro 31: erro de driver

BattleEye hoje em dia instala um driver de kernel e serviço para anticheat. Ambos não são possíveis com vinho, na verdade.

Em um tópico diferente, alguém começou a mexer no lado multiplayer do jogo? Sei que o Battleye será difícil, mas há relatos de jogos do Battleye funcionando no Linux.

O erro atual é algo como:
Erro 31: erro de driver

Multiplayer sempre funcionou perfeitamente para mim, matchmaking e servidores personalizados. Acabei de cancelar a instalação do BattleEye quando solicitado.

Em um tópico diferente, alguém começou a mexer no lado multiplayer do jogo? Sei que o Battleye será difícil, mas há relatos de jogos do Battleye funcionando no Linux.
O erro atual é algo como:
Erro 31: erro de driver

Multiplayer sempre funcionou perfeitamente para mim, matchmaking e servidores personalizados. Acabei de cancelar a instalação do BattleEye quando solicitado.

Uau, você está certo, eu nem tinha tentado o multiplayer devido ao BattleEye mencionado anteriormente, mas sim, tem funcionado bem para mim também após cancelar a instalação no início. Eles devem ter desativado por agora, e tenho certeza de que deixará de funcionar em algum momento no futuro, mas por enquanto tudo parece estar funcionando.

Com relação ao singleplayer, minha configuração atual envolve o uso de dotnet48, vcrun2019 e instalação do exe dotnet core, juntamente com a configuração do prefixo para Windows 10. Ainda estou tendo travamentos a cada hora ou mais, e às vezes com mais frequência, especialmente logo após carregar um Salve . Também tenho recebido o mesmo erro de @YellowApple envolvendo um System.AccessViolationException com a placa de identificação do partido.

Finalmente, @Yarwin , uma vez que o OP foi mencionado, você pode considerar adicionar o novo material .net Core, pois parece reduzir travamentos e agora temos um relatório do relator de travamento trabalhando depois de instalado!

Obrigado pela sua contribuição - adicionarei o núcleo .net ao mini-guia de solução alternativa.
Lista de requisitos, se alguém estiver curioso: https://forums.taleworlds.com/index.php?threads/installing -missing-needed-dependencies.407126 / (vcruns são instalados por padrão pelo Steam e parece que funcionam bem )

Em um tópico diferente, alguém começou a mexer no lado multiplayer do jogo? Sei que o Battleye será difícil, mas há relatos de jogos do Battleye funcionando no Linux.
O erro atual é algo como:
Erro 31: erro de driver

Multiplayer sempre funcionou perfeitamente para mim, matchmaking e servidores personalizados. Acabei de cancelar a instalação do BattleEye quando solicitado.

Eu não tinha ideia de que estava funcionando. Isso é hilário.

Provavelmente a única pessoa tentando rodar no CentOS 8, mas ... não importa o que eu faça, não consigo passar pela tela de carregamento inicial na inicialização, ela não congela, mas a tela de carregamento nunca termina.

A compilação atual é Proton-5.5-GE-1 com dot472 (também tentado dot48) em win10.

Vejo pessoas sugerindo vcrun2019, não consigo instalá-lo, só vejo até vcrun2017 como uma opção para mim.

Alguma sugestão?

Provavelmente a única pessoa tentando rodar no CentOS 8, mas ... não importa o que eu faça, não consigo passar pela tela de carregamento inicial na inicialização, ela não congela, mas a tela de carregamento nunca termina.

A compilação atual é Proton-5.5-GE-1 com dot472 (também tentado dot48) em win10.

Vejo pessoas sugerindo vcrun2019, não consigo instalá-lo, só vejo até vcrun2017 como uma opção para mim.

Alguma sugestão?

Definitivamente será algo em seu sistema então. Estou executando exatamente a mesma configuração, literalmente sem problemas. A única vez que uso o CentOS é no trabalho. Tenho certeza de que pode ser feito, mas não consigo imaginar jogar nele.

Arch Linux ou Manjaro parecem ser o caminho a percorrer para os jogos Proton.

Provavelmente a única pessoa tentando rodar no CentOS 8, mas ... não importa o que eu faça, não consigo passar pela tela de carregamento inicial na inicialização, ela não congela, mas a tela de carregamento nunca termina.
A compilação atual é Proton-5.5-GE-1 com dot472 (também tentado dot48) em win10.
Vejo pessoas sugerindo vcrun2019, não consigo instalá-lo, só vejo até vcrun2017 como uma opção para mim.
Alguma sugestão?

Definitivamente será algo em seu sistema então. Estou executando exatamente a mesma configuração, literalmente sem problemas. A única vez que uso o CentOS é no trabalho. Tenho certeza de que pode ser feito, mas não consigo imaginar jogar nele.

Arch Linux ou Manjaro parecem ser o caminho a percorrer para os jogos Proton.

Achei que seria o caso. Acho que é hora de aprender pacman ...

Então, só para confirmar o comportamento.

Se o jogo travar, preciso encerrar manualmente seu processo no gerenciador de tarefas. No entanto, se eu tentar iniciá-lo novamente no Steam, nada acontece. Ele só será iniciado novamente se eu reiniciar o Steam por completo.

Então, só para confirmar o comportamento.

Se o jogo travar, preciso encerrar manualmente seu processo no gerenciador de tarefas. No entanto, se eu tentar iniciá-lo novamente no Steam, nada acontece. Ele só será iniciado novamente se eu reiniciar o Steam por completo.

Isso estava acontecendo comigo também durante os meus testes

Ele só será iniciado novamente se eu reiniciar o Steam por completo.

Isso parece um pouco estranho. Depois de encerrar o processo, o wineerver ainda está em execução ou acaba sozinho?

Então, só para confirmar o comportamento.

Se o jogo travar, preciso encerrar manualmente seu processo no gerenciador de tarefas. No entanto, se eu tentar iniciá-lo novamente no Steam, nada acontece. Ele só será iniciado novamente se eu reiniciar o Steam por completo.

Eu descobri que frequentemente há um explorer.exe (entre outras coisas) em execução (especialmente se aparecer com uma caixa de diálogo de erro do Wine). Matar isso geralmente é o suficiente para limpar todo o resto (eu geralmente mantenho htop executando com um filtro .exe especificamente para pegá-los caso permaneçam por perto).

Você também precisará matar quaisquer processos wineserver remanescentes.

Apenas tentei adicionar o .NET core de que precisamos para winetricks . Esperamos que seja aceito e possamos simplificar nossa solução alternativa para protontricks dotnet472 e protontricks dotnetcore2

Provavelmente a única pessoa tentando rodar no CentOS 8, mas ... não importa o que eu faça, não consigo passar pela tela de carregamento inicial na inicialização, ela não congela, mas a tela de carregamento nunca termina.
A compilação atual é Proton-5.5-GE-1 com dot472 (também tentado dot48) em win10.
Vejo pessoas sugerindo vcrun2019, não consigo instalá-lo, só vejo até vcrun2017 como uma opção para mim.
Alguma sugestão?

Definitivamente será algo em seu sistema então. Estou executando exatamente a mesma configuração, literalmente sem problemas. A única vez que uso o CentOS é no trabalho. Tenho certeza de que pode ser feito, mas não consigo imaginar jogar nele.
Arch Linux ou Manjaro parecem ser o caminho a percorrer para os jogos Proton.

Achei que seria o caso. Acho que é hora de aprender pacman ...

Ou apenas role para cima neste tópico gigante (eu sei; é muita leitura) e veja onde as pessoas mencionaram a correção para "não é possível encontrar vc2019 em winetricks / protontricks" várias vezes.

GloriousEggroll não é "aleatório" mais do que o próprio Proton é aleatório, ou Mozilla Firefox, ou qualquer software de código aberto na Internet que é fornecido gratuitamente sem garantia ou indenização.

Mozilla e Valve são muito mais confiáveis ​​do que alguns indivíduos que fornecem binários na Internet. As primeiras são empresas responsáveis, as últimas não.
E, novamente, é quase certo que ajudará a Valve _less_ se os dados que eles têm para este jogo estiverem usando algum fork do Proton que não está nem perto do que eles estão lançando. Porque não vamos nos enganar, o objetivo desse problema neste repositório é promover o objetivo de fazer este jogo funcionar com o lançamento de Proton da Valve, e não com eggroll ou qualquer outro fork do Proton. E este não é um fórum geral de suporte para jogos (há um no site da Taleworld).

Existem forks de Proton especificamente porque obter contribuições aceitas para esses projetos upstream (Proton e Wine) é historicamente difícil e um processo muito lento e trabalhoso.

* **Valve isn't responsive to the community.** When major new titles come out, they make no effort to engage with the community, to announce "we're working on it" or "help us out and we'll incorporate your fixes into Proton" or anything of the sort. Proton is very much run as an "ivory tower" commercial open source GitHub repository. Pull requests sit for months or years with little or no feedback.

* **Valve (and often, upstream Wine) sometimes decline practical, useful contributions and instead insist on a "perfect" solution that is much more difficult to develop.** When trying to get a game or a piece of software running, it's often easy to make a "quick fix" that solves the immediate problem. You can even scope this fix to a specific process name to prevent it from affecting other software. But the upstreams we're dealing with -- Valve/Proton and Wine -- are often reluctant to accept these contributions, instead insisting that the underlying code be completely redesigned or reworked to perfection before a contribution can be accepted. These major refactorings are often out of the skillset of the people who can contribute quick fixes; even if they are within their abilities, it can take months or years to complete such major changes. In the meantime, we'd have no compatibility with the broken software/game without a quick fix. **This is why fix builds to Proton (and Wine before it) are so popular and useful.**

* **The companies that work on this software are sometimes pretty hypocritical about workarounds.** One of the major companies involved in Wine/Proton is Codeweavers. They distribute a paid, commercial distribution of Wine called CrossOver Linux (and CrossOver Mac, too). While these are heavily based on upstream Wine, it's not uncommon for them to implement hacks, workarounds and other such "practical" measures to fix a major title or major piece of software (most often Microsoft Office) in their commercial product, while not merging the same workaround to the upstream, open source code. So workarounds are fine if it makes their product look better, but not fine if others are contributing the workarounds.

* **The upstreaming is already happening!** There is an earlier post in this thread with direct evidence that the mouse cursor fix for Bannerlord has been accepted by wine-staging, which is Proton's upstream. The only thing preventing that patch from getting pulled into a stable release of Proton, is time. Lots and lots of time -- weeks or months, probably. So there is no real work left to be done to get this stuff upstreamed now. My earlier points about the difficulty of getting stuff upstream are mostly pertaining to other games and other types of workarounds that aren't as clear-cut as this one was. GE's fork of Proton contains many practical fixes for games that may not hit wine upstream for months, if ever.

Eu concordo com a maior parte disso, mas acho que as soluções alternativas "hacky" e aquelas com escopo específico para o nome do processo devem ser minimizadas o máximo possível nos repositórios principais. Tudo está bem do jeito que está agora, com a comunidade fornecendo correções para os últimos lançamentos, enquanto o upstream contém apenas commits que levam o quadro mais amplo em consideração. Não acho que nenhum dos projetos ou seus mantenedores devam ser responsabilizados por não incluir tais soluções alternativas, pois isso acabará levando a enormes dívidas técnicas. A correção do cursor do mouse para este jogo já está upstream no wine-staging, então não é como se eles estivessem ignorando correções 'não hacky'

Proton 5.5 GE não funciona com minha configuração. Bate nele instantaneamente na batalha ou após 2 minutos no mapa.

Estou seguindo a solução alternativa atual de: Proton 5.5-GE + protontricks 261550 dotnet472, garantindo que defini o Win 10 como o sistema operacional.

Estou encontrando uma falha a cada poucos minutos, com aproximadamente os mesmos módulos carregados. Não consigo entender o log totalmente, esperando que alguém o faça.
backtrace.txt

1060Ti 6GB (driver nvidia 440) com CPU Ryzen 1800x

Bom trabalho a todos na solução deste problema e torná-lo jogável para as massas!

Eu estava tendo esses travamentos aleatórios em um sistema que funcionava de outra forma e finalmente descobri, 99%, certo de que era o salvamento automático com versão errada. Por exemplo, atualizar um salvamento de 1.0.6 para 1.0.7 travaria em 1-15 minutos sem que eu fizesse nada de especial. Excluir o salvamento automático (1.0.6) corrigiu isso. Eu tentei isso com alterações de versões anteriores também. Isso eliminou 90% das minhas falhas. Espero que ajude alguém aqui.

Estou seguindo a solução alternativa atual de: Proton 5.5-GE + protontricks 261550 dotnet472, garantindo que defini o Win 10 como o sistema operacional.
Estou encontrando uma falha a cada poucos minutos, com aproximadamente os mesmos módulos carregados. Não consigo entender o log totalmente, esperando que alguém o faça.
backtrace.txt
1060Ti 6GB (driver nvidia 440) com CPU Ryzen 1800x
Bom trabalho a todos na solução deste problema e torná-lo jogável para as massas!

Eu estava tendo esses travamentos aleatórios em um sistema que funcionava de outra forma e finalmente descobri, 99%, certo de que era o salvamento automático com versão errada. Por exemplo, atualizar um salvamento de 1.0.6 para 1.0.7 travaria em 1-15 minutos sem que eu fizesse nada de especial. Excluir o salvamento automático (1.0.6) corrigiu isso. Eu tentei isso com alterações de versões anteriores também. Isso eliminou 90% das minhas falhas. Espero que ajude alguém aqui.

Vou fazer um teste, tenho mantido minhas defesas por perto, então vou eliminá-las e tentar novamente. Obrigado!

Eu uso proton-5.5-GE-1, tenho dotnet472, vcrun2019 e dotnetcore2 instalados. Quando eu inicio o jogo, ele parece estar funcionando bem. No entanto, recebo falhas aleatórias e quando, após algumas falhas, não consigo reiniciar o jogo. Se isso acontecer, abrir protontricks 261550 dá o seguinte erro:
/home/krulvis/.cache/protontricks/proton/Proton-5.5-GE-1/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""
Alguém teve experiências semelhantes ou possivelmente sabe o que está acontecendo?

Notei um padrão, se eu apenas resolver automaticamente as batalhas com o botão "Enviar tropas!" opção, o jogo trava com muito mais frequência em comparação com apenas ir para o campo e lutar manualmente.

@Krulvis Tenho exatamente o mesmo problema às vezes ... Reiniciar o sistema sempre resolve isso para mim. Dito isso, eu não experimentei isso recentemente. Provavelmente tem algo a ver com processos prolongados.

Eu uso proton-5.5-GE-1, tenho dotnet472, vcrun2019 e dotnetcore2 instalados. Quando eu inicio o jogo, ele parece estar funcionando bem. No entanto, recebo falhas aleatórias e quando, após algumas falhas, não consigo reiniciar o jogo. Se isso acontecer, abrir protontricks 261550 dá o seguinte erro:
/home/krulvis/.cache/protontricks/proton/Proton-5.5-GE-1/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""
Alguém teve experiências semelhantes ou possivelmente sabe o que está acontecendo?

Sim, eu tinha isso. Usei a construção original do próton fornecida por @YellowApple e

https://forums.taleworlds.com/index.php?threads/known -issues-will-be-updated-soon.401168 /

Alguns de nossos jogadores podem perceber que o jogo não inicia de forma alguma, travando após o inicializador e travando após a tela de carregamento. Estamos investigando esse problema. É crucial se você usar o uploader de travamento após todos os travamentos. Você pode tentar uma possível solução alternativa para esse problema aqui. Observe que estamos trabalhando muito para corrigir esse problema de não lançamento!

https://forums.taleworlds.com/index.php?threads/possible -workaround-for-game-not-launching-issue.407128

O jogo que não inicia também é um problema do Windows.

Provavelmente a única pessoa tentando rodar no CentOS 8, mas ... não importa o que eu faça, não consigo passar pela tela de carregamento inicial na inicialização, ela não congela, mas a tela de carregamento nunca termina.
A compilação atual é Proton-5.5-GE-1 com dot472 (também tentado dot48) em win10.
Vejo pessoas sugerindo vcrun2019, não consigo instalá-lo, só vejo até vcrun2017 como uma opção para mim.
Alguma sugestão?

Definitivamente será algo em seu sistema então. Estou executando exatamente a mesma configuração, literalmente sem problemas. A única vez que uso o CentOS é no trabalho. Tenho certeza de que pode ser feito, mas não consigo imaginar jogar nele.
Arch Linux ou Manjaro parecem ser o caminho a percorrer para os jogos Proton.

Achei que seria o caso. Acho que é hora de aprender pacman ...

Ou apenas role para cima neste tópico gigante (eu sei; é muita leitura) e veja onde as pessoas mencionaram a correção para "não é possível encontrar vc2019 em winetricks / protontricks" várias vezes.

Eu sou novo no github, então quando eu executei originalmente um ctrl-f "vcrun2019" não vi nada.

Obrigado por colocar seu nome em seu perfil para que eu saiba que devo evitá-lo em um ambiente profissional.

Provavelmente a única pessoa tentando rodar no CentOS 8, mas ... não importa o que eu faça, não consigo passar pela tela de carregamento inicial na inicialização, ela não congela, mas a tela de carregamento nunca termina.
A compilação atual é Proton-5.5-GE-1 com dot472 (também tentado dot48) em win10.
Vejo pessoas sugerindo vcrun2019, não consigo instalá-lo, só vejo até vcrun2017 como uma opção para mim.
Alguma sugestão?

Definitivamente será algo em seu sistema então. Estou executando exatamente a mesma configuração, literalmente sem problemas. A única vez que uso o CentOS é no trabalho. Tenho certeza de que pode ser feito, mas não consigo imaginar jogar nele.
Arch Linux ou Manjaro parecem ser o caminho a percorrer para os jogos Proton.

Achei que seria o caso. Acho que é hora de aprender pacman ...

Ou apenas role para cima neste tópico gigante (eu sei; é muita leitura) e veja onde as pessoas mencionaram a correção para "não é possível encontrar vc2019 em winetricks / protontricks" várias vezes.

Eu sou novo no github, então quando eu executei originalmente um ctrl-f "vcrun2019" não vi nada.

Obrigado por colocar seu nome em seu perfil para que eu saiba que devo evitá-lo em um ambiente profissional.

Hã? Eu não estava sendo sarcástico. É realmente muita leitura. Se você vai evitar alguém por tentar genuinamente ajudar, essa é sua prerrogativa, eu acho.

A razão pela qual você não o teria encontrado ao fazer um ctrl + f é por causa desta coisa escondida no meio desta página: https://i.imgur.com/nxX7Qz4.png

Eu nunca trabalhei em um problema tão grande antes, então não percebi até que realmente olhei. TIL! Desculpe por qualquer mal-entendido.

@allquixotic Com tudo isso dito, depois de uma pesquisa bem minuciosa sobre esse problema, não encontrei nada que realmente explique como instalar o vcrun2019, e estou tendo o mesmo problema ... Você se importaria de explicar? Tentei a opção --force e pesquisei.

Decidi dar uma olhada no log gerado ao usar o sinalizador PROTON_LOG e, surpreendentemente, gerou um arquivo de 274 MB com milhões de linhas, deveria ser assim? Observe que eu apaguei o log anterior antes de iniciar o jogo.

@ptkato Eu tive um arquivo de log de 8 GB uma vez porque habilitei PROTON_LOG=1 . Isso foi com e1.0.4 e próton de estoque e uma sessão _mais longa_ (cerca de 30 minutos). Aparentemente, esses arquivos de log ficam grandes rapidamente.

@allquixotic Com tudo isso dito, depois de uma pesquisa bem minuciosa sobre esse problema, não encontrei nada que realmente explique como instalar o vcrun2019, e estou tendo o mesmo problema ... Você se importaria de explicar? Tentei a opção --force e pesquisei.

Pelo que descobri, o vcrun2019 não parece fazer nada diferente, exceto instalar o vcrun2015 e o vcrun2017. Embora pessoalmente tenha tentado instalar os dois e a instalação falhou dizendo que já estava instalado ...

@ptkato Enchei completamente o meu disco rígido ontem ... Cerca de 340 GB

@allquixotic Com tudo isso dito, depois de uma pesquisa bem minuciosa sobre esse problema, não encontrei nada que realmente explique como instalar o vcrun2019, e estou tendo o mesmo problema ... Você se importaria de explicar? Tentei a opção --force e pesquisei.

vcrun2019 parece ser uma adição recente aos winetricks. Em arch é encontrado no pacote winetricks-git, mas não winetricks.

Queria dar uma atualização;
Estou correndo:

• Proton-5.5-GE-1
• protontricks 261550 dotnet472
• proton - gui solução alternativa para instalar o núcleo dotnet
• Windows 10 em winecfg
• Exclua todos os autosaves anteriores de patches anteriores do jogo

Consegui jogar uma sessão de hora e meia com apenas 1 travamento ao alterar as configurações de vídeo (fiquei ganancioso). Caso contrário, ainda não encontrei um.

Coisas testadas:

• Arena
• Raiding Village
• Batalha Siming e batalha real
• Entrou em uma batalha já em andamento
• Falei com várias pessoas
• Pausado quase a qualquer momento que eu pudesse pensar
• Tentei escapar de conversas e batalhas
• Tabulado como um maníaco durante as batalhas e após as batalhas
• Alt + Tab praticamente de qualquer ponto do jogo

Um guia atualizado pode ser encontrado aqui

Deixe-me tentar juntar tudo então ...

Agradecemos a VictorRogers , YellowApple , Metal079 , allquixotic , lboklin por suas ótimas sugestões e correções e todos os outros ajudando a fazer o Bannerlord funcionar!

Pegando tudo que você precisa

Proton-5.5-GE-1

• baixe o lançamento aqui .
  
  
  
  • há um botão "Ativos" no final de cada postagem de lançamento
  
  
• extraia o conteúdo do arquivo .tar.gz em /home/<your-name>/.steam/compatibilitytools.d/
  
  
  
  • se essa pasta não existir, crie-a
  
  
  • você agora deve ter uma subpasta nessa pasta chamada Proton-5.5-GE-1
  
  
• reinicie o Steam se já estiver em execução
• clique com o botão direito em Bannerlord e vá em "Propriedades"
  
  
  
  • na guia "Geral" na parte inferior, marque a opção "Forçar o uso de uma ferramenta de compatibilidade Steam Play específica"
  
  
  • você deve ser capaz de selecionar a opção "Proton-5.5-GE-1"
  
  
• se você não vir a opção nas propriedades, tente mover a pasta "Proton-5.5-GE-1" para o seguinte local: ~/.local/share/Steam/compatibilitytools.d (crie as pastas se elas não existirem) conforme recomendado aqui
  
  
  
  • reinicie o Steam e verifique se a opção existe agora
  
  

protontricks

• infelizmente, parece não haver outra maneira "fácil" de obter protontricks além do método de instalação pipx
• as instruções de instalação podem ser encontradas aqui
• de acordo com esta postagem , os usuários do Arch podem ter outra alternativa usando pamac install protontricks-git

núcleo dotNet

• nos fóruns oficiais, eles recomendam o uso da versão 2.1.17 do .NET core
• a versão mais recente da Microsoft parece ser a versão 3.1.3
• _Fiz o download e instalei ambos (primeiro o 2.1.17 e depois o 3.1.3) _
  
  
  
  • _é bem possível que 2.1.17 seja suficiente_
  
  

winetricks com vcrun2019

• é uma boa ideia instalar a versão mais recente do winetricks, porque muitos repositórios distribuem versões antigas do winetricks que não sabem como lidar com o vcrun2019
• winetricks é apenas um arquivo binário que você precisa baixar e tornar executável:
  
  
  
  • Compilei as instruções desta e desta fonte
  
  

cd "${HOME}/Downloads"
wget  https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
chmod +x winetricks

• se você deseja instalá-lo para o usuário atual:

mkdir "${HOME}/bin"
mv winetricks "${HOME}/bin"

• se você deseja instalá-lo em todo o sistema:

sudo mv winetricks /usr/bin/

• você terá que fazer login novamente para ver o comando no console

Fazendo Bannerlord trabalhar

• certifique-se de ter a versão de pré-requisito proton e protontricks instalados
• vá para /home/<your-name>/.steam/steam/steamapps/compatdata/ e renomeie a pasta "261550" para algo como "Backup_261550"
  
  
  
  • copiar não é suficiente, pois você realmente deseja iniciar com a inicialização de y completamente fresco prefixo de vinho
  
  
  • copiar a pasta irá fazer backup de seus savegames, suas configurações e todo o seu prefixo wine no caso de você querer recuperar ou testar coisas mais tarde
  
  
• execute o jogo uma vez
  
  
  
  • isso é para permitir que o Steam instale algumas dependências
  
  
  • iniciar uma nova campanha não é necessário
  
  
• saia do jogo
• abra um console e execute protontricks 261550 dotnet472
  
  
  
  • ele funcionará através de várias instalações de versões anteriores do dotnet
  
  
  • quando o instalador perguntar, escolha "Reiniciar agora" (não reiniciará realmente o seu PC)
  
  
• quando estiver pronto, execute protontricks 261550 vcrun2019
  
  
  
  • _Não tenho cem por cento de certeza se isso é necessário, mas consegui e minha configuração parece funcionar bem_
  
  
• quando isso for feito, execute protontricks 261550 --gui
  
  
  
  • selecione "Selecione o wineprefix padrão"
  
  
  • verifique no título da janela se o prefixo correto está selecionado, ele deve ser /home/<your-name>/.steam/steam/steamapps/compatdata/261550/pfx
  
  
  • selecione "Executar explorador"
  
  
  • abra o dispositivo "/" e vá até onde você baixou o arquivo dotnet-core e clique duas vezes nele para permitir a instalação
  
  
  • _Como eu tinha dois arquivos "dotnet core", instalei os dois desta forma_
  
  
  • feche o explorador quando a instalação terminar
  
  
  • selecione "Executar winecfg"
  
  
  • na guia "Aplicativos" na parte inferior, defina "Versão do Windows" como Windows 10
  
  
  • _Não tenho cem por cento de certeza se isso é necessário. Eu tenho no Windows 7 e tudo parece funcionar bem_
  
  
  • feche winecfg com o botão "OK" e saia da interface do protontricks pressionando "Cancelar" até que feche
  
  
• iniciar Bannerlord através do Steam
• iniciar uma nova campanha
  
  
  
  • você não tem outra escolha, porque seus savegames antigos estão apenas no backup
  
  
  • você pode tentar recuperar seus jogos salvos antigos, mas apenas se você os fez com a mesma versão do jogo que você está usando agora
  
  
  • Eu não testei isso ainda, então ... informe se funciona.
  
  

Solução de problemas

Se as coisas ainda não funcionarem, há algumas coisas que foram mencionadas na longa edição do github que você pode tentar fazer.

Você está executando uma GPU AMD e o jogo não funciona

• você pode tentar atualizar para os drivers MESA mais recentes
• uma boa opção para isso é o oibaf ppa

Você está executando o NixOS e deseja instalar o Winetricks

• Os procedimentos de instalação do NixOS são diferentes, então instalar o Winetricks é um pouco mais complicado. Eu não uso, mas foi fornecido um script que pode ser usado para instalar os winetricks mais recentes

O jogo trava e não consigo reiniciá-lo

• isso pode ser devido a um processo do servidor de vinho preso. Verifique o gerenciador de tarefas do seu sistema operacional e elimine-o se necessário.

Quero depurar o jogo, mas os arquivos de log são ENORMES

• proton assume um conjunto de configurações de depuração, mas você pode mudar isso. Veja esta postagem para uma explicação

@Tercus

extraia o conteúdo do arquivo .tar.gz em /home/<your-name>/.steam/compatibilitytools.d/

• você agora deve ter uma subpasta nessa pasta chamada Proton-5.5-GE-1

Parece que estou preso nesta etapa, não há nenhuma pasta de ferramentas de compatibilidade lá para mim e se eu criar uma e extra a pasta lá, não tenho a opção de usá-la como uma versão proton

Deixe-me tentar juntar tudo então ...

Bom guia! Algumas sugestões:

• Torne isso um Gist GitHub para que possa ser vinculado ao invés de ter que procurar por este problema (sua postagem será enterrada neste ritmo). Link para isso em um comentário aqui. O restante de nós pode apenas criar um link para o seu problema sempre que alguém fizer uma pergunta (neste problema do GitHub ou em outro lugar) que já seja abordada por seu guia.

• Como suas instruções incluem vcrun2019 você também deve incluir as etapas de solução de problemas para corrigir a situação em que o usuário não tem o vcrun2019 disponível em sua instalação do Winetricks porque é muito antigo. Eu e alguns outros participantes incluímos esta etapa alguns dias atrás neste tópico, mas o ponto crucial é executar sudo winetricks --self-update . Você também pode notar que isso não funciona para o "NixOS" por causa da forma única do NixOS de empacotar software, mas outro usuário gentilmente contribuiu com uma solução alternativa para os usuários do NixOS! Espero que você também possa encontrar essa postagem neste tópico.

• Outra solução alternativa: se o usuário não vir o diretório ~/.steam/compatibilitytools.d , ele deve executar mkdir -p ~/.local/share/Steam/compatibilitytools.d e copiar a pasta Proton-GE para lá. Obrigado a @ Metal079

• Outro usuário relatou que o jogo travava de forma confiável no início e frequentemente com os drivers gráficos de código aberto da AMD no Ubuntu 18.04, mas quando ele atualizou para a pilha de gráficos de código aberto git master do PPA mais recente, o jogo começou a funcionar. Portanto, acho que outro problema conhecido seria se você estiver executando uma instalação antiga do Ubuntu usando os drivers gráficos de código aberto da AMD e precisa atualizá-los usando o PPA do oibaf.

@allquixotic Descobriu o problema! Eu precisava criar a pasta compatibletools.d em /home/USERNAME/.local/share/Steam

Certifique-se de que o nome da pasta está correto (o ".d" no final) e também reinicie o Steam depois de extrair a versão do próton. Verifique se o arquivo de prótons extraiu acidentalmente um nível mais profundo, como "Proton-5.5.0-GE-1 / Proton-5.5.0-GE-1 /"

@allquixotic Descobriu o problema! Eu precisava criar a pasta compatibletools.d em /home/USERNAME/.local/share/Steam

Ah legal. Não tenho certeza do que está acontecendo com esse caminho sendo diferente do usual ~ / .steam. Editou minhas sugestões para o guia de Tercus acima!

Queria adicionar algo, eu estava tendo muitos travamentos também com a solução descrita acima (Proton-GE, dotnet472, dotnet core e windows 10), e o que consertou para mim foi mudar para o driver ACO mesa em vez do padrão (estou executando o Manjaro com Mesa 20.0.4 e uma Radeon RX 580). Antes de trocar, eu estava tendo travamentos a cada poucos minutos (às vezes podia jogar até uma hora sem travar), mas depois de trocar para o driver ACO o jogo ainda não travou depois de jogar por cerca de 2 horas. Esperançosamente, isso pode ajudar as pessoas que ainda estão tendo problemas.

Queria adicionar algo, eu estava tendo muitos travamentos também com a solução descrita acima (Proton-GE, dotnet472, dotnet core e windows 10), e o que consertou para mim foi mudar para o driver ACO mesa em vez do padrão (estou executando o Manjaro com Mesa 20.0.4 e uma Radeon RX 580). Antes de trocar, eu estava tendo travamentos a cada poucos minutos (às vezes podia jogar até uma hora sem travar), mas depois de trocar para o driver ACO o jogo ainda não travou depois de jogar por cerca de 2 horas. Esperançosamente, isso pode ajudar as pessoas que ainda estão tendo problemas.

Estou usando ACO e não parece ter melhorado em nada.

Até agora, posso salvar cerca de 3 a 4 horas antes de começar a travar consistentemente em todas as correções, e isso se tiver sorte. Freqüentemente, só consigo cerca de uma hora. Atualizar o pfx parece me levar uma hora em um salvamento antigo com a mesma versão do jogo. Até agora, só passei das primeiras horas sem dotnet *, mas os tempos de salvamento tornam isso difícil de testar.

@allquixotic
~ / .steam deve ser um link simbólico para ~ / .local / share / Steam

linux 5.6.2.arch1-2
mesa-aco-git 20.1.0_devel | mesa 20.0.4-1
Processador AMD Ryzen 5 3600X de 6 núcleos
AMD Radeon RX 580

Eu uso proton-5.5-GE-1, tenho dotnet472, vcrun2019 e dotnetcore2 instalados. Quando eu inicio o jogo, ele parece estar funcionando bem. No entanto, recebo falhas aleatórias e quando, após algumas falhas, não consigo reiniciar o jogo. Se isso acontecer, abrir protontricks 261550 dá o seguinte erro:
/home/krulvis/.cache/protontricks/proton/Proton-5.5-GE-1/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""
Alguém teve experiências semelhantes ou possivelmente sabe o que está acontecendo?

@Krulvis É muito provável que haja um processo wineserver travado que precisa ser eliminado. Eu encontrei a mesma coisa e matar aquele preso wineserver consertou.

Decidi dar uma olhada no log gerado ao usar o sinalizador PROTON_LOG e, surpreendentemente, gerou um arquivo de 274 MB com milhões de linhas, deveria ser assim? Observe que eu apaguei o log anterior antes de iniciar o jogo.

@ptkato Sim, isso é normal com versões de protontricks 'd .NET. Você pode reduzir isso passando uma variável WINEDEBUG em suas opções de inicialização. Por padrão, o Proton assume WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+mscoree ; o +seh é o que está gerando essas linhas, então é isso que você quer tirar.

Você também pode definir isso criando um user_settings.py na pasta de instalação do Proton, por exemplo, ~/.steam/steam/compatibilitytools.d/$PROTON_VERSION/ ou ~/.steam/steam/steamapps/common/$PROTON_VERSION/ (deve haver um user_settings.sample.py como um modelo) . Esta é a maneira que a Valve parece recomendar, mas eu pessoalmente prefiro definir essas coisas em uma base por jogo.

quando isso for feito, execute protontricks 261550 --gui dlls

@Tercus Você também pode simplesmente executar protontricks 261550 --gui e usar a opção "selecionar o prefixo padrão" (que é selecionada automaticamente). Deve levá-lo ao mesmo lugar (mesmo que essa opção tenha um nome enganoso, dado que o conjunto de protontricks "padrão" é de fato aquele em compatdata/261550/pfx vez de, por exemplo, ~/.wine ).

Até agora, posso salvar cerca de 3 a 4 horas antes de começar a travar consistentemente em todas as correções, e isso se tiver sorte. Freqüentemente, só consigo cerca de uma hora. Atualizar o pfx parece me levar uma hora em um salvamento antigo com a mesma versão do jogo. Até agora, só passei das primeiras horas sem dotnet *, mas os tempos de salvamento tornam isso difícil de testar.

Este é agora meu comportamento também. Posso salvar algumas horas antes de começar a travar de forma consistente. Vou tentar olhar um pouco mais de perto alguns logs e ver o que posso encontrar. Estou morrendo aqui! :)

Até agora, posso salvar cerca de 3 a 4 horas antes de começar a travar consistentemente em todas as correções, e isso se tiver sorte. Freqüentemente, só consigo cerca de uma hora. Atualizar o pfx parece me levar uma hora em um salvamento antigo com a mesma versão do jogo. Até agora, só passei das primeiras horas sem dotnet *, mas os tempos de salvamento tornam isso difícil de testar.

@allquixotic
~ / .steam deve ser um link simbólico para ~ / .local / share / Steam

linux 5.6.2.arch1-2
mesa-aco-git 20.1.0_devel | mesa 20.0.4-1
Processador AMD Ryzen 5 3600X de 6 núcleos
AMD Radeon RX 580

Sim, o ACO foi um sinalizador falso, e depois de carregar meu save mais tarde hoje, tenho obtido o mesmo comportamento. Estive olhando os registros, e parece que a falha se deve ao mesmo erro todas as vezes, o que deve ser encorajador pelo menos:

 Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that othe

TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatches(String text, Int32 beginIndex, Int32 endIndex, List`1 tokenMatches)
   at TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatchesAndText(String text)
   at TaleWorlds.Localization.TextProcessor.Tokenizer.<Tokenize>d__2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at TaleWorlds.Localization.MBTextManager.Process(String query, TextObject parent)
   at TaleWorlds.Localization.MBTextManager.ProcessText(TextObject to)
   at TaleWorlds.Localization.MBTextManager.ProcessText(TextObject to)
   at TaleWorlds.Localization.TextObject.ToString()
   at SandBox.ViewModelCollection.Nameplate.PartyNameplateVM.RefreshDynamicProperties(Boolean forceUpdate)
   at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
   at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
   at System.Threading.Tasks.Task.<>c__DisplayClass176_0.<ExecuteSelfReplicating>b__0(Object )
   at System.Threading.Tasks.Task.Execute()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
   at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

@ptkato Sim, isso é normal com versões de protontricks 'd .NET. Você pode reduzir isso passando uma variável WINEDEBUG em suas opções de inicialização. Por padrão, o Proton assume WINEDEBUG=+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+mscoree ; o +seh é o que está gerando essas linhas, então é isso que você deseja remover.

Obrigado, isso ajudou, o log agora segue:
steam-261550.log

Exceção não tratada: System.AccessViolationException: tentativa de ler ou gravar memória protegida. Isso geralmente é uma indicação de que outro
TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatches (String text, Int32 beginIndex, Int32 endIndex, List`1 tokenMatches)
em TaleWorlds.Localization.TextProcessor.Tokenizer.FindTokenMatchesAndText (String text)
em TaleWorlds.Localization.TextProcessor.Tokenizer.d__2.MoveN
...

@tkamat Desculpe se isso é ruído, mas de que log é, não foi possível encontrar nada semelhante em 261550/pfx/drive_c/ProgramData/Mount and Blade II Bannerlord/logs/ ou em WINEDEBUG = + timestamp, + pid, + tid, + seh, + debugstr, + loaddll, + mscoree

@allquixotic @Tercus Eu diria que os truques do Proton podem ser instalados via AUR "pamac install protontricks-git" Eu acredito que IIRC (não estou na minha mesa atualmente para verificar o nome do pacote)

O multijogador parou de funcionar para alguém? Estou recebendo couldn't receive login results from server erros agora. :(

Eu atualizei meu pequeno guia e incluí as sugestões. A essência pode ser encontrada aqui . Você pode comentar lá para mudanças nele. Obrigado a todos pelo excelente trabalho. Logo após o lançamento, o jogo pode ser reproduzido no Linux!

@ptkato Olhei no log, a única coisa que percebi foi

4307.340:002a:0032:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution

Não posso ter certeza de que é isso que está causando as falhas, mas é fácil de corrigir; está faltando um pacote Linux! Se você estiver em distros baseadas em Debian / Ubuntu, será winbind como a mensagem de erro diz, se você estiver executando algo baseado em Arch, será samba .

Experimente e veja se isso corrige alguma coisa!

Eu descobri o que era que, pelo menos para mim, tornava meu tempo de economia muito mais rápido do que alguns outros.
Sem o dotnet, meu tempo de salvamento era de cerca de 10 segundos e com o dotnet demorava cerca de 2 segundos. Alguns outros tiveram números semelhantes.
Onde para a maioria, ao que parece, os números estavam em torno de 2-3 minutos e 30 segundos, respectivamente.

O motivo, para mim, é o fsync. Com ele habilitado, eu obtenho os tempos de economia rápidos, com ele desligado eu obtenho os tempos de economia lentos.

Para mim, o dotnet parece ser a causa de uma série de travamentos aparentemente aleatórios. Tentei todas as combinações de correções aqui, assim como coisas que eu mesmo fiz sem nenhuma melhoria. Os problemas de desempenho que alguns tiveram com o dotnet nunca parecem acontecer comigo, então travamentos são o único problema que eu tive com o dotnet.

Portanto, minha melhor experiência, atualmente, é não fazer nenhum ajuste / instalação de protontricks, mas ter certeza de que o fsync está funcionando, o que já estava. Eu prefiro ter salvos de 10 segundos e nenhuma / muito menos travamentos do que salvamentos de 2 segundos e muitos travamentos. Eu não tentei por tempo suficiente para dizer o quão livre de falhas estou, mas pelo menos ele melhorou significativamente.

Eu preciso do dotnet para que o launcher funcione, então eu uso a nova solução pretendida para contornar o launcher TaleWorlds introduzido em um patch recente, para lançar Bannerlord.Native.exe lugar. Renomeie-o para TaleWorlds.MountAndBlade.Launcher.exe e pronto.

Edit: Uma desvantagem com o exe alternativo é que o inicializador lida com o carregamento do mod, então os mods não são carregados se o inicializador for contornado. Isso pode ser tratado fazendo o que foi mencionado aqui , portanto, é administrável, mas não ideal.

@albin-engstrom Hmm, o jogo rodando melhor com fsync me faz pensar que esync pode ser um problema, como tem sido para outros jogos. Alguém já tentou rodar o jogo com PROTON_NO_ESYNC=1 ?

@tkamat Tentei todas as combinações de fsync e esync ativadas ou desativadas. Mas apenas com dotnet.
Com esync e fsync desativados, o travamento era igual a qualquer outra combinação, até onde eu sabia. Como era isso que eu estava testando na época, não notei especificamente como os tempos de economia eram, mas se eles fossem notavelmente mais lentos, presumo que teria percebido isso.

@tkamat @ albin-engstrom Eu também testei o jogo com esync, fsync e sem ambos e sem dotnet, os tempos de salvamento são sempre em torno de 15 segundos (com uma CPU ryzen 3700x e samsung 860 evo ssd).

ATUALIZAR:
@ albin-engstrom Ao usar sua sugestão ( Bannerlord.Native.exe linkado para TaleWorlds.MountAndBlade.Launcher.exe ) meus tempos de salvamento melhoram em cerca de 50%, por exemplo, eu agora consigo tempos de salvamento em torno de 7,5 segundos (quando não estou executando nenhum comando Winetricks).

O multijogador parou de funcionar para alguém? Estou recebendo couldn't receive login results from server erros agora. :(

Verificado novamente esta manhã e está funcionando agora! Woo!

Também testei o jogo com esync, fsync e sem ambos e sem dotnet, os tempos de salvamento são sempre em torno de 15 segundos (com uma cpu ryzen 3700x e samsung 860 evo ssd).

@elovin Isso é interessante. Pode ser que haja algum tipo de problema que o fsync resolve / workround no meu caso, mas em outros casos o problema pode não estar presente e o fsync não muda tanto as coisas. E eu tenho um Ryzen 3900X e um 970 Evo, coisas bastante semelhantes, então é improvável que seja a diferença para nós.

Ao usar sua sugestão (Bannerlord.Native.exe com link simbólico para TaleWorlds.MountAndBlade.Launcher.exe) meus tempos de salvamento melhoram em cerca de 50%, por exemplo, agora consigo tempos de salvamento em torno de 7,5 segundos (quando não estou executando nenhum comando Winetricks).

Isso é ótimo, o motivo pode ser que parece carregar as coisas de forma diferente. Quando eu tentei pela primeira vez eu tinha dotnet instalado e tempos de salvamento curtos e renomear exe parecem desabilitar / não carregar dotnet. Eu tive os longos tempos de salvamento depois de fazer isso.
Pode ser que o dotnet seja especificamente necessário apenas para o inicializador e carregado com ele, portanto, quando o inicializador é ignorado, o dotnet não é carregado.
É possível que haja algumas outras coisas que não estão carregadas também que podem ser a razão de seus resultados.

@ albin-engstrom Bem, finalmente terminei de compilar um kernel habilitado para fsync (usei linux-tkg ) e posso confirmar que o tempo de salvamento sem dotnet ou qualquer outro protontricks caiu de ~ 2 minutos para apenas cerca de 10 segundos! Não joguei por tempo suficiente para tirar conclusões definitivas sobre estabilidade, mas não tive nenhum travamento até agora com esta configuração, enquanto todas as soluções dotnet que tentei acabaram travando eventualmente.

Para reiterar, aqui estão as etapas que segui:

1. Instale um kernel habilitado para fsync (novamente eu recomendaria linux-tkg).
2. Symlink Bannerlord.Native.exe para TaleWorlds.MountAndBlade.Launcher.exe
3. Selecione Proton-5.5-GE-1, exclua o prefixo anterior e inicie o jogo.
4. É isso aí! Não são necessários protontricks ou outras coisas.

Embora os tempos de salvamento sejam um pouco mais longos com esse método, acho que a estabilidade amplamente aumentada compensa os poucos segundos de diferença, e vou usar isso até que alguém consiga depurar as falhas do dotnet. Seria ótimo ver se isso funciona para mais alguém, e sim, obrigado a @albin-engstrom por descobrir o fsync.

@tkamat Ótimo saber que funciona bem para outra pessoa também, já joguei por cerca de 3 horas com essa configuração sem um único travamento, onde antes eu tinha pelo menos algumas horas, às vezes muito mais e às vezes muito menos. Mas nunca se ouviu falar de 3 horas sem travamentos.

Também estou usando o linux-tkg e posso recomendá-lo, é uma grande ajuda para compilar seu próprio kernel sem fazer isso inteiramente por conta própria. Eu faço isso por vários motivos, fsync sendo um deles.
Mas se alguém não quiser compilar os seus próprios, provavelmente existem alguns pré-compilados disponíveis na distribuição de sua escolha.

No meu caso, também estou usando proton-tgk, bem como scripts do tkg para compilar dxvk.

@ albin-engstrom Bem, finalmente terminei de compilar um kernel habilitado para fsync (usei linux-tkg ) e posso confirmar que o tempo de salvamento sem dotnet ou qualquer outro protontricks caiu de ~ 2 minutos para apenas cerca de 10 segundos! Não joguei por tempo suficiente para tirar conclusões definitivas sobre estabilidade, mas não tive nenhum travamento até agora com esta configuração, enquanto todas as soluções dotnet que tentei acabaram travando eventualmente.

Para reiterar, aqui estão as etapas que segui:

1. Instale um kernel habilitado para fsync (novamente eu recomendaria linux-tkg).
2. Symlink Bannerlord.Native.exe para TaleWorlds.MountAndBlade.Launcher.exe
3. Selecione Proton-5.5-GE-1, exclua o prefixo anterior e inicie o jogo.
4. É isso aí! Não são necessários protontricks ou outras coisas.

Embora os tempos de salvamento sejam um pouco mais longos com esse método, acho que a estabilidade amplamente aumentada compensa os poucos segundos de diferença, e vou usar isso até que alguém consiga depurar as falhas do dotnet. Seria ótimo ver se isso funciona para mais alguém, e sim, obrigado a @albin-engstrom por descobrir o fsync.

Você já liderou algum cerco no jogo? Eu percebi participar de cerco, mas principalmente liderar o cerco é uma atividade muito propensa a acidentes.

@vahtos Não

@vahtos Eu tentei liderar um cerco e não

@tkamat Obrigado. Vou tentar sua configuração então. Eu não acho que seja um problema de orçamento de textura, já que eu caio no mapa da campanha ao configurar o cerco ou construir máquinas de cerco. Na verdade, nunca cheguei à batalha em um cerco que estou liderando.

Acabei de testar o jogo em um novo prefixo sem nenhuma das correções de protrontricks, embora tivesse o fsync habilitado, e não tive um único travamento. Além de tentar mexer nas configurações do jogo, o que ainda travava o jogo, o jogo é muito estável ao ponto de ser totalmente jogável.

@ albin-engstrom Bem, finalmente terminei de compilar um kernel habilitado para fsync (usei linux-tkg ) e posso confirmar que o tempo de salvamento sem dotnet ou qualquer outro protontricks caiu de ~ 2 minutos para apenas cerca de 10 segundos! Não joguei por tempo suficiente para tirar conclusões definitivas sobre estabilidade, mas não tive nenhum travamento até agora com esta configuração, enquanto todas as soluções dotnet que tentei acabaram travando eventualmente.
Para reiterar, aqui estão as etapas que segui:

1. Instale um kernel habilitado para fsync (novamente eu recomendaria linux-tkg).
2. Symlink Bannerlord.Native.exe para TaleWorlds.MountAndBlade.Launcher.exe
3. Selecione Proton-5.5-GE-1, exclua o prefixo anterior e inicie o jogo.
4. É isso aí! Não são necessários protontricks ou outras coisas.

Embora os tempos de salvamento sejam um pouco mais longos com esse método, acho que a estabilidade amplamente aumentada compensa os poucos segundos de diferença, e vou usar isso até que alguém consiga depurar as falhas do dotnet. Seria ótimo ver se isso funciona para mais alguém, e sim, obrigado a @albin-engstrom por descobrir o fsync.

Você já liderou algum cerco no jogo? Eu percebi participar de cerco, mas principalmente liderar o cerco é uma atividade muito propensa a acidentes.

Tentei participar de um cerco específico cerca de seis vezes, que congelou cerca de dois segundos na tela de carregamento em todas as ocasiões, exceto. Ainda não tentei cercar nenhuma outra cidade.
Isso é com um 5700XT, usando os drivers de código aberto, com o proton build original postado por @YellowApple , e nenhum outro

Eu voltei para o Warband, mas parece que um bom progresso foi feito aqui, então eu posso pular de volta no movimento da depuração de vinhos neste fim de semana.

Fedora 32, Kernel 5.6.3
Ryzen 2700 em 4ghz
AMD Rx580
Proton-5.5-GE-1

Eu instalei o DotNet 4.72 usando Winetricks. O iniciador funciona bem se você fizer isso. No entanto, o desempenho não é tão bom. Em seguida, tentei substituir o lançador por Bannerlord.Native.exe . Isso realmente melhorou o desempenho significativamente. Mas salvar o jogo agora leva cerca de 2 minutos. Além disso, haverá momentos em que o jogo atinge 100% de uso da CPU e parece congelar. Após alguns minutos, ele voltará ao normal e poderá ser reproduzido novamente.

O desempenho é um tanto bom. Parece um pouco gaguejado e congela ocasionalmente.

Edit: Uma desvantagem com o exe alternativo é que o inicializador lida com o carregamento do mod, então os mods não são carregados se o inicializador for contornado. Isso pode ser tratado fazendo o que foi mencionado aqui , portanto, é administrável, mas não ideal.

Pode valer a pena tentar passá-los como opções de lançamento; parece que .exe pega uma lista deles em seus argumentos se meu rgl_log for qualquer coisa a seguir:

Command Args: /singleplayer _MODULES_*Native*SandBoxCore*CustomBattle*Sandbox*StoryMode*BannerLogger*CalradiaFutureWarfare*CharacterTrainer*DeveloperConsole*XorberaxYell*zzBannerlordTweaks*zzCharacterCreation*_MODULES_ /anticheat

Eu instalei o kernel XanMod para Ubuntu 19.10 e posso confirmar que os tempos de salvamento caíram de um ou dois minutos para alguns segundos com o novo prefixo sem protontricks.

@DeathTBO Experimente um kernel habilitado para fsync, que deve acelerar o salvamento em cerca de 10 segundos ou menos. Para alguns, pelo menos. Não sei se um pré-compilado está disponível para o Fedora, mas presumo que haja pelo menos um. Caso contrário, você terá que compilar o seu próprio.
E os congelamentos que você mencionou são apenas os autosaves, então esses também seriam muito mais rápidos.

Pode valer a pena tentar passá-los como opções de lançamento; parece que o .exe leva uma lista deles em seus argumentos se meu rgl_log for alguma indicação:
Command Args: /singleplayer _MODULES_*Native*SandBoxCore*CustomBattle*Sandbox*StoryMode*BannerLogger*CalradiaFutureWarfare*CharacterTrainer*DeveloperConsole*XorberaxYell*zzBannerlordTweaks*zzCharacterCreation*_MODULES_ /anticheat

@YellowApple Farei uma tentativa mais tarde, se funcionar, é uma abordagem melhor, já que a outra abordagem requer a cópia dos arquivos mod para os outros módulos em vez de mantê-los separados como pretendido.

Experimentei o jogo apenas com próton GE e funciona muito bem. Sem surpresa, o principal problema são as defesas longas, mas eu toleraria isso se o jogo não fosse autosaving antes de cada luta ... existe uma maneira de desativar essas defesas automáticas? Prefiro fazer alguns (longos) salvamentos quando quero do que rodar um kernel diferente.

Instale o dotnet472, ele salva o jogo quase instantaneamente e um amigo meu que jogava Warband regularmente me disse que você vai querer salvar com muita frequência porque ele trava com frequência (mesmo no Windows). Ele também corrige o inicializador, mas isso não é terrivelmente especial, pois o link simbólico de Bannerlord.exe para ManagedStarter.exe faz o mesmo.

Instale o dotnet472, ele salva o jogo quase instantaneamente e um amigo meu que jogava Warband regularmente me disse que você vai querer salvar com muita frequência porque ele trava com frequência (mesmo no Windows). Ele também corrige o inicializador, mas isso não é terrivelmente especial, pois o link simbólico de Bannerlord.exe para ManagedStarter.exe faz o mesmo.

Tentei com o dotnet, mas o jogo travou algumas vezes, então prefiro executá-lo apenas com o próton GE se for possível desativar o salvamento automático.

@ Zouizoui78 Pelo que eu sei, não há maneira conhecida de desativar o salvamento automático, infelizmente.

Eu instalei o kernel liquorix (que eu acho que está habilitado para fsync) no Linux Mint 19.2, usei um prefixo novo e agora estou

Desempenho visivelmente pior do que antes (tropeços ao carregar texturas ou a primeira vez que vou em combate, o menu principal teve quedas massivas de fps nas configurações gráficas padrão / máximas), mas diminuir para médio parece normal.

Apenas um aviso , o mais recente

Usando essas correções, ainda estou conseguindo controle do mouse, talvez 1 em cada 10 inicializações.

Isso é realmente estranho, depois de corrigir o vinho um tempo atrás, eu obtenho o controle do mouse 100% do tempo. Alguém mais está enfrentando o mesmo problema em que os patches _não_ funcionam?

@jaynus : você tentou usar um prefixo novo (execute protontricks 261550 annihilate )? Não deve fazer nenhuma diferença, mas talvez você tenha algumas modificações estranhas de antes, ou ??

@craftyguy Usando um novo prefixo, estou recebendo cliques do mouse a cada dois lançamentos. Estou usando proton-5.5-GE-1 e protontricks dotnet472 e vcrun2019

Usar um kernel habilitado para fsync + prefixo fresco tornou o jogo muito estável para mim agora.
Anteriormente, tive travamentos a cada 10/15 minutos e com ainda mais frequência em algumas áreas.

Eu instalei linux-zen que tem fsync já corrigido.
No Arch linux, o kernel zen pré-construído está no repositório oficial, por isso é muito fácil de instalar.
Fiz um novo prefixo, executando proton-tkg 5.5 e não instalei nenhuma biblioteca adicional.

O jogo é muito estável e joguei por mais de 1 hora sem travar. Os tempos de salvamento são um pouco lentos (10 segundos), mas é uma boa troca pela estabilidade.

Eu recomendo a todos que experimentem o kernel linux-zen .

SO: Arch Linux
KERNEL: 5.6.3-zen1-1-zen
CPU: AMD Ryzen 5 2600 Six-Core
GPU: Radeon RX Vega 56
DRIVER GPU: 4.6 Mesa 20.0.4
RAM: 8 GB

Eu instalei o kernel liquorix (que eu acho que está habilitado para fsync) no Linux Mint 19.2, usei um prefixo novo e agora estou

Desempenho visivelmente pior do que antes (tropeços ao carregar texturas ou a primeira vez que vou em combate, o menu principal teve quedas massivas de fps nas configurações gráficas padrão / máximas), mas diminuir para médio parece normal.

O desempenho cai quando o carregamento de texturas / cenas pela primeira vez é normal, eles devem começar a desaparecer quanto mais você joga enquanto o cache de shader faz seu trabalho.

Eu recomendo a todos que experimentem o kernel linux-zen .

Estou lendo há algumas horas sobre este novo kernel. Não consigo encontrar uma opção de reversão. Estou olhando para o licorix em particular. Digamos que haja algum problema com o kernel, é difícil voltar ao padrão do debian?

Eu instalei o kernel liquorix (que eu acho que está habilitado para fsync) no Linux Mint 19.2, usei um prefixo novo e agora estou
Desempenho visivelmente pior do que antes (tropeços ao carregar texturas ou a primeira vez que vou em combate, o menu principal teve quedas massivas de fps nas configurações gráficas padrão / máximas), mas diminuir para médio parece normal.

O desempenho cai quando o carregamento de texturas / cenas pela primeira vez é normal, eles devem começar a desaparecer quanto mais você joga enquanto o cache de shader faz seu trabalho.

Parece que, depois de jogar por algumas horas, realmente não percebi nada. Ao todo, uma sessão de 5 horas sem um único travamento.

@jake-hedges Normalmente, quando desejo experimentar diferentes kernels, configuro meu gerenciador de inicialização para ter uma opção de menu para inicializar o kernel experimental, enquanto deixo o stable / mainline como opção padrão. Dessa forma, você não perde a opção de reserva.

Eu recomendo a todos que experimentem o kernel linux-zen .

Estou lendo há algumas horas sobre este novo kernel. Não consigo encontrar uma opção de reversão. Estou olhando para o licorix em particular. Digamos que haja algum problema com o kernel, é difícil voltar ao padrão do debian?

Tente perguntar no IRC do debian ou em algum outro canal de suporte para sua distro. Isso está fora do assunto aqui ..

E um aviso para os outros: não baixe kernels aleatórios ou faça experiências com kernels se não souber como se recuperar ou se não tiver motivação para descobrir. As pessoas geralmente são rápidas em recomendar coisas que podem quebrar seu sistema, mas lentas para ajudá-lo a consertar as coisas quando elas quebram.

Tente perguntar no IRC do debian ou em algum outro canal de suporte para sua distro. Isso está fora do assunto aqui ..

Esta é uma rotação de 180 graus proveniente do usuário que fala sobre o uso de soluções alternativas de desenvolvedores aleatórios em um thread de solução de problemas.

Desculpe, mas acredito que se forem sugeridas soluções alternativas que podem afetar todo o seu sistema, discutir uma reversão é apenas uma boa prática. Pode não caber em _seu_ escopo deste tópico, mas parece que esta opção é muito atraente para muitas pessoas agora. Por que você decidiu se tornar de repente um pseudo moderador é cômico.

Tente perguntar no IRC do debian ou em algum outro canal de suporte para sua distro. Isso está fora do assunto aqui ..

Esta é uma rotação de 180 graus proveniente do usuário que fala sobre o uso de soluções alternativas de desenvolvedores aleatórios em um thread de solução de problemas.

Desculpe, mas acredito que se forem sugeridas soluções alternativas que podem afetar todo o seu sistema, discutir uma reversão é apenas uma boa prática. Pode não caber em _seu_ escopo deste tópico, mas parece que esta opção é muito atraente para muitas pessoas agora. Por que você decidiu se tornar de repente um pseudo moderador é cômico.

@jake-hedges talvez você não esteja prestando atenção (dica: você não está), mas eu nunca sugeri que você usasse algum kernel aleatório, alguém fez. Estou sugerindo que todo esse "omg eu brickei meu sistema tentando alguns kernels!" a discussão vá para outro lugar, não tem nada a ver com o tópico aqui.

Por que você decidiu se tornar de repente um pseudo moderador é cômico.

A relação sinal: ruído neste problema é super alta, então aqueles de nós que realmente se preocupam em rastrear os problemas com este jogo têm que examinar os comentários de idiotas como você, que preferem falar sobre como consertar a instalação da sua distro que você estragou tentando sugestões que você não entende.

Então, vá pedir suporte para consertar sua instalação Linux em outro lugar (que você evidentemente quebrou, lol), este não é um fórum de suporte debian.

Embora a instalação de outro kernel como uma solução alternativa seja de interesse para nós que queremos jogar agora, não é realmente relevante para fazer o jogo funcionar corretamente, já que o Steam não está prestes a instalar um novo kernel para fazer um jogo rodar adequadamente com próton. Portanto, com a lógica de @craftyguy , nenhuma discussão adicional deve ocorrer em torno dele. A outra opção é permitir alguns guias breves (sem suporte) sobre como fazer isso para várias distros.

Embora já esteja comentando sobre isso, posso também acrescentar que para NixOS não há kernel zen no nixpkgs, mas é muito fácil adicionar o patch ao seu configuration.nix assim:

boot.kernelPatches = [
      { name = "fsync-support"; patch = ./linux-v5.4-fsync.patch; }
    ];

onde linux-v5.4-fsync.patch é obtido a partir daqui . Isso é tudo que há para fazer. Demorou um pouco para compilar o kernel e tive que limitar o número de núcleos a serem usados ​​ou travaria meu sistema por algum motivo.

A solução alternativa do kernel está errada de várias maneiras. Não o use, a menos que você realmente queira jogar com menos travamentos quando estiver no estado de acesso antecipado. IMHO funciona bem em kernel estável no ArchLinux com Proton 5.5 GE + dotnet472 e dotnet core de comentários anteriores. Tenho 13 horas de jogo, com ocasionais 1 a 2 horas de jogo sem problemas. Basta salvá-lo com frequência e você ficará bem. E também, pega leve, é apenas um jogo.

@CrafterSvK Meu entendimento é que a motivação para usar um kernel com o patch fsync da Valve não é reduzir travamentos. O jogo parece usar algumas primitivas de sincronização do Windows que têm um paralelo no Linux (eventfd), mas não são exatamente idênticas. Os desenvolvedores do Proton escreveram um patch de kernel para permitir que uma thread espere em múltiplos futexes exatamente da mesma forma que é feito no Windows, mas ainda não passou dos altos padrões do Linux e, portanto, não é mesclado com o upstream.

Suponho que a falta desses primitivos força o Wine a emulá-los de uma forma extremamente ineficiente, e produz um travamento brutal no jogo toda vez que salva, o que é muito frequente. Joguei várias horas com ele e é jogável, mas doloroso. Eu estarei experimentando com o kernel zen mais tarde hoje, e se funcionar, valeria a pena inicializar apenas para jogar este jogo. "Salve com frequência" é um conselho excepcionalmente ruim porque o problema que está sendo abordado aqui é que salvar o jogo leva mais de 2 minutos.

Estou vendo sugestões de links simbólicos para pular o inicializador, mas uma solução mais limpa que não exige que você repita o processo em cada patch é dizer ao Steam para executar o binário correto para começar nas opções de inicialização. Aqui está o meu: echo %command% && exec /usr/share/steam/compatibilitytools.d/proton-ge-custom/proton waitforexitandrun "/home/$USER/.local/share/Steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/Bannerlord.exe"

Caso você esteja usando um diretório Proton diferente, você pode obter o% command% real que o Steam está rodando iniciando o jogo com echo %command% > ~/cmd .

@CrafterSvK Meu entendimento é que a motivação para usar um kernel com o patch fsync da Valve não é reduzir travamentos. O jogo parece usar algumas primitivas de sincronização do Windows que têm um paralelo no Linux (eventfd), mas não são exatamente idênticas. Os desenvolvedores do Proton escreveram um patch de kernel para permitir que uma thread espere em múltiplos futexes exatamente da mesma forma que é feito no Windows, mas ainda não passou dos altos padrões do Linux e, portanto, não é mesclado com o upstream.

Suponho que a falta desses primitivos força o Wine a emulá-los de uma forma extremamente ineficiente e produz um travamento _brutal_ no jogo toda vez que salva, o que é muito frequente. Joguei várias horas com ele e é jogável, mas doloroso. Eu estarei experimentando com o kernel zen mais tarde hoje, e se funcionar, valeria a pena inicializar apenas para jogar este jogo. "Salve com frequência" é um conselho excepcionalmente ruim porque o problema que está sendo abordado aqui é que salvar o jogo leva mais de 2 minutos.

Estou economizando em 1-2 segundos com a versão GE do próton, portanto, meu conselho é baseado na experiência.

@KimmoKM qual versão do XanMod você está usando? Eu tentei o XanMod e (depois que consertei os drivers da nvidia totalmente danificados) as coisas estão decididamente piores do meu lado.

Parece que os patches do kernel FUTEX_WAIT_MULTIPLE tiveram um impacto muito bom em uma nova versão não protontricks d construída para mim também (usando o patch do linux-tkg , combinado com uma versão modificada de Slackware64-current 's kernel-generic.SlackBuild ). O desempenho e os tempos de economia ainda são visivelmente piores do que dotnet472 (ainda muita gagueira, especialmente no mapa da campanha), mas os tempos de economia são significativamente melhores do que com um prefixo padrão e sem FUTEX_WAIT_MULTIPLE (direto ao ponto onde "salvar frequentemente" é realmente viável, já que salvar leva cerca de 10-30 segundos em vez de vários minutos), e é infinitamente menos travado do que dotnet472 (apenas jogado por várias horas seguidas sem travamentos, enquanto antes teria sorte se eu aguentasse uma hora).

Estou vendo sugestões de links simbólicos para pular o inicializador, mas uma solução mais limpa que não exige que você repita o processo em cada patch é dizer ao Steam para executar o binário correto para começar nas opções de inicialização.

Se você está apenas fazendo os links simbólicos ManagedStarter.exe → Bannerlord.exe e ManagedStarter_BE.exe → Bannerlord_BE.exe , eles devem sobreviver aos patches e ainda fazer o launcher funcionar (ou pelo menos ambos foram verdadeiros no meu caso, através de quase todos os patches das últimas semanas e dezenas de prefixos com e sem qualquer versão de dotnet ). Se você está realmente ignorando o inicializador, então sim, as opções de inicialização são uma maneira limpa de fazer isso.

@KimmoKM qual versão do XanMod você está usando? Eu tentei o XanMod e (depois que consertei os drivers da nvidia totalmente danificados) as coisas estão decididamente piores do meu lado.

5.5.15-xanmod1 deste repositório . Estou usando a GPU AMD.

@KimmoKM é a mesma versão que tirei ...
$cat /proc/version
Linux version 5.5.15-xanmod1 (root@mascote) (gcc version 9.3.0 (Debian 9.3.0-8)) #0 SMP PREEMPT Thu Apr 2 10:37:55 -03 2020

Talvez Nvidia / AMD possa ser o problema. Estou usando o Proton 5.5-1 do GloriousEggroll. Após a alteração, o inicializador do jogo funciona bem, mas quando tento iniciá-lo, ele abre em uma tela branca e imediatamente trava. O uploader de falha agora funciona de alguma forma.

@KimmoKM é a mesma versão que tirei ...
$cat /proc/version
Linux version 5.5.15-xanmod1 (root@mascote) (gcc version 9.3.0 (Debian 9.3.0-8)) #0 SMP PREEMPT Thu Apr 2 10:37:55 -03 2020

Talvez Nvidia / AMD possa ser o problema. Estou usando o Proton 5.5-1 do GloriousEggroll. Após a alteração, o inicializador do jogo funciona bem, mas quando tento iniciá-lo, ele abre em uma tela branca e imediatamente trava. O uploader de falha agora funciona de alguma forma.

Se não me engano, a correção está documentada aqui: https://gist.github.com/Tercus/3db75788df3c7e1efee06904bb985419 em Solução de problemas.

@allquixotic Infelizmente não ... Estou usando drivers Nvidia, não AMD. As coisas geralmente estavam funcionando para mim, embora com travamentos frequentes. O kernel xanmod parece ter quebrado minha configuração. Vou brincar um pouco mais e ver se consigo fazer funcionar, mas talvez tenha que reverter.

Processador AMD® Ryzen threadripper 1900x 8 núcleos × 16
NVidia 2060
Ubuntu 19.10 com kernel xanmod (5.5.15-xanmod1)

EDITAR

Corrigido: Acontece que os drivers da Nvidia ainda eram o problema, parece que você não consegue instalar novos drivers com a GUI do Ubuntu depois de mudar para o novo kernel ... Mais uma tentativa com a linha de comando e tudo está instalado e funcionando facilmente.

Depois de testes mais vigorosos hoje, retiro minha declaração anterior. O desempenho é melhor com Dotnet 4.7 instalado e usando o inicializador. Dotnet também acelera o tempo de economia para apenas alguns segundos, bem como as áreas de carregamento. O desempenho geral pode exigir algum trabalho, mas acho que está relacionado ao jogo em si.

@YellowApple Carregar mods por meio de opções de inicialização funcionam.

Portanto, para as pessoas que ignoram o inicializador lançando Bannerlord.Native.exe vez disso e têm mods que desejam carregar, podem usar isso como uma opção de inicialização no Steam.

%command%
 _MODULES_
*Native*SandBoxCore*CustomBattle*Sandbox*StoryMode*TheNameOfAMod*
_MODULES_

@allquixotic Infelizmente não ... Estou usando drivers Nvidia, não AMD. As coisas geralmente estavam funcionando para mim, embora com travamentos frequentes. O kernel xanmod parece ter quebrado minha configuração. Vou brincar um pouco mais e ver se consigo fazer funcionar, mas talvez tenha que reverter.

Processador AMD® Ryzen threadripper 1900x 8 núcleos × 16
NVidia 2060
Ubuntu 19.10 com kernel xanmod (5.5.15-xanmod1)

EDITAR

Corrigido: Acontece que os drivers da Nvidia ainda eram o problema, parece que você _não pode_ instalar novos drivers com a GUI do Ubuntu depois de mudar para o novo kernel ... Mais uma tentativa com a linha de comando e tudo está instalado e funcionando facilmente.

Estou usando os drivers Nvidia mais recentes com o kernel Xanmod LTS (o mais recente 5.4.x estável) e está funcionando bem aqui também.

@allquixotic Infelizmente não ... Estou usando drivers Nvidia, não AMD. As coisas geralmente estavam funcionando para mim, embora com travamentos frequentes. O kernel xanmod parece ter quebrado minha configuração. Vou brincar um pouco mais e ver se consigo fazer funcionar, mas talvez tenha que reverter.

Processador AMD® Ryzen threadripper 1900x 8 núcleos × 16
NVidia 2060
Ubuntu 19.10 com kernel xanmod (5.5.15-xanmod1)

EDITAR

Corrigido: Acontece que os drivers da Nvidia ainda eram o problema, parece que você _não pode_ instalar novos drivers com a GUI do Ubuntu depois de mudar para o novo kernel ... Mais uma tentativa com a linha de comando e tudo está instalado e funcionando facilmente.

Estou tendo a mesma falha em que ele simplesmente fecha na tela branca com um relatório de falha. Estou usando o Ubuntu 18.04.4 em um MBP com uma GPU Intel e ainda não consegui superar esse travamento da tela branca. Pelo que eu sei, você parece ser o único neste tópico que sofreu esse travamento, então presumo que seja um problema de driver. Minha pergunta é se seus drivers trabalhavam com o Bannerlord antes de usar o xanmod? Se for assim, sei que é isso que devo examinar, a menos que alguém tenha outras idéias úteis.

Definitivamente, há algo que o iniciador faz que tem impacto nos tempos de salvamento.
Não tenho o dotnet instalado, pois causa travamentos e o fsync habilitado para obter tempos de salvamento decentes.

Como o iniciador não é iniciado sem o dotnet, posso ignorá-lo renomeando Bannerlord.Native.exe para TaleWorlds.MountAndBlade.Launcher.exe que faz com que o Steam inicie isso. Também é possível criar um link simbólico ou usar opções de inicialização para conseguir isso.

Ou posso renomear Bannerlord.exe e Bannerlord_BE.exe para ManagedStarter.exe e ManagedStarter_BE.exe respectivamente para fazer o lançador funcionar, não sei por que funciona, pode ter sido explicado em algum ponto neste tópico. A abordagem de link simbólico ou opção de inicialização pode funcionar lá também.

Ao fazer o primeiro e contornar o iniciador, obtenho cerca de 9 segundos de salvamento, ao usar a última abordagem para usar o iniciador, obtenho cerca de 16 segundos de salvamento.

@remosasso Sim, meus drivers funcionavam antes de usar o xanmod. Se você for para a seção sobre nas configurações, deverá ver seus gráficos listados ... Antes de atualizar os drivers, ele não identificava minha placa como NVidia ... Atualizei com o seguinte:

$ sudo add-apt-repository ppa: graphics-drivers / ppa
$ sudo apt update
$ sudo apt-get install nvidia-driver-440

Reiniciar

@remosasso Sim, meus drivers funcionavam antes de usar o xanmod. Se você for para a seção sobre nas configurações, deverá ver seus gráficos listados ... Antes de atualizar os drivers, ele não identificava minha placa como NVidia ... Atualizei com o seguinte:

$ sudo add-apt-repository ppa: graphics-drivers / ppa
$ sudo apt update
$ sudo apt-get install nvidia-driver-440

Reiniciar

Obrigado. No entanto, parece que meus drivers estão bem instalados e tudo isso sem sorte para mim aí. Você encontrou mais alguém com o problema de travamento da tela branca? Eu obtenho a mesma falha, não importa qual Proton eu uso, se eu uso dotnet 472 ou alterando qualquer arquivo .exe. Os drivers parecem ser o problema lógico, mas não parecem ser.

Estou enfrentando a mesma falha de tela branca na nvidia. O autosave foi criado durante a execução no linux e trava alguns segundos após carregar o autosave. O jogo funciona bem com o mesmo salvamento no Windows

Alguém já fez alguma comparação de desempenho entre o Proton e o Windows?

Não consigo encontrar jogos no modo multijogador no branch beta 1.1 e, revertendo para o branch estável, não consigo fazer o login. Alguém mais consegue jogar mp?

Editar:
Parece que o mp está quebrado para todos (não confirmado) no branch beta: https://forums.taleworlds.com/index.php?threads/e1 -1-0-cant-test-new-patch-because-cant-find- a-match.413059 /

Vou tentar o branch estável novamente e ver se consigo efetuar login agora.

Não consigo encontrar jogos no modo multijogador no branch beta 1.1 e, revertendo para o branch estável, não consigo fazer o login. Alguém mais consegue jogar mp?

Editar:
Parece que o mp está quebrado para todos (não confirmado) no branch beta: https://forums.taleworlds.com/index.php?threads/e1 -1-0-cant-test-new-patch-because-cant-find- a-match.413059 /

Vou tentar o branch estável novamente e ver se consigo efetuar login agora.

Acabei de fazer login no multijogador no branch estável. Tive um problema há cerca de duas noites em que não conseguia fazer o login, mas o problema foi resolvido no dia seguinte.

Não consigo fazer login no branch estável agora. Talvez algo bagunça ao reverter do beta?

Não consigo fazer login no branch estável agora. Talvez algo bagunça ao reverter do beta?

Aconteceu comigo várias noites atrás, antes mesmo de o beta existir. Achei que eles finalmente descobriram que eu não estava no Windows e me baniram. Ele começou a funcionar novamente no dia seguinte.

Está funcionando para mim agora, e eu estava jogando SP no beta antes de voltar ao estável para MP.

Usando a opção PROTON_LOG=1 , encontro isto no log:

[000000000000006F:] EXCEPTION handling: System.Net.Sockets.SocketException: Connection reset by peer.
...
[000000000000006F:] EXCEPTION handling: System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer.
...
[000000000000006E:] EXCEPTION handling: System.Net.Sockets.SocketException: Error looking up error string
[000000000000006E:] EXCEPTION handling: System.IO.IOException: Unable to write data to the transport connection: Error looking up error string.
[0000000000000067:] EXCEPTION handling: System.IO.IOException: The authentication or decryption has failed.
...
[0000000000000073:] EXCEPTION handling: System.Net.WebException: Error: SecureChannelFailure (The authentication or decryption has failed.)
...
[0000000000000073:] EXCEPTION handling: System.AggregateException: One or more errors occurred. (Error: SecureChannelFailure (The authentication or decryption has failed.))
...
[0000000000000066:] EXCEPTION handling: System.Net.WebException: The operation has timed out.
...

Devo acrescentar que este é o prefixo padrão em execução em um kernel habilitado para fsync. Tentei com e sem VPN.

A nova versão beta 1.1.0 parece corrigir mais falhas. Eu até recebo de volta um save corrompido de 1.0.10. Estou usando próton-gtk "vanilla". Ainda noto alguns problemas de desempenho às vezes, uma economia de tempo em torno de 10 ~ 12 segundos e travamentos aleatórios após 3-4 horas, mas é claramente jogável.

Coloquei mais de 60 horas neste jogo no Linux. Vivi com o tempo de economia de mais de 30 segundos por um tempo, mas usar Proton 5.5-GE com dotnet472 e dotnetcore reduziu meus tempos de salvamento para menos de 5 segundos.

.NET core é open source, talvez wine / proton deva considerar empacotá-lo como um componente opcional da mesma forma que fazem com gecko.

Meu jogo trava durante o lançamento. Estou na versão e1.1.0 - Beta com Proton-5.5-GE-1

❯ rm -rf ~/.steam/steam/steamapps/compatdata/261550
❯ # Launch the game
❯ protontricks --version
protontricks (1.4.1)
❯ winetricks --version
20191224 - sha256sum: 1582b249d827074bb4c456b6ee5f55293a5fea5a66245f5cbe474f771c65e820
❯ protontricks 261550 dotnet472 2&>1 > log

------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Using winetricks 20191224 - sha256sum: 7b91df1f0a0c7be5e085edce2737ea9d8cea60b6ed891e04f041a46e61242131 with wine-5.0 and WINEARCH=win64
Executing w_do_call dotnet472
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet472 
------------------------------------------------------
This package (dotnet472) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Current Wine does not have Wine bug 42170, so not applying workaround
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
uninstaller: The application with GUID '{8938A429-407D-5208-903D-37777470D766}' was not found
------------------------------------------------------
Working around wine bug 34803 
------------------------------------------------------
reg: The system was unable to find the specified registry key or value
reg: The system was unable to find the specified registry key or value
reg: The system was unable to find the specified registry key or value
Executing rm -f /home/tanner/.steam/steam/steamapps/compatdata/261550/pfx/dosdevices/c:/windows/system32/mscoree.dll
Executing rm -f /home/tanner/.steam/steam/steamapps/compatdata/261550/pfx/dosdevices/c:/windows/syswow64/mscoree.dll
Executing w_do_call dotnet462
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet462 
------------------------------------------------------
This package (dotnet462) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet461
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet461 
------------------------------------------------------
This package (dotnet461) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet46
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet46 
------------------------------------------------------
This package (dotnet46) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet45
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet45 
------------------------------------------------------
This package (dotnet45) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call dotnet40
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_dotnet40 
------------------------------------------------------
This package (dotnet40) may not fully work on a 64-bit installation. 32-bit prefixes may work better.
------------------------------------------------------
------------------------------------------------------
dotnet40 does not yet fully work or install on wine.  Caveat emptor.
------------------------------------------------------
Current Wine does not have Wine bug 42701, so not applying workaround
Executing w_do_call remove_mono
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_remove_mono 
------------------------------------------------------
Mono does not appear to be installed.
------------------------------------------------------
Executing w_do_call winxp
------------------------------------------------------
You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
------------------------------------------------------
Executing load_winxp 
The operation completed successfully
Setting Windows version to winxp
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine regedit C:\windows\Temp\set-winver.reg
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine64 regedit C:\windows\Temp\set-winver.reg
------------------------------------------------------
Running /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wineserver -w. This will hang until all wine processes in prefix=/home/tanner/.steam/steam/steamapps/compatdata/261550/pfx terminate
------------------------------------------------------
Executing cd /home/tanner/.cache/winetricks/dotnet40
Unhandled exception: C++ exception(object = 0x0032f594, type = 0x1009be00) in 32-bit code (0x7b032c45).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7b032c45 ESP:0032f494 EBP:0032f4f8 EFLAGS:00000212(   - --  I   -A- - )
 EAX:0032f4a0 EBX:e06d7363 ECX:0032f490 EDX:0032f4b4
 ESI:100187cc EDI:00000000
Stack dump:
0x0032f494:  0032f534 0000000c 7bc75a1c e06d7363
0x0032f4a4:  00000001 00000000 7b032c45 00000003
0x0032f4b4:  19930520 0032f594 1009be00 0032fe18
0x0032f4c4:  00641a00 0032f4e8 00860000 00641a58
0x0032f4d4:  0032f4e8 0032f500 00110000 00000000
0x0032f4e4:  00000000 0032f528 7bc769e5 0032f510
Backtrace:
=>0 0x7b032c45 RaiseException+0x50(code=<couldn't compute location>, flags=<couldn't compute location>, count=<couldn't compute location>, args=<couldn't compute location>) [Z:\build\wine-5.0\dlls\kernelbase\debug.c:319] in kernelbase (0x0032f4f8)
  1 0x100814f2 in setupengine (+0x814f1) (0x0032f540)
  2 0x10066a29 EntryPoint+0xffffffff() in setupengine (0x0032f5b0)
  3 0x100636d8 EntryPoint+0xffffffff() in setupengine (0x0032f5d0)
  4 0x10061338 EntryPoint+0xffffffff() in setupengine (0x0032f608)
  5 0x10035a14 EntryPoint+0xffffffff() in setupengine (0x0032f678)
  6 0x1006b498 EntryPoint+0xffffffff() in setupengine (0x0032fdd8)
  7 0x1005fa6e EntryPoint+0xffffffff() in setupengine (0x0032fe48)
  8 0x10058323 EntryPoint+0xffffffff() in setupengine (0x0032fe9c)
  9 0x00402928 EntryPoint+0xffffffff() in setup (0x0032ff30)
  10 0x7b454c52 call_process_entry+0x11() in kernel32 (0x0032ff48)
  11 0x7b455070 start_process+0xdf(entry=<couldn't compute location>, peb=<couldn't compute location>) [Z:\build\wine-5.0\dlls\kernel32\process.c:153] in kernel32 (0x0032ffd8)
  12 0x7b454c5e __wine_start_process+0x9() in kernel32 (0x0032ffec)
0x7b032c45 RaiseException+0x50 [Z:\build\wine-5.0\dlls\kernelbase\debug.c:319] in kernelbase: addl  $12,%esp
Unable to access file 'Z:\build\wine-5.0\dlls\kernelbase\debug.c'
Modules:
Module  Address         Debug info  Name (112 modules)
PE    400000-  415000   Export          setup
PE  10000000-100c8000   Export          setupengine
PE  6cd00000-6cd24000   Deferred        sqmapi
ELF 7b000000-7b0e0000   Dwarf           kernelbase<elf>
  \-PE  7b020000-7b0e0000   \               kernelbase
ELF 7b400000-7b510000   Dwarf           kernel32<elf>
  \-PE  7b420000-7b510000   \               kernel32
ELF 7bc00000-7beb6000   Deferred        ntdll<elf>
  \-PE  7bc30000-7beb6000   \               ntdll
ELF 7c000000-7c006000   Deferred        <wine-loader>
ELF 7ccd2000-7cceb000   Deferred        kerberos<elf>
  \-PE  7cce0000-7cceb000   \               kerberos
ELF 7cceb000-7cd2a000   Deferred        uxtheme<elf>
  \-PE  7cd00000-7cd2a000   \               uxtheme
ELF 7cd2a000-7cd33000   Deferred        libxfixes.so.3
ELF 7cd33000-7cd40000   Deferred        libxcursor.so.1
ELF 7ce40000-7ce55000   Deferred        libxi.so.6
ELF 7ce55000-7ce5a000   Deferred        libxcomposite.so.1
ELF 7ce5a000-7cedb000   Deferred        setupapi<elf>
  \-PE  7ce70000-7cedb000   \               setupapi
ELF 7cedb000-7cf0a000   Deferred        libxcb.so.1
ELF 7cf0a000-7d05d000   Deferred        libx11.so.6
ELF 7d05d000-7d100000   Deferred        winex11<elf>
  \-PE  7d080000-7d100000   \               winex11
ELF 7d124000-7d133000   Deferred        libxrandr.so.2
ELF 7d133000-7d141000   Deferred        libxrender.so.1
ELF 7d141000-7d149000   Deferred        libxxf86vm.so.1
ELF 7d149000-7d15f000   Deferred        libxext.so.6
ELF 7d15f000-7d17c000   Deferred        libz.so.1
ELF 7d17c000-7d1bc000   Deferred        libpng16.so.16
ELF 7d1bc000-7d1cf000   Deferred        libbz2.so.1
ELF 7d1cf000-7d295000   Deferred        libfreetype.so.6
ELF 7d2ca000-7d2e3000   Deferred        libresolv.so.2
ELF 7d2e3000-7d311000   Deferred        iphlpapi<elf>
  \-PE  7d2f0000-7d311000   \               iphlpapi
ELF 7d311000-7d356000   Deferred        netapi32<elf>
  \-PE  7d320000-7d356000   \               netapi32
ELF 7d356000-7d394000   Deferred        secur32<elf>
  \-PE  7d360000-7d394000   \               secur32
ELF 7d394000-7d3b4000   Deferred        jsproxy<elf>
  \-PE  7d3a0000-7d3b4000   \               jsproxy
ELF 7d3b4000-7d3f9000   Deferred        winhttp<elf>
  \-PE  7d3c0000-7d3f9000   \               winhttp
ELF 7d3f9000-7d40f000   Deferred        psapi<elf>
  \-PE  7d400000-7d40f000   \               psapi
ELF 7d40f000-7d429000   Deferred        userenv<elf>
  \-PE  7d420000-7d429000   \               userenv
ELF 7d429000-7d449000   Deferred        bcrypt<elf>
  \-PE  7d430000-7d449000   \               bcrypt
ELF 7d449000-7d4ff000   Deferred        crypt32<elf>
  \-PE  7d460000-7d4ff000   \               crypt32
ELF 7d4ff000-7d53a000   Deferred        wintrust<elf>
  \-PE  7d510000-7d53a000   \               wintrust
ELF 7d53a000-7d55d000   Deferred        odbccp32<elf>
  \-PE  7d540000-7d55d000   \               odbccp32
ELF 7d55d000-7d579000   Deferred        mspatcha<elf>
  \-PE  7d560000-7d579000   \               mspatcha
ELF 7d579000-7d595000   Deferred        imagehlp<elf>
  \-PE  7d580000-7d595000   \               imagehlp
ELF 7d595000-7d5b2000   Deferred        sxs<elf>
  \-PE  7d5a0000-7d5b2000   \               sxs
ELF 7d5b2000-7d5da000   Deferred        cabinet<elf>
  \-PE  7d5c0000-7d5da000   \               cabinet
ELF 7d5da000-7d602000   Deferred        imm32<elf>
  \-PE  7d5e0000-7d602000   \               imm32
ELF 7d602000-7d651000   Deferred        usp10<elf>
  \-PE  7d610000-7d651000   \               usp10
ELF 7d651000-7d7a7000   Deferred        comctl32<elf>
  \-PE  7d680000-7d7a7000   \               comctl32
ELF 7d7a7000-7d7e5000   Deferred        ws2_32<elf>
  \-PE  7d7c0000-7d7e5000   \               ws2_32
ELF 7d7e5000-7d80d000   Deferred        mpr<elf>
  \-PE  7d7f0000-7d80d000   \               mpr
ELF 7d80d000-7d88c000   Deferred        wininet<elf>
  \-PE  7d820000-7d88c000   \               wininet
ELF 7d88c000-7d933000   Deferred        urlmon<elf>
  \-PE  7d8b0000-7d933000   \               urlmon
ELF 7d933000-7da62000   Deferred        msi<elf>
  \-PE  7d960000-7da62000   \               msi
ELF 7da62000-7db99000   Deferred        oleaut32<elf>
  \-PE  7da90000-7db99000   \               oleaut32
ELF 7db99000-7dc34000   Deferred        rpcrt4<elf>
  \-PE  7dbc0000-7dc34000   \               rpcrt4
ELF 7dc34000-7dda0000   Deferred        ole32<elf>
  \-PE  7dc70000-7dda0000   \               ole32
ELF 7dda0000-7ddc8000   Deferred        shcore<elf>
  \-PE  7ddb0000-7ddc8000   \               shcore
ELF 7ddc8000-7de2d000   Deferred        shlwapi<elf>
  \-PE  7dde0000-7de2d000   \               shlwapi
ELF 7de2d000-7e7d6000   Deferred        shell32<elf>
  \-PE  7de60000-7e7d6000   \               shell32
ELF 7e7d6000-7e8b1000   Deferred        msvcrt<elf>
  \-PE  7e800000-7e8b1000   \               msvcrt
ELF 7e8b1000-7e8c8000   Deferred        version<elf>
  \-PE  7e8c0000-7e8c8000   \               version
ELF 7e8c8000-7ea14000   Deferred        gdi32<elf>
  \-PE  7e8f0000-7ea14000   \               gdi32
ELF 7ea14000-7ec46000   Deferred        user32<elf>
  \-PE  7ea50000-7ec46000   \               user32
ELF 7ec46000-7ecca000   Deferred        advapi32<elf>
  \-PE  7ec60000-7ecca000   \               advapi32
ELF 7eeff000-7f000000   Deferred        libm.so.6
ELF f7afe000-f7b6a000   Deferred        msxml3<elf>
  \-PE  f7b10000-f7b6a000   \               msxml3
ELF f7bb0000-f7bb8000   Deferred        libxdmcp.so.6
ELF f7bb8000-f7bbd000   Deferred        libxau.so.6
ELF f7bc1000-f7bc7000   Deferred        libdl.so.2
ELF f7bc7000-f7da7000   Deferred        libc.so.6
ELF f7da7000-f7dc9000   Deferred        libpthread.so.0
ELF f7dc9000-f7f7d000   Dwarf           libwine.so.1
ELF f7f81000-f7fab000   Deferred        ld-linux.so.2
ELF f7fae000-f7fb0000   Deferred        [vdso].so
Threads:
process  tid      prio (all id:s are in hex)
00000008 dotNetFx40_Full_x86_x64.exe
    00000028    0
    00000009    0
0000000e services.exe
    00000025    0
    0000001c    0
    00000015    0
    00000010    0
    0000000f    0
00000011 plugplay.exe
    00000019    0
    00000018    0
    00000012    0
00000013 explorer.exe
    00000022    0
    00000021    0
    0000001f    0
    00000014    0
0000001a winedevice.exe
    00000020    0
    0000001e    0
    0000001d    0
    0000001b    0
00000023 winedevice.exe
    00000027    0
    00000026    0
    00000024    0
0000002c (D) C:\9121dba59fb375d0b974\Setup.exe
    00000030    0
    0000002d    0 <==
System information:
    Wine build: wine-5.0
    Platform: i386 (WOW64)
    Version: Windows XP
    Host system: Linux
    Host version: 4.19.108
Using native override for following DLLs: mscoree
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine regedit C:\windows\Temp\override-dll.reg
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine64 regedit C:\windows\Temp\override-dll.reg
The operation completed successfully
The operation completed successfully
The operation completed successfully
Setting Windows version to default
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine regedit C:\windows\Temp\set-winver.reg
Executing /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wine64 regedit C:\windows\Temp\set-winver.reg
------------------------------------------------------
Running /nix/store/rq1ra5a2fki62dmw2yc3d3750q0avisw-wine-wow-5.0/bin/wineserver -w. This will hang until all wine processes in prefix=/home/tanner/.steam/steam/steamapps/compatdata/261550/pfx terminate
------------------------------------------------------
------------------------------------------------------
dotnet40 install completed, but installed file /home/tanner/.steam/steam/steamapps/compatdata/261550/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found
------------------------------------------------------

O erro do lançamento real do jogo parece ser:

ERROR: ld.so: object '/home/tanner/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

Ainda não consigo fazer login no multiplayer no branch estável (e1.0.10).

@agates você não teve problemas para iniciar o jogo após reiniciar?
Estou reinstalando para ver se corrige as configurações. Ontem à noite funcionou bem, mas hoje não foi lançado
Tenho que executar protontricks 261550 dotnetcore para instalá-lo após dotnet472 ?

@agates você não teve problemas para iniciar o jogo após reiniciar?
Estou reinstalando para ver se corrige as configurações. Ontem à noite funcionou bem, mas hoje não foi lançado
Tenho que executar protontricks 261550 dotnetcore para instalá-lo após dotnet472 ?

Todos os problemas que tive foram relacionados a mods, até agora.

dotnetcore não está em winetricks, então tem que instalar manualmente. @Aliervo mostrou como fazer isso em um comentário acima .

@YellowApple
Fizemos a notícia! Obrigado pela correção!

@Aliervo @agates Estou recebendo esta saída:

./proton run ~/dotnet-runtime-2.1.17-win-x64.exe
ProtonFixes[19625] INFO: Running protonfixes
ProtonFixes[19625] INFO: Running checks
ProtonFixes[19625] INFO: All checks successful
ProtonFixes[19625] INFO: No protonfix found for UNKNOWN (261550)

Estou faltando alguma coisa?

@Aliervo @agates Estou recebendo esta saída:

./proton run ~/dotnet-runtime-2.1.17-win-x64.exe
ProtonFixes[19625] INFO: Running protonfixes
ProtonFixes[19625] INFO: Running checks
ProtonFixes[19625] INFO: All checks successful
ProtonFixes[19625] INFO: No protonfix found for UNKNOWN (261550)

Estou faltando alguma coisa?

O arquivo dotnet-runtime-2.1.17-win-x64.exe no seu diretório inicial?

Recebo a saída exata quando o local especificado não existe.

O meu está em ~/Downloads/dotnet-runtime-2.1.17-win-x64.exe , por exemplo.

@agates sim, tudo no lugar, talvez seja porque eu já tenho instalado?

Testes

Planos

Tentei testar algumas das sugestões que vimos até agora. Vou tentar mais algumas combinações amanhã, que podem incluir o uso de um kernel habilitado para fsync. Também tentarei estender os testes de algumas das soluções mais promissoras, como alterar as configurações gráficas sem travar e estabilidade geral de jogo. Vou atualizar este post, mas também pode ser visto nesta essência .

A configuração

Minha maneira atual de testar é incrivelmente básica. Eu crio um novo prefixo e executo o jogo uma vez para fazer a configuração básica do vapor. Em seguida, adiciono os componentes que desejo testar. Se o novo teste incluir os componentes testados anteriormente, pulo a criação de um novo prefixo (nenhum novo prefixo quando mudei de vcrun2019 para vcrun20190 + dotnet472 ). Eu então começo o jogo, começo uma nova campanha, corro na área de treinamento, saio dela, corro no mapa-múndi e, por último, salvo o jogo uma vez. Estenderei o teste para as soluções mais promissoras.

System:    Host: tobias-X570 Kernel: 5.5.0-050500rc5-generic x86_64 bits: 64 Desktop: KDE Plasma 5.18.4
           Distro: KDE neon User Edition 5.18
Machine:   Device: desktop System: Gigabyte product: X570 AORUS MASTER v: -CF serial: N/A
           Mobo: Gigabyte model: X570 AORUS MASTER v: x.x serial: N/A
           UEFI: American Megatrends v: F11 date: 12/06/2019
CPU:       8 core AMD Ryzen 7 3800X (-MT-MCP-) speed/max: 1897/3900 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Device 7340
           Display Server: x11 (X.Org 1.19.6 ) drivers: ati,amdgpu (unloaded: modesetting,fbdev,vesa,radeon)
           Resolution: [email protected]
           OpenGL: renderer: Radeon RX 5500 XT (NAVI14, DRM 3.36.0, 5.5.0-050500rc5-generic, LLVM 9.0.1)
           version: 4.6 Mesa 20.1.0-devel (git-089e1fb 2020-04-09 bionic-oibaf-ppa)

Esteja avisado

Embora meus testes possam mostrar alguns resultados promissores, eles não mostram como o jogo é estável no longo prazo. Tudo o que fiz em meus testes foi abrir o jogo e começar uma nova campanha, sair do campo de testes e salvar o jogo.

Os resultados (até agora)

| Versão do jogo | vcrun 2019 | dotnet 472 | dotnet 480 | .Net-Core 2.1.17 | .NET-Core 3.1.3 | Campo de treinamento FPS | Mapa-múndi FPS | Economize tempo | Streaming lento * |
|: -: |: -: |: -: |: -: |: -: |: -: |: -: |: -: |: -: |: -: |
| 1.1.0 | 🔲 | 🔲 | 🔲 | 🔲 | 🔲 | 45-50 | 56-72 | 1:12 | não |
| 1.1.0 | ☑️ | 🔲 | 🔲 | 🔲 | 🔲 | 45-50 | 56-72 | 1:28 | não |
| 1.1.0 | ☑️ | ☑️ | 🔲 | 🔲 | 🔲 | 69-74 | 65-75 | 0:02 | não |
| 1.1.0 | 🔲 | ☑️ | 🔲 | 🔲 | 🔲 | 69-74 | 66-79 | 0:02 | não |

* refere-se ao efeito de um jogo lento enquanto todos os objetos são carregados ao entrar em uma nova área

@matheo você deve obter uma janela do instalador mesmo se já estiver instalado. Verifique novamente sua pasta STEAM_COMPAT_DATA_PATH e compatibilitytools.d .

Alguém conseguiu que o som surround (por exemplo, 5.1) funcionasse corretamente?

Encontrei o seguinte problema com a versão recomendada do Proton-5-5-GE sempre que tento abrir uma janela nela (como a janela Bannerlord ou o explorador de protontricks):

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Curiosamente, lançar, por exemplo, o instalador dotnet core com wine-staging funciona bem, então parece ser específico para esta versão do Proton. Alguma ideia de qual poderia ser a causa disso ou como resolver isso?

Troquei meu prefixo (padrão do Steam) por um com dotnet472 e dotnetcore2 e agora posso fazer o login no multiplayer no branch estável. Não sei se vcrun2015 e vcrun2017 estão instalados; eles não são listados ao executar protontricks 261550 list-installed .

É estranho como posso fazer o login em 1.1 beta com um pfx padrão (embora não haja servidores disponíveis para jogar de fato).

Encontrei o seguinte problema com a versão recomendada do Proton-5-5-GE sempre que tento abrir uma janela nela (como a janela Bannerlord ou o explorador de protontricks):

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Curiosamente, lançar, por exemplo, o instalador dotnet core com wine-staging funciona bem, então parece ser específico para esta versão do Proton. Alguma ideia de qual poderia ser a causa disso ou como resolver isso?

Você tentou remover a pasta compatdata/261550/ ae instalar todas as dependências, incluindo dotnet472 e dotnetcore? Isso fez com que funcionasse no meu sistema.

Você tentou remover a pasta compatdata/261550/ e instalar todas as dependências, incluindo dotnet472 e dotnetcore? Isso fez com que funcionasse no meu sistema.

Tentei remover a pasta e instalar o dotent472 novamente, mas não pareceu ajudar. Não consegui instalar o dotnetcore neste caso, pois o instalador parece não iniciar devido ao mesmo erro. Eu também tentei a mesma coisa com a versão 5.6-GE-1 de 2 horas atrás, mas encontrei os mesmos problemas.

Não sei se vcrun2015 e vcrun2017 estão instalados; eles não são listados ao executar protontricks 261550 list-installed .

Não instalei o vcrun em minha configuração atual.

Posso confirmar que estou obtendo um ótimo desempenho, tempos de economia de ~ 5-10 segundos e travamentos muito raros com Proton-GE, o kernel zen (para patches fsync) e um prefixo de próton normal criado e provisionado pelo Steam.

Para qualquer outra pessoa em um sistema NixOS, carregue o seguinte arquivo em seu configuration.nix para construir e instalar o kernel zen: https://gist.github.com/hjones2199/11b45917a2944b692dac40015ea0fd41 Você provavelmente também precisará desabilitar seu boot.kernelPackages atual expressão para evitar conflitos.

Para qualquer outra pessoa em um novo kernel (estou executando o xanmod): Eu também instalei o dotnetcore e até agora parece ser o melhor dos dois mundos - ainda não experimentei uma única falha e o desempenho é muito bom. Ocasionalmente, as batalhas demoram muito, mas um reinício parece consertar isso, e a trepidação do mapa de campanha desaparece completamente.

Ainda travando ao alterar as configurações de vídeo com dotnet472 instalado (e muitos outros travamentos aleatórios), a menos que eu o instalei incorretamente? Existe uma maneira de verificar? (Eu usei protontricks 261550 list-installed e dotnet 472 realmente aparece).

Ocasionalmente, as batalhas demoram muito, mas um reinício parece consertar isso, e a trepidação do mapa de campanha desaparece completamente.

O lado do Windows tem problemas de desempenho semelhantes e vazamentos de memória, etc., então parece que está funcionando muito bem :).

Encontrei o seguinte problema com a versão recomendada do Proton-5-5-GE sempre que tento abrir uma janela nela (como a janela Bannerlord ou o explorador de protontricks):

000b:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
000b:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Curiosamente, lançar, por exemplo, o instalador dotnet core com wine-staging funciona bem, então parece ser específico para esta versão do Proton.
Tentei remover a pasta e instalar o dotent472 novamente, mas não pareceu ajudar. Não consegui instalar o dotnetcore neste caso, pois o instalador parece não iniciar devido ao mesmo erro. Eu também tentei a mesma coisa com a versão 5.6-GE-1 de 2 horas atrás, mas encontrei os mesmos problemas.

Eu tentei outras versões "vanilla" do Proton também agora (5.0-5 e até 4.2-9) e recebo exatamente o mesmo erro nos logs, por isso não parece ser específico para as compilações GE.

Edit: Depois de mais pesquisas, encontrei # 2878 que indica que este é um problema específico do NTFS - mover o jogo para o meu SSD ext4 resolveu o problema

Posso confirmar que estou obtendo um ótimo desempenho, tempos de economia de ~ 5-10 segundos e travamentos muito raros com Proton-GE, o kernel zen (para patches fsync) e um prefixo de próton normal criado e provisionado pelo Steam.

Para qualquer outra pessoa em um sistema NixOS, carregue o seguinte arquivo em seu configuration.nix para construir e instalar o kernel zen: https://gist.github.com/hjones2199/11b45917a2944b692dac40015ea0fd41 Você provavelmente também precisará desabilitar seu boot.kernelPackages atual expressão para evitar conflitos.

Este problema é quase impossível de navegar, então não culpo você por perdê-lo, mas eu já forneci uma solução fácil para isso apenas adicionando um patch ao kernel atual e é muito simples: https://github.com/ ValveSoftware / Proton / issues / 3706 # issuecomment -612160300

Basicamente, adicione o patch ao seu configuration.nix assim:
boot.kernelPatches = [{ name = "fsync-support"; patch = ./linux-v5.4-fsync.patch; }];
onde linux-v5.4-fsync.patch é obtido a partir daqui . Porém, pode demorar um pouco para compilar.

No momento, se eu tento entrar em um cerco, a interface meio que trava e eu não consigo mais nada, o jogo está funcionando bem, mas parece que o mouse não responde; Ainda consigo mover o mouse, mas ele está piscando muito rápido. Também preciso pressionar Esc e Alt + Tab dentro e fora do jogo para fazer o menu de escape aparecer.

Edite isso com apenas fsync e sem correções de protontricks. Se eu também usar as correções de protontricks, o jogo volta a travar como antes.

O patch mais recente (1.0.11) quebrou o jogo para mim (testado com um prefixo de vinho limpo) sempre que tento ir para a tela com os savefiles, recebo esta exceção:

Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object

No entanto, posso começar uma nova campanha, mas ao selecionar a opção "Salvar como", recebo a mesma exceção.

Atualizar:
@agates O branch beta funciona, obrigado

@elovin Você já experimentou o branch beta (e1.1.0)?

Parece que o Bannerlord não funciona com primusrun agora, mas consegui colocá-lo em execução em um laptop com gráficos comutáveis ​​da nvidia usando nvidia-xrun .

Parece que o Bannerlord não funciona com primusrun agora, mas consegui colocá-lo em execução em um laptop com gráficos comutáveis ​​da nvidia usando nvidia-xrun .

Bem, nada realmente funciona tão bem com abelha e primus. Tive que mudar para xrun para fazer metade dos jogos funcionarem.

Deve funcionar com PRIME Render Offloading também.

Ok, eu acho que isso provavelmente não está estritamente relacionado ao Bannerlord, mas, novamente, apenas talvez as bibliotecas que o Steam instala para o prefixo ou algum outro fator específico do Bannerlord mudem algo (eu não sei), então acho que devo Bem, pergunte aqui: Estou tentando executar protontricks para dotnet472, mas isso resulta em uma falha quando a caixa de diálogo "Extraindo arquivos" abre e a barra de progresso termina. protontricks dotnet48 falha de maneira semelhante. Saída do console

Quaisquer dicas?

Olá, estou tendo dificuldade em fazer o bannerlord funcionar no arch, tentei o próton 5.5-GE e 5.6-GE-2. até agora eu tenho uma janela para abrir e exibir o cursor uma vez antes de travar!

• minha biblioteca Steam está em um HDD (ntfs), que agora está montado corretamente e com link simbólico (dessa biblioteca) para apontar para minha pasta de compatdata do linux

• Eu removi a pasta compatdata e lancei, então fiz protontricks 261550 dotnet472 - foi assim que eu fiz minha janela de jogo aparecer e o cursor visível por alguns segundos

aqui está o registro do steam / proton: https://gist.github.com/hadallen/336ffcf1f8ae7e73024898306bb6ac01

e o relatório de travamento do windows / wine quando ele inicia e trava. Não consigo fazer com que o cursor e a janela apareçam novamente, a falha ocorre primeiro. depois disso, o bannerlord aparentemente ainda está "funcionando" com força, não consigo pará-lo. https://gist.github.com/hadallen/d7b00c97e492195f360b8589c5d67685

Estou preocupado que seja apenas um erro estúpido da minha parte em algum lugar, mas não sei o que fazer aqui

edit1: eu finalmente passei por este tópico o suficiente para encontrar o guia que Tercus escreveu. Acabei de passar por isso novamente e ainda tenho o mesmo problema

edit2 : Eu estava quase pronto para desistir, eu reinstalei o bannerlord no Steam

1. protontricks 261550 dotnet48 para começar. Eu realmente não queria esperar os 30 minutos para que o dotnet472 fosse instalado, então tentei sozinho e funcionou --Ran in Steam; caiu
2. vcrun2019 instalado e os 2 dotnetcore (de acordo com Tercus 'write up) --Ran novamente; COMEÇADO! mas muito lento e sem entrada do mouse, travando após sair das configurações .. parecia que não estava usando o próton atualizado
3. Isso foi estranho, pois o bannerlord selecionou o próton 5.6-GE-1. isso me deu a ideia de desabilitar "Ativar Steam Play para todos os outros títulos" nas configurações do Steam, e _voila_; está funcionando muito bem!

Já que o dotnetcore ainda parece ser útil, vou mencionar aqui que meu PR foi aceito e agora está em winetricks!

Execute winetricks --self-update (como root se você instalou com seu gerenciador de pacotes) para obter a versão mais recente, então você pode usar winetricks dotnetcore2 !

Dica profissional: Em qualquer instalação de winetricks, adicione -q para colocá-lo em modo autônomo e não ter que clicar em "Instalar" em um monte de janelas. Portanto, o acima seria winetricks -q dotnetcore2

@Aliervo Recebo um erro de vinho:
https://docs.microsoft.com/en-us/dotnet/framework/install/application-not-started?version= (null) & processName = rundll32.exe & platform = 0009 & osver = 3 & isServer = 0 & shimver = 4.0.30319.0
e então este:

é normal para instalações de 64 bits?

@matheo , não tenho certeza sobre o erro, mas winetricks irá instalar as versões de 32 e 64 bits do .Net Core. Isso é esperado.

Ele também verifica se a instalação foi corrigida, portanto, se você não vir uma mensagem de erro após os dois instaladores, saberemos que o primeiro erro não afetou nada.

Tenho tempos de salvamento muito lentos (1 min +) com dotnet472 com ou sem vcrun2019. Alguém sabe se o patch do kernel fsync é essencial para reduzir o tempo de salvamento / outras boas idéias para melhorar o tempo de salvamento?

@rgreenblatt
O Fsync acelera notavelmente o tempo de salvamento para quase todos, pelo que eu sei, então pode valer a pena tentar se você estiver confortável em rodar kernels personalizados e / ou compilar seus próprios.

Outra coisa a fazer é ignorar o iniciador, caso ainda não o tenha feito. Como começar Bannerlord.Native.exe vez de TaleWorlds.MountAndBlade.Launcher.exe . Isso pode ser feito renomeando-os, criando um link simbólico ou definindo qual iniciar nas opções de inicialização do Steam.

Por razões desconhecidas, o inicializador que está sendo usado praticamente dobra meus tempos de salvamento quando eu uso o fsync e nenhum outro ajuste de protontricks. Não sei se isso se aplica a qualquer outro cenário, mas pode valer a pena tentar de qualquer maneira.

Minha melhor experiência foi com o fsync, que renomeia e não usa protontricks. Relativamente poucas falhas e cerca de 7 a 8 segundos de salvamento. Dotnet encurtaria os tempos de salvamento para cerca de 2 segundos, mas introduziria muito mais travamentos.

@rgreenblatt pelo que vi no restante deste tópico, dotnet foi a solução para longos tempos de salvamento, às custas de alguma instabilidade. Como disse albin-engstrom, o fsync teve um desempenho muito pior para economizar tempo. Dito isso, achei o jogo praticamente impossível de jogar sem um kernel habilitado para fsync e não posso recomendá-lo o suficiente.

Para todos os outros, o multiplayer tem funcionado para mais alguém? Não consigo fazer login há quase uma semana. Chego à página de login e vejo o círculo giratório da desgraça por alguns minutos antes de me dizer que não é possível fazer login. Isso nos ramos Beta e Stable.

Existe alguma diferença entre Bannerlord.exe e Bannerlord.Native.exe? (desculpas se isso estiver em algum lugar no tópico acima, não consegui encontrar uma maneira de pesquisar os comentários do github)

Consegui reduzir o tempo de salvamento para menos de 10 segundos (de mais de um minuto) instalando https://liquorix.net/ (que acho que tem patches fsync) e usando Bannerlord.Native.exe em vez de Bannerlord.exe. Não tenho certeza de qual mudança foi útil. Posso fazer mais testes científicos mais tarde.

@rgreenblatt Liquorix tem fsync até onde eu sei, então é provável que tenha tido o maior impacto e executar Bannerlord.Native.exe ajudou um pouco mais. Pelo menos essa tem sido a minha experiência.

Quanto à diferença de Bannerlord.exe eu realmente não sei. Executar o nativo é a forma oficial de contornar o iniciador, então estou usando isso. Meu palpite seria que ele foi ajustado para ser executado sozinho, ao passo que o não nativo foi projetado / só funciona quando executado pelo inicializador.

Há um monte de argumentos que o iniciador acrescenta ao executar o exe, então talvez ele não funcione corretamente sem eles.

Relacionado a isso, entre esses argumentos estão os mods a serem carregados, que o inicializador normalmente lida, portanto, ao contornar o inicializador, quaisquer mods teriam que ser adicionados manualmente como argumentos através das opções de inicialização do Steam.

Expliquei como isso é feito em algum lugar nos comentários acima, mas de fato não há uma boa maneira de pesquisar comentários no github, então, se você quiser saber como fazer, posso explicar novamente. Levará muito menos tempo do que procurar um comentário antigo.

Para todos os outros, o multiplayer tem funcionado para mais alguém? Não consigo fazer login há quase uma semana. Chego à página de login e vejo o círculo giratório da desgraça por alguns minutos antes de me dizer que não é possível fazer login. Isso nos ramos Beta e Stable.

Consigo jogar no branch estável, mas não consigo por cerca de um patch antes do 1.1. Fiz funcionar novamente instalando dotnet472 e / ou dotnetcore2 (não sei o que fez a diferença).

Para mim, a solução dotnet causava travamentos a cada 5-10 minutos de jogo, pior do que os tempos de salvamento de 2 minutos.
Vou tentar com licorix, mas tenho algumas perguntas sobre os comentários acima sobre pular o launcher. sem o dotnet, o inicializador não aparece, o jogo sai imediatamente. Como faço para configurá-lo nas opções de inicialização para ir para o nativo?

Tentei defini-lo como "Bannerlord.Native.exe" ou "bin / Win64_Shipping_Client / Bannerlord.Native.exe", mas posso estar indo na direção errada aqui

@aradapilot Alguém em algum lugar neste tópico disse como fazer isso por meio das opções de inicialização, mas eu não faço isso, então não sei exatamente como é feito.
Eu pessoalmente renomeio Bannerlord.Native.exe para TaleWorlds.MountAndBlade.Launcher.exe e removo ou renomeio o exe inicializador original. Ele deve ser refeito após a maioria das atualizações do jogo. O link simbólico também deve funcionar e pode não ter que ser refeito.

Eu faço os comandos de carregamento do mod nas opções de inicialização, mas não esta parte.

bem, não consigo encontrar, mas algum progresso.
Eu defino as opções de lançamento para apenas
echo "%command%" > /tmp/cm

depois disso, o arquivo tinha
wraymond @ shelob : ~ $ cat / tmp / cm
'/home/wraymond/.steam/compatibilitytools.d/Proton-5.6-GE-1'/proton waitforexitandrun' /home/wraymond/.steam/steam/steamapps/common/Mount & Blade II Bannerlord / bin / Win64_Shipping_Client / TaleWorlds .MountAndBlade.Launcher.exe '

da CLI
wraymond @ shelob : ~ $ PROTON_LOG = 1 '/home/wraymond/.steam/compatibilitytools.d/Proton-5.6-GE-1'/proton waitforexitandrun' /home/wraymond/.steam/steam/steamapps/common/Mount & Blade II Bannerlord / bin / Win64_Shipping_Client / Bannerlord.Native.exe '
Proton: nenhum caminho de dados compat?

então eu percebi que tinha algum env definido, entretanto env/set/printenv > / tmp / steamenv - deixa o arquivo vazio, ele não tem env definido. não tenho ideia de onde está obtendo o dir compatdata, que mecanismo o Steam usa.

e, claro, porque a vida é difícil, definir essa string nas opções de inicialização não faz nada
PROTON_LOG = 1 '/home/wraymond/.steam/compatibilitytools.d/Proton-5.6-GE-1'/proton waitforexitandrun' /home/wraymond/.steam/steam/steamapps/common/Mount & Blade II Bannerlord / bin / Win64_Shipping_Client / Bannerlord.Native.exe '
- nenhum arquivo de log foi criado
- nada inicia, morre imediatamente

então ainda está preso lá. Vou tentar renomear / criar links simbólicos, mas esperava encontrar uma maneira de não precisar refazer cada patch

hah Eu renomeei o exe lançador e copiei o exe nativo para esse caminho. o jogo foi lançado, mas agora novamente sem entrada do mouse (com próton-GE 5.5 ou 5.6).
Vou tentar renomear o managedstarter, já que funcionou no passado, mas passa pelo inicializador, então pode estragar meus tempos de salvamento ... ahhhhhhh
atualização que também não ajuda. sem entrada do mouse, não consigo passar da tela de calibração. Estou perdida.

Conforme: https://github.com/ValveSoftware/Proton/issues/3706#issuecomment -612178492
echo %command% && exec /home/USERNAME/.steam/compatibilitytools.d/Proton-5.6-GE-2/proton waitforexitandrun "/PATH/TO/steam/steamapps/common/Mount & Blade II Bannerlord/bin/Win64_Shipping_Client/Bannerlord.exe"

Obrigado, não consigo fazer com que comece a apontar para o launcher ou nativo ou qualquer coisa com isso. existe alguma maneira de fazer isso no CLI? fazer isso por meio da IU do Steam é apenas esconder muitas informações