Proton: Engenheiros Espaciais - 244850

A propósito, posso confirmar que Space Engineers, de fato, trabalha com vinho, já que fui capaz de iniciar SE com wine-staging 3.18 sem dxvk. Ele trava porque a API wined3d11 não era capaz de rodar o SE por tempo suficiente para realmente tocar, parecia travar em pontos aleatórios no tempo, mas isso indica que o SE deve ser funcional, uma vez que corrigimos o próton.

Tentei localizar o patch que o faz funcionar no estágio de vinho, mas não consegui. Ou sou completamente cego ou não existe. Pode ser que a função que não está funcionando seja um subproduto de algum outro bug. Vou continuar procurando

Agora que descobri que o SE falha por causa de algo diferente, e essa função está quebrada em ambas as versões do wine, agora irei descobrir por que ele falha em primeiro lugar.

Eu descompilei o SE e descobri onde está o caminho do código problemático, parece que o SE acha que '-report' foi passado como um argumento de linha de comando, mas pelo que eu entendi da fonte descompilada, não deve haver uma razão para SE pensar isso.

Eu postei um link para este tópico na página oficial de suporte dos engenheiros espaciais. Vou ver se alguém aí tem alguma ideia.

Também suba na votação desse tópico no fórum para tentar chamar a atenção caso seja um SE e não um problema de vinho!

https://support.keenswh.com/spaceengineers/general/topic/improve-compatibility-with-steam-play-and-proton-linux-mac

Não, você me entendeu mal, deixe-me explicar um pouco mais. SE usa .NET 4.7.1 que ESTÁ quebrado no Wine, mas pode ser executado com uma solução alternativa e um pouco de sorte. Aqui está a solução alternativa necessária. Em seguida, o SE usa Stream Output / Transform Feedback, que é um recurso obsoleto no DX11 e provavelmente foi transportado do renderizador DX9, que o SE usou no passado. Agora, Vulkan recebeu recentemente esta extensão "VK_EXT_transform_feedback", que permite que Stream Output funcione em Vulkan, portanto, DXVK agora suporta Transform Feedback, portanto SE deve funcionar em wine, mas wine ainda precisa de patches para expor esta extensão. O Proton já tem esses patches, acho, não tenho certeza, não me cite. O vinho da linha principal chegará no próximo lançamento porque já foi testado, o que significa que o vinho também terá. Agora, o wine-staging tem um patch no lugar que permite que o SE inicie sob opengl, ele ainda trava já que o opengl não é capaz de sustentar o motor gráfico. O problema no próton não está relacionado ao feedback de transformação. Não consigo identificar o patch responsável por isso, pois na verdade não sei qual é o problema. Descompilei o SE e examinei o código que está causando a falha, com base no rastreamento de pilha fornecido pelo tempo de execução .net e não vejo uma razão clara para a falha. Vou postar as funções relevantes mais tarde.

Eu sei, ele tenta notificar o usuário de que ele deve atualizar seus drivers gráficos. É por isso que tenta relatar algo. Mas ainda assim, ele funciona no teste de vinho, então ainda precisamos encontrar o patch relevante.

Alguém pode ajudar? Não tenho certeza do que procurar nesses patches.

https://stackoverflow.com/questions/11796082/invalid-parameter-when-setting-an-image e isso parece estar relacionado, não estou mais perto de descobrir isso embora.

a linha 914 parece ser o problema, é a única coisa que consigo ver, o GdiPlus.dll é uma dll nativa do wine como pode ser visto aqui

GetGdiImageFlags retorna um parâmetro inválido se a imagem ou sinalizadores estiverem vazios, como pode ser visto aqui , linha 5219, então provavelmente está sendo anulado em algum lugar em .net ou ao ser passado para a biblioteca nativa do wine.

Acho que encontrei, se estou entendendo bem,

GpStatus WINGDIPAPI GdipGetImageFlags(GpImage *image, UINT *flags)
{
    TRACE("%p %p\n", image, flags);

    if(!image || !flags)
        return InvalidParameter;

    *flags = image->flags;

    return Ok;
}

esta função não deve verificar se flags é 0, pois flags é a variável de saída, que pode ser qualquer.

Estou completamente errado em meu último comentário, odeio dicas. De qualquer forma, vou voltar para o rastreamento de pilha tentando descobrir porque a imagem é nula.

Não tenho certeza das ramificações legais, mas os engenheiros espaciais fornecem um EULA visível / aberto de seu código-fonte no github, se você puder dar uma olhada, para não ter que descompilar.
Pode valer a pena dar uma olhada se for kosher, para descobrir o que está explodindo e se comprometer com o vinho.

https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/EULA.txt

Editar:
Eles têm uma cláusula de interoperabilidade que o vinho se enquadra como 'compatibilidade'

Por favor, espere alguns meses até que a Valve atualize a versão do Wine que o Proton usa. A Valve tem alguns patches no topo do Wine e precisa testar a estabilidade, então há razões pelas quais a Valve não atualiza imediatamente a versão do Wine que o Proton usa.

@SpookySkeletons Esse código-fonte não foi atualizado desde 2016.

@aaronfranke
Isso afeta o vinho de baunilha assim como o próton, o que chegar primeiro pode transferi-lo para o outro.
Os engenheiros espaciais têm sido um grande problema por anos em qualquer tipo de embalagem, mesmo quando funcionava, era estável como um banquinho de duas pernas.

Talvez eu simplesmente não saiba como isso funciona, mas isso pode ser algo para se investigar.

6421.401: 0031: 0032: trace: module : load_dll Módulo L "C: \ windows \ assembly \ NativeImages_v4.0.30319_64 \ mscorlib \ 386b8793866138dad77588a7399d11c3 \ mscorlib.ni.dll" (nativo) em 0x64478000000
A biblioteca carrega em 0x64478000000
Algum tipo de função ativa e queima aqui, compartilhando um espaço de memória muito próximo com mscorlib.ni.dll:

6421.486: 0031: 0032: trace: seh : RtlVirtualUnwind tipo 0 rip 64478454d69 rsp 53b5d0
6421.486: 0031: 0032: trace: seh : dump_unwind_info * * func 454cf0-454da3
6421.486: 0031: 0032: trace: seh : dump_unwind_info desenrolar informações em 0x644785364bc sinalizadores 3 função de bytes de prólogo 0x10 0x64478454cf0-0x64478454da3
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0x10: subq $ 0x68,% rsp
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0xc: pushq% rbx
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0xb: pushq% rsi
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0xa: pushq% rdi
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0x9: pushq% r12
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0x7: pushq% r13
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0x5: pushq% r14
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0x3: pushq% r15
6421.486: 0031: 0032: trace: seh : dump_unwind_info 0x1: pushq% rbp
6421.486: 0031: 0032: trace: seh : dump_unwind_info manipulador 0x644783da000 dados em 0x644785364d8

Parece que mscorlib.ni.dll é um componente do .NET framework, que é conhecido por ser instável no Wine. Você pode ter sorte usando winetricks para brincar com o dotnet, mas espero que Ethan Lee encontre uma solução melhor no futuro.

Com o Mesa 18.3.1 com patches aplicados a partir daqui aplicados para suportar Transform Feedback e usando winetricks para instalar o .NET 4.7.2, cheguei muito perto de ter o jogo funcionando usando DXVK. O jogo chegou ao menu principal, rodando a 120 FPS, e o cursor do mouse carrega. No entanto, o jogo trava antes que o vídeo de fundo e os botões do menu apareçam.

As mensagens de log parecem ser bastante relevantes neste caso. O aviso DXVK parece intimamente relacionado ao que aconteceu com o Wine:

SpaceEngineers_dxgi.log

SpaceEngineers_d3d11.log

steam-244850.log.gz

SpaceEngineers.log

VRageRender-DirectX11.log

Informações do meu sistema. Observe que isso está mostrando uma versão diferente do Mesa porque as compilações do Mesa de 32 bits e 64 bits são distintas agora.

Consegui entrar no jogo com drivers de teste de vinho, dxvk e nvidia proprietários. Todos os voxels estavam terrivelmente malformados e não consegui reproduzi-los desde a atualização do Wine.

@FurretUber
A última versão do jogo trava após um minuto ou mais. Opte pela revisão multijogador na guia beta e ela funcionará.

Acabei de atualizar meu GC para NVIDIA GeForce GTX 1060 e todos os meus jogos Steam funcionam via Steamplay, exceto SE. Eu pressiono o play e o SE tenta iniciar e depois para. Nenhuma mensagem de erro, nenhum som e nenhuma janela de jogo. Eu tentei todas as versões de prótons que o Steamplay pode rodar. Depois de ler este tópico, pelo menos sei que muitas pessoas estão tentando descobrir. Parece que uma nova versão de próton e vinho são necessárias. Eu esperava poder usar wintricks ou algo assim, mas pode ser mais complicado. Isso é uma chatice. Talvez um lib ou vários libs com winecfg?

Este jogo pode ser iniciado com o wine 4.3 e DXVK 1.0 - mas você precisará do .NET 4.7.2 como instalação adicional.
O instalador Lutris para o jogo funciona perfeitamente para novas instalações.
Se você tem uma instalação atual do engenheiro espacial, ela pode não funcionar, mas ainda não descobri por que esse é o caso.
Depois disso, você pode jogar o jogo, mas pequenos erros ainda estarão lá, como:

• Quebrando quando você voa em outras embarcações ou rochas a 20 + m / s (a ferramenta de relatório para SE aparece)
• Após a tela inicial, você tem que clicar com o mouse algumas vezes para chegar ao menu principal, já que o cinematográfico não será reproduzido, senão você terá apenas uma tela preta.
• Pequenos problemas de áudio, que foram corrigidos principalmente com o wine 4.3, mas vão melhorar à medida que o faudio for aprimorado.
• Telas de carregamento lento no início devido a novos shaders precisam ser armazenadas em cache.

Pastebin aqui de logs ao executar e bater em um planeta que bloqueia o jogo.
https://pastebin.com/tPC8y3tK

Presumo que o último protão beta ainda não seja o wine4.3? É por isso que ele não funciona via Steam diretamente?

Consegui fazer os engenheiros espaciais funcionarem. Definitivamente não está em boa forma, mas funciona. Eu precisei:

1) Instale dotnet472 no Space Engineers WINEPREFIX;
2) Construir FAudio com suporte xWMA e bibliotecas em diretórios não padrão. Esta compilação do FAudio deve funcionar com Megadimension Neptunia VIIR ;
3) Faça com que o libFAudio.so construído seja usado para Engenheiros Espaciais, substituindo o Proton de lib64 ou LD_PRELOAD;
4) Certifique-se de que os drivers de vídeo suportem Transform Feedback, como Mesa 19.1.0-devel para Intel Gen9;
5) Certifique-se de que a biblioteca FAudio construída NÃO funcionará! Ele não consegue encontrar as bibliotecas necessárias ao iniciar engenheiros espaciais;
6) Os engenheiros espaciais devem trabalhar, mas sem som .

Existem alguns bugs relacionados aos gráficos como vídeo de abertura que não carrega, nas bordas esse efeito porque o capacete tem bugs, mesmo assim é ótimo considerando que o GPU é um Intel HD Graphics 520 e tinha bugs no Windows 10 até muito recentemente.

Muitos bugs relacionados à geração do terreno estão acontecendo, todos os planetas e luas são paisagens infernais.

Imagens:

Eu meio que consegui fazer funcionar, mas fps estava bem lento no menu (nunca me preocupei em tocar) e o áudio está estalando. Usei https://github.com/Kron4ek/FAudio-Builds, mas talvez não tenha sido instalado corretamente.

EDIT: Não instalei faudio desta vez, e nenhum som, então devo ter instalado corretamente. Talvez o menu principal apenas faça isso porque funciona, mas como você observou, a geração do terreno é completamente confusa.

Se você instalar via Lutris (sim, eu sei) Ele tem uma compilação tkg do Wine 4.4
com F-Audio que faz maravilhas.

Na quarta-feira, 20 de março de 2019 às 03h25, jarrard [email protected] escreveu:

Eu meio que consegui fazer funcionar, mas o fps era bem lento no menu (nunca me preocupei em
play) e o áudio está estalando. eu usei
https://github.com/Kron4ek/FAudio-Builds, mas talvez não tenha sido possível instalar
corretamente.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-474658732 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi
.

Vou tentar relatar minhas descobertas, é uma pena que você não possa baixar o vinho
constrói a partir de lutris, sem lutris

No domingo, 24 de março de 2019, 15:09, Maltahl [email protected] escreveu:

Se você instalar via Lutris (sim, eu sei) Ele tem uma compilação tkg do Wine 4.4
com F-Audio que faz maravilhas.

Na quarta-feira, 20 de março de 2019 às 03h25, jarrard [email protected] escreveu:

Eu meio que consegui fazer funcionar, mas o fps era bem lento no menu (nunca me preocupei em
play) e o áudio está estalando. eu usei
https://github.com/Kron4ek/FAudio-Builds, mas talvez não
instalar
corretamente.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
<
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment -474658732
,
ou silenciar o tópico
<
https://github.com/notifications/unsubscribe-auth/AHuHtRix32b6V_NKrATqj1t79SVRJY1Kks5vYZwdgaJpZM4XyGNi

.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-475963063 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AHonVxCEiLofIF2Jsbrz-HZMdIWpKfgyks5vZ4c2gaJpZM4XyGNi
.

Wine4.4 faudio copiado protonificado em minha pasta de compat do Steam personalizado, jogo reinstalado e dotnet472, carregado, sem áudio.
O jogo parece que pode rodar melhor, mas tem essa gagueira, talvez o áudio não funcional seja o culpado.
De qualquer forma, não parece ter resolvido meu problema de áudio, provavelmente preciso instalar caixas pré-compiladas de algum lugar na pasta proton personalizada, estou no ar, então provavelmente as compiladas em outras distros não funcionarão.

EDIT: Eu construí faudio customizado com suporte a ffmpeg, ainda sem sorte com o som, provavelmente fazendo algo errado, encolher os ombros. De qualquer forma, o jogo é IMO impossível de jogar, todos os mapas de bases de planetas não funcionam / quebraram, tem gagueira e travamento .. Talvez um dia.

Eu duvido que as caixas de outras distros não funcionem. Eles irão, basta instalar
wine a maneira de arco para obter todas as dependências e isso deve servir.

No domingo, 24 de março de 2019, 23:59 jarrard [email protected] escreveu:

Copiei wine4.4 faudio protonificado em minha pasta personalizada do Steam compat,
jogo reinstalado e dotnet472, carregado, sem áudio.
O jogo parece que pode funcionar melhor, mas tem essa gagueira acontecendo,
talvez o áudio não funcional seja o culpado.
De qualquer forma, não pareceu corrigir meu problema de áudio, provavelmente preciso instalar
caixas pré-compiladas de algum lugar na pasta proton personalizada, estou no arco
então, provavelmente, os compilados em outras distros não funcionarão.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476010132 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AHonV0PNKjPrMbFLzUDFBzbXqp2ZjOUNks5vaANBgaJpZM4XyGNi
.

Sim, é apenas um problema de instalação no meu final, também pareço ser capaz apenas de construir libs de 64 bits, não consigo ver as de 32 bits a menos que sejam o mesmo arquivo (não tenho ideia).

Quando copiei meu arquivo libFAudio.so para a pasta personalizada proton_wine e carreguei o SE, ele apenas definiu todas as minhas configurações de volume para zero e não as salvaria se aumentasse, então algo estava errado.

MAS, como eu disse, o jogo tem grandes problemas no Linux, então não é como se eu pudesse jogar atm de forma realista, a menos que fosse pura sobrevivência no espaço sem luas ou planetas!

O principal problema é a geração do terreno. Estou intrigado com o quão infernal
paisagens podem ser criadas

Na segunda-feira, 25 de março de 2019, 06:51 jarrard [email protected] escreveu:

Sim, é apenas um problema de instalação do meu lado, também parece que só consigo
construir bibliotecas de 64 bits, não consigo ver as de 32 bits, a menos que sejam o mesmo arquivo (não
idéia).

Quando copiei meu arquivo libFAudio.so para a pasta personalizada proton_wine e
carregado SE ele apenas definiu todas as minhas configurações de volume para zero, e não salvou
eles se aumentam, então algo está errado.

MAS, como eu disse, o jogo tem grandes problemas no atm, então eu não poderia
jogar atm de forma realista, a menos que seja pura sobrevivência no espaço sem luas ou
planetas!

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476063606 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AHonVxB8URy1FGMFsPoU2eRKq1dVFeg6ks5vaGP8gaJpZM4XyGNi
.

Sim, se alguém conseguir descobrir isso, será ótimo.
O que estou pensando é que o jogo está detectando talvez memória limitada ou núcleos de CPU limitados, portanto, ele não pode fazer o trabalho.

Se você olhar no log de erros do jogo, ele diz que o terreno é muito complexo etc. nesses casos, verifique.

sim, o wine com relatórios de memória, núcleos e outras coisas disponíveis não é ótimo.

Na segunda-feira, 25 de março de 2019 às 6h55 jarrard [email protected] escreveu:

Sim, se alguém conseguir descobrir isso, será ótimo.
O que estou pensando é que o jogo está detectando talvez memória limitada ou limitada
núcleos de CPU, portanto, ele não pode fazer o trabalho.

Se você olhar no log de erros do jogo, ele diz que o terreno é muito complexo
etc nesses casos, verifique.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-476064274 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AHonV9U7V6QwDB69qwGpkGR_avGmUh7Jks5vaGTdgaJpZM4XyGNi
.

Eu tenho um i7 4790k, 16 GB de RAM e GTX 1080. O jogo é executado usando o script lutris com wine 4.4, FAudio e DXVK e o desempenho é bom, 1440p @ 60FPS no entanto:

• mapas de planetas não funcionam nem no modo single ou multiplayer
• música está ausente
• há uma gagueira periódica e muito regular durante o jogo que é muito irritante
• o jogo congela 30-60 minutos em jogo, aparentemente ao acaso, e então trava

Eu não acho que seja jogável nesta fase

Posso ter descoberto porque o terreno é gerado de forma inadequada. Parece que os mapas de altura usados ​​pelo jogo não estão sendo lidos corretamente pelo jogo ou vinho / próton ou algo assim ... Eu obtive o terreno para gerar no planeta alienígena abrindo os mapas de altura do terreno (os arquivos chamados front.png back.png esquerdo .png right.png up.png down.png Localizado em ~ / SpaceEngineers / Content / Data / PlanetDataFiles / Alien /) e sem modificar a imagem real, salvou-os com novas opções. Usei o Gimp versão 2.10.6 para sobrescrever os arquivos com as seguintes opções.

Estranhamente, ao usar a câmera do espectador para ir para a lua local (à qual eu não apliquei a correção), o jogo apenas congelou em vez de gerar o terreno de spiking.
A seguir estão as capturas de tela do jogo de trabalho:

Meu conhecimento sobre isso é muito limitado, então se alguém pudesse descobrir o que está acontecendo aqui, ficaria muito grato.

Nota: Meu jogo travava constantemente ao tentar essas correções, mas os momentos em que conseguia entrar no jogo não travavam durante a sessão de jogo, com exceção de quando fui à lua e o jogo congelou. Depois disso, não consegui fazer o jogo carregar o jogo salvo ou começar um novo mundo sem travar. Depois de deletar e recriar o prefixo, o jogo começou a funcionar novamente.

Muito bom resolver problemas aqui. Portanto, precisamos de próton / vinho para descobrir por que ele não consegue ler esses arquivos PNG corretamente. Pode estar relacionado a um bug desagradável no próprio vinho não ser capaz de ler configurações específicas para esses arquivos!

Eu gostaria que isso pudesse ser transferido para um desenvolvedor para ser analisado, realmente adoraria que este jogo funcionasse melhor. Infelizmente, o problema do mapa de altura não é o único problema, temos de lidar com a gagueira de som e de quadro, mas isso pode estar parcialmente relacionado.

@ Linux74656
Como o material do png poderia interpretar o png de forma errada?

Isso explicaria a loucura de alta-baixa acontecendo ... Talvez esteja apenas sendo truncado de 16 para 8 bits int ...

O que acontece com 8 bpc vs 16 bpc e compressão desligada vs compressão máxima?

Pode valer a pena pedir uma solução rápida dos desenvolvedores KSH, já que isso não parece afetar o jogo base fazendo esse ajuste. No entanto, valerá a pena consertar isso no vinho upstream, agora que sabemos o problema.

O mais importante para sua correção, que lib png o wine usa ?

Não tenho certeza do que o png lib wine usa, mas se você instalar o MS Windows Imaging Component (windowscodecs) com winetricks no prefixo de jogos; a maioria das imagens dos jogos (ícones, miniaturas ... etc) são rosa e o terreno fica completamente plano.

Tentei a sugestão de @SpookySkeletons. Em anexo estão as imagens do cinza 8bpc compactado e do cinza 16bpc (não compactado como compactado não fez diferença em nenhum dos casos). Parece que o 16bpc está funcionando de maneira semelhante às imagens originais fornecidas com o jogo.

Estranhamente, ao testar o cinza 16bpc (compactado e não compactado) o jogo não iniciava o cenário Alien Planet, ele congelava durante o carregamento. Eu contornei isso começando um cenário do Mundo Vazio no modo criativo e gerando o planeta.
Depois disso, decidi comparar o arquivo original com os modificados. Usei uma ferramenta chamada tweakpng (apenas para Windows, mas funciona no Wine sem problemas) para ver os dados do cabeçalho do png fornecido com o jogo e do que modifiquei com 8bpc.
O arquivo que vem com os engenheiros espaciais de fato usa tons de cinza de 16bcp.

Já o modificado, como esperado, usa tons de cinza de 8bcp.

Eu acho que eles (Keen Software House) estão usando 16bcp porque permitiria mais profundidade de cor de escala de cinza e talvez fornecer um terreno mais suave, embora sem ser capaz de testar a geração de terreno de 16bcp no jogo eu não posso dizer com certeza.

O jogo carrega apenas com WINED3D (dxvk desabilitado) e lê o terreno de 16bcp corretamente? Se isso não puder ser feito, talvez o DXVK possa ser testado no windows10 para ver se é o culpado ou se o próprio Wine é o culpado.

É importante saber se o DXVK ou a equipe WINE devem obter o relatório de bug.

O jogo trava ao usar DirectX (PROTON_USE_WINED3D = 1) com uma mensagem de erro.

Quando clico na caixa vazia antes de clicar na mensagem de erro, posso ouvir a música do menu principal do Space Engineers e o som do botão.

Se alguém conseguir fazer o DXVK rodar este jogo no Windows, isso seria ótimo. Enquanto isso, continuarei tentando obter PROTON_USE_WINED3D = 1 para retornar resultados positivos.

Tente falsificar o sinalizador de configurações personalizadas da AMD, o que eu acho possível com regedit de vinhos ou variáveis ​​em algum lugar usando ids de fornecedor e produto. Existem alguns truques que podem ser feitos. (Não consigo me lembrar deles imediatamente)

Acho que Keen escolheu 16 bits especificamente para ajustar o gradiente de altura o mais próximo possível da imagem de 2048x2048, em comparação com as 256 gradações de 8 bits.

Não estou vendo nenhuma falta de precisão no mapeamento de altura usando esta solução alternativa ... Talvez o próprio mecanismo espere uma redução da amostra de 16 para 8 em primeiro lugar ou uma seja implicitamente aplicada que causa isso em primeiro lugar.
Keen parece estar aplicando precisão em excesso a um processo que joga fora a precisão extra.

De qualquer maneira, se pudéssemos entrar em contato com keen e perguntar se é uma boa ideia enviar mapas de altura de 8 bits, isso poderia ser um ótimo band-aid para avançar em direção ao suporte de prótons. E definitivamente uma correção real para o Proton, já que este é um problema com o próprio vinho ...

@jarrard Eu tentei definir a placa para um AMD RX480 VideoPciDeviceID para 10de (hex) e o VideoPciVendorID para 1002 (hex) e ainda obtive o mesmo erro. No entanto, consegui iniciar o jogo executando o SpaceEngineers.exe com wine 4.5 e d3d11_43 instalados. O jogo chega ao menu principal, mas trava ao tentar carregar um cenário.

@SpookySkeletons Enviarei um e-mail para o suporte Keen, com um link para este tópico e ver se recebo uma resposta útil Talvez tenhamos sorte e eles investiguem.

Enquanto isso, vou continuar tentando fazer com que os engenheiros espaciais funcionem com o d3d11.

Fiz WINED3D funcionar, mas não por meio de vapor ou próton. Excluí o prefixo antigo e criei um novo com o Steam. Em seguida, instalei todo o redist dx11 da Microsoft, bem como o habitual dotnet472 e xact. Eu também tive que forçar os engenheiros espaciais a rodar em modo de janela, já que estava constantemente congelando e travando. Consegui superar o congelamento do carregamento iniciando um novo mundo vazio em vez de direto no planeta Alien. Usei o menu de spawn para adicionar o planeta alienígena para os dois mundos. (Resultados nas fotos abaixo)

O 16bpc não funcionava no WINED3D e o 8bpc ainda funcionava.

EDIT: Eu estava procurando no WineHQ por problemas semelhantes, quando me deparei com este relatório de bug:
https://bugs.winehq.org/show_bug.cgi?id=46558
O comentário 8 faz referência a este tópico e à correção temporária, para que eles estejam definitivamente cientes do que está acontecendo. Esperemos que eles possam descobrir isso! :sorriso:

Quanto ao problema da gagueira, tenho tentado várias coisas para ver se consigo restringi-lo.
O problema de gagueira existe tanto no WINED3D quanto no DXVK (percebi que o DXVK usa menos recursos da CPU em comparação com a implementação do D3D do Wine). E o problema parece ocorrer nos mesmos intervalos, não importa quais configurações de gráficos eu uso.

Tentei várias configurações de CPU com os seguintes resultados.
Eu defini minha cpu (i7 4770k) para iniciar apenas com um núcleo (bios usado para desativar todos, exceto um núcleo e sem hyper-threading). O jogo demorou mais para carregar, mas uma vez no mundo, a gagueira parecia inalterada.

Em seguida, fiz underclock (4,2 GHz é o que eu costumo executar) minha CPU para 2,5 GHz (com todos os núcleos e hyper-threading reativado). A gagueira ainda acontecia no mesmo intervalo, mas a duração da gagueira era visivelmente pior, em vez de durar uma fração de segundo, parecia durar um segundo ou mais.

Então, eu fiz overclock em minha CPU para 4.5 GHz e a gagueira ainda ocorreu no mesmo intervalo, mas foi um pouco menos perceptível do que as velocidades de 4,2 GHz que normalmente executa.

Então, isso poderia ser um problema de thread de atualização do jogo? O jogo está realizando cálculos em intervalos definidos e sobrecarregando a CPU? Se sim, o que faria com que isso fosse perceptível no Linux / wine / proton, em comparação com o imperceptível no Windows?

Entrei em contato com o suporte do Keen e contei-lhes sobre os problemas que estamos enfrentando. Eu dei a eles os três principais problemas para fazer isso funcionar no Linux (o terreno, a gagueira e o áudio) e expliquei qual é o problema com o terreno. Eu também coloquei um link para eles neste tópico. Eles responderam com algo parecido com que estão de olho no Linux, mas não planejam nenhuma mudança no momento. Acho que por enquanto estamos por nossa conta.

Talvez você possa gravar um apitrace e postá-lo no fórum DXVK? ainda pode ser corrigido no final do DXVK, você acha?

OK, abri um problema e referenciei este tópico.

ATUALIZAÇÃO: Não é DXVK que está causando o problema. O que significa que nosso problema provavelmente não está relacionado aos gráficos.

Nota rápida para quem deseja se livrar da irritante tela preta e, a necessidade de clicar para obter o jogo para iniciar o menu principal: você pode renomear (basta adicionar .old ao final do arquivo) o arquivo aqui: ~ SpaceEngineers /Content/Videos/KSH.wmv e o jogo começa mais normalmente. Eu até consigo algumas imagens de inicialização quando o jogo começa em tela cheia.

Desenvolvimento interessante: agora que os problemas com DXVK e gráficos foram descartados, voltei meu foco para o áudio. E acho que posso estar no caminho certo.

Se você converter a música do menu principal (~ / SpaceEngineers / Content / Audio / MUS / se_mainmenu1.xwm) para um formato mp3 (mas certifique-se de que o nome do arquivo e a extensão são iguais ao original, ou seja, se_mainmenu1.xwm), então há sem lag no menu principal, embora a música não toque. Se você simplesmente excluir o arquivo, o lag no menu ainda existirá e o não será reproduzido. Portanto, se você der ao mecanismo de jogo um tipo de arquivo de som que ele não reconheça, parece que o problema de lag do menu foi resolvido.

Tentei ver se isso corrigia a gagueira do jogo, mas quando eu converto as outras músicas da mesma forma, o jogo entra em um loop de carregamento infinito ao tentar iniciar um jogo. Também tentei desativar o som no wine e no jogo, mas isso não afetou em nenhum dos casos.

Se você abrir o se_mainmenu1.xwm original no VLC, o mesmo tipo de falha acontece no jogo.

os arquivos XWM não são um formato de arquivo microsoft de baixa qualidade?

Sim, fallout4 / skyrim, todos os jogos que tiveram problemas no passado com áudio usaram este formato de xaudio2.

Tive muitos problemas com Fallout 4, especialmente com áudio. Mas ficou melhor com o tempo, e não vejo o mesmo tipo de gagueira no Fallout 4 que vejo no SpaceEngineers. Agora a questão é ... Por que isso aparentemente está causando um problema nos Engenheiros Espaciais, embora não tenha o mesmo problema no Fallout 4?

Você já tentou abandonar o FAudio e apenas instalar o MS xact ou xaudio seja o que for via winetricks? isso é o que eu costumo fazer para que o áudio do Fallout4 funcione (eventualmente seria cortado)

Pode valer a pena tentar.

Atualmente, estou usando o xact para engenheiros espaciais. Eu nunca consegui fazer os engenheiros espaciais carregar apenas usando Faudio (Winetricks ou Kron4eks Custom Builds.)
Acabei de verificar, a dose de música do menu principal do Fallout 4 não tem gagueira no jogo, mas se você extrair o MUS_MainTheme.xwm do Fallout4-Sounds.ba2 e reproduzi-lo com vlc, a mesma falha de áudio que está nos engenheiros espaciais estará presente.

Não tenho mais certeza se a gagueira no jogo é um problema de áudio. Depois de ficar frustrado demais para lidar com o áudio, tentei voltar e ver em qual versão do jogo o problema começou. A gagueira no jogo existe desde a versão 1.172 (que é tão antiga quanto a guia do Steam beta). Mas o problema de áudio no menu principal não existe nesta versão. Na verdade, o problema de áudio do menu principal só começou na versão 1.188 do jogo. Mas a gagueira no jogo está presente em todas as versões disponíveis na aba betas.

Aqui está algo relacionado aos Engenheiros Espaciais, espero que isso o entretenha. Enquanto esperamos por uma solução.
https://gist.github.com/Linux74656/6093bd3fe9457f29f2f544681a262572

O bug do voxel é um bug windowscodecs no vinho. Descrevi o bug e anexei um patch de correção em https://bugs.winehq.org/show_bug.cgi?id=46558. Testado trabalhando para mim no vapor com vinho. Presumo que o Proton funcione da mesma forma com um windowscodecs wine-dll atualizado.

Sim, mas e quanto aos problemas de distorção de som e gagueira?

@jarrard funciona para mim usando https://github.com/Kron4ek/FAudio-Builds - presumo que as versões do wine e próton sejam muito antigas.

@kainz , você deixou alguma coisa com defeito no jogo com as compilações recentes do FAudio e o patch do windowscodecs? Ou está funcionando bem?

@ fazo96 sombras não funcionam bem, então eu brinco com elas desabilitadas e ainda tenho travamentos pontuais do dotnet.

Ainda falta um pouco.
Espero que as futuras versões do wine possam resolver esses problemas restantes.
É bom ter jogos como este que apontam claramente os problemas na camada de compatibilidade do vinho, casos difíceis, mas solucionáveis.

Aqui está um windowscodecs.dll.so pré-compilado com o patch do bug vinculado. Solte-o no diretório Proton 4.2 / dist / wine / lib64 sobrescrevendo o arquivo existente.

Há um efeito colateral: as imagens de visualização do cenário e do jogo salvo não carregam, são apenas preenchimento magenta. É perfeitamente possível que isso se deva a um descuido de minha parte ao construí-lo. Não notei quaisquer outros efeitos nocivos.

windowscodecs.zip

O jogo não começa via Steam para mim. Você ainda precisa do .NET 472 para ser instalado com o próton mais recente? também o faudio ainda está desatualizado com próton?

É isso que o impede de carregar? por que Faudio não tem suporte para WMV
habilitado por padrão? existem efeitos colaterais negativos?

Mais uma vez, o .net ainda é necessário?

Na sexta-feira, 26 de abril de 2019 às 16:57, lucifertdark [email protected] escreveu:

Eu construo Faudio a partir da fonte para adicionar o suporte wmv, é realmente fácil e
rápido.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-486956240 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AEE7DLTBNX7CLOZAPUK3FYDPSKVFNANCNFSM4F6IMNRA
.

-
- - - - - - -
Eu percebi que quando me esforço para alcançar e ter sucesso, eu me distancio
do momento.

Você ainda precisa do dotnet472 sim. Eu precisei especificar -q ao instalá-lo via protontricks.

A última compilação do FAudio também não está funcionando para mim, apenas trava do mesmo jeito. xact parece consertá-lo, mas não há som.

E também estou vendo aquela gagueira periódica.

Isso está apenas parcialmente relacionado, mas alguém está experimentando estalos com
faudio? Reiniciar pulseaudio corrige isso para mim. Isso acontece com Fallout4,
Eu quero saber se algo semelhante acontece com o SE. Também se eu abrir e
feche FO4 várias vezes sem reiniciar o pulso e fica pior.

Na sexta-feira, 26 de abril de 2019, 10:27, roothorick [email protected] escreveu:

Você ainda precisa do dotnet472 sim. Eu precisava especificar -q ao instalá-lo
via protontricks.

A última compilação do FAudio também não está funcionando para mim, apenas trava todos os
mesmo. xact parece consertá-lo, mas não há som.

E também estou vendo aquela gagueira periódica.

-
Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-486973608 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AB5COVZBOCGLBILENE4RB3DPSK4GRANCNFSM4F6IMNRA
.

gagueira periódica, sim, até que seja resolvido, não vou tocar nisso.

É isso que o impede de carregar? por que Faudio não tem suporte a WMV habilitado por padrão? existem efeitos colaterais negativos? Mais uma vez, o .net ainda é necessário?
…
Na sexta-feira, 26 de abril de 2019 às 16:57, lucifertdark @ . * > escreveu: Eu construo Faudio a partir do código-fonte para adicionar o suporte a wmv, é realmente fácil e rápido. - Você está recebendo isso porque foi mencionado. Responda a este e-mail diretamente, visualize-o no GitHub < # 1792 (comentário) > ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AEE7DLTBNX7CLOZAPUK3FYDPSKVFNANCNFSM4F6IMNRA .
- - - - - - - - Tenho notado que quando me esforço para conquistar e ter sucesso, me distancio do momento.

Ignorar o que escrevi (excluído agora) Não tenho certeza do que estava falando bobagem.

Não consigo nem fazer o Faudio trabalhar com isso, nem eu mesmo compilado ou a dll do Kron4eks, pois ambos travam com um erro de "nenhum aplicativo associado". O nativo do Xaudio funciona, mas a gagueira é insuportável e parece afetar o desempenho gráfico também, mas aumentar a latência do áudio do pulso ajuda um pouco.

Também tentei a correção de windowscodecs vinculada acima para o solo, enquanto ela corrige o problema que recebo skyboxes rosa.

Parece que você está perdendo dotnet472. Isso ainda é necessário.

Em 6 de maio de 2019 2:57:47 AM CDT, fls2018 [email protected] escreveu:

Não consigo nem fazer o Faudio trabalhar com isso, nem eu mesmo compilado nem o
Kron4eks dll's como ambos travam com um erro "nenhum aplicativo associado".
Xaudio nativo funciona, mas a gagueira é insuportável e parece afetar
desempenho gráfico também, aumentar a latência de áudio de pulso ajuda um pouco
Apesar.

Também tentei a correção windowscodecs ligados acima para o solo, enquanto
corrige o problema que recebo skyboxes rosa.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment -489537313

-
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Parece que você está perdendo dotnet472. Isso ainda é necessário.

Não, eu instalei o dotnet472 corretamente, o jogo nem rodaria com o xaudio configurado como nativo de outra forma.

O problema é que o Faudio está habilitado, o jogo trava após a tela inicial. Usando o xaudio padrão, ele funciona, mas com gagueira.

O Running Space Engineer agora funciona com pequenas falhas de áudio e pequenos erros, mas sem mais erros gráficos e de desenho.

Tive que mudar para Wine 4.8 com DXVK 1.2 depois de usar o instalador Lutris

Congelamentos acontecem se você atingir o solo / navios / rochas com 30 m / s ou mais rápido
Registro da falha, incluindo informações do sistema e informações do driver aqui:
https://pastebin.com/yTV7FcBa

Olá @Maltahl , este commit deve ajudar a GPU a travar no impacto. Teste novamente com mesa 19.0.4 ou mesa git master.

Proton 4.2-4 tem um novo problema de terreno, a base na missão 3 do primeiro cenário está flutuando no ar.

Se você puder testar, isso acontece no vinho 4.7 ou no vinho 4.8?

Em 14 de maio de 2019 4:13:59 PM CDT, fls2018 [email protected] escreveu:

Proton 4.2-4 tem um novo problema de terreno, a base na missão 3 do
O primeiro cenário está flutuando no ar.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment -492412089

-
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Se você puder testar, isso acontece no vinho 4.7 ou no vinho 4.8?
…
Em 14 de maio de 2019, às 4:13:59 CDT, fls2018 @ . * > escreveu: Proton 4.2-4 tem um novo problema de terreno, a base na missão 3 do primeiro cenário está flutuando no ar. - Você está recebendo isso porque foi mencionado. Responda a este e-mail diretamente ou visualize-o no GitHub: # 1792 (comentário)
- Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Não tenho certeza, terei que compilar um próton TKG novo, no entanto, estou baseando meu relatório no Proton 4.2-4 lançado hoje, que foi criado para corrigir esses problemas de terreno. Até agora, ele apenas corrigiu o terreno pontiagudo da missão 2.

Observe também que não consigo esse problema com a correção de wincodecs postada acima neste tópico (apenas o céu rosa / miniaturas).

Infelizmente, mesmo depois de renomear o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo) Eu ainda travo após o logotipo do Space Engineers.

Manjaro
Kernel: 5.0.9-2
Driver da Nvidia: 418.56

https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

Infelizmente, mesmo depois de renomear o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo) Eu ainda travo após o logotipo do Space Engineers.

Manjaro
Kernel: 5.0.9-2
Driver da Nvidia: 418.56

https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

Eu confirmo, o jogo trava imediatamente após o início.
OS: Archlinux
Drivers NVidia: 418,74

Parece que o 4.2-4 corrigiu o problema do terreno corrompido. Não deveria mais precisar do meu DLL especial. dotnet472 e xact ainda são necessários.

A gagueira ainda está lá. Tenho quase certeza de que não é relacionado ao áudio; é muito irregular para isso. Parece piorar conforme você se aproxima de voxels (planetas / asteróides) e melhora um pouco se você ficar parado. Meu instinto diz bloqueio / sincronização relacionado ao streaming. Eu não saberia por onde começar a perseguir isso.

Parece que o 4.2-4 corrigiu o problema do terreno corrompido. Não deveria mais precisar do meu DLL especial. dotnet472 e xact ainda são necessários.

A gagueira ainda está lá. Tenho quase certeza de que _não_ está relacionado ao áudio; é muito irregular para isso. Parece piorar conforme você se aproxima de voxels (planetas / asteróides) e melhora um pouco se você ficar parado. Meu instinto diz bloqueio / sincronização relacionado ao streaming. Eu não saberia por onde começar a perseguir isso.

Você pode tentar a missão 3 "Acampamento em ruínas" do cenário "O primeiro salto"? O primeiro planeta na missão 2 pode não ser mais pontiagudo, mas não resolveu completamente o problema aqui.

@FurretUber fez um guia para fazer o jogo rodar alguns meses atrás neste tópico, mas isso mudou desde então? Ou seja, substituir faudio por xact? O protontricks é necessário ou a instalação do dotnet472 por meio do winetricks normal funciona? (alimentando-o com o WINEPREFIX certo?)
Eu tentei seguir as instruções originais com 4.2-4 e ainda fiquei com o travamento da tela preta.

dotnet472 e xact podem ser instalados normalmente via winetricks, use o sinalizador --unattended (ou -q), eu apenas uso scripts sppfx.

PROTON_PATH = "$ HOME / .steam / steam / steamapps / common / Proton 4.2 /" sppfx 275850 winetricks - dotnet472 xact autônomo

Tentei executar WINEPREFIX="/home/[user]/.steam/steam/steamapps/compatdata/244850/pfx/" winetricks -q dotnet472 xact
Mas então o jogo ainda não inicia, no modo winxp (que o winetricks o define) ou win7. Eu tenho o lançamento mais recente de winetricks

você embaralhar seu prefixo se você fizer isso dessa forma, é por isso que eu uso SPPFX

Use os protontricks mais recentes. Usar winetricks diretamente pode causar problemas porque pode invocar a versão errada do Wine. Protontricks recentes configura o ambiente de forma que winetricks usarão o Wine empacotado com Proton.

protontricks 244850 -q dotnet472 xact

(Isso leva muito tempo; seja paciente.)

Sim, basicamente o que eu estava dizendo. SPPFX é um conjunto de scripts semelhante ao protontricks, mas também funciona com qualquer outro comando.

Se você sempre pretende usar scripts de truques, então protontricks é bom, mas às vezes eu quero instalar algo manualmente ou executar winreg etc.

protontricks 244850 -q dotnet472 xact

Executando isso, e depois de renomear o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo), eu pude não apenas chegar ao menu principal, mas carregar um jogos! A taxa de quadros é realmente aceitável (atingindo altos 90), mas a parte chata é a gagueira, tornando a experiência longe de ser agradável.

Mas ele realmente funciona! E também não travou, apenas o problema estranho que experimentei é semelhante ao que o fls2018 relatou com o terreno! Trabalho maravilhoso Valve, CodeWeavers, doitsujin e realmente todos os envolvidos! Estamos chegando tão perto!

Infelizmente, mesmo depois de renomear o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo) Eu ainda travo após o logotipo do Space Engineers.
Manjaro
Kernel: 5.0.9-2
Driver da Nvidia: 418.56
https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

Eu confirmo, o jogo trava imediatamente após o início.
OS: Archlinux
Drivers NVidia: 418,74

Tente instalar protontricks e executar este:

protontricks 244850 -q dotnet472 xact

Em seguida, renomeie o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo)

Consegui fazer o jogo funcionar

EU:

1. SE instalado
2. Executou uma vez para gerar o prefixo
3. Executou protontricks 244850 -q dotnet472 xact
4. Arquivo KSH.wmv renomeado
5. Tentei executar SE com o botão play em 4.2-4
   Mas o jogo continua "rodando" e nunca inicia. Nenhum arquivo exe aparece no gerenciador de tarefas.

O arquivo de log é muito curto e contém esta linha-chave:
313044.458:0027:0028:err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"SpaceEngineers.exe" cannot be loaded 313044.458:0027:0028:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\james\\.local\\share\\Steam\\steamapps\\common\\SpaceEngineers\\Bin64\\SpaceEngineers.exe" failed, status c0000135
steam-244850.log

Parece que o .NET não foi instalado corretamente.

O que faz com que o .NET seja instalado incorretamente?

Winetricks tem um problema com o verbo dotnet476 e sua 'solução alternativa para o bug'. Tente sinalizar o verbo para não contornar 'no wine 4.0 ou mais recente.

Em 16 de maio de 2019, 14h23min41s CDT, pipnina [email protected] escreveu:

O que faz com que o .NET seja instalado incorretamente?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment -493199360

-
Enviado do meu dispositivo Android com K-9 Mail. Por favor desculpe minha brevidade.

Infelizmente, mesmo depois de renomear o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo) Eu ainda travo após o logotipo do Space Engineers.
Manjaro
Kernel: 5.0.9-2
Driver da Nvidia: 418.56
https://gist.github.com/Evernow/6c6b02c027a4df3cb114037460b73ff2

Eu confirmo, o jogo trava imediatamente após o início.
OS: Archlinux
Drivers NVidia: 418,74

Tente instalar protontricks e executar este:

protontricks 244850 -q dotnet472 xact

Em seguida, renomeie o arquivo aqui: ~ SpaceEngineers / Content / Videos / KSH.wmv (basta adicionar .old ao final do arquivo)

Consegui fazer o jogo funcionar

Sim, consegui executar o jogo. Não consegui instalar o dotnet472 sem o parâmetro -q , deu um erro. Mas o jogo ainda não pode ser jogado para mim. O FPS está muito baixo, com falhas de áudio e artefatos gráficos (por exemplo, espaço preto colorido rosa). Defini a qualidade gráfica como baixa, mas com o mesmo resultado. Minha placa de vídeo é NVidia GTX 770, os drivers são 418,74.

FPS é bom para mim, no entanto, há falhas de áudio e gráficos (toda vez que o áudio falha, os gráficos também).

(Driver Arch linux e AMDGPU no Gigatebyte RX 560 4GB OC)

Já joguei e testei o jogo por cerca de 2 horas e encontrei alguns bugs adicionais:

• Os efeitos das partículas não funcionam. Isso inclui efeitos de ferramentas, fumaça, etc.
• O pós-processamento também parece não funcionar
• Os faróis do engenheiro funcionam, mas apenas resultam em um cone de luz sólido, sem desbotamento nas bordas, etc. Os refletores e as luzes internas parecem funcionar bem.

Isso se soma à gagueira que todo mundo está sentindo. Nada disso quebra o jogo, mas ainda assim são bugs.

Qual motor gráfico o SE usa? unidade?

Os engenheiros espaciais usam um motor desenvolvido internamente chamado VRAGE. O mesmo motor é usado em Medieval Engineers e Miner Wars 2081.

provavelmente explica allot, muitos hacks não conformes, provavelmente.

Não precisei renomear para fazê-lo funcionar. Apenas a gagueira é deixada como um problema real.

O fundo do menu não exibirá os vídeos. Isso pode ser investigado, pode resolver outras coisas também.

Não tenho certeza, mas o jogo parece melhor agora, ainda parece lento embora o fps esteja alto, mas a grande trepidação parece ter sumido.

Embora o fps caia muito ao salvar, parece. Ainda precisa de melhorias para tornar a experiência totalmente jogável, mas está chegando lá rápido. Bom trabalho a todos!

O que você fez para se livrar da gagueira (que é 100% relacionada ao áudio, pois ela desaparece quando eu aperto o botão mudo)? último próton?

Hmm, tudo que recebo por um tempo agora é esta mensagem de erro:

Alguma ideia de como consertar isso?
Estou usando o Proton 4.2-7 e tenho o xact, dotnet472 instalado

O que você fez para se livrar da gagueira (que é 100% relacionada ao áudio, pois ela desaparece quando eu aperto o botão mudo)? último próton?

Acho que não fiz nada, quer dizer, a gagueira ainda está aí, só é muito menos prevalente do que antes, pelo menos para mim. talvez o novo driver nvidia (on430.14 agora) e atualizações do Proton?

Olá @kellerkindt , DXVK precisa de uma pilha de drivers Vulkan para traduzir DirectX 11 para Vulkan. Algum aplicativo vulkan como vulkaninfo funciona?

Copie as informações do seu sistema do Steam ( Steam -> Help -> System Information ) e coloque-as em uma essência , a seguir inclua um link para a essência neste relatório de problema.

Olá @kellerkindt , DXVK precisa de uma pilha de drivers Vulkan para traduzir DirectX 11 para Vulkan. Algum aplicativo vulkan como vulkaninfo funciona?

Copie as informações do seu sistema do Steam ( Steam -> Help -> System Information ) e coloque-as em uma essência , a seguir inclua um link para a essência neste relatório de problema.

Aqui está:

vulkaninfo
Steam-info

À primeira vista, parece que está tudo bem. Adicione PROTON_LOG=1 %command% às opções de lançamento do jogo e arraste e solte o $ HOME / steam-244850.log gerado na caixa de comentários.

À primeira vista, parece que está tudo bem. Adicione PROTON_LOG=1 %command% às opções de lançamento do jogo e arraste e solte o $ HOME / steam-244850.log gerado na caixa de comentários.

Aqui esta

Parece que o wine-mono está tendo problemas com algumas variantes de Mono: DllImport error loading library 'd3d11': 'Datei nicht gefunden. todo o log.

11121.045:0025:0026:trace:module:get_load_order looking for L"C:\\windows\\system32\\d3d11.dll"
11121.045:0025:0026:trace:module:get_load_order_value got environment  for L"d3d11"
11121.046:0025:0026:warn:module:load_dll Failed to load module L"d3d11.dll"; status=c0000135

Isso indica que d3d11.dll foi desativado pela variável de ambiente WINEDLLOVERRIDES.

11121.045:0025:0026:trace:module:get_load_order looking for L"C:\\windows\\system32\\d3d11.dll"
11121.045:0025:0026:trace:module:get_load_order_value got environment  for L"d3d11"
11121.046:0025:0026:warn:module:load_dll Failed to load module L"d3d11.dll"; status=c0000135

Isso indica que d3d11.dll foi desativado pela variável de ambiente WINEDLLOVERRIDES.

Bem, não foi definido (por mim):

$ echo ">> $WINEDLLOVERRIDES <<"
>>  <<

Desde a última versão do próton, tenho encontrado essa mensagem de erro em outros jogos. Às vezes, eles ainda funcionam depois de clicar em ok, como o war thunder em próton. Isso me faz pensar se é um bug. Eu testei proton em ambos arch linux e openmandriva lx4 znver. Não tenho certeza se isso faria diferença, mas eu pessoalmente uso um RX 560 com drivers AMDGPU ... Não tenho certeza se o outro comentador aqui usa AMD também.

Não consigo instalar o dotnet472.
My winetricks --version is 20190615-next.
quando tento: protontricks 244850 -q dotnet472 xact Está falhando no dotnet 40 com
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Não consigo instalar o dotnet472.
My winetricks --version is 20190615-next.
quando tento: protontricks 244850 -q dotnet472 xact Está falhando no dotnet 40 com
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Estou tendo exatamente o mesmo problema. Não tenho ideia de como resolver isso. Estou usando o Ubuntu 18.04 e protontricks 1.2.2 com uma GPU AMD R9 Fury.

Não consigo instalar o dotnet472.
My winetricks --version is 20190615-next.
quando tento: protontricks 244850 -q dotnet472 xact Está falhando no dotnet 40 com
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Estou tendo exatamente o mesmo problema. Não tenho ideia de como resolver isso. Estou usando o Ubuntu 18.04 e protontricks 1.2.2 com uma GPU AMD R9 Fury.

Eu usei Protontricks GUI sem problemas, talvez tente isso?

Não consigo instalar o dotnet472.
My winetricks --version is 20190615-next.
quando tento: protontricks 244850 -q dotnet472 xact Está falhando no dotnet 40 com
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Estou tendo exatamente o mesmo problema. Não tenho ideia de como resolver isso. Estou usando o Ubuntu 18.04 e protontricks 1.2.2 com uma GPU AMD R9 Fury.

Eu usei Protontricks GUI sem problemas, talvez tente isso?

Acabei de tentar e ainda recebo o seguinte erro:
dotnet40 install completed, but installed file /home/username/.steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Não consigo instalar o dotnet472.
My winetricks --version is 20190615-next.
quando tento: protontricks 244850 -q dotnet472 xact Está falhando no dotnet 40 com
dotnet40 install completed, but installed file (...).steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Estou tendo exatamente o mesmo problema. Não tenho ideia de como resolver isso. Estou usando o Ubuntu 18.04 e protontricks 1.2.2 com uma GPU AMD R9 Fury.

Eu usei Protontricks GUI sem problemas, talvez tente isso?

Acabei de tentar e ainda recebo o seguinte erro:
dotnet40 install completed, but installed file /home/username/.steam/steam/steamapps/compatdata/244850/pfx/dosdevices/c:/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe not found

Em qual distro você está? Talvez um pacote esteja desatualizado?

Em qual distro você está? Talvez um pacote esteja desatualizado?

Estou no Ubutntu 18.04. Certifiquei-me de verificar se há atualizações para o protontricks antes de executar o comando. Conforme escrevi, a última versão disponível para mim parece ser 1.2.2.

Em qual distro você está? Talvez um pacote esteja desatualizado?

Estou no Ubutntu 18.04. Certifiquei-me de verificar se há atualizações para o protontricks antes de executar o comando. Conforme escrevi, a última versão disponível para mim parece ser 1.2.2.

Vá para Steam, Ajuda, Informações do sistema, selecione tudo (CTRL + A) e, em seguida, copie tudo (CTRL + C) e cole em pastebin.com se você puder, por favor

Olá, recebo exatamente o mesmo erro que @LordJABA . Aqui estão as informações do meu sistema https://pastebin.com/7Ab8CY1Q

protontricks 244850 -q dotnet472 xact exigiu uma combinação PRECISA de winetricks 20190310 e protontricks 1.2.2, nem mais nem menos, pois então haveria falha na instalação do dotnet40.

Mundos baseados em planetas travam em configurações de gráficos mais altas do que baixas Falando em planetas, o terreno está completamente quebrado (Proton 4.2-9):

Obrigado pela dica @LunaSquee . Eu tive que executar protontricks 244850 -q --force dotnet472 xact embora. Não posso confirmar o terreno irregular nos planetas, no entanto. No jogo, experimento congelamentos curtos irritantes / gagueira em intervalos de 1-2 segundos. Mas isso cobre a experiência atual de outros usuários em relação às postagens no protondb. Esperançosamente isso será resolvido! Procurando por.

Em qual distro você está? Talvez um pacote esteja desatualizado?

Estou no Ubutntu 18.04. Certifiquei-me de verificar se há atualizações para o protontricks antes de executar o comando. Conforme escrevi, a última versão disponível para mim parece ser 1.2.2.

estou tendo exatamente o mesmo problema que você, estou no ubuntu 16.04

@EduardoGodoy fez você tentar as sugestões do @LunaSquee com protontricks 1.2.2 e winetricks 20190310?

O terreno e as sombras agora funcionam corretamente ...

O valor poderia ser considerado prata se pudéssemos identificar a causa da gagueira no jogo. A média é de cerca de 110-150 ms no contador de tempo de quadro DXVK.
Existe alguma maneira de criar perfis de aplicativos dotnet no wine para detectar o desligamento?

alguém disse que era relacionado ao áudio? talvez remova todos os drivers de áudio e componentes / arquivos e teste novamente?

O jogo trava imediatamente quando a pasta de áudio está faltando.
Desligar todas as configurações de áudio não parece mudar nada.

@fwillo Se você está determinado e tem algumas horas de tempo, minha solução suja foi:

• abra /usr/bin/winetricks no editor de texto
• procure load_dotnet472()
• poucas linhas abaixo é uma chamada para a versão anterior do dotnet como w_call dotnet462 .
• Segui a corrente e removi o 4.0 do último
• tentei outra vez
• falhou em alguma versão posterior
• toda vez que isso acontecia, encontrava um link de download e argumentos para o instalador no script winetricks e o instalava dentro do prefixo wine manualmente. (4.0 parece estar integrado no vinho? / Não é necessário, os mais novos são necessários)
• depois dessa chamada de remoção / comentário para a versão dotnet instalada no script winetricks e tente novamente

Depois de 2 ou 3 horas, consegui que os engenheiros espaciais trabalhassem bem ... talvez exceto a parte inicial - você terá apenas uma tela em branco, será necessário esperar pelo menos ~ 15s e clicar com o mouse para que o menu apareça.
Depois disso, o desempenho é o mesmo do Windows para mim, mas se eu instalar qualquer mods, ele não funcionará no modo offline do Steam - não tenho certeza se esse é o jogo ou minha configuração

EDITAR: para ficar claro, não estou executando sob o próton, mas via

lutris wine steam runner
wine version: ge-protonified-nofshack-4.9
DXVK:1.2.3

Você pode obter próton GE para vapor pré-compilado com 4.11, no máximo. Funciona com spengies.
Então, o que você está dizendo é:
Você usou o mono embutido do Proton para dotnet 4.0 e inferior, mas instalou os binários da Microsoft para tudo que passou e funcionou sem falhas?

Você poderia ~ zipar e carregar sua garrafa de vinho ou ~ ser um pouco mais conciso sobre como você conseguiu isso?

Moderator note: Above line partially struck out because it would contain copyrighted libraries from the workaround.

@LordJABA Estou disposto a tentar suas instruções. No entanto, tenho que concordar com as notas de

@SpookySkeletons Tenho certeza que desliguei o mono, apesar do instalador do dotnet 4.0 afirmar que eu nunca tenho a versão instalada e se recusa a instalar.
@fwillo Desculpe por instruções pouco claras - eu estava hesitante até mesmo em postá-las assim. Eu vaguei aqui alguns dias depois de descobrir, então nenhuma história de bash ou memórias frescas.

farei o meu melhor para limpá-lo abaixo, assumindo um novo sistema.

• Primeiro instale o wine, certifique-se de que ele também instalou o wine32: i386 - para mim,
• instale o Lutris https://lutris.net/downloads/
• No lutris, clique na engrenagem perto de "Corredores" no canto superior esquerdo para chegar ao gerenciador de corredores,
• Encontre "Wine" na lista, clique no botão azul "Gerenciar versões" e certifique-se de que o ge-protonified-nofshack-4.9 está ativado na lista
• Logo abaixo de "Wine" na lista deve estar "Wine Steam", clique em "Runner Options" ao lado dele e adicione %command% -no-cef-sandbox em "Argumentos", defina a versão correta do vinho e marque stop steam após o jogo terminar
• Clique em Instalar Runner

Deve instalar bem. Agora a parte complicada.

Instale winetricks via script bash conforme descrito aqui https://github.com/Winetricks/winetricks
desta forma, você sempre pode executar update_winetricks para desf ... restaurar seu /usr/bin/winetricks

No tipo de console
export WINEPREFIX="/home/<user>/.local/share/lutris/runners/winesteam/prefix64"
Você pode verificar nas opções do corredor lutris
Agora você está trabalhando dentro do prefixo winesteam

Vou usar o dotnet 40 como exemplo de como remover a dependência em winetricks, pois precisamos fazer isso com certeza,
Certifique-se de que o mono está desativado digitando winetricks remove_mono
Tente digitar winetricks dotnet472 - vai tentar, mas para mim falha no início tentando instalar o 40 alegando que já está atualizado - isso impede que o winetricks nunca instale um.
Portanto, abra / usr / bin / winetricks no aditor de texto e encontre "load_dotnet472"

`` `
load_dotnet472 ()
{
w_package_warn_win64

if w_workaround_wine_bug 42170 "Running un-official repacked .NET 4.7.2 setup until the official version is fixed.", 3.1; then
    # Un-official slim version. See https://repacks.net/forum/viewtopic.php?t=7
    file_package="dotNetFx472_Full_x86_x64_Slim.exe"
    w_download "https://drive.google.com/uc?export=download&id=1aLBCH0Yt2-6ROpWRBxZ01kqGMyhc_8hM&confirm" a36da041b8f46079f8e16647312d642953cde520f4a600ad5b3f4f90a23495a7 $file_package
    unattended_args="/ai /gm2"
else
    # Official version. See https://www.microsoft.com/en-us/download/details.aspx?id=53344
    w_download https://download.microsoft.com/download/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe c908f0a5bea4be282e35acba307d0061b71b8b66ca9894943d3cbb53cad019bc
    file_package="NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
    unattended_args="/sfxlang:1027 /q /norestart"
fi

w_call remove_mono

w_call dotnet462
w_set_winver win7

`` `

Há algumas coisas a serem observadas aqui:

• você vê w_call para dotnet462, então você precisa ir para load_dotnet462 e repetir até chegar ao que chama o que está falhando - então em nosso exemplo w_call dotnet40 está em load_dotnet48 e precisa ser removido para seguir em frente.
  Você precisará fazer isso para cada instalador que não irá instalar automaticamente através do winetricks (você instalou manualmente) ou se ele for instalado com sucesso, mas os winetriks não marcarão como instalado.
  Coisas que você precisa se o instalador falhar:
• em w_set você precisa da versão win para o instalador
• em w_download você tem 2 urls (neste caso) que você pode colar no navegador da web para baixar o instalador
• em unattended_args você tem argumentos para executar o instalador com

presumindo que você removeu a chamada para dotnet40 e salvou o arquivo, você pode tentar novamente.
Ele irá falhar alguns instaladores depois disso -

• se o instalador alegar que a instalação foi bem-sucedida, mas o winetricks queixa-se de arquivos ausentes no final e não vai instalar o próximo, remova o w_call para ele - ele provavelmente foi instalado corretamente, mas a verificação falhou.
• se nem mesmo começar, tente se o url está funcionando - se não, pesquise na página microsft ou no google pelo nome .exe
• se o url estiver ok, baixe-o,
  definir a versão win de acordo com a parte winetricks para esse ex dotnet. winetricks win7
  tente executá-lo wine <installer>.exe <arguments from winetricks>
• Se falhar, tente sem os argumentos - você terá que clicar em próximo;)
• Se falhar e você tiver mais de um url / instalador, tente o outro
• se não for instalar, remova o w_call e torça para que este não seja necessário - pelo menos um deles falhou independentemente do que eu fiz, mas o jogo roda.

Depois de ter o dotnet472 finalmente instalado, você só precisa adicionar algumas coisas (não tenho certeza de que sejam todas necessárias)
winetricks xact vcrun2013 vcrun2015 vcrun2017 faudio d3dx9 d3dx10 corefonts - não tenho problemas aqui
xact-this on é necessário com certeza

Em seguida, no lutris, clique em Wine steam na lista de corredores e sinal de + acima da lista para adicionar o jogo.
Digite um nome e na guia "Opções de jogo", o steamid 244850 para o eng espacial
Ícones e resto são opcionais,
Verifique as opções do corredor
Argumentos: %command% -no-cef-sandbox
versão vinho: ge-protonified-nofshack-4.9
DXVK: 1.2.3 e habilitado
Inicie-o a partir da lista de aplicativos e ele deve funcionar a vapor e iniciar o download

Espero que funcione!

Mencione-me se precisar de ajuda ... ou [email protected] - é público de qualquer maneira

Não consegui rodar o jogo com lutris (Steam diz que não tenho rede), mas instalei no Steam com protontricks 1.2.2 e winetricks 20190310. Proton 4.9.2.
Eu instalei dotnet472 xact vcrun2013 vcrun2015 vcrun2017 faudio d3dx9 d3dx10 corefonts.
Renomeei o vídeo de introdução e inicio o jogo com: PROTON_NO_ESYNC = 1% command%

E honestamente o jogo correu bem. Tenho cerca de 100 fps no planeta com configurações gráficas altas. Consegui começar um jogo com vários mods. Não joguei atm por horas, tenho que reservar um tempo para fazer mais testes.
A mineração nas rochas estava ok, a mineração era boa no planeta ou asteróides. Comecei com o mapa do sistema estelar.

Tenho um bug de som como todo mundo, mas está tudo bem depois de alguns minutos. O bug continua menos perceptível, mas você pode jogar. Tenho que fazer um teste se entro em outro jogo, sem hospedar o jogo.

Parece que o jogo está perto de ser jogável sem problemas, exceto pelo bug de som.

Obrigado por todas as dicas desta página!

@LtStich O dotnet472 foi instalado corretamente sem problemas para você?
Se sim, é uma ótima notícia, eles finalmente consertaram o script. Eu confirmo um
pequeno som gagueja logo após o início. Eu também notei que as sombras
às vezes tremem estranhamente, mas não sei se é a culpa do jogo ou
próton

czw., 18 lip 2019 o 11:26 LtSich [email protected] napisał (a):

Não consegui rodar o jogo com lutris (Steam diz que não tenho
rede), mas eu instalei no Steam com protontricks 1.2.2 e
winetricks 20190310. Proton 4.9.2.
Eu instalei dotnet472 xact vcrun2013 vcrun2015 vcrun2017 faudio d3dx9
d3dx10 corefonts.
Renomeei o vídeo de introdução e inicio o jogo com: PROTON_NO_ESYNC = 1
%comando%

E honestamente o jogo correu bem. Tenho cerca de 100 fps no planeta com alta
configurações gráficas. Consegui começar um jogo com vários mods. Eu não
jogar por horas atm, tenho que dar um tempo para fazer mais teste.
A mineração nas rochas estava ok, a mineração era boa no planeta ou asteróides. eu comecei
com o mapa do sistema estelar.

Tenho um som parecido com o de todo mundo, mas tudo bem depois de alguns minutos. O inseto
continu menos perceptível, mas você pode jogar. Tenho que fazer teste se entro
outro jogo, sem hospedar o jogo.

Parece que o jogo está perto de ser jogável sem problemas, exceto
o bug de som.

Obrigado por todas as dicas desta página!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792?email_source=notifications&email_token=ABSXEL3A4XGGNMQUHZ4NSITQAAZNVA5CNFSM4F6IMNRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2H4LLQ#issuecomment-512738734 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABSXEL6J4HFRILSQPK5FHVLQAAZNVANCNFSM4F6IMNRA
.

@MagicRB Foi bom, mas com protontricks 1.2.2 e winetricks 20190310.
A versão mais recente de winetricks parece ter problemas, devo tentar novamente, mas agora que o jogo está funcionando, não quero quebrar tudo :)

Vou brincar um pouco mais e ver se está tudo bem.

Sim, não consigo fazer o jogo funcionar porque o protontricks (1.2.3-1) não instala o dotnet porque pensa que já está instalado. Isso é com uma nova instalação de arco também, então há um grande mau funcionamento nas versões recentes do vinho ou algo assim. Bastante pita, quem sabe se algum dia será consertado ..

Se apenas MONO emulado dotnet 472 ....

Esses problemas devem ser documentados e instalados pelo Steam diretamente para o jogo ...
É chato precisar brincar com prototricks e winetricks ...

Qual versão de winetricks você usa? Você sabe que pode fazer uma instalação manual para usar uma versão específica ...

wget http://winetricks.org/winetricks -O / usr / bin / winetricks

Mais recente, qual é o comando para instalar a versão de trabalho correta?

Aqui está uma parte interessante que percebi.
A mesma gagueira que normalmente está presente no jogo se torna muito frequente se você puxar qualquer ferramenta manual.

As passagens de renderização DXVK também parecem dar um salto para os três dígitos na gagueira.

Em outras notícias, quando o wine mono estará pronto para executar aplicativos dotnet 4.7.2? Alguém sabe o que está implementado até agora?

wget http://winetricks.org/winetricks -O / usr / bin / winetricks

Mais recente, qual é o comando para instalar a versão de trabalho correta?

Acesse aqui: https://github.com/Winetricks/winetricks/releases
Download: 20190310
Descompacte, vá para src para obter truques de wint.

Desinstale o Winetrick que você possui.
E coloque os winetricks que você baixou em seu caminho (/ usr / local / bin para mim no Debian).

Depois disso, tente reinstalar do zero o SE e tente reinstalar tudo o que você precisa.
Não se esqueça de renomear o vídeo de introdução.

ok instalar o dotnet agora parece funcionar. POR QUE os mantenedores do Winetricks prejudicariam o suporte .net? ninguem sabe? Parece que ninguém percebe, mesmo que seja essencial para tantas coisas, que é como lançar uma atualização do wine que impede que o .exe funcione ... uma loucura!

Enfim deixei um problema no github sobre isso, quem sabe alguém vai notar ....

Sobre o jogo, parece que está carregando agora, o som falha um pouco, eu carreguei um jogo personalizado no planeta Terra e ele carregou bem, exceto muitas falhas e pausas, provavelmente relacionadas ao motor de som ter problemas, também alertou sobre problemas de desempenho algumas vezes, mas isso parece ter desaparecido.
Eu diria que os problemas estão relacionados ao motor de som que causa os problemas de gagueira, etc ...

Não tenho certeza se o problema está relacionado ao mecanismo de som, mas provavelmente é sobre o desempenho que afeta o áudio. Eu tinha outro jogo como este, o som gaguejava, mas depois que comprei uma nova CPU ele funcionou bem.

Do meu lado, já jogo há algumas horas, o jogo geralmente roda bem, mas a velocidade do sim não passa de 0,8.
Desativei a música, mas isso não altera o desempenho.

Poucos travam, mas em geral o jogo é jogável se você aceitar alguns atrasos / travamentos e travar. Tenho cerca de 100fps em configuração gráfica média na Terra.
Provavelmente testarei meu minerador de atmo hoje, verei se o jogo não trava. Na verdade, tenho apenas um pequeno veículo espacial ...

Eu instalei dxvk 0.96 com protontricks, mas isso não muda nada.
Meu CPU não está muito usado, a carga é pequena, mas o jogo parece não conseguir usar todo o núcleo ou desempenho do computador.

Como eu disse antes, para mim o problema de som é a consequência do problema de desempenho global (provavelmente do lado da CPU) e não o motivo do jogo travar ... Não sei o que podemos fazer sobre isso ...

ok instalar o dotnet agora parece funcionar. POR QUE os mantenedores do Winetricks prejudicariam o suporte .net? ninguem sabe? Parece que ninguém percebe, mesmo que seja essencial para tantas coisas, que é como lançar uma atualização do wine que impede que o .exe funcione ... uma loucura!

Enfim deixei um problema no github sobre isso, quem sabe alguém vai notar ....

Sobre o jogo, parece que está carregando agora, o som falha um pouco, eu carreguei um jogo personalizado no planeta Terra e ele carregou bem, exceto muitas falhas e pausas, provavelmente relacionadas ao motor de som ter problemas, também alertou sobre problemas de desempenho algumas vezes, mas isso parece ter desaparecido.
Eu diria que os problemas estão relacionados ao motor de som que causa os problemas de gagueira, etc ...

Eu duvido que eles fariam isso intencionalmente, é mais provável que a Microsoft altere o instalador .Net de alguma forma, então o número da versão é diferente do que o Winetricks estava procurando, eles adoram mexer.

os instaladores dotnet não mudaram

os instaladores dotnet não mudaram

Bem, com coisas assim, tudo o que precisamos é um único erro de grafia em uma única linha para causar todos os tipos de problemas, eu seriamente duvido que os mantenedores do Winetricks fariam algo assim para nos ferrar, qual seria o ponto?

Parece que o Wine 4.12.1 instala o .Net de tal forma que funciona com o Wine 4.12.1, enquanto o Wine 4.2 o instala da forma que funciona com o 4.2. Definir WINE e WINESERVER variáveis ​​de ambiente apontando para os binários do Proton fez winetricks funcionar de forma confiável.

Em relação ao jogo, fico gaguejando muito por causa do som: a velocidade de simulação é 1, mas graças aos efeitos sonoros ela reduz para 0,73 e volta a 1 depois. Se eu usar o soldador Simulation Speed ​​cai para 0,53 até que se recupere. O problema ocorre independentemente de eu remover as bibliotecas FAudio ou usar winetricks xact , mesmo com o som desativado isso acontece, realmente perceptível com o soldador.

Parece que há um bug gráfico nos cantos do capacete e nas fontes de luz, mas isso é secundário.

Informação do sistema

Com o Proton 4.11-1, ele funciona imediatamente se você tiver renomeado o arquivo de vídeo. Mas há bastante gagueira, tanto para áudio como visualmente. Instalar dotnet472 e xact não parece resolver isso. Alguma dica?

Eu também não descobri como resolver a gagueira, se não fosse pela gagueira, então estaria tudo bem, mesmo em 4k no meu 1080TI deu 50-60fps o que é bastante bom, exceto pelas gagueiras ...

Nenhuma mudança de desempenho para mim com 4.11.
Eu continuo pensando que o problema de som é um problema de desempenho e não um problema de som (veja a velocidade do sim). O som falha por causa da estabilidade / desempenho ruim.

Mudar para o kernel 5.2 melhora o desempenho. Mas o problema do som está sempre aqui.

Também não posso confirmar uma melhoria de desempenho para mim com o Proton 4.11. Também experimentei a função FSync no Arch Linux com o kernel linux-fsync fornecido. Verificou-se que o kernel correto está carregado e não pode confirmar uma melhoria aqui também, infelizmente. A gagueira ainda está lá.

Uma pequena questão: o jogo foi iniciado com DXVK_HUD=full %command% . O gráfico de tempos de quadros mostra barras vermelhas quando ocorre a gagueira. Presumo que isso não tenha nenhum significado especial além de que nenhum quadro é renderizado.

Eu notei que a velocidade de simulação "ociosa" ficou um pouco maior aqui, de 0,73 para 0,87 de forma consistente. O problema de desempenho que ocorre, aparentemente, quando os sons são reproduzidos ainda está presente. É estranho que ele continue rodando na velocidade de simulação de 0,87 mesmo quando há, supostamente, ciclos sobressalentes de CPU suficientes.

Percebi que muitas vezes o jogo parece recriar os fluxos de som. pavucontrol mostra que o stream do jogo é o stream 2, mas mais tarde é o stream 6 e depois é o stream 10 ao usar pulseaudio.

Além disso, toda vez que fecho o jogo, ele abre o Wine Debugger e, em seguida, abre a janela dizendo que o jogo travou.

Gravei um vídeo mostrando um pouco do status do jogo, incluindo os problemas de som: https://cdn.discordapp.com/attachments/457747189616214019/606572169886957577/se-sound000.webm

O comando winetricks que usei para o prefixo atual é winetricks -q xact dotnet472 vcrun2013 vcrun2015 vcrun2017 faudio sound=alsa . E as especificações atuais do

Interessante, claramente tenho um desempenho melhor e não tenho esse problema ao usar ferramentas (pelo menos não tanto). A velocidade do meu sim está entre 0,7 e 0,9.

Quando jogo, se executo o htop, vejo claramente que minha CPU não está totalmente usada, pois tenho muitos "recursos sobressalentes" disponíveis. Eles provavelmente podem fazer algo sobre isso ... Como mudar o vídeo para o menu iniciar e não usar aquele formato wmv ... Talvez todas as coisas sobre o som sejam o mesmo problema ... Arquivos muito do tipo "windows" e ferramentas ...

[EDITAR]
Teste rápido no espaço, sem mods. Pequeno problema de som, mas muito pequeno.
Velocidade do Sim entre 0,9 e 1. Não desça abaixo de 0,8, mesmo quando eu uso ferramentas.
Cerca de 100 fps com alta configuração gráfica.

O desempenho provavelmente cairá se o drone surgir, tenho um grande problema com isso no meu jogo com mods na terra. Como o jogo provavelmente não consegue usar todo o núcleo ou distribuir a carga.
[/EDITAR]

Confirmamos que um apitrace para este jogo não vai ajudar neste problema específico? Parece que pode ser um problema relacionado ao vinho e não ao dxvk.

Na verdade, existem 3 ou 4 problemas de rollup, como eu os entendo:

1. o áudio precisa de alguns recursos avançados do FAudio para funcionar. Isso não é mesclado a partir do Proton 4.11. Mesmo com o FAudio, você verá uma quantidade significativa de falhas de áudio, que podem diminuir dependendo da sua máquina / cpu / taxa de quadros / etc.
2. dotnet472 é necessário. Eu acho que Proton 4.11 corrige isso?
3. o vídeo ingame não funciona. Provavelmente um problema de estrutura de mídia como muitos outros jogos.
4. Ainda não fui capaz de testar com o Proton 4.11, mas pelo menos no 4.2, o analisador PNG 'windowscodecs' (ou o código upstream dele) não lida corretamente com a ordem de bytes de PNGs em tons de cinza de 16 bits, que é o que VRAGE (o motor dos engenheiros espaciais) usa para seus mapas de altura planetários. Isso pode ser corrigido, mas eu mudei de uma máquina nvidia para um Vega, então estou sendo atingido por travamentos de GPU vistos em https://github.com/doitsujin/dxvk/issues/252 quando tento executar o SE no um planeta. Posso voltar e verificar a máquina nvidia algum tempo depois, mas se você estiver vendo planetas 'pontiagudos', consulte https://source.winehq.org/git/wine.git/commit/0c0def962f2b86f44625f11d8d9d2013aaffa46a se quiser tentar backporting essa correção.

@kainz
Os bits de Faudio ausentes estão causando a gagueira no jogo?
Algum problema aberto ou patch para testá-los que você conhece?

Eu sei que já foi criado um perfil antes e a gagueira não era resultado de nenhuma chamada DX.

Não sou dev, mas na minha opinião o problema que temos com o SE está mais relacionado ao multi thread e performance.
Provavelmente no que eles estão trabalhando: https://lkml.org/lkml/2019/7/30/1399 e com a substituição do esync: fsync: https://steamcommunity.com/games/221410/announcements/detail/2957094910196249305

Isso precisa de um kernel muito recente, talvez alguém no Arch possa fazer alguns testes ... Vou ver como uso o kernel Liquorix no Debian ...

Para instruções fsync: https://steamcommunity.com/app/221410/discussions/0/3158631000006906163/

O jogo inicia apenas com Mono, mas recebo esta mensagem (clicando em fecha o jogo):

Surpreendentemente, eu não tinha gagueira de música do menu quando isso apareceu, talvez a gagueira seja devido ao próprio dotnet no vinho?

Uau! Arrumado! Como você conseguiu lançar com Mono?
@LtSich
Usuário do Gentoo aqui, o fsync não ajuda. Se for mono como @ fls2018 disse acima, então isso poderia ser uma boa solução.

depende se gagueja no jogo.

Uau! Arrumado! Como você conseguiu lançar com Mono?
@LtSich
Usuário do Gentoo aqui, o fsync não ajuda. Se for mono como @ fls2018 disse acima, então isso poderia ser uma boa solução.

Apenas um novo prefixo com a instalação de prótons mono por padrão, eu também tive que mudar as dlls xaudio para nativas, pois faudio faz com que travem. Eu estou supondo que o pop-up é porque ou mono precisa de wpf ou talvez esteja procurando por .Net, encontrando mono e se recusando a continuar. Nos logs, vejo que ele reconhece mono como o ambiente: Environment.Version: Mono 6.3.0 (tarball)

Eu também instalei o dotnet472 novamente, ele me permitiu entrar no jogo, mas voltou a falhar o menu, também usando o kernel fsync.

Então você diz que não há gagueira com mono, mas o jogo se recusa a continuar sem dotnet ...
Isso é algo que KSH poderia mudar diretamente em seu jogo para nos ajudar?
O mesmo que mudar o formato do vídeo para evitar renomear o vídeo de introdução e poder vê-lo em segundo plano no menu ...

Isso pode ser algo que a KSH poderia mudar. Se eles removerem a verificação dotnet na presença de vinho, isso pode ajudar, mas é claro: NÃO siga o conselho dos desenvolvedores de vinho.

Devemos abrir um relatório de bug no WineHQ e obter alguma assistência, assim como o problema de pico de terreno. Onde posso encontrar esse binário mono egde sangrando?
Vou testar uma compilação noturna.

Agora que testei isso, pode valer a pena pedir aos desenvolvedores para desbloquear o uso de mono. Eles verificam a variável de ambiente para ver se você está executando o dotnet com erros antigos para dizer para atualizar, mas parece que ele não leva em conta um valor nulo e simplesmente descarta o jogo por completo.

Os estados de log: 03/08/2019 11: 07: 01.985 - Thread: 1 -> Erro ocorrido durante a enumeração das informações do ambiente. O aplicativo continua. Exceção: System.ArgumentNullException: o valor não pode ser nulo.

Neste caso, se pudermos pedir ao KSH para retirar o cheque, o Proton pode funcionar com uma classificação Gold tão rapidamente no protondb!
Onde é um bom lugar para pegar o jeito de Keen?

Então você diz que não há gagueira com mono, mas o jogo se recusa a continuar sem dotnet ...

Só para deixar claro, estou falando sobre a gagueira da música do menu, que parece estar relacionada à gagueira do jogo. O problema pode não ser o áudio ou os gráficos, mas o fato deste jogo depender mais do .Net do que de alguns outros títulos e do .Net via winetricks é, na melhor das hipóteses, instável.

Pode ser que ele precise apenas de mono para não ser bloqueado pelo cheque e está tudo bem, no entanto, se o jogo usa outro material de .Net como WPF, então pode ser o caso de estar exibindo o pop-up porque não pode ser não disponível em mono (ainda).

@SpookySkeletons

Provavelmente aqui: https://forum.keenswh.com/

1 dev da KSH deve realmente se juntar a nós aqui e dar uma olhada nisso ...
Este e o formato de vídeo para usar algo que funcionaria no Linux para evitar a necessidade de renomear o vídeo de introdução ...

Não consigo receber um e-mail de confirmação da minha conta antiga, parece que outra pessoa terá que fazer o tópico. Como @LtSich disse, aponte-os para nosso git para que possamos

Eu sei que KSH também está ativo no Discord se alguém tiver um link para seu canal, você pode enviar uma mensagem para lá.

Aqui está a discórdia oficial: https://discordapp.com/invite/KeenSWH

Precisamos perguntar se o jogo requer WPF ou outros componentes específicos do DotNet.
Desbloquear mono não valerá muito se eles estiverem usando recursos não implementados.

Proton 4.11-1 adiciona uma regressão que reintroduz a geração de terreno com bugs

Proton 4.2-9 funciona bem, mas ainda tem gagueira, mas parece ser DotNet como SpookySkeletons e fls2018 mencionaram

Parece que a versão 4.11 traz muitos problemas.
Empyrion e Frostpunk não começam mais, mas funcionam bem com 4.2-9.

Aparentemente, a SE tem alguns problemas com a geração do terreno.
Não vi isso, mas só joguei alguns minutos para testar se o jogo começava.

tentei rodar com 4.11-1 com d9vk habilitado. dá um erro que o .net framwork está desatualizado e usa um hotfix do Windows e então trava.

tentei rodar com 4.11-1 com d9vk habilitado. dá um erro que o .net framwork está desatualizado e usa um hotfix do Windows e então trava.

O jogo não deve rodar em DirectX 9 a menos que você reverta alguns patches.

DXVK e Proton 4.2-9 com DotNet 472 são atualmente a única forma conhecida de rodar o jogo.
No entanto, irá gaguejar e, atualmente, isso não é evitável.

Eu tentei: https://twitter.com/LtSich/status/1158672187022348288

É mais uma falha de desempenho do que qualquer coisa, algo está engatando, se esse algo for resolvido, o jogo terá um desempenho e funcionará bem com bons fps.

Punho de tudo, GRANDE TRABALHO.
Você percorreu um longo caminho que somente os verdadeiros engenheiros podem seguir. É uma verdadeira dedicação bem aqui. : +1:

Agora, de volta ao assunto.
Com relação aos problemas de desempenho que você mencionou, eu recomendo que você mude para uma "construção de modding" que distribuímos junto com a versão vanilla no Steam.
Além de um monte de guloseimas para modders, ele vem com nosso profiler interno habilitado para que você possa ver exatamente o que está deixando seu jogo mais lento. É sempre mais fácil _ consertá-lo_ quando você sabe qual é o problema.

Você encontrará tudo o que precisa aqui:
https://github.com/malware-dev/MDK-SE/wiki/Advanced-Profiling-The-Game

Quando se trata da "verificação da versão .NET", o jogo não impõe nenhuma versão específica do .NET, desde que todos os componentes sejam iniciados e executados corretamente.
Depois de uma rápida olhada no código, parece que esta caixa de mensagem foi disparada por uma falha na inicialização do compilador de script. Se for esse o caso, você deverá ver a seguinte linha no log do jogo:
"Erro durante a inicialização do ModAPI: ALGUMA MENSAGEM AQUI"

O compilador não é essencial para o jogo, contanto que você não exija mods ou scripts no jogo, para que possa executá-lo para teste. Você sabe mexer nos binários do MSIL, certo?
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/Sandbox.Game/MySandboxGame.cs#L1401

@InflexCZE
Obrigado pela informação.

Não tenho muita experiência em edição de IL, mas consegui editar esse valor e chegar aos menus com mono:

Mas ao tentar carregar um jogo, ele trava com este erro:

Aqui está o registro:

SpaceEngineers.log

Provavelmente, eu não editei a dll corretamente, ela está mostrando erros sobre a existência de uma duplicata de algo na lista de permissões.

Com base no log, o casamento de Mono e nosso compilador não é particularmente feliz: stick_out_tongue:
Tudo bem, não precisamos disso.

Infelizmente, não há um ponto único para desabilitar o compilador (ainda), então você terá que eliminar 2 lugares-chave que identifiquei e espero pelo melhor.

1) Obtenha a casca de todas as coisas neste ctor.
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptWhitelist.cs#L47

2) Faça com que este método retorne null (evite que ele invoque o núcleo do compilador)
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptCompiler.cs#L154

@InflexCZE existe uma compreensão do que falha e por quê? Ou uma maneira de criar um pequeno teste que falhe de maneira semelhante.

Cada tempo de execução .NET (.NET FW, Mono, .NET Core, Xamarin, ...) vem com sua própria biblioteca de classes base (BCL). Embora a implementação e a funcionalidade sejam muito semelhantes em todas as áreas, e o programa compilado com um BCL específico em mente normalmente seja adequado quando dada uma implementação diferente em tempo de execução, algumas diferenças ainda existem.

Nesse caso, é a distribuição de certos tipos de BCL entre os binários de BCL que está confundindo o compilador. Alguns ajustes rápidos provavelmente resolveriam o problema e tornariam o compilador totalmente funcional no Mono BCL também, mas isso seria um pouco mais difícil do que derrubar o compilador e testar se o jogo roda melhor ou não no Mono-Linux. Nesse caso, podemos nos concentrar no polimento.

Espero que isso responda sua pergunta de forma compreensível: smile_cat:

Bem, eu tentei fazer o contrário e tentar fazer a construção do profiler funcionar, mas tive menos sorte com isso. Eu instalei o Mod SDK e tentei executar o jogo instalando dotnet472 e xact em seu prefixo e vinculando simbolicamente a pasta Contents ao seu caminho (é assim que eu realmente executei o Mod SDK na minha instalação do Windows) e copiando a pasta Bin64_Profiler para a minha instalação normal (onde tudo já está funcionando e posso iniciar o jogo). Nenhuma das abordagens realmente funcionou.

Eu defini todas as variáveis ​​de ambiente que o wine pode precisar e usei o wine encontrado em ~/.local/share/Steam/steamapps/common/Proton 4.11 , tentei executar proton run partir desse diretório, mas todos os métodos produziram os mesmos resultados:

• Recebi um aviso sobre a execução sem o runtime do Steam e me instruindo a alterar o valor da variável MyFakes.ENABLE_RUN_WITHOUT_STEAM , o que não posso fazer sem editar o assembly, pelo menos pelo que entendi.
• Em seguida, reclamou sobre a execução de atualizações do driver do Windows e da placa gráfica
• Depois de tudo isso, tudo que consigo é uma falha, com o seguinte rastreamento de pilha

Unhandled Exception: System.ArgumentException: Parameter is not valid.
   at System.Drawing.Image.get_Flags()
   at System.Windows.Forms.ControlPaint.IsImageTransparent(Image backgroundImage)
   at System.Windows.Forms.Control.set_BackgroundImageLayout(ImageLayout value)
   at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm.InitializeComponent()
   at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm..ctor(MyCrashScreenTexts& texts)
   at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm.ShowDialog(MyCrashScreenTexts& texts, String& message, String& email)
   at Sandbox.MyErrorReporter.ReportGeneral(String logName, String gameName, String id)
   at Sandbox.MyCommonProgramStartup.PerformReporting()
   at SpaceEngineers.MyProgram.Main(String[] args)

O que não é muito útil, porque essa é a mensagem do relatório de falha ao carregar ...

Se alguém tiver uma ideia sobre o que estou fazendo de errado e conseguir fazer a construção de perfil funcionar, as instruções adequadas serão apreciadas, quanto mais olhos no problema, melhor :)

Forneça o log do jogo. Deve conter a exceção original.

Log anexado:

SpaceEngineers.log

Como ele está mencionando DX9 em alguns dos namespaces, tentei executá-lo sem o DXVK pensando que poderia estar errando, mas não parece ter ajudado.

O problema está realmente em algum lugar interno deste método (Windows Forms), pois falhou ao carregar a imagem do cursor do jogo.

https://github.com/mono/mono/blob/master/mcs/class/System.Drawing/System.Drawing/Image.cs#L154

at System.Drawing.Image.FromStream(Stream stream, Boolean useEmbeddedColorManagement, Boolean validateImageData)

Espero que alguém saiba o que está acontecendo, porque é aqui que meu campo de especialização termina.

Bem, eu também estava fazendo algo errado ao mexer manualmente com o prefixo, então tentei apenas largar a pasta Bin64_Profile em minha instalação normal e renomeá-la para Bin64 . Isso ajudou um pouco (pegou a tela inicial), mas provavelmente está falhando devido a bits adicionais incluídos na construção de perfil. Primeiro, ele falha em obter o nome do sistema operacional (usando Mono, não reclama com o real MS dotnet instalado), mas parece superar isso (com o nome do sistema operacional aparentemente correto também, então, sim ...), mas falha na tentativa de inicializar os gráficos (isso acontece com DXVK ativo e ao definir USE_WINED3D ). Então, parece que a construção de perfil não carregará por enquanto.

SpaceEngineers-Mono.log

Mono log anexado, a falha real é a mesma com o dotnet, isso apenas demonstra a falha do Mono também.

Largue aqui o log de renderização também, por favor

Ah, nunca percebi que isso é escrito por ele. Aqui está:

VRageRender-DirectX11.log

Falha na compilação do shader, ao que parece. Existe uma maneira de obter versões pré-compiladas desses em algum lugar?

Interessante. O jogo já vem com shaders pré-compilados em %SE_install_dir%/Content/ShaderCache .
Verifique se eles estão intactos, não corrompidos nem nada.

O diretório alternativo do cache para sombreadores compilados por jogo é %dir_where_you_found_the_logs%/ShareCache2 .
Você pode tentar copiar o cache aqui para ver se o jogo tem melhor sorte em encontrá-lo aqui.

Tentei verificar os arquivos, tentei copiá-los para %appdata%/SpaceEngineers/ShaderCache2 , até tentei %SE_install_dir/TempContent/ShaderCache apenas no caso de a compilação de perfil tentar aquele também, mesmo resultado em todos os casos :(

Hm, é possível que a criação de perfil adicione algum código de perfil aos sombreadores também, o que tornará o cache fornecido inutilizável.

Você disse que tem SE rodando no Win também, certo?
Talvez você pudesse tentar executar a criação de perfil no Win e, em seguida, copiar o cache de shader gerado para o Linux?

vocês estão tentando fazer isso funcionar sem dotnet (com mono), ou tentando resolver a gagueira? (ou ambos).

Bem, no lado da criação de perfis, estou tentando com o dotnet, pois sabemos que ele carrega completamente e é jogável, então, esperançosamente, poderíamos definir os travamentos nessa frente. Dado que o problema atual com mono é que o compilador não funciona, o que significa que os scripts e mods não funcionarão mesmo se o enganarmos para carregar, acho que pode ser um melhor curso de ação por agora, tanto na frente de começar o jogo totalmente funcional e podemos fixar para baixo um problema na Proton que, se fixa, pode afetar outros jogos também e fazê-los funcionar.

Infelizmente, no momento estou preso nessa frente - acessei minhas partições do Windows e tentei copiar os shaders de lá (havia muito mais arquivos presentes), mas sem sorte, exatamente o mesmo travamento. Eu planejei também limpar completamente tudo na minha instalação do Windows e apenas iniciar o jogo no modo de criação de perfil de uma tela em branco para ter certeza de que os shaders foram compilados, mas minha instalação do Windows não está inicializando atualmente devido a alguma partição e embaralhamento do HDD recentemente e ainda não consegui consertar (ou reinstalar).

Se alguém mais tiver um dual boot funcionando (ou um PC extra com Windows instalado) e puder refazer meus passos para ver se ele roda com arquivos de sombreador compilados copiados, isso seria ótimo. Enquanto isso, tentarei fazer com que minha instalação do Windows funcione novamente quando tiver algum tempo livre para fazê-lo.

Eu deveria ter instalado um Windows 10 funcionando, não o usei por um tempo, mas ele deve funcionar. Quando eu chegar em casa, vou tentar fazer aquela coisa de shader.

@InflexCZE obrigado por nos ajudar, pessoal do Linux! Sem querer ser rude nem nada, mas já faz muito tempo que pedimos ajuda, o que mudou?

Então, consegui obter novos shaders de uma instalação do Windows (envolvia compartilhamento de família, um colega de quarto e subornos, ainda menos incômodo do que reinstalar o Windows).

Bem, sem dados, parece que a intenção é recompilar esses shaders, não importa o quê. Tentei instalar tempos de execução Visual C também (todos eles de 2010 em diante, mas 2015 falhou na instalação e eu realmente não me incomodei em tentar fazer isso funcionar também) na esperança de que esteja faltando apenas alguns tempos de execução C ++, mas sem sorte com isso também.

Então, a menos que vcrun2015 em particular ajudasse (o que, dados os erros, eu duvido), estou sem ideias, isso envolve shaders e coisas específicas de VRage que estão bem acima da minha cabeça. Caso outra pessoa consiga fazer isso, por favor, poste seus resultados.

@ Onyx47 o que preciso fazer para chegar ao estado que você está?

@MagicRB Tudo o que fiz foi instalar como todos nós fizemos até agora (incluindo protontricks 244850 -q dotnet472 xact ), instalei a versão do Mod SDK da página de ferramentas e copiei sobre o diretório Bin64_Profile para o diretório de instalação SE regular e renomeou-o para Bin64 após renomear o original para Bin64_bak .

Iniciar o jogo a partir do Steam tentará executar a construção de perfil. Para referência e para poupá-lo de vasculhar a estrutura do diretório (você deve ser capaz de copiar e colar os caminhos em seu gerenciador de arquivos / terminal):

• A instalação do SE deve ser em ~/.steam/steam/steamapps/common/SpaceEngineers/
• A instalação do Mod SDK de onde você deve obter o diretório Bin64_Profile deve estar em ~/.steam/steam/steamapps/common/SpaceEngineersModSDK/
• SpaceEngineers.log e VRageRender-DirectX11.log devem estar em ~/.steam/steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers

Filho de um Klang, ele corre! Tudo o que precisávamos era de d3dcompiler_47 pacote de winetricks. E lá estava eu ​​instalando tempos de execução XNA e VC para tentar ver se algum deles continha os cabeçalhos ausentes ( float.h e xnamath.h ) sobre os quais ele estava reclamando ...

Bem, ele começa agora, mas infelizmente falha ao criar ou carregar um mundo. Posso confirmar que o criador de perfil funciona pelo menos no menu (e a gagueira está presente mesmo lá, então pode ser algo com que possamos trabalhar de qualquer maneira).

Estou anexando meus logs mais recentes desde o momento em que ele começou até tentar carregar um mundo (após o qual ele travou). Estou percebendo que a última linha em SpaceEngineers.log é

External debugger: listening...

Pode ser o que está travando, pode não ser, mas ... Não estou familiarizado com depuração remota em .NET, é que apenas um soquete como gdb fornece e há uma chance de anexarmos a ele usando MonoDevelop ou algo assim? Ou há pelo menos uma maneira de obter algumas informações significativas dele mesmo no menu sozinho, mesmo sem isso? Como despejar alguns logs de perfil em um arquivo em algum lugar? Não vejo nada sobre isso no Wiki vinculado.

cc: @InflexCZE

NOTA (principalmente para Inflex): Não se preocupe com os erros de vídeo, estamos cientes de que ele não carrega e realmente não nos importamos de qualquer maneira, o jogo roda após clicar nele.

SpaceEngineers.log

VRageRender-DirectX11.log

Edit: Algumas imagens do profiler no menu, pelo menos, os principais culpados parecem ser MyAudio-Update (como foi pelo menos parcialmente suspeitado) e GuiManager - Update Screens , que não é realmente o que eu esperava.

https://imgur.com/a/S1O435i

Boas notícias: +1:

Infelizmente, os logs não contêm nenhuma informação útil que me ajude a determinar a causa da falha. O problema mais provável no código nativo, resultando em falha de segmentação e sistema operacional encerrando o processo imediatamente. A maneira usual de depurar isso é instruir o sistema operacional a fazer um dump mini / completo do processo antes de derrubá-lo. Se você conseguir capturar um e resolver o rastreamento de pilha dele, provavelmente poderei dizer o que está acontecendo. Uma vez que as venezianas também estão presentes no menu principal, eu não me importaria com isso agora e passaria diretamente para o perfil.

Para fazer isso:
1) Inicie o jogo no menu principal
2) Abra o profiler com Alt + [NumPad Dot]
3) Mudar o profiler para o modo de profiling profundo Alt + E
4) Colete uma janela completa de criação de perfil de dados (aguarde 1024 frames)
5) Salve no slot # 1 com LCtrl + Alt + 1
6) Localize e compartilhe o arquivo em% appdata% / FullProfile1

Todas essas informações estão no manual que postei antes:
https://github.com/malware-dev/MDK-SE/wiki/Advanced-Profiling-The-Game

Editar:
"MyGuiSandbox :: Update3" atualiza a entrada do jogo (coleta os estados do mouse, teclado e joystick do sistema operacional). Temos vários blocos de perfil lá também, eu me pergunto por que eles não aparecem. Ative o perfil profundo se eles aparecerem nesse modo.

@InflexCZE : Ok, reescrevendo todo o meu post porque você finalmente me forçou a tentar aprender como usar o depurador Wine e realmente encontrou a causa da falha imediatamente: perder o tempo de execução do VC 2003, presumo que seja um requisito ao instalar o ModSDK, mas devido a da forma como o Wine funciona, ele não foi instalado no prefixo (prefixo sendo uma instalação completa do Windows no que diz respeito ao aplicativo dentro dele), eu estava executando o jogo. Depois de instalar, o jogo realmente roda em criação de perfil.

Portanto, ignorando o menu por enquanto, aqui está um dump do profiler que peguei em um mapa do sistema solar vazio.

FullProfiler-1.gz
(renomeado devido ao GitHub ser exigente)

E aqui está o menu também, caso seja o mesmo problema e o despejo do menu possa ter menos ruído no sinal:

FullProfiler-2.gz

Espero não ter esquecido algo crucial aqui.

Pelo que posso ver nos perfis, não há um único sistema sendo afetado que tornaria o jogo todo lento. Todo o sistema e todos os threads são afetados igualmente em toda a linha. Infelizmente, isso significa que não existe um único sistema que possamos otimizar e / ou consertar para ajudá-lo com as persianas. O que isso nos diz do outro lado é que o problema está no lado do sistema das coisas.

Eu reconheço o padrão nos perfis muito bem. Quando vejo no Windows, 9 vezes e meia em cada 10 é GC (coletor de lixo .NET). Ou há algo afetando sua funcionalidade normal e fazendo com que pare o jogo por uma quantidade enorme de tempo durante cada ciclo de trabalho ou, por ser uma máquina de autoajuste, ficou terrivelmente mal configurado devido a informações inválidas fornecidas por um sistema operacional portado incorretamente função.

Alternativamente, pode haver alguma função do sistema operacional muito básica, algo tão comum como malloc por exemplo que todos os sistemas do jogo inteiro (ou .NET Framework para esse assunto) usam. O fato de uma dessas funções apresentar desempenho insatisfatório em uma chamada também pode explicar as descobertas.

Em qualquer caso, o jogo não será capaz de fazer o perfil de si mesmo e encontrar o problema. Ele precisará ser traçado de fora e a causa encontrada por uma ferramenta externa que será capaz de identificar a função lenta do sistema operacional ou condenar o GC de culpa. Nesse caso, saber o que é lento no GC pode nos dizer como resolver isso também. Não estou familiarizado com a criação de perfis no Linux, então não poderei ajudá-lo nisso.

Quanto à segunda opção, o Mono parece lidar com o jogo com mais estabilidade, então, alternativamente, poderíamos prosseguir com o Mono e ver como ele se sairá bem com um pouco mais de carga de trabalho. Minha última instrução sobre esse assunto mostrou como eliminar o compilador do jogo, então agora você deve ser capaz de iniciar uma sessão. Se você encontrar quaisquer outros problemas lá e se estiver dentro da minha área de especialização, terei prazer em ajudá-lo.

É muito provável que as funções de consulta de recursos tenham sido fragmentadas e estejam alimentando informações ruins do .NET, talvez no WMI ou em uma função NtQuery * no ntdll.

Em primeiro lugar, muito obrigado, Inflex, por dedicar seu tempo para analisar isso, o que eu suponho ser seu tempo livre do trabalho.

Bem, embora não seja uma boa notícia para uma solução rápida que esperávamos, pelo menos nos coloca no caminho certo em vez de perseguir fantasmas. Eu me baguncei um pouco olhando os gráficos e percebi que os picos acontecem em todos os lugares, então, mesmo como alguém de fora da base de código (e alguém com conhecimento muito superficial em .NET), acho a explicação dos problemas de GC muito atraente .

Vou analisar tudo o que puder nas frentes Mono e .NET nativa nos próximos dias e tentar fornecer o máximo de informações aqui ou ver se valeria a pena abrir um novo problema. No longo prazo, provavelmente seria o melhor se pudéssemos consertá-lo adequadamente e fazer o patch upstream, porque se o GC está funcionando mal, isso significa que há ganhos potenciais de desempenho em uma ampla gama de aplicativos, não apenas em jogos. Mas, passos de bebê :)

Espero que isso seja pelo menos um pouco útil, eu realmente tenho pouca experiência com esse tipo de coisa.
setrace.zip
Esta é uma cópia de um rastreamento do sistema obtido do perf. Deve ser aberto a partir do PerfView no Windows. Ou você pode, alternativamente, soltar o fileperf.data.txt no SpeedScope
Tentei olhar os traços no SpeedScope, mas, como disse, basicamente não tenho ideia do que estou olhando.
Espero que outra pessoa possa fazer uso disso. Se mais informações ou um rastreamento diferente for necessário, farei o meu melhor para fornecer o que puder.

Hi @ kisak-valve apenas para informações Os engenheiros espaciais não funcionam com o Proton 4.11-2, mas funcionam com o Proton 4.2-9.
Estava começando com 4.11, mas com bugs estranhos, e com 4.11-2 ele nem começou.

E continuamos a sofrer com o mau desempenho, com a ajuda de @InflexCZE para descobrir qual é o problema, mas neste momento não avançamos porque é muito complexo.

Se precisar de ajuda para encontrar o que está causando o problema com 4.11-2 basta postar aqui que tentaremos ajudar.
E se você puder trabalhar com @InflexCZE para melhorar o desempenho do jogo, será incrível :)

Olá @LtSich , lembrete amigável de que sou um moderador dos rastreadores de problemas da Valve no Github e não um desenvolvedor da Proton.

Olhando para a história recente, parece que vários desenvolvedores apareceram e estão pensando no jogo, então não há muito que eu possa contribuir. Esta parece ser a primeira menção clara de uma regressão Proton 4.11-1 -> 4.11-2. Você pode adicionar PROTON_LOG=1 %command% às opções de inicialização do jogo e arrastar e soltar o $ HOME / steam- $ APPID.log gerado na caixa de comentários.

Desculpe pelo meu erro @ kisak-valve.

Aqui está meu log do Proton 4.11-3 https://dl.cafe-philo.net/steam-244850.log.gz
A instalação do dotnet 472 falhou.

Alguma atualização / progresso?

Nenhuma atualização, eu acho.

A instalação do dotnet 472 falhou.

Certifique-se de que o winetricks esteja atualizado, se não tentar fazer o downgrade de algumas versões, este era um bug em sua versão anterior que me disseram que pode ser corrigido com a versão mais recente. (ainda tento sozinho)

Aqui está um resumo do jogo carregando em um novo mundo alienígena sob Win10 com método de injeção de invólucro (d3d11, dxgi). Nenhuma sobreposição está habilitada. 1080TI usado.

Win10-trace [1.6 GB]: https://www.dropbox.com/s/2yxl18f7a2l126o/SpaceEngineers.7z?dl=0
_Linux-trace []: isso ajudaria? _

Talvez isso ajude outras investigações sobre os problemas de desempenho.

Eu olhei para as gravações de desempenho um pouco mais. Ainda não tenho ideia do que está acontecendo, mas percebi que a incompatibilidade de Inode parece ocorrer com frequência e é o item que está ocupando mais o desempenho da CPU durante um pico de atraso. (Veja a imagem em anexo)

Também notei que durante o atraso, um único núcleo atinge 100% e os outros núcleos diminuem no uso. Não tenho certeza do que fazer com isso. Talvez o resto do jogo esteja esperando por algo de thread único.

Aqui está uma imagem com mais do pico selecionado. (Há muito mais itens abaixo da tela, mas eu não queria postar uma dúzia de capturas de tela.)

Abaixo está uma seleção um pouco mais restrita de um pico diferente que mostra problemas semelhantes.

Não tenho nenhum conhecimento técnico sobre isso, mas espero que seja de alguma ajuda.

AFAIK inode mismatch é um aviso do sysprof de que o arquivo foi alterado no disco. Em seu rastreamento, isso pode significar que os binários Proton e steam mudaram no disco desde que você registrou o rastreamento. Portanto, nenhum símbolo real dos executáveis ​​que causaram os picos pode ser exibido.

Tudo bem ... algo no MS Dotnet está causando o problema de lag. Eu coloquei o SE trabalhando com wine-mono 4.9.3, depois de seguir o conselho

O jogo correu perfeitamente ... sem gagueira em tudo. Houve apenas um fraco fade out ocasional de áudio (provavelmente alguns problemas com o faudio, já que o mesmo fade de áudio é no Fallout 4), mas nenhum atraso ou falha para acompanhá-lo. Posso confirmar que a gagueira existe com o MS DotNet, mesmo com o compilador de script eviscerado. Portanto, não tenho certeza do que há de errado com o compilador de script, o que significa que não há mods ... mas isso significa que mono será capaz de rodar o jogo vanilla muito bem se o compilador de script estiver desabilitado.

Se alguém precisar de logs ou outras informações, farei o possível para ajudar.

Tudo bem, criei um vídeo mostrando as versões DotNet e Wine-Mono do jogo. A versão mono funciona muito melhor!

Aqui está um link para o vídeo:
https://youtu.be/LwqRLCQR6aM

Agora tudo o que precisamos fazer é descobrir como fazer o compilador de script cooperar com o Mono, e o jogo será, se não tão, jogável quanto no Windows!

Essa é uma grande diferença!
Obrigado pelo seu teste!

Com mono é sem mods e sem scripts?
Ou apenas um jogo de baunilha sem mods?

Como você faz para rodar o jogo dessa maneira?
Qualquer documento em algum lugar? (Eu realmente não sou bom nessas coisas).

@LtSich Ambas as versões dotnet e mono são plain vanilla sem scripts ou mods.

Para fazer o jogo rodar, usei o conselho de @InflexCZE e cortei o compilador de script.
Postagem de 10 de agosto de

Com base no log, o casamento de Mono e nosso compilador não é particularmente feliz stick_out_tongue
Tudo bem, não precisamos disso.

Infelizmente, não há um ponto único para desabilitar o compilador (ainda), então você terá que eliminar 2 lugares-chave que identifiquei e espero pelo melhor.

1. Get rind of all stuff in this ctor.
   https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptWhitelist.cs#L47

2. Make this method return `null` (prevent it from invoking the compiler core)
   https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptCompiler.cs#L154

Parece manteiga suave @ Linux74656 . Afinal, seu trabalho duro valeu a pena, CG 👍
Posso dar uma olhada no compilador à noite, talvez consigamos fazê-lo funcionar também, para que você também possa desfrutar dos mods.

A propósito, eu dei uma olhada no trace @ Linux74656 fornecido, mas foi meu uso incompetente do PerfView ou estavam faltando símbolos ou algo assim, mas em qualquer dos casos eu não consegui abrir o trace e ver qualquer informação útil há. Uma vez que mono parece bastante estável, acho que podemos continuar com ele e deixar a depuração do .NET FW para outra pessoa :)

Eu também não consegui obter dados úteis do rastreamento de desempenho ... é por isso que desisti do dotnet e comecei a trabalhar para fazer o mono funcionar. Tenho certeza de que os traços estão incompletos, porque não consigo descobrir como resolver os símbolos ausentes.

Droga, o jogo pode ser executado com mods e scripts que poderiam ser realmente incríveis ...
Muito obrigado pelo seu trabalho, pessoal!

Aqui estão os logs e o arquivo de minidespejo do jogo enquanto ele tenta carregar um mundo salvo.
Isso está usando wine-mono, e o único código modificado é desabilitar o pop-up dotnet, de forma que o código do compilador de script não seja alterado.
SpaceEngineers.zip

Depois de uma rápida olhada no compilador, parece que poderíamos contornar o problema muito rápido, pelo menos este. Veremos o que / se algum outro pulará sobre nós depois.

Na VRage.Scripting.MyScriptWhitelist existem 6 guardas que garantem a compatibilidade da lista branca com o BCL fornecido (mais sobre isso aqui: https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-520141233).
Esses precisam ir.

Substitua o seguinte IL.thow s por IL.pop seguido por IL.ret imediato.

MyScriptWhitelist#RegisterMember(MyWhitelistTarget, ISymbol, MemberInfo):
    (2x) throw new MyWhitelistException("The member " + member + " is covered by the " + namespaceKey + " rule");
    (1x) throw new MyWhitelistException("Duplicate registration of the whitelist key " + whitelistKey + " retrieved from " + member);

MyScriptWhitelist#Register(MyWhitelistTarget, INamespaceSymbol, Type):
    (1x) throw new MyWhitelistException("Duplicate registration of the whitelist key " + whitelistKey + " retrieved from " + type);

MyScriptWhitelist#Register(MyWhitelistTarget, ITypeSymbol, Type):
    (1x) throw new MyWhitelistException("The type " + type + " is covered by the " + namespaceKey + " rule");
    (1x) throw new MyWhitelistException("Duplicate registration of the whitelist key " + whitelistKey + " retrieved from " + type);

Após essa alteração, corremos o risco de que o verificador da lista de permissões deixe de funcionar um pouco, permitindo que os scripts façam mais do que deveriam ou proibindo algo que deveria ser permitido. Podemos lidar com isso quando chegarmos lá. Por agora, seria bom começar :)

Deixe-me saber aonde isso leva você, se você entrar no jogo ou se algum outro problema o impedir.

Isso me leva ao jogo com o modo Experimental habilitado. Antes de receber uma mensagem de erro.

Infelizmente, acho que os scripts não estão funcionando. Consegui fazer alguns mods básicos (DX11 Door pack DX11 Shutters ... etc) funcionando, mas coisas como o Easy Inventory não funcionam.
Achei algo muito interessante, as missões de campanha de jogos também não parecem funcionar ... presumo que dependem de scripts. Você pode ver o erro no vídeo abaixo.
Link do vídeo: https://youtu.be/aP7FdE4L6-M

Aqui estão os arquivos de registro deste evento:
SpaceEngineers.zip

Sim, a campanha também funciona em scripts.

Há uma tela especial para erros de carregamento de mod. (Ctrl?) + F11 depois de carregar em um jogo. Se algo deu errado durante o carregamento, ele deve estar lá.

Para um teste rápido do compilador, tente colar bloco + bateria programável no mundo vazio e carregar no script a seguir. Ele deve imprimir a mensagem em bloco de informações detalhadas ou lançar alguns erros de compilação para você se falhar. Isso deve nos dizer se o compilador funciona e só precisa de alguns ajustes ou se está totalmente quebrado.

void Main() 
{
    Echo("Yay works");
}

Criei um mundo vazio e coloquei uma bateria e um bloco programável com o código acima. Este foi o resultado depois de clicar no código de verificação:

Nada mais apareceu.
Quando fechei e voltei para o Painel de Controle, apertei Executar, diz que montagem não encontrada ... (Resultados abaixo)

Clicar em recompilar não faz nada.

Acho que isso se enquadra na categoria "totalmente quebrado" :)
Alguma coisa no log?

Aqui estão os logs: SpaceEngineers.zip Incluí o log gerado pelo Proton também.

Alt + F11 me leva a esta tela:

e clicar em abrir em uma nova janela mostra isso:

Eu tenho 4 mods carregados neste teste: Easy Inventory (Failed), Text HUD API (Failed), DX11 DoorPack (Alguns problemas de textura, mas funcionais), e DX11 Shutters (totalmente funcional, sem problemas.)
Portanto, parece que os mods sem scripts integrados funcionarão.

Nenhuma mensagem de erro, nada no log, não tenho certeza de como isso acontece, mas parece que você encontrou um buraco em nosso relatório de erro do compilador.

Acho que vou ter que depurar isso sozinho. Você poderia anotar as etapas para fazer o SE funcionar em mono para mim. Qual Linux usar, quais pacotes baixar, ... Vou configurar a VM e tentar restringir o que está acontecendo.

Tudo bem @InflexCZE Eu fiz um guia rápido do início ao fim. Acho que não esqueci nada importante e fiz o guia voltado para todos. Ele está incompleto, no entanto, as partes que faltam não se aplicam realmente a você, pois envolve a modificação do código.

NOTA: Eu evitaria uma VM, nunca conseguiria iniciar o jogo usando uma. Uma VM pode funcionar para depuração de código limitada ... mas provavelmente seria muito mais fácil no longo prazo instalar o Ubuntu em um SSD _blank e separado_ (para minimizar o risco de perda de dados). Um HDD provavelmente funcionaria, mas eu notei mais travamentos no jogo enquanto ele é instalado em um HDD.
Boa sorte! Eu espero que isso ajude.

Guide.docx

Bem, parece que coisas estão acontecendo na minha ausência, eu meio que nunca consegui continuar depurando usando .NET, mas se o Mono funcionar é ainda melhor!

Suponho que esta seja a compilação normal, executar a versão ModSDK não faria mais sentido aqui? Isso deve registrar exceções de mods para o arquivo de log, IIRC?

Vou tentar isso mais tarde e postar os logs se acontecer alguma coisa.

Guide.docx

Obrigado pelo seu médico ... Mas, caramba, você apenas pára na parte mais importante :(
Isso provavelmente é algo que KSH tem que fazer diretamente no jogo.
Ignore o dotnet e verifique se há alguma maneira de detectar se o jogo é executado no Linux ...

A verificação dotnet deve permanecer para usuários do Windows, mas também deve verificar o suporte mono na mesma instrução

Se você está falando sobre modificação do jogo para adicionar verificações específicas de prótons / vinho, por favor, não faça isso.

@ Linux74656 embora eu entenda sua apreensão em escrever um guia sobre como modificar o código, você poderia pelo menos me dizer qual ferramenta usou? O Assembly Browser do MonoDevelop não parece permitir que nenhuma modificação seja feita (ou estou apenas falhando em usá-lo corretamente) e não consigo encontrar nenhuma outra ferramenta Linux disponível. Tenho uma cópia licenciada do Rider na minha máquina de trabalho, o que pode ajudar, mas tentaria evitar mexer com isso no trabalho.

Leia novamente, _a ferramenta_ está no guia :)

@ Linux74656 Btw, adicione o passo de "Ativando o SteamPlay para todos os outros títulos". Levei uma hora para descobrir por que basicamente todos os jogos da minha biblioteca oferecem download direto, apenas SE oferece apenas streaming de outra máquina (eu sei, sou burro)

@InflexCZE Eu realmente vi isso, mas esperava algo que funcionasse corretamente no Linux, já que minha instalação do Windows está hospedada no momento e eu não tive tempo nem disposição para consertar ainda ... Vou colocar uma VM em execução Acho que vou continuar amanhã, se necessário, mas com você agora, pode ser supérfluo. Ainda assim, tentarei dar uma mão onde e se possível :)

@ Onyx47 Ah, desculpe, não percebi. Não estou acostumado a trabalhar com .NET no Linux, então não conheço as ferramentas lá :(

Eu trago algumas boas notícias tho. Consegui fazer o compilador rodar, compilar o assembly dinâmico e executá-lo também. Até agora testado apenas em .NET FW tho. É quase 1h, então não posso me incomodar em tentar mudar para Mono agora: stick_out_tongue:
Em qualquer caso, aqui vai a correção. Experimente, se você encontrar qualquer problema no Mono, continuarei a depuração amanhã.

Nosso mecanismo chama Roslyn aqui:
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/MyScriptCompiler.cs#L204

O código do link está um pouco desatualizado, na verdade existe mais um argumento ( pdbStream ) na versão atual do jogo. Elimine este argumento (passe null invés) e o compilador deve obedecer. (Então, basicamente, reverta para esta versão antiga da linha que está no link.)

Claro, aplique essa mudança nas principais mudanças de ontem. Se o verificador da lista de permissões reclamar (como eu disse, o BCL não é totalmente compatível, então pode estar um pouco mal configurado agora), você pode encerrá-lo simplesmente colocando retorno imediato no início deste método:
https://github.com/KeenSoftwareHouse/SpaceEngineers/blob/master/Sources/VRage.Scripting/Analyzers/WhitelistDiagnosticAnalyzer.cs#L43

Desculpe @InflexCZE, eu perdi isso completamente! Obrigado por apontar isso! Eu atualizei o link do guia com uma versão revisada!

@ Onyx47 Infelizmente tentei procurar ferramentas que

Parece que ainda dá muito trabalho para usuários comuns do Steam fazerem este jogo funcionar. Espero que algumas dessas soluções possam ser atualizadas para SE algum dia, para que as pessoas possam simplesmente apertar o play e terminar com isso. Posso dizer agora que muitos não se importarão em compilar seus próprios scripts :)

@InflexCZE Isso mesmo !!!!
O script do jogo que você me deu antes de compila!

void Main() 
{
    Echo("Yay works");
}

O Easy Inventory também funciona!

@InflexCZE
Oh WOW!

Veremos essas mudanças no jogo, embora de uma forma um pouco menos hacky, em breve? Adoraria começar a jogar de novo, já faz muito tempo.

Deixe-nos saber como será o aumento da contagem de jogadores do Linux em sua extremidade assim que chegar ao reddit!

Como uma solução temporária, a criação de um arquivo de patch / script de patcher que faz as alterações relevantes automaticamente seria desaprovada do ponto de vista legal? Não sou advogado, mas me parece que vários patches widescreen e similares para alguns jogos nunca incomodaram ninguém e isso me parece o mesmo tipo de modificação ...

Para ser claro, eu não estou sugerindo distribuir uma versão modificada executável, apenas um diff binário simples que iria corrigir o jogo existente que ainda teria que ser baixado do Steam.

Talvez @InflexCZE pudesse verificar isso para nós com Keen jurídico / liderança para nós? Claro, eu espero que haja uma boa mudança, podemos simplesmente colocar essas mudanças no próprio jogo e fazer tudo isso discutível, mas como uma alternativa (no caso de isso poder causar problemas a montante) pode ser viável (e pode ser transformado em um script Lutris para jogadores menos experientes em tecnologia).

Outra opção são, é claro, atualizações para Wine / Proton que fariam o jogo funcionar corretamente com o MS .NET, mas como parece ser um problema de GC, isso pode estar muito longe, já que é sem dúvida um problema complicado.

É bom ver que existe pelo menos um pouco de amor pelo jogo no linux, eu adoraria poder jogar, mesmo através de prótons.

@ Onyx47 Se for possível criar um diff contendo apenas as alterações necessárias, não

Entrei em contato com Keen sobre a legalidade de redistribuir um patch como este, e a pessoa para a qual encaminhou o e-mail disse que o apresentaria ao CEO em sua reunião na segunda-feira.

Dito isso ... Eu criei um patch Diff e apliquei ao jogo no computador da minha irmã. Parece não ter nenhum problema e funcionou bem. Podemos até jogar um jogo de conexão direta da LAN. sem qualquer problema.
No entanto, tenho uma preocupação com o modo multiplayer e talvez @InflexCZE possa me esclarecer. Já que modifiquei alguns dos arquivos DLL do jogo para fazer isso funcionar. Quais são as chances de que o jogo / vapor seja capaz de detectar isso e pensar que é uma forma de trapaça se o jogo se conectar a um servidor oficial / público? E também quais seriam as outras ramificações potenciais de ter jogadores do lado do cliente executando código de jogo modificado que permite que alguns scripts passem pelo filtro da lista de permissões?

Se isso for algo que pode acontecer, e eu obtiver permissão do meu contato Keen para distribuir tal patch, eu precisaria ter certeza de que as pessoas entendem que não devem se conectar a jogos multijogador pela Internet e, em vez disso, jogar apenas jogos LAN locais enquanto estiver remendado.

Você fez um trabalho muito bom!
Muito obrigado por isso!

Espero que você possa distribuir o patch.

Como jogo apenas um jogador, não tenho problemas com o aspecto multi-jogador do jogo.

Vou deixar a parte jurídica do ppl responsável por isso e me concentrar apenas no aspecto técnico do negócio em minha resposta.

Como você teve a chance de ver por si mesmo, mexer no jogo para fazer algo que nunca foi planejado é muito fácil e por isso os clientes não são confiáveis . Essa é a filosofia que seguimos estritamente e todo o jogo é codificado como tal. Resultado disso é que os servidores fazem toda a simulação enquanto o cliente é apenas uma interface gráfica que conecta o jogador humano ao servidor. Os clientes nunca computam nada "para o servidor" e também nunca dizem a ele o que fazer, eles meramente retransmitem solicitações de humanos. O servidor irá verificar cada solicitação, executá-la e enviar-lhe o resultado (ou chutá-lo no local se você fizer algo que não tem permissão para fazer).

Isso se aplica a solicitações originadas de modos do lado do cliente também. Para scripts de bloco programáveis, a situação é ainda mais simples, eles são executados apenas no servidor.

Resumindo, desde que o animal que o servidor observa do outro lado da conexão siga o protocolo e faça consultas válidas, ele será aceito e tratado como cliente legítimo, não importa o que seja _realmente_.

Uma coisa que gostaria de salientar é que existe uma tabela fixa de consultas MP que tanto o cliente quanto o servidor criam na inicialização. Se você modificar seu jogo muito fortemente, você pode jogar esta mesa do seu lado e o servidor se recusará a permitir que você se conecte. Nesse caso, você será informado de que está usando uma versão do jogo diferente da que o servidor está executando. Se você o encontrar, você sabe o que está acontecendo.

Bem, vou esperar pelo potencial diff que parece, ou estou fazendo algo errado com minha edição de IL ou há outra coisa sutil acontecendo em algum lugar, ter um jogo modificado funcionando confirmado provavelmente seria uma ideia melhor do que perseguir fantasmas. Estou apenas ficando preso em um loop de carregamento ao criar um mundo. Dito isso, anexar logs apenas no caso:

SpaceEngineers.txt

Observe que ele para em MyDefinitionManager.LoadData() - START , a última linha é depois que fechei o jogo com força. Dado que está mencionando scripts lá (embora eu nem mesmo habilite o modo experimental, eu queria testá-lo sem isso primeiro), tenho grandes esperanças de que seja apenas eu cometendo erros ao fazer as edições, em vez de ser sensível ao Mono versões ou qualquer outra coisa.

EDIT: pode não ser o jogo, descobri ontem que meu HDD está desistindo do fantasma, então sim ... quem sabe ...

@ Linux74656 Tenho uma pergunta. Neste vídeo (https://youtu.be/LwqRLCQR6aM) você mostra o jogo rodando bem no Mono, embora haja alguns picos no gráfico de tempo de quadro.

Apenas por curiosidade profissional, você poderia mudar para a construção de Modding (construir com o profiler) e medir para mim o que está causando os picos no thread de renderização e quão grandes são os picos.

@InflexCZE
Pode ser devido à saída não otimizada do código do sombreador LLVM. RADV, o driver gratuito e vulkan, usa LLVM por padrão para compilar sombreadores no jogo e é bastante sujeito a gaguejar.
Pode valer a pena repetir o novo ramal ACO da válvula e ver se a gagueira ainda está presente. Tinha um microstutter semelhante no piso 2 que o ACO consertou.

As capturas de renderização do Engenheiro Espacial já foram analisadas no rastreador de ocorrências dxvk antes, sem problemas aparentes nas chamadas de API.

Eu precisaria obter o diff para testar eu mesmo. Esperando pelo sim / não legal, eu acho.

@InflexCZE Eu tentei o profiler (com as modificações de código) no wine-mono sem sucesso. Ele trava sem mensagem de erro quando eu carrego um mundo. Eu tentei (com as modificações de código) com dotnet e obtive o mesmo resultado. Eu tentei um mundo pré-salvo com o modo experimental e um novo Crashed Red Ship World sem o modo experimental.
Logs são anexados para o mundo pré-salvo para mono e dotnet:
LogDOTNETProfiler.zip
LogsMonoProfiler.zip

Também recebi uma resposta do meu contato do Keen, e ele disse que, como essas modificações estão sendo feitas como uma atividade voltada para a comunidade, o keen não tem nenhum problema com isso. Ele enfatizou que eles não têm suporte oficial para Linux no momento.
Por isso, gostaria de agradecer ao @InflexCZE por nos ajudar, em seu tempo livre, a chegar até aqui. Isso jamais teria sido possível sem sua ajuda!

Estou construindo um guia para explicar como instalar esses patches. Vou postar uma atualização quando terminar!

Certo, fiz um repositório simples que contém um leia-me explicando como instalar os patches e os arquivos de patch reais compactados e arquivados.
Você pode encontrá-lo aqui:
https://github.com/Linux74656/SpaceEngineersLinuxPatches

@SpookySkeletons Se for algo na GPU (shaders ruins) ou DX API (Proton wrapper),

Se for esse o caso, você pode esperar melhorias bastante boas em versões futuras por causa das otimizações que fizemos para o XBox.

@ Linux74656 É uma pena que seja um travamento forte sem qualquer rastreamento de pilha. Acho que vou deixar pra lá, você vai ver se melhora nos próximos lançamentos.

Uma coisa que você pode tentar é definir a variável de ambiente "MONO_GC_PARAMS" para o processo do jogo para nursery-size=32m ou minor=simple-par ou nursery-size=32m,minor=simple-par e observar se isso faz alguma diferença na frequência e / ou tamanho das pontas, respectivamente.

Em todo caso, foi um prazer trabalhar com todos vocês e espero que vocês tenham algum tempo de qualidade com SE 👍
Se precisar de ajuda no futuro, não hesite em me enviar um ping.

Muito obrigado @ Linux74656
Mas para mim, atm, o jogo começa bem, e quando tento iniciar um mapa, o jogo trava.
E depois desse jogo travar toda vez que tento iniciá-lo ...

Tenho que deletar a pasta% appdata% para reiniciar ...

Vou fazer mais teste pra descobrir qual é o problema ...
Talvez configuração gráfica ou algo assim.

Pelo menos não tenho problemas de som ou bugs no menu principal.
Ativar o vsync parece diminuir o desempenho.

É um grande passo em frente para podermos jogar nosso jogo :)

@InflexCZE Tentei sua sugestão. Isso definitivamente fez a diferença!
Este é o tamanho do berçário = 32 m

Isso é menor = paridade simples

e este é o tamanho do berçário = 32 m, menor = paridade simples
(Retirado do jogo porque o menu não tinha nenhum pico. OBSERVAÇÃO este pico NÃO tem gagueira associada a ele.)

Assim, parece que o tamanho do berçário = 32 m, menor = paridade simples irá reduzir os picos de maneira bastante eficaz. Não tenho certeza do que isso significa. Mas presumo que seja bom.

@LtSich Eu tive uma experiência semelhante, só que sempre ficava preso em um loop de carregamento infinito em vez de uma falha, não conseguia carregar um único mapa.

Vou tentar novamente o mais rápido possível, mas preciso consertar meu PC hoje à noite, discos rígidos com defeito são uma droga :(

@LtSich Você está executando o modSDK build (profiler)? Se sim, use o jogo normal. Eu só vi travamentos na carga quando o bin64 está usando a compilação modSDK

@LtSich Você está executando o modSDK build (profiler)? Se sim, use o jogo normal. Eu só vi travamentos na carga quando o bin64 está usando a compilação modSDK

Hum, lembro que fiz alguns testes com isso.
Farei uma instalação completa e limpa e tentarei novamente.

BTW, como você altera a variável MONO_GC_PARAMS?

[EDITAR]
E outra pergunta, devemos continuar usando o comando PROTON_NO_ESYNC = 1% para iniciar o jogo?
[/EDITAR]

Você coloca MONO_GC_PARAMS = Nursery-size = 32m, minor = simple-par% command% em suas opções de inicialização do Steam para o jogo. Clique com o botão direito em Space Engineers, clique em properties, clique em SET LAUNCH OPTIONS ... e cole na caixa.
Não tenho PROTON_NO_ESYNC = 1 em minha linha de comando e parece funcionar bem.

THX :)
No momento, estou baixando o jogo depois de remover tudo.
Serei capaz de dizer se isso faz alguma diferença.

[EDITAR]
Para mim, o jogo é muito instável ... Mesmo depois de remover / instalar o jogo.
Na maioria das vezes, não consigo iniciar o jogo sem remover SpaceEngineers.cfg
E mesmo que eu possa iniciar o jogo, não consigo iniciar nenhum mapa / jogo sem travar ...
Farei mais testes mais tarde ... Para tentar encontrar alguma configuração que não trava ...
[/EDITAR]

@ Linux74656 Aqui está uma documentação de alto nível para aquela mágica que sugeri antes: stick_out_tongue: Você pode achar que é útil, embora não espere maravilhas
https://www.mono-project.com/docs/advanced/garbage-collector/sgen/working-with-sgen

@LtSich Por favor, nos forneça o log do jogo para que possamos saber o que está acontecendo

@InflexCZE Vou dar uma olhada obrigado!

@InflexCZE : Encontrei o problema ao iniciar o jogo.
Tenho que desativar o rastreamento anônimo.
Se eu ativar, não consigo reiniciar o jogo.
Contanto que eu diga não (tenho que dizer não toda vez que começo o jogo), posso iniciar o jogo.

Agora tenho que tentar iniciar um jogo ou tentar entrar em um servidor personalizado :)

Você quer alguns logs quando eu travar com o rastreamento anônimo ativado?

Lembro-me de ter visto nos logs que ele reclama por não conseguir obter o consentimento do GDPR e apenas ter atingido o tempo limite quando eu escolhi não (isso deve estar visível no log que postei acima). Possivelmente algumas APIs da web no Mono não são adequadas / não são 100% compatíveis?

Então, tentar o patch do Linux74656 parece funcionar, com algumas exceções notáveis.

1. O filme de introdução não é reproduzido (? Acho que agora) e, como resultado, passei os primeiros 10 minutos olhando para uma tela em branco porque pensei que estava pendurada. Eu cliquei e "pulei" a introdução e a mensagem GDPR (clique não)
2. Ele funcionará bem por um tempo, então de repente (preciso testá-lo mais) o jogo trava na área de trabalho, mas funciona bem de outra forma.
3. Um bom número de avisos de "baixa velocidade do sim"
   Executando Arch Linux com um RTX 2070 e um 8750H (deve ser o bastante, hein?)
   Deve-se notar que isso faz o Laptop soar como um Jet Engine, embora isso nunca seja chocante: P

@StripedMonkey Se você remover ou renomear o vídeo localizado em SpaceEngineers / Content / Videos / ksh.wmv, ele irá pular o vídeo de introdução e levá-lo para o menu principal.
Eu tive um travamento ocasional, mas ele estava funcionando por várias sessões, com duração de mais de 4 horas, sem problemas (depois de iniciar). Na próxima vez que ele travar, se você soltar os logs aqui, talvez possamos descobrir o que está acontecendo.
Alguma perda de desempenho é esperada ao executar o jogo através de Proton e DXVK ... Eu vi alguns problemas de desempenho em um gtx960 e um 4770K, embora a lentidão seja menos perceptível em um rx580 e um R5 2500x. Um RTX2070 não deve ter problemas com gráficos em configurações de médio a alto, e um 8750H deve ser capaz de jogar com alguns mods básicos.
Quando você pressiona Shift + F1, do que em particular ele está reclamando?

Especificamente, ele diz "Qualidade reduzida de deformações e alterações de Voxel devido à qualidade de simulação adaptativa". Os logs do IIRC SE apenas têm uma mensagem GC frequente, mas não parece estar relacionada ao instante de uma falha. Na próxima falha que gerar, postarei o log de.

Pessoalmente, acho que tem algo a ver com o Sim, já que a primeira falha com a qual realmente associei foi tentar fazer um 180 na velocidade máxima no mundo do tutorial. quase assim que eu virei ele morreu. É preciso fazer mais testes adequados para descobrir isso.

Também recebo muito essa mensagem. Menos no computador RX + R5, mas ainda com bastante frequência. Já que você está executando um processador móvel ... Não acho que haja muito que você possa fazer para melhorar o desempenho além de garantir que ele seja bem resfriado e com turbo adequado até a velocidade de 4,10 Ghz. Você também pode tentar desmarcar algumas das configurações do jogo, como a estanqueidade, e ver se isso tem um impacto.

SpaceEngineers.log <- Crashed
No geral, o desempenho parece bom, ignorando as falhas. Portanto, não estou muito preocupado em melhorar isso no curto prazo. Este acidente foi gerado especificamente depois que fui kamakazi em uma nave inimiga NPC. Eu caí quase imediatamente depois de morrer (embora, note que eu nem sempre caio ao morrer), não tenho certeza do que exatamente causa isso.

O registro termina quando você morreu. Parece que não registrou o acidente.
Eu rapidamente tentei carregar em um mundo e ver se conseguia travar. Eu bati três navios no chão e me matei quatro outras vezes sem nenhum problema. Percebi que minha irmã tem mais problemas em seu sistema RX + R5. Se eu conseguir descobrir por que o dela trava com mais frequência do que o meu ... Vou ver o que posso descobrir.

Eu acho que entendi Tente instalar o vcrun2005 com winetricks e veja se isso resolve os problemas de travamento. Certifique-se também de definir o prefixo da versão do Windows de volta para o Windows 7.

Eu realmente esperava tentar, mas parece que recebo um segfault ao tentar carregar um novo mundo
https://pastebin.com/E7Ha8aCK - steam-244850.log

EDITAR//
Muito burro, provavelmente deveria dar algum tipo de detalhes.
O log é cortado apenas nos pedaços aparentemente interessantes, a maior parte do log depois é apenas mensagens de símbolo não encontradas um bilhão de vezes.
O sistema é Slackware64-current, Proton 4.11-6, percorreu o guia postado (obrigado Linux74656!), Incluindo vcrun2005 e configuração da versão do Windows para Windows 7, embora também travasse antes disso.

Então, com essa correção, pode ser confirmado se os mods e jogos multiplayer com usuários do Windows funcionam?

@Aerol Tente verificar a integridade dos arquivos do jogo e reaplique os patches.

@jarrard Mods funcionarão. O modo multiplayer com outros usuários Linux funcionará. Eu não tentei jogar com um usuário do Windows ... mas deve funcionar.

@ Linux74656 Instalando vcrun2005 e Windows 7 resultou em alguns muito ruim gagueira, switiching volta para winXP parecia para corrigi-lo? De qualquer forma, consegui jogar um pouco mais do que antes, embora no final ainda conseguisse cair. Talvez tenha algo a ver com viagens? Eu realmente não sei. Eu estava salvando uma estação e tive alguns casos em que a velocidade do sim caiu abaixo do normal, mas depois voltei. Assim que saí da estação e estava prestes a embarcar em um navio abandonado, caí novamente. Esta foi provavelmente a minha corrida mais longa sem um acidente, mas, novamente, eu não estava me movendo ao redor de uma tonelada, apenas triturando coisas e tentando reconstruir o navio.

Tentei seguir os passos em seu guia e o jogo carrega (o menu tem um pequeno pico de som de vez em quando), no entanto, iniciar um novo mundo baseado na Terra faz com que o jogo falhe ao iniciar o mundo e um travamento aconteça no processo.

Dar de ombros. Segui para o T, https://github.com/Linux74656/SpaceEngineersLinuxPatches

_Houve um erro ao carregar o mundo, verifique o arquivo de log._

@StripedMonkey Tenho win7 em ambos e só notei gagueira no meu computador. Eu configurei para winxp e a leve gagueira desapareceu. Para uniformidade, mudei o guia para definir como WinXP.
Vamos tentar uma correção geral e instalar tudo no seu prefixo que está instalado no meu: Acho que isso é tudo que instalei no prefixo ao longo do tempo: vcrun2003 vcrun2005 vcrun2015 vcrun2017 xact d3dcompiler_43 d3dcompiler_47 veja se instalando todas essas ajudas.

@jarrard Essa mensagem de erro deveria ter sido desativada pelos arquivos de patch ... tente verificar a integridade de seus arquivos de jogo e reaplique os patches.

Eu verifiquei antes de aplicar os patches, acho que farei de novo (sim, os arquivos foram modificados por data)

Eu descobri, suas instruções têm um pequeno problema que não diferencia maiúsculas de minúsculas.

bspatch VRage.Scripting.dll Vrage.Scripting.dll $ HOME / Documents / SpaceEngineers / VRage.Scripting.dll.patch

Veja o problema :)

@jarrard Obrigado! Consegui e foi corrigido no guia!

@Aerol Veja se isso está relacionado ao seu problema. Reaplique VRage.Scripting.dll.patch usando o comando corrigido bspatch VRage.Scripting.dll VRage.Scripting.dll

Bem, parece que está progredindo, mas fica com 4-5 GB de uso de memória e% 50 de uso de CPU para sempre. Devo esperar meia hora para carregar ou algo assim? ou continuar tentando? certamente o jogo tem problemas de estabilidade.

Sim, este é um problema conhecido. Não se preocupe em esperar por ele, ele nunca carregará. Apenas force o fechamento e tente recarregar. Funcionará cerca de 50% do tempo. Estou tentando descobrir o que está causando isso.

Ok, eu consegui carregar em um mundo já salvo de quando eu estava brincando um tempo atrás. Isso pareceu funcionar, talvez apenas alguns obstáculos na criação de um novo mundo sejam o problema, talvez se eu continuasse tentando, funcionaria.

Mesmo assim, a taxa de quadros é muito jogável agora, o único problema é o travamento / travamento na criação de mundos e, no meu caso, ainda há um pequeno estalido de áudio, pode haver uma solução alternativa com pulseaudio que posso tentar lá.

O jogo roda muito bem em 4k mesmo com 10k tree's definido, apenas desligue fxaa (use reshade smaa se necessário), defina shader / sombras para médio, tudo bem. Pode até ser mais suave do que o Windows, porque sob o Windows eu tenho um corte de fps estranho, mesmo que seja a 80fps ou mais. (pode ser uma sincronização rápida ou algo assim).

Além disso, se alguém descobrir como resolver o pequeno estalo de áudio que acontece, me diga, eu tentei algumas configurações de áudio de pulso até agora, sem muita sorte.

ATUALIZAÇÃO: PULSE_LATENCY_MSEC = 90 na linha de comando ajudou a distribuir para minha placa de som USB OMNI, agora realmente não há nenhum estalo, exceto para o som ocasional muito fraco que não é irritante. YAY

Infelizmente, verificar os dados do jogo não corrigiu nada além de baixar vídeos novamente, e eu já havia executado os comandos bspatch adequados. : /

Se você verificou os dados do jogo, precisará reaplicar os patches, caso ainda não o tenha feito.

Estou recebendo o mesmo bloqueio de tela de carregamento que outras pessoas estão recebendo e, além disso, também, o mesmo bloqueio parece surgir no jogo momentos depois de carregar um mundo offline. Ele roda a CPU em cerca de 40%.
A renderização não para e as partículas ainda se movem, mas o mecanismo de física pára, relata baixa qualidade de simulação e paralisa o quadro por breves períodos enquanto permanece parado e não faz nada fisicamente.

Nenhuma entrada para menus é aceita, não consigo mover o caractere, mas todo o resto ainda é renderizado.

Estou recebendo a mesma tela de carregamento para outras pessoas

Sim, isso parece acontecer com freqüência na geração de um novo mundo, se você continuar tentando parece progredir de forma diferente a cada tentativa. O que descobri que funcionava% 100 é carregar um mundo EXISTENTE que você fez anteriormente, acho que você pode até fazer o download deles. Mas sim, o travamento parece estar amplamente relacionado à geração de um novo ATM mundial.

aplicou os patches em um prefixo de próton no Steamplay,
consegui chegar ao menu, mas o jogo trava assim que tento iniciar qualquer jogo, também estou sem som e não consigo usar o Alt-Tab no jogo.

onde estão localizados os arquivos .log?

Arch lin4.19.69-1-lts
GTX-1070
intel I5-7600K

Mais do que isso, carregar mundos existentes congela na tela com muita frequência.

Se eu conseguir entrar no jogo, todo o mecanismo de física para e não posso tentar nenhum dos menus, mas os frames continuam chegando e os efeitos continuam se movendo.

Aqui está um mundo que você pode usar, vai para o local da sua pasta de salvamento _ (não tenho certeza se o número é exclusivo para mim, mas as pastas dentro podem ir para qualquer uma que você tenha) _. Isso funcionou 100% das 4 ou 5 vezes que tentei carregá-lo. O arquivo é, na verdade, um arquivo 7zip fyi.

spaceengineerssavedworld.zip

@StripedMonkey Feito, é claro, infelizmente ainda segfaults.

@EduardoGodoy Você pode adicionar PROTON_LOG = 1 às suas opções de inicialização, executar o jogo e verificar ~ / steam-244850.log? O registro do jogo está em ~ / .local / share / Steam / steamapps / compatdata / 244850 / pfx / drive_c / users / steamuser / Application Data / SpaceEngineers / SpaceEngineers.log

Conseguiu entrar em seu save igual ao meu, mas mesmo congelamento do motor de física no jogo antes que a GUI do traje pudesse carregar. O compilador está quebrando?

Curioso o que iria atrasá-lo assim ...

Hmm, bem, você pode tentar meus arquivos compilados, mas não vejo como isso poderia dar errado ou ser diferente.
compiledfilesfortesting.zip

Se isso não funcionar, então outra coisa está travando para você. Talvez drivers de vídeo? Estou usando apenas os nvidia no pop_os plasma5 atm para meu 1080TI. (se você usa AMD, tente forçar o fornecedor de prótons a usar a NVIDIA)

"O compilador" não deve ter nada a ver com isso.

@EduardoGodoy Eles estão localizados no prefixo Steam. ~/.local/share/Steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers/SpaceEngineers.log
Para instalar e executar isso, eu:

1. Winetricks, wine-mono e bsdiff instalados (literalmente nunca instalei o Wine antes)
2. Antes mesmo de executar o jogo pela primeira vez, executou WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2015 xact
   e
   WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" msiexec -i "Downloads/wine-mono-4.9.3.msi"
3. Verifique os arquivos do jogo e execute

bspatch Sandbox.Game.dll Sandbox.Game.dll $HOME/Downloads/Patches/Sandbox.Game.dll.patch
 ```
and

bspatch VRage.Scripting.dll Vrage.Scripting.dll $ HOME / Downloads / Patches / VRage.Scripting.dll.patch
`` `

1. (Opcional) Exclua SpaceEngineers/Content/Videos/ksh.wmv para evitar que uma tela preta seja carregada.

Pelo que eu sei, isso é tudo que fiz para colocá-lo em execução no arco.
Proton versão 4.11
Wine Version 4.16
wine-mono 4.9.2
winetricks 20190912-1
driver nvidia 435,21

aqui está o log:
https://pastebin.com/zZ7MzreW

"O compilador" não deve ter nada a ver com isso.

@EduardoGodoy Eles estão localizados no prefixo Steam. ~/.local/share/Steam/steamapps/compatdata/244850/pfx/drive_c/users/steamuser/Application Data/SpaceEngineers/SpaceEngineers.log
Para instalar e executar isso, eu:

1. Installed winetricks, wine-mono, and bsdiff (Literally never installed Wine before this)

2. Before even running the game for the first time ran `WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2015 xact`
   and
   `WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" msiexec -i "Downloads/wine-mono-4.9.3.msi"`

3. Verify the gamefiles and run

bspatch Sandbox.Game.dll Sandbox.Game.dll $HOME/Downloads/Patches/Sandbox.Game.dll.patch

e

bspatch VRage.Scripting.dll Vrage.Scripting.dll $HOME/Downloads/Patches/VRage.Scripting.dll.patch

1. (Optional) Delete `SpaceEngineers/Content/Videos/ksh.wmv` to prevent a black screen on loading.

Pelo que eu sei, isso é tudo que fiz para colocá-lo em execução no arco.
Proton versão 4.11
Wine Version 4.16
wine-mono 4.9.2
winetricks 20190912-1
driver nvidia 435,21

aqui está o que eu executei para instalar o patch:

Proton versão 4.11-6
NVIDIA-SMI 435,21
wine-4.15 (Staging) (eu não usei vinho embora)
winetricks 20190615 (eu não usei winetricks também)

Pelo que vejo, a única diferença do meu sistema para o seu é que não executei "vcrun2015 xact", farei isso e verei se recebo esse erro.

REGISTRO:
https://pastebin.com/zZ7MzreW

Tentei limpar o prefixo várias vezes e meu md5 corresponde aos arquivos corrigidos.

Eu carrego no jogo e então o mesmo travamento na tela de carregamento ocorre, mas no jogo. Às vezes, a GUI da primeira pessoa tem a chance de carregar e outras vezes não. Não consigo fazer nenhum pressionamento de tecla, olhe ao redor, a física para se eu estiver flutuando no lugar, ela pára de funcionar, sem menus e o aplicativo consome CPU.

Gentoo com AMDGPU.

Hmmm, por acaso você não tem uma CPU Zen2? Ryzen 3xxx

É um Intel de 4ª geração, que em breve será uma 3ª geração novamente quando eu puxo meu laptop coreboot. Ele não tem nenhum dos novos problemas de instrução da CPU.

Algum outro componente (software) do meu sistema deve estar bagunçando isso.

Pelo que vejo, a única diferença do meu sistema para o seu é que não executei "vcrun2015 xact", farei isso e verei se recebo esse erro.

Você 110% precisa ter vcrun2015 et al. Instalado.

NVIDIA-SMI 435,21
wine-4.15 (Staging) (eu não usei vinho embora)
winetricks 20190615 (eu não usei winetricks também)

Sua versão do Winetricks tem 3 meses, embora possa não ter nada a ver com os problemas que estamos tendo. É provavelmente melhor tê-los o mais idênticos possível, hein? Você também não mencionou uma versão mono, suponho que você a instalou também?

@StripedMonkey, executei WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" winetricks --force -q vcrun2015 xact
e depois:
WINEPREFIX="$HOME/.local/share/Steam/steamapps/compatdata/244850/pfx" msiexec -i "Downloads/wine-mono-4.9.3.msi

desta vez, quando iniciei um jogo, ele não travou imediatamente, no entanto, fiquei preso na tela de carregamento por 15 minutos (comecei a gerar o mundo às 01:30 hora local), sem travamentos, mas imagino que o jogo seria preso na tela de carregamento para sempre
ainda não tinha som e ainda não conseguia usar o alt-tab, tive que sair do XFCE e matar o processo no terminal.

Eu não mencionei o mono porque ele deve ser instalado por padrão, não é? também não tenho protontricks para verificar a versão mono no prefixo do steam (winetricks mostra a versão para wine eu suponho?)

Vou atualizar o winetricks para a versão mais recente e verificar a versão mono.

aqui está o novo log:
https://pastebin.com/YNLAK9We
atualizar:
a versão mono é "mono-6.0.0.319-1"

Experimente estes patches:
NEWPatches.tar.gz
Você precisará colocar as DLLs originais no diretório SE antes de aplicar esses patches. O IE verifica a integridade dos arquivos do jogo se você não fez backups.

Se isso funcionar, atualizarei o repositório com esses patches pela manhã.

Eu não mencionei o mono porque ele deve ser instalado por padrão, não é? também não tenho protontricks para verificar a versão mono no prefixo do steam (winetricks mostra a versão para wine eu suponho?)

Mono! = Vinho-mono. Você não precisa do protontricks instalado para verificá-lo e (o guia do Linux74656 o mencionou especificamente) ele pediu 4.9.3

Posso dizer com certeza que esse mono não está correto simplesmente porque o versionamento não corresponde à versão atual do wine-mono, que lançou 4.9.3 há uma semana

Eu não mencionei o mono porque ele deve ser instalado por padrão, não é? também não tenho protontricks para verificar a versão mono no prefixo do steam (winetricks mostra a versão para wine eu suponho?)

Mono! = Vinho-mono. Você não precisa do protontricks instalado para verificá-lo e (o guia do Linux74656 o mencionou especificamente) ele pediu 4.9.3

Posso dizer com certeza que esse mono não está correto simplesmente porque o versionamento não corresponde à versão atual do wine-mono, que lançou 4.9.3 há uma semana

como faço para verificar o wine-mono? ao pesquisar no google, vejo apenas perguntas relacionadas a erros "mono não encontrado".

Experimente estes patches:

Se isso funcionar, atualizarei o repositório com esses patches pela manhã.

O que mudou?

@ Linux74656 Com este novo patch, estou recebendo a nhttps: //support.microsoft.com/kb/3120241 \ n \ nO jogo não funcionará corretamente, caso contrário

ok, eu tentei muitas coisas, mas não consigo entrar em nenhum jogo :(
Não consigo criar um novo jogo, não consigo entrar em um jogo em um computador Windows, não consigo tentar carregar um jogo salvo (baixado aqui).

Aqui estão alguns registros quando tento criar um novo jogo: https://dl.cafe-philo.net/logsse.tar.gz
Não encontrei nada de útil nesses logs, mas talvez não procure no lugar certo.

O prefixo é configurado como diz o documento, tente winxp ou win7.
Tente adicionar outro componente (crun2003 vcrun2005 vcrun2015 vcrun2017 xact d3dcompiler_43 d3dcompiler_47)

Eu percebi o pequeno erro no VRage e Vrage e reapliquei o patch.

Tentei iniciar um jogo com várias opções diferentes (experimental, som, scripts, etc.).

Instalei o mono-devel, mas isso não muda nada.

Eu voltarei mais tarde, talvez eu tenha perdido alguma coisa ...

Instalei o mono-devel, mas isso não muda nada.

conforme mencionado anteriormente wine-mono! = mono-devel. você o instalou de https://github.com/madewokherd/wine-mono/releases ?

Instalei o mono-devel, mas isso não muda nada.

conforme mencionado anteriormente wine-mono! = mono-devel. você o instalou de https://github.com/madewokherd/wine-mono/releases ?

Sim, sim, instalei isso com wintetricks conforme mencionado na documentação.
Mas, para ter certeza, instalei o mono-devel, pois meu jogo continua travando quando tento iniciar algo.

Pude começar um novo mundo alienígena desta vez, tudo bem. Então, decidi tentar entrar em um servidor MP (local sem mods) e ele parecia estar carregando, mas acabou travando após 20 segundos :(

SpaceEngineers.log

@jarrard Você já tentou carregar em um servidor Windows? O log diz claramente, a mesa MP está desligada (o problema que mencionei antes)

Em relação ao jogo travar, se você conseguir fazer um dump do jogo enquanto ele está neste estado (ou qualquer outra coisa que você costuma fazer no Linux para inspecionar o estado interno de um processo), isso pode nos dizer o que está acontecendo.

a mesa MP está desligada (o problema que mencionei antes)

Desculpe, não tenho ideia do que você está falando, era o servidor Austrália 2 que funcionava no Windows.

[...] há uma tabela fixa de consultas de MP que o cliente e o servidor criam na inicialização. Se você modificar seu jogo muito pesadamente, você pode jogar esta mesa do seu lado e o servidor se recusará a deixá-lo conectar
https://github.com/ValveSoftware/Proton/issues/1792#issuecomment -536186685

Ou é apenas mais um problema com BCL diferente que vem do Mono. Em qualquer dos casos, parece que não será tão trivial fazer o jogo cruzado funcionar.

Tudo bem. @SpookySkeletons

O que mudou?

Os novos patches são dos binários modificados corretamente. Vamos apenas dizer que eu era TheBigDumb ^tm e tomei um atalho ao modificar o código descompilado, modificando os métodos de código C # e recompilando-o (sem o código-fonte completo ... eu sei direito!). Desta vez, usei apenas o editor de Linguagem Intermediária para modificar os binários. Parece ter corrigido muitos dos travamentos de inicialização que ocorreram. Eu aprendi minha lição. Chega de atalhos se eu não souber exatamente o que estou fazendo!

@StripedMonkey

@ Linux74656 Com este novo patch, estou recebendo a nhttps: //support.microsoft.com/kb/3120241 \ n \ nO jogo não funcionará corretamente, caso contrário
Você pode tentar apenas reaplicar o patch para Sandbox.Game.dll. Embora eu apenas reaplicaria os dois patches em novas cópias originais dos arquivos DLL.

@LtSich Os novos patches provavelmente resolverão seus problemas com o carregamento mundial. Além disso, não acho que a versão mono fará diferença (contanto que seja mais recente). Acabei de incluí-lo no guia de uniformidade, para garantir que todos estariam executando a mesma versão caso ocorressem erros.

@jarrard Infelizmente, parece que o multiplayer com computadores Windows não estará disponível no momento. Mas posso confirmar que se você jogar com outros computadores Linux que tenham esse patch, o jogo funciona muito bem.

Eu atualizei o repositório do guia aqui: https://github.com/Linux74656/SpaceEngineersLinuxPatches para incluir os novos patches. Todos devem seguir novamente o guia e aplicar os novos patches. Certifique-se de aplicar os patches às DLLs originais (ou seja, verificar a integridade do jogo ou copiar os backups que você fez de volta para o diretório Bin64)

Quase virei minha mesa até que percebi que os engenheiros espaciais tinham acabado de fazer uma atualização: sorria: se o seu jogo for atualizado para a versão mais recente, os patches não funcionarão. Vou compilar um novo CORRETAMENTE! e colocá-los no repo.
@InflexCZE existe uma maneira de saber qual versão do jogo está no computador sem executar o jogo? Isso será útil para garantir que as pessoas apliquem os patches corretos.

Infelizmente, ele foi atualizado nas minhas costas: sweat_smile: Acho que tenho que esperar por esses novos patches.

Temo que a versão do jogo esteja incorporada ao binário e não haja nenhum "Version.txt" extra ou algo parecido.

@ Linux74656

cat $HOME/.local/share/Steam/steamapps/appmanifest_244850.acf | grep buildid | cut -f 4 | sed -e 's/"//g'

Um pouco desajeitado, provavelmente uma maneira mais agradável de fazer isso usando awk (eu deveria realmente inclinar awk !), Mas funciona para obter o número da compilação instalada atual. O número de compilação mais recente pode ser recuperado usando steamcmd se o seu plano é escrever um script de inicialização para verificar cada execução ou algo assim, consulte: https://steamcommunity.com/app/346110/discussions/0/530646715636738547 /

Eu recomendaria exigir algum tipo de analisador JSON se você está indo por esse caminho, entretanto, pesquisar isso é muito complicado, pelo menos para o meu gosto. Venha para pensar sobre isso, Python deve funcionar bem para isso, ele está instalado em quase todas as distros de qualquer maneira.

Tudo bem, eu carreguei os novos patches 1.192.103. Se o seu jogo foi atualizado, você precisa aplicar esses patches em vez dos outros.
@ Onyx47 você acha que uma verificação de checksum simples nas DLLs seria eficaz o suficiente? Eu poderia tentar escrever um script para comparar as DLLs dos usuários com uma lista de checksum pré-gerada, que deveria em teoria corresponder à versão do jogo instalada. Talvez ele pudesse executar o bspatch automaticamente e instalar a versão correta para o usuário.

@ Linux74656 funcionaria, eu acho, mas honestamente estava pensando que algo mais simples poderia funcionar:

1. Um script para gerar patches que:
   
   
   
   • Pega a DLL original, DLL modificada, cria um patch e o coloca em um arquivo chamado algo como SE_Linux_$buildnumber.tar.gz
   
   
   • Carrega o arquivo em algum lugar, seja no GitHub ou em outro servidor
   
   
2. Um script para o usuário que:
   
   
   
   • Lê a versão atual instalada e verifica se um arquivo chamado SE_Linux_$buildnumber.tar.gz existe em um servidor / GitHub.
   
   
   • Se for 404, o patch ainda não existe
   
   
   • Se ele existir, baixe-o, aplique-o e escreva um arquivo em algum lugar (o diretório de dados SE provavelmente seria o mais seguro) que contenha o número do patch mais recente baixado. Isso pode ser usado no futuro para verificar se algo precisa ser baixado na próxima execução.
   
   
   • Se tudo estiver bem (ou nenhum patch for necessário), execute o jogo através do Steam
   
   

Alguma verificação dos arquivos ainda é uma opção em todo o processo, é claro, mas isso parece ser a menor quantidade de trabalho necessária em ambos os lados da equação depois que os scripts são escritos. A única desvantagem disso é que ele não lidaria com atualizações, então talvez a parte de inicialização seja algo que seja melhor manter no Steam, então ele atualiza lá e o usuário pode simplesmente executar o patcher se uma atualização acontecer.

Eu tenho um servidor com espaço livre suficiente e largura de banda ilimitada que posso providenciar para a causa se decidirmos não usar GH para eles, só preciso configurar uma conta FTP para a parte de upload e deve ficar tudo bem.

Provavelmente poderei encontrar algo utilizável esta noite, assim que colocar minha máquina de volta em ordem de funcionamento.

bem, novo patch ou não meu jogo continua a travar ...
Usando o teste Debian ... Bem ... Isso é triste para mim ....

@LtSich Tenho um palpite sobre os problemas de travamento. Tente excluir seu prefixo de vinho. Reinstale a versão mono listada no guia. Em seguida, instale apenas vcrun2017 e xact.
Eu verifiquei a página Steamdb dos engenheiros espaciais e vcrun2017 é o único vcruntime listado. Eu o tenho (e muitos outros) instalado no meu sistema e tenho travamentos muito raros.

já existe uma solução para scripts? Não consigo me conectar a nenhum servidor onde os scripts estão sendo executados.
a atualização funciona muito bem. THX

@LtSich Tenho um palpite sobre os problemas de travamento. Tente excluir seu prefixo de vinho. Reinstale a versão mono listada no guia. Em seguida, instale apenas vcrun2017 e xact.
Eu verifiquei a página Steamdb dos engenheiros espaciais e vcrun2017 é o único vcruntime listado. Eu o tenho (e muitos outros) instalado no meu sistema e tenho travamentos muito raros.

Obrigado pelas dicas, mas isso não muda nada ... Bem, vou apenas sentar no fundo e esperar a bênção de Deus, talvez isso funcione :)

Espero que o multiplayer com máquinas Windows possa acontecer em algum momento. Parece uma pena, realmente.

Comprei e instalei engenheiros espaciais para ver se finalmente funcionaria. Segui as instruções para corrigir o jogo.

Consegui acessar o menu principal conforme esperado, mas não consegui iniciar um Cenário ou um Jogo Personalizado. O jogo chegou à tela de carregamento, carregou por cerca de 5 a 10 segundos e o processo parou de funcionar. Não tenho certeza de onde procurar o problema. Aqui estão alguns arquivos de registro, mas realmente não consigo aprender nada com eles:

SpaceEngineers.log
steam-244850.log

@dsge me faça um favor. Verifique a integridade dos arquivos do jogo.
Salve uma cópia deste arquivo: https://github.com/Linux74656/SpaceEngineersLinuxPatches/blob/master/autopatcher.py em sua área de trabalho ou na pasta de downloads. Em seguida, abra o terminal / Konsole no mesmo diretório e execute:
python3 autopatcher.py

Não está completo, mas deve pelo menos ser capaz de corrigir o seu jogo por enquanto.
Deixe-me saber dos resultados.

Eu estarei contribuindo com o autopatcher em um momento, se você não se importa @ Linux74656. Pelo menos python eu sei que posso ajudar com: P

Bem, acontece que uma grande parte do que foi corrompido no antigo HDD era coisa do Steam, então estou baixando novamente o jogo para o caso. Comecei alguns trabalhos básicos no patcher enquanto estou esperando, vamos descobrir solicitações pull e mesclagens conforme avançamos, pois vejo que @StripedMonkey também está ajudando.

@StripedMonkey , verifique meu fork se você não se importar, veja que não duplicamos o trabalho se não for necessário;) (Observação: eu realmente não faço Python além de consertos como este, então algumas das minhas coisas podem não ser as melhores práticas). Provavelmente deveríamos começar a rastrear essas coisas nesse projeto também, para não poluir mais esse tópico de problemas.

Bem, você certamente teve alguns dos mesmos problemas com ele: P, embora você tenha feito isso de uma maneira diferente. Na verdade, vou criar um problema na página Patches para que possamos deixar aqui para lidar com a solução de problemas do SE.

Agradeço a ajuda de qualquer pessoa quando se trata disso! Tenho muito pouca experiência em python.

@ Linux74656 Verifiquei os arquivos do jogo e executei o arquivo py (versão 7f742ac1 ):

$ python3 autopatcher.py
Please insert your install location for Space Engineers. Should look somthing like this /home/USER/.local/share/Steam/steamapps/common/SpaceEngineers/ 
/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/
b6d168be7e38640817f8d7f1de523346
cf4b860b7917fa53d8c95e0c6a377451
VERSION FOUND: 1.192.103
https://raw.github.com/Linux74656/SpaceEngineersLinuxPatches/master/V1.192.103Patches.tar.gz
Program End!

Não toquei no meu prefixo wine, ele ainda está no mesmo estado em que estava depois das instruções originais .

Desta vez, o jogo está realmente instável. Anteriormente (quando eu instalava os hacks manualmente), eu conseguia acessar o menu principal e a tela de carregamento a cada tentativa e só travava depois disso. Desta vez, eu tive vários lugares onde o jogo travou (também conhecido como a janela do jogo e o processo simplesmente desaparece) nas execuções subsequentes:

• depois da tela inicial
• depois de pressionar "Não" na caixa de diálogo de coleta de dados
• e depois da tela de carregamento.

Fiz cerca de 15 tentativas e não consegui realmente passar da tela de carregamento. Eu não consegui entrar no jogo, nem uma vez.

Esses logs foram feitos quando consegui chegar à tela de carregamento antes do jogo travar:
SpaceEngineers.log
steam-244850.log
(Devo postar isso? Não tenho ideia do que postar que ajudaria)

Na verdade, esse é um problema conhecido, quando você diz "Não" à coleta de dados, o jogo começa a travar (somente Linux).
Exclua appdata do jogo (para redefinir a decisão, faça backup de quaisquer mundos ou BPs, se tiver), concorde na próxima vez que o jogo perguntar e você estará pronto para ir.

Pelo que entendi, na verdade é o contrário. Clicar em "sim" faz com que ele trave. : pensando: (como alguém que sempre acertou "não")

@InflexCZE Se eu disser "sim", obtenho o mesmo resultado depois disso (o processo desaparece após a tela de carregamento), porém, na próxima execução, o jogo trava na tela inicial com o relator de falha real:

See the end of this message for details on invoking \njust-in-time (JIT) debugging instead of this dialog box.\n\n************** Exception Text **************\nSystem.ComponentModel.Win32Exception (0x80004005): Sikeres.

  at System.Diagnostics.Process.StartWithShellExecuteEx (System.Diagnostics.ProcessStartInfo startInfo) [0x00102] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at System.Diagnostics.Process.Start () [0x00032] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.Start()
  at System.Diagnostics.Process.Start (System.Diagnostics.ProcessStartInfo startInfo) [0x0001b] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at System.Diagnostics.Process.Start (System.String fileName) [0x00006] in <f508ff7dc2d3475abfc25b6b60600edf>:0 
  at VRage.Platform.Windows.Forms.MyMessageBoxCrashForm.linklblLog_LinkClicked (System.Object sender, System.Windows.Forms.LinkLabelLinkClickedEventArgs e) [0x00010] in <6669c852ae2c4f45a64d6d2ce7411724>:0 
  at System.Windows.Forms.LinkLabel.OnLinkClicked (System.Windows.Forms.LinkLabelLinkClickedEventArgs e) [0x00020] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.LinkLabel.OnMouseUp (System.Windows.Forms.MouseEventArgs e) [0x000fb] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control.WmMouseUp (System.Windows.Forms.Message& m, System.Windows.Forms.MouseButtons button, System.Int32 clicks) [0x001c3] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x005a0] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Label.WndProc (System.Windows.Forms.Message& m) [0x0005d] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.LinkLabel.WndProc (System.Windows.Forms.Message& msg) [0x0001b] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.OnMessage (System.Windows.Forms.Message& m) [0x00001] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x000b3] in <2880ee803a384afc84fc95657b396772>:0 
  at System.Windows.Forms.NativeWindow.Callback (System.IntPtr hWnd, System.Int32 msg, System.IntPtr wparam, System.IntPtr lparam) [0x00030] in <2880ee803a384afc84fc95657b396772>:0 

\n************** Loaded Assemblies **************\nmscorlib\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/4.5/mscorlib.dll\n----------------------------------------\nSpaceEngineers\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.exe\n----------------------------------------\nSandbox.Game\n    Assembly Version: 0.1.1.0\n    Win32 Version: 0.1.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Sandbox.Game.dll\n----------------------------------------\nnetstandard\n    Assembly Version: 2.0.0.0\n    Win32 Version: 4.6.26011.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/netstandard.dll\n----------------------------------------\nVRage.Render\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Render.dll\n----------------------------------------\nVRage.Steam\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Steam.dll\n----------------------------------------\nVRage\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.dll\n----------------------------------------\nSpaceEngineers.Game\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.Game.dll\n----------------------------------------\nSystem\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll\n----------------------------------------\nVRage.Library\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Library.dll\n----------------------------------------\nSystem.Xml\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll\n----------------------------------------\nVRage.Math\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Math.dll\n----------------------------------------\nVRage.Game\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Game.dll\n----------------------------------------\nVRage.NativeWrapper\n    Assembly Version: 0.1.1.0\n    Win32 Version: 0.1.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.NativeWrapper.dll\n----------------------------------------\nSandbox.Graphics\n    Assembly Version: 0.1.1.0\n    Win32 Version: 0.1.1\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Sandbox.Graphics.dll\n----------------------------------------\nSandbox.Common\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Sandbox.Common.dll\n----------------------------------------\nSystem.Core\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll\n----------------------------------------\nVRage.Platform.Windows\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Platform.Windows.dll\n----------------------------------------\nSystem.Windows.Forms\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Windows.Forms/4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll\n----------------------------------------\nSteamworks.NET\n    Assembly Version: 13.0.0.0\n    Win32 Version: 13.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/Steamworks.NET.dll\n----------------------------------------\nSharpDX\n    Assembly Version: 4.2.0.0\n    Win32 Version: 4.2.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SharpDX.dll\n----------------------------------------\nSharpDX.DXGI\n    Assembly Version: 4.2.0.0\n    Win32 Version: 4.2.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SharpDX.DXGI.dll\n----------------------------------------\nSystem.Runtime\n    Assembly Version: 4.1.2.0\n    Win32 Version: 4.6.25714.01\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/System.Runtime.dll\n----------------------------------------\nSharpDX.Direct3D11\n    Assembly Version: 4.2.0.0\n    Win32 Version: 4.2.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/SharpDX.Direct3D11.dll\n----------------------------------------\nVRage.Ansel\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/VRage.Ansel.dll\n----------------------------------------\nProtoBuf.Net\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/ProtoBuf.Net.dll\n----------------------------------------\nProtoBuf.Net.Core\n    Assembly Version: 1.0.0.0\n    Win32 Version: 1.0.0.0\n    CodeBase: file:///Z:/media/egyteras/SteamLibrary/steamapps/common/SpaceEngineers/Bin64/ProtoBuf.Net.Core.dll\n----------------------------------------\nSystem.Reflection.Emit.Lightweight\n    Assembly Version: 4.0.1.0\n    Win32 Version: 4.0.0.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/4.5/Facades/System.Reflection.Emit.Lightweight.dll\n----------------------------------------\nSystem.Reflection.Emit.ILGeneration\n    Assembly Version: 4.0.1.0\n    Win32 Version: 4.0.0.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/4.5/Facades/System.Reflection.Emit.ILGeneration.dll\n----------------------------------------\nAnonymously Hosted DynamicMethods Assembly\n    Assembly Version: 0.0.0.0\n    Win32 Version: n/a\n    CodeBase: \n----------------------------------------\nSystem.Drawing\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Drawing/4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll\n----------------------------------------\nAccessibility\n    Assembly Version: 4.0.0.0\n    Win32 Version: \n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/Accessibility/4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll\n----------------------------------------\nSystem.Configuration\n    Assembly Version: 4.0.0.0\n    Win32 Version: 4.6.57.0\n    CodeBase: file:///C:/windows/mono/mono-2.0/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll\n----------------------------------------\n\n************** JIT Debugging **************\n

Tive que editar meu SpaceEngineers.cfg 's GDPRConsent campo de volta de True para False para mover além disso.

Ou minha memória está falhando. Ignore-me, devo dormir: upside_down_face:

EDITAR:
Em qualquer caso, seria bom rastrear "problemas conhecidos" em algum lugar junto com "soluções conhecidas".

Atualização para quem pode entrar no jogo. instale vcrun2003 no topo de seu prefixo de trabalho. Isso pode resolver o travamento enquanto você está no jogo. A melhor maneira de testar isso é criar uma versão criativa do mundo Alien planet world, entrar no lutador de dissuasão e começar a atirar nas naves menores próximas com mísseis. Isso parecia causar falhas no computador da minha irmã até que instalei o vcrun2003. Coloque o jogo sob o máximo de estresse possível e se ele não travar, carregue em outro mundo e tente novamente. Se ainda não travar, acho que esse é o problema.

Quanto às pessoas que ainda não conseguem entrar no mundo do jogo devido a travamentos e congelamento. Vamos tentar uma instalação geral de tudo na minha história de winetricks, que seria sobre a versão mono no guia.
winetricks --force -q vcrun2003 vcrun2005 vcrun2015 vcrun2017 msxml6 xact d3dcompiler_47 corefonts dxvk winxp

Avise-me se alguma coisa mudar!

@ Linux74656
Eu validei meus arquivos novamente. Então eu fiz:

$ rm -rf / media / egyteras / SteamLibrary / steamapps / compatdata / 244850 / pfx

$ WINEPREFIX = "/ media / egyteras / SteamLibrary / steamapps / compatdata / 244850 / pfx" winetricks --force -q vcrun2003 vcrun2005 vcrun2015 vcrun2017 msxml6 xact d3dcompiler_47 corefonts dxvk winxp

$ WINEPREFIX = "/ media / egyteras / SteamLibrary / steamapps / compatdata / 244850 / pfx" msiexec -i "./wine-mono-4.9.3.msi"

$ python3 autopatcher.py
bsdiff está instalado!
Não é possível localizar o diretório de instalação. Insira o local da pasta steamapps onde Space Engineers está instalado.
/ media / egyteras / SteamLibrary / steamapps /
BuildID: 4246126
checksum.json recuperado
Patches recuperados
Programa completo!

(a versão autopatcher.py é a de Linux74656 / SpaceEngineersLinuxPatches # 5)

Infelizmente, o comportamento depois disso ainda é o mesmo dos comentários anteriores: o jogo trava à esquerda e à direita e não consigo passar pela tela de carregamento.
Os arquivos de log não mostram nenhuma alteração, tanto quanto posso dizer:
SpaceEngineers.log
steam-244850.log

Eu fiz um teste rápido e meu jogo travou ao carregar. Eu apliquei os novos patches para v103, mas talvez eu verifique novamente e tente novamente.

@dsge Obrigado pela correção do autopatcher! Você poderia me dizer sua versão do sistema operacional, versão do kernel.

@ Linux74656

steam_systeminfo.txt

Mudei meu jogo para o NVMe, refiz o patch. Parece funcionar bem na segunda tentativa de qualquer maneira.
Eu realmente espero que o desenvolvedor do Space Engineers possa fazer esses patches funcionarem com servidores multiplayer do Windows, acho que é um problema muito importante a ser superado.

@dsge Tente executar o jogo com este arquivo de configuração:
Não altere nenhuma configuração até tentar carregar um mundo vazio.

EDITAR: Use este em vez disso, o outro era em francês (na verdade eu não falo francês, mas estava vendo se o jogo agia de forma diferente com outra localização ... não parece).
SpaceEngineers.cfg.zip

Sim, eu estava me perguntando por que a localidade francesa seria mais adequada para executar o jogo: D

Assim, o jogo personalizado chamado "mundo vazio" faz carga até :

(Eu não sabia que havia literalmente um jogo personalizado com esse nome, como disse, acabei de comprar o jogo ontem.)

Outros jogos personalizados parecem não funcionar, no entanto, tive apenas 1 travamento das 8 tentativas que fiz em outros jogos personalizados. Nas outras 7 vezes, fiquei preso na tela de carregamento. Por "travado", quero dizer que pude ver no Gnome System Monitor que o jogo não lê ou grava nada na minha unidade e usa 50% da CPU (também conhecido como usa totalmente 2 dos meus 4 núcleos).

Monitorar o sistema se o jogo não lê ou grava nada na minha unidade e usa 50% da CPU (também conhecido como usa 2 dos meus 4 núcleos).

Sim, isso é típico do que você experimenta quando ele decide que não vai carregar. Já tive muitas vezes, mas normalmente consigo na segunda tentativa. Não sei por que está sempre falhando para você. Ele depende do mono para fazer o trabalho de compilação mundial, então talvez o mono esteja interrompendo seu sistema para cargas de trabalho maiores.

Você pode definir parâmetros diferentes para mono no carregamento, atm eu uso _MONO_GC_PARAMS = Nursery-size = 32m, minor = simple-par% command% _

OK, estamos progredindo.
Percebi que o computador da minha irmã tem o mesmo problema de carregamento de vez em quando. Mas meu computador não. Não pensei muito nisso, pois era apenas um pequeno inconveniente, mas pode estar relacionado, então vou ver se consigo consertar no dela.

Ainda estou tendo problemas para carregar nada. Não conseguiu lançar um mundo uma única vez, apesar de várias tentativas e fazendo várias coisas.

Eu estava acompanhando os logs do SE enquanto tentava, e parece que está conectado a definições de carregamento na maioria das vezes, não em particular pelo que vejo, apenas definições em geral - às vezes carrega definições de voxel bem, às vezes não carrega nada, e então simplesmente trava. Fiz uma corrida em que ele realmente carregou tudo e tentei iniciar uma sessão, mas depois travou.

Estou meio perplexo no momento, não tenho ideia se tentar anexar qualquer tipo de depurador mono nos daria algo útil, já que esta compilação não tem símbolos de depuração, mas no momento parece ser totalmente inconsistente, tanto entre as cargas em um único sistema e entre os próprios sistemas.

Enquanto eu estou feliz que tudo isso nos deu pelo menos algumas dicas, e espero que possamos descobrir se Mono é pelo menos uma solução viável temporária, estou meio tentado a apenas tentar voltar ao dotnet e ver se seguindo os logs do Wine podemos revelar o que exatamente está atrapalhando o GC e ver se podemos consertar isso no Wine ...

Você pode definir parâmetros diferentes para mono no carregamento, atm eu uso _MONO_GC_PARAMS = Nursery-size = 32m, minor = simple-par% command% _

@jarrard Eu tentei isso agora. Infelizmente, a única diferença que notei é que agora o jogo voltou a travar 100% após a tela de carregamento (o que significa que não fica preso aí). "Empty World" ainda carrega muito bem, nenhuma mudança aí.

OK, estamos progredindo.
Percebi que o computador da minha irmã tem o mesmo problema de carregamento de vez em quando. Mas meu computador não. Não pensei muito nisso, pois era apenas um pequeno inconveniente, mas pode estar relacionado, então vou ver se consigo consertar no dela.

@ Linux74656 Obrigado a você e a todos que estão dedicando seu tempo a isso. Muitos dos meus amigos jogam este jogo e eu realmente gostaria de experimentá-lo para ver se é bom. Pelo menos no modo single player por enquanto.

@InflexCZE Você acha que as pessoas poderiam tentar instalar esses patches em suas versões do jogo para Windows? Isso permitiria que algumas pessoas jogassem com usuários do Windows, aqueles que criam seus próprios jogos personalizados.

EDIT: Também existe alguma maneira de desativar temporariamente a coleta de lixo durante a execução do dotnet? Se desativá-lo remover a gagueira, saberemos qual é o problema.

@dsge Verifique seus arquivos de jogo. Não aplique o patch e, em vez disso, crie um novo prefixo para executar o jogo com o seguinte comando:
winetricks --force -q vcrun2015 xact dotnet472

Se você conseguir lançar o jogo em um mundo com isso, então o seu problema provavelmente está relacionado ao wine-mono e aos patches.

@ Linux74656 Você pode tentar, mas duvido que as mudanças que você fez causassem uma diferença tão grande na tabela MP, como vi nos logs. Existem muitos plug-ins e projetos de comunidade para SE que executam milhares de pequenos patches ou substituem métodos e sistemas inteiros e funcionam bem com clientes vanilla.

Imho, este é outro problema vindo das diferenças no Mono BCL. Infelizmente, consertar este, ao contrário do compilador de script, seria muito mais complicado, principalmente por causa da serialização.

Em relação ao GC, é um sistema muito essencial que rastreie e recupere a memória que não é mais usada pelo jogo para que possa ser reciclada e usada novamente (Sim, sistema de pensamento muito verde, a mãe natureza se orgulha: stick_out_tongue :) Tenho certeza há uma maneira de instruir o .NET FW GC a alocar nova memória do sistema operacional em vez de tentar identificar e recuperar bits que não são mais usados ​​(ou seja, em vez de fazer todo o trabalho intensivo de desempenho), mas esteja ciente de que você está olhando para a RAM consumo em algum lugar em uma vizinhança de + 500 GB apenas para entrar em uma cena vazia. Portanto, a menos que você tenha um PC ou Linux realmente preparado para o futuro, conheça alguma mágica muito boa sobre a troca, não acho uma boa ideia seguir esse caminho. Em qualquer caso, tentar configurá-lo manualmente com os parâmetros adequados, o mesmo que fizemos com Mono GC antes, pode corrigir isso.

Como alternativa, você pode tentar o .NET Core. A última vez que ouvi falar, ele funciona muito bem no Linux e deve ser muito compatível com .NET FW, mesmo em BCL. A última vez que tentamos, ele conseguiu executar o servidor dedicado SE _quase_ fora da caixa, então, quem sabe, talvez funcione ainda melhor do que o Mono.

@InflexCZE Vou dar uma chance ao dotnetcore e ver se ele coopera.
Eu olhei para a documentação de como funciona o dotnet GC. A imagem mostrada nesta seção falando sobre threading: https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals#what -happens-during-a-garbage-collection atua de forma semelhante à criação de perfil tiros que tentei obter. Um único núcleo salta para 100% de uso, enquanto o resto parece diminuir significativamente em uso ou parar. Isso poderia ser uma coincidência?

@InflexCZE Eu estava mais pensando em verificar os logs para ver quais chamadas para bibliotecas nativas do Windows não estão completamente implementadas no Wine e apenas ver se elas podem ser preenchidas corretamente e se isso ajudaria. Muitas coisas na implementação do Wine da API do Windows são apenas esboçadas e implementadas apenas o suficiente para fazer as coisas funcionarem inicialmente, e estão sendo lentamente preenchidas com o tempo.

Quanto ao .NET Core, ainda precisaríamos executá-lo no Wine (pelo menos partes do VRage). Quer dizer, o próprio VRage depende do WINAPI, certo? E também suspeito que o ABI seja compatível, já que, afinal, é um aplicativo do Windows. Além disso, ainda precisamos traduzir essas chamadas DirectX para OpenGL ou, de preferência, Vulkan. Talvez seja algo que possa ser feito independentemente do Wine, não li sobre isso.

Indiscutivelmente, quaisquer bugs do Wine que afetem o .NET 4.7 também afetariam o Core, já que teríamos que executar a versão do Windows dele de qualquer maneira. E observe, o uso atual do Mono para SE não é rodarmos o Linux Mono nativo e apenas alimentar o executável SE para ele; na verdade, é uma construção feita especificamente para o Wine e, na verdade, é um aplicativo do Windows.

Além disso, como eu uso o .NET Core para o desenvolvimento do Linux (mas não lido com coisas de baixo nível no .NET o suficiente para ter conhecimento dessa parte), posso dizer que sim, o código funcionará normalmente , mas há muitas coisas que não funcionam entre plataformas: não há Windows Forms, é claro, algumas coisas como System.Drawing agora existem como um pacote nuget, mas não são 100% compatíveis ... Basicamente, algo como um serviço que você seria executado em um servidor? Deveria trabalhar. Algo gráfico? Na verdade não.

Tenho certeza de que há uma maneira de instruir o .NET FW GC a alocar nova memória do sistema operacional em vez de tentar identificar e recuperar bits que não são mais usados ​​(ou seja, em vez de fazer todo o trabalho intensivo de desempenho), mas esteja avisado, estou olhando para o consumo de RAM em algum lugar perto de + 500 GB apenas para entrar em uma cena vazia.

Com base em minha experiência (reconhecidamente limitada), eu realmente acho que zram pode realmente ser capaz de lidar com a compressão de uma cena vazia enquanto deixa o GC desligado. Se forem dados semelhantes (e eu assumiria que seria em uma cena vazia), então eles devem ser facilmente compactáveis. Obviamente, não é uma boa solução e pode afetar a pref. Mas acho que seria realmente interessante tentar.

Deixe-me esclarecer. O jogo não pré-aloca tanto mem apenas para o caso de ser necessário. Seria aquela quantidade de bits aleatórios de memória usados durante o carregamento da cena vazia, mas não seriam mais necessários. O GC é capaz de encontrar esses bits e reciclar durante a vida útil do processo (~ a cada poucos quadros). Sem ele, eles ficarão lá e comerão espaço para sempre.

@ Onyx47 Você está certo, eu não percebi no momento que o Core não nos protegerá da necessidade de APIs do Win e executar o Win build sobre o Proton provavelmente sofreria dos mesmos problemas que o .NET FW.

@ Linux74656 Pode significar qualquer coisa. Pode ser GC ou pode ser renderização cheia enquanto a simulação está travada ou algo assim.

Fiz uma pesquisa rápida online, infelizmente parece que o .NET FW GC não oferece nenhuma opção de configuração (pelo menos nenhuma que valha a pena, tamanho fixo de heap, tamanho Gen 0, alocação de threads para trabalhos de coleção, .. .) então, a menos que você tenha mais alguns truques na manga sobre como traçar o perfil / identificar os picos, acho que estamos sem sorte aqui :(

@InflexCZE Se eu definir o tamanho de heap fixo e / ou Gen 0 para algo ridículo como 25 gb (um dos meus sistemas tem 32 gb de ram), isso impediria o coletor de lixo de funcionar por pelo menos alguns segundos?
Se sim, como eu o configuraria para fazer isso?

Sim, pilhas fixas de algum tamanho insano devem reduzir muito a frequência do GC (em troca de um ligeiro aumento do tempo de coleta _quando_ realmente acontece e do consumo ridículo de memória, ofc), mas como eu disse, não parece que o .NET GC suporta qualquer tipo de configuração (manual), infelizmente.

Eu entendo agora. Desculpe por toda a confusão.

@dsge Verifique seus arquivos de jogo. Não aplique o patch e, em vez disso, crie um novo prefixo para executar o jogo com o seguinte comando:
winetricks --force -q vcrun2015 xact dotnet472

Se você conseguir lançar o jogo em um mundo com isso, então o seu problema provavelmente está relacionado ao wine-mono e aos patches.

@ Linux74656 Fiz exatamente isso, aqui estão os resultados.

Estou recebendo isso duas vezes antes da tela inicial e uma vez se eu sair do jogo pelo menu (pressionar "sim" me leva até aqui - acho que graças à Microsoft):

Fora isso, o jogo começa. Consegui iniciar qualquer jogo personalizado que experimentei.

O jogo gagueja em intervalos muito regulares (não é totalmente visível em minhas imagens porque tirar uma imagem momentaneamente bagunça os tempos dos quadros e os fps relatados por dxvk hud), o que também causa gagueira em qualquer som que esteja sendo reproduzido. Em um mundo vazio era menos frequente (cerca de uma vez por segundo) e em um mundo mais construído era pelo menos 2-3 vezes por segundo. Além da gagueira, parece que tenho 120fps (todas as opções de gráficos são definidas com o valor mais baixo possível) sem muitos problemas no meu sistema ( especificações ).

Minha impressão geral é que tecnicamente o jogo funciona, mas a gagueira torna-o muito chato de jogar.

@dsge Sim ... a gagueira é o motivo pelo qual começamos a usar o wine-mono.
Pelo menos sabemos que os problemas com o lançamento no mundo estão relacionados ao wine-mono e aos patches.

Sim, eu sei, é também por isso que a coleta de lixo está sendo discutida. Eu só queria documentar que pelo menos com o dotnet472 estou obtendo praticamente o mesmo resultado que todo mundo. Ao contrário dos patches wine-mono + que, por qualquer motivo, parecem funcionar muito melhor para você do que para mim.

Há muita coisa acontecendo neste tópico, qual é a maneira certa de executar isso no momento? Eu instalei o xact dotnet472 para fazê-lo funcionar, mas ele gagueja muito no meu equipamento, vejo menções de um patch?

O processo atual é mencionado aqui (mas não super clean, irei trabalhar no readme um pouco se o Linux não). Basicamente, instale o vcrun2005, xact, wine-mono e use a ferramenta de patch para aplicar os patches do Linux ou faça isso manualmente com o bspatch. Atualmente não consigo fazer o multiplayer Linux-windows, mas linux-linux parece funcionar.

@InflexCZE O que <gcServer enabled="true"> faz exatamente? Isso quebraria o jogo de alguma forma que eu não pudesse entender? Eu adicionei a alguns arquivos e parece ter resolvido o problema de falha do dotnet. Não pode ser tão fácil ... no entanto, como isso tem algo a ver com coleta de lixo, contanto que o que eu mudei não quebrasse outras partes do jogo com uso intensivo de CPU, presumo que a falha no dotnet tenha sido relacionada ao GC o tempo todo . A menos que haja algo mais que eu esteja perdendo (considerando o quão tarde é isso é muito possível: sorria :),

onde está a configuração _gcServer enabled = "true" _? isso em uma configuração em algum lugar?

Você o testou em servidores windows mp para ver se você pode se juntar a eles (melhor teste no servidor sem mods para começar).

A MS é muito vaga sobre o que a predefinição de GC do servidor realmente faz, mas pelo que posso dizer, ela tenta aproveitar mais núcleos (que geralmente estão presentes nas máquinas do servidor) e aloca segmentos de memória maiores, o que resultaria em disparos menos frequentes de GC negociados aumento do consumo geral de mem do processo.
https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals#workstation -and-server-garbage-collection

Sinta-se à vontade para experimentá-lo, é altamente improvável que você quebre qualquer coisa no jogo com as configurações de GC, na pior das hipóteses pode começar a travar.

Este é realmente um achado interessante. Lendo um pouco eu mesmo (colado dos documentos):

For single-processor computers, the default workstation garbage collection
should be the fastest option. Either workstation or server can be used for
two-processor computers. Server garbage collection should be the fastest
option for more than two processors.

Isso me faz pensar que, embora o GC possa ser afetado ao executar no Wine, é possível que a parte do problema também esteja relacionada ao agendador? IIRC, muitas pessoas relataram que o jogo usa apenas 50% da CPU, embora esteja com problemas (e acho que isso também aconteceu comigo), embora eu tenha certeza que vi atingir pelo menos 80% no Windows no meu equipamento. Talvez seja apenas o problema de GC rodar no mesmo núcleo que o resto do jogo enquanto não acontece nativamente porque o agendador do Windows lida com as coisas de forma diferente e / ou o agendador do Linux não sabe que é thread-safe (possivelmente porque várias coisas que são separados em um sistema Windows real, todos podem estar em execução no processo wineserver no Linux), portanto, ele se recusa a movê-lo para um núcleo diferente?

Vou testar isso hoje à noite e relatar os resultados. Se funcionar, seria uma ótima notícia! Especialmente porque não vejo uma razão para isso não ser ativado no jogo em si, dados os seus requisitos, acho que podemos praticamente contar com todos jogando com um sistema multicore, ou pelo menos um hyperthreaded que ainda deve melhorar o desempenho. Sim, eu sei que os documentos mencionam vários processadores , mas com CPUs modernas essa linha é borrada de qualquer maneira, não é?

Olá eu tenho:
<Runtime> <gcServer enabled = "true" /> </Runtime>

inserido no final do meu SpaceEngineers.exe.config e o jogo agora está rodando com .net já 4 horas sem gaguejar.
Também no modo multijogador em um servidor Windows.

Alguém pode tentar isso?

@ Onyx47 SE é capaz de alavancar efetivamente apenas ~ 2,5 até 4 threads, dependendo da complexidade da cena. É um problema bem conhecido vindo da arquitetura antiga do motor usado. Se você não vê que ele está escalando bem com o número de códigos fornecidos, isso não significa _necessariamente_ que é falha de alguma coisa em sua configuração do Linux. Mais provavelmente, nossa dívida técnica.

Meu palpite desde o início é que o mecanismo de ajuste automático do GC está falhando por causa de alguns dados incorretos alimentados a ele do lado do Proton e é muito possível que esse problema não se manifeste no modo de servidor. Seja qual for o verdadeiro culpado, não importa muito, contanto que funcione bem: sorria:

Estou muito feliz que até mesmo o jogo cruzado com o Windows funcione bem. Scripts e mods também funcionam, certo?

Acabei de testar scripts.
funciona em modo multiplayer e singleplayer.
Mesmo com mods sem problemas

a carga da minha GPU é um pouco maior do que no Windows

Eu vejo um pico a cada 10-20 segundos em meu hud dxvk, mesmo uma leve queda de fps, 5-10 fps, mas a média está entre 50-60 com vsync e configurações altas (GPU RX580 8GB)

Aí você acabou de instalar o dotnet472, xact e fazer a mudança na configuração?
Isso é tudo ? Você pode usar a última versão do próton?

pacotes instalados: protontricks 244850 -q --force vcrun2005 vcrun2015 dotnet472 xact
configurações de inicialização do Steam: DXVK_HUD = PROTON_NO_ESYNC = 1% COMMAND% -skipintro completo

Próton: 4.11-6
Kernel: 5.0.0-30-genérico Ubuntu 19.04

Atualização: sry, esqueci dotnet472

ok, aparentemente não consigo instalar o vcrun2015, tenho este erro:
Nota: o comando /home/sich/.steam/steam/steamapps/common/Proton 4.11 / dist / bin / wine vc_redist.x86.exe / q retornou o status 102. Abortando.

mas instalei o dotnet472 e adicionei <gcServer enabled = "true" /> dentro do Runtime e agora está funcionando muito bem :)

Eu testei 2/3 mods e aparentemente está tudo bem para isso.

Mas adicionar isso ao final do arquivo .config não funciona. :

<Runtime>
  <gcServer enabled = "true" />
</Runtime>

Eu mudei o arquivo de configuração assim no final:

    </assemblyBinding>
  <gcServer enabled = "true" />
  </runtime>

Obrigado pelas dicas.
Se você sabe como aumentar o uso de memória (tenho 32 GB), diga-me, provavelmente vai ajudar.

o final da minha configuração fica assim:

  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
  </startup>
  <runtime>  
    <gcServer enabled="true"/>
  </runtime>
</configuration>

ok tá dentro da configuração então.
Provavelmente é o mesmo, contanto que permaneçamos dentro da configuração.

Mas não consegui fazer nada sem o dotnet472.

@diKsens Portanto, parece que não preciso adicioná-lo a todos os arquivos de configuração (Sandbox.Game.dll.config e VRage.Game.dll.Config). Apenas SpaceEngineers.exe.config. É bom saber.

Posso confirmar que os scripts funcionam de fato e que a conexão com servidores Windows (keen na) funciona sem problemas.

Posso pedir um log SE do .NET FW? Apenas registro regular após o jogo começar com sucesso.

@InflexCZE Aqui está!
SpaceEngineers.log

Ainda estou convencido de que algo está acontecendo nos bastidores. Eu usei o mod de aumento de velocidade e peguei a nave vermelha que bateu em outro asteróide a 300m / se o jogo praticamente não teve problemas com isso. Vou continuar testando.

_O jogo não teve problemas de desempenho quando fiz algo para o qual foi projetado._
Isso é uma coisa ruim ou o quê? 😛

Oh ... Eu pensei que o jogo limitava a velocidade da nave a 100m / s por causa de problemas de desempenho?

Depende. Jogue isso contra um planeta e espere o impacto amanhã desta vez. Ele irá aumentar a velocidade do sim muito forte, mesmo em equipamentos decentes.
https://steamcommunity.com/sharedfiles/filedetails/?id=501767620

Noto uma coisa aqui que também vi sob o Mono (mas pensei que poderia ser apenas uma coisa Mono):

2019-10-03 09:27:06.247 - Thread:   1 ->  GC Memory: 1,857,883,240 B
2019-10-03 09:27:06.251 - Thread:   1 ->  Process Memory:  B

Talvez valha a pena investigar no Wine, o GC pode estar usando uma chamada semelhante para WINAPI e não obtendo dados?

Esta chamada consulta NtQuerySystemInformation ( SystemProcessInformation ):
https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysysteminformation

Se você souber onde, pode verificar se está implementado corretamente ou apenas esboçado?

Bem, com esse pequeno arquivo de configuração ele funciona agora, muito bom na verdade. Até juntei um servidor MP, sem problemas.

O vcrun2015 também não foi instalado para mim, mas talvez já esteja instalado pelo Steam? de qualquer forma, isso é incrível. De classificação de lixo em protondb a ouro basicamente :)

https://source.winehq.org/git/wine.git/blob/a8745d1211033dd38682e2f4e8bc322d47a15e0f : /dlls/ntdll/nt.c#l2373

Parece estar implementado, mas também inclui um fixme, não tenho tempo suficiente para analisar profundamente o que pode estar errado com ele (se houver alguma coisa, a não ser como ele deixa o uso de memória em primeiro lugar com um cheiro ruim) agora .

@InflexCZE Pelo lolz eu fiz isso:

Depende. Jogue isso contra um planeta e espere o impacto amanhã desta vez. Ele irá aumentar a velocidade do sim muito forte, mesmo em equipamentos decentes.

E eu vejo seu ponto: sorria:

Ainda estou surpreso com o quanto o jogo melhorou desde a última vez que o joguei corretamente no Windows (cerca de um ano e meio agora). Você e os outros engenheiros espaciais desenvolvedores levaram este jogo mais longe do que eu jamais pensei ser possível. Obrigado por todo o trabalho árduo que vocês colocaram neste jogo.

Há alguns novos jogos do tipo engenheiros espaciais sendo lançados que parecem consertar os problemas de limitação física que a SE tem, como limites de velocidade e colisões que causam o inferno. Seria bom se algo fosse feito para o motor VRage, mas eu suspeito que simplesmente não seja possível.

@InflexCZE Fui bobo e estava olhando para a parte errada do código, presumo que esta seja a parte relevante:

https://source.winehq.org/git/wine.git/blob/a8745d1211033dd38682e2f4e8bc322d47a15e0f : /dlls/ntdll/nt.c#l2460

Olhando um pouco para a documentação, estou assumindo que PrivatePageCount é a propriedade relevante? O que não parece estar definido em lugar nenhum.

@jarrard Tudo é possível com tempo e recursos suficientes. Infelizmente nossa equipe é pequena, então temos que fazer uma escolha. Ou entregamos novos conteúdos e jogabilidade, ou fazemos mudanças profundas no motor e implementamos novas tecnologias de ponta que surgiram nos últimos anos.

Acreditamos que nossos jogadores irão apreciar mais se nos concentrarmos no primeiro e quando chegar a hora de melhorar significativamente a tecnologia, isso provavelmente virá de mãos dadas com o anúncio de um novo jogo, portanto não temos que manter a compatibilidade com versões anteriores para cada pouca coisa que mudamos (o que geralmente consome a maior parte do tempo).

(Não, não estamos abandonando o SE agora, ainda estamos trabalhando nisso 😄)

@ Onyx47 entendo. Isso poderia explicar algumas coisas

@InflexCZE : esse é um bom caminho a seguir.

Apenas se você puder pensar em nossa pequena comunidade linux quando estiver trabalhando em seu novo jogo, isso pode ser uma coisa muito boa :)
Só que podemos brincar com o Proton sem muitos problemas, como parece que provavelmente faremos com os engenheiros espaciais em breve :)

Porque com os Medieval Engineers não podemos nem começar o jogo ...
Espero que não seja esse o caso do seu próximo jogo!

Agora que Space Engineers pode ser reproduzido no Linux, poderei remover completamente o Windows, pouco antes do fim da vida útil do Win7, simplesmente perfeito: D

E, a propósito, obrigado a todas as pessoas que trabalham tanto para encontrar uma solução para os engenheiros espaciais!
Obrigado @InflexCZE por se juntar a nós aqui e por toda a ajuda que você forneceu!

Já que esta parece ser uma solução muito mais estável para fazer os Engenheiros Espaciais rodarem, eu refiz o repo e leia-me todas as coisas mono em que trabalhamos é um subdiretório neste repositório, se precisarmos voltar a ele.

Obrigado novamente a todos por ajudarem a descobrir isso. Tem sido uma jornada interessante: sorria:

@LtSich A decisão de não prestar atenção especial ao Linux é muito simples, dinheiro. Isso se aplica a todos os estúdios universalmente. Ou um jogo de motor usa suporte Linux fora da caixa, nesse caso o jogo "suporta Linux" ou o motor não o suporta, nesse caso ninguém realmente se importa e se concentra apenas nas principais plataformas. Os desenvolvedores são caros e <1% do mercado fala claramente.

Quanto ao caso do VRage, agora estamos suportando também o XBox, então tivemos que reestruturar um pouco o motor para torná-lo independente de plataforma. Isso significa que ao implementar a interface limitada, o jogo será capaz de rodar em qualquer plataforma que possa rodar .NET, portanto, se você encontrar quaisquer problemas com nossos jogos futuros, você pode simplesmente reimplementar esta interface com chamadas Linux adequadas e ter um bom tempo com um novo jogo.

Podemos ser <1%, mas acho que somos muito barulhentos por ser um grupo tão pequeno: P

Podemos ser <1%, mas acho que somos muito barulhentos por ser um grupo tão pequeno: P

E determinado!

Sim, bem, isso não vai pagar meu jantar, não é? 😛

Sim, bem, isso não vai pagar meu jantar, não é? língua de saída presa

Estou bem com um crowfunding para coletar dinheiro para fazer alguma mudança no jogo para rodar melhor no Linux ... Tenho certeza que muitas pessoas ficarão bem em doar algum dinheiro para que o jogo funcione melhor no Linux. .

E o problema é que você faz um jogo para Windows, e depois tenta rodar no Linux ...
Para fazer um jogo que execute várias placas, você tem que pensar nisso desde o início. E não use apenas ferramentas do Windows.

E não se esqueça que o Google Stadia chegará em breve, e em servidores Linux ...
Ser capaz de rodar o jogo no Proton / Linux dá a habilidade de vender o jogo no Google Stadia ...

E sobre o Windows ... Win10 é uma praga ... Muitas pessoas gostariam de usar o Linux para evitar isso ...
Trabalho com servidores Linux há mais de 10 anos, mas só uso no meu computador há 1 ano ... Porque não quero usar Win10 ...

Mas não se preocupe, eu entendo perfeitamente por que KSH não suporta Linux.
E estou muito grato pela ajuda que você dá :)

Ah, e aqui está um bom post de um desenvolvedor de Linux, é interessante ler :)
https://beardedgiant.games/benefits-of-supporting-linux-if-you-are-a-small-indie-developer/

Somos mais de 1%. A pesquisa do Steam foi concluída. Estou completamente livre do Windows há 10 anos e recebi a pesquisa apenas uma vez. Mais uma coisa - não conte com estatísticas do Net Marketshare etc. Muitos usuários do Linux ainda precisam usar o agente de usuário do Windows por vários motivos.

Olá pessoal, embora seja bom ver que uma solução alternativa útil foi descoberta, vamos tentar manter este relatório de compatibilidade focado no jogo. Sinta-se à vontade para discutir o estado geral dos jogos no Linux nos fóruns.

Se você ainda está aberto a conversas sobre até mesmo considerações em potencial para suporte ao Linux para lançamentos futuros do Keen, seria possível ter um canal de algum tipo sobre a discórdia Keen (lembro-me que existia há um tempo atrás) para lidar com esse tipo de tópico? não desviaremos muito esse segmento de problemas de prótons da finalidade pretendida, como Kisak disse que somos? Acho que poderia haver discussões interessantes a esse respeito, especialmente porque o panorama da programação gráfica (vulkan) e do dotnet está mudando.

Depois de seguir as instruções, o jogo parece funcionar para mim como esperado e a grande maioria da gagueira irritante se foi. Ainda há alguns problemas restantes com o áudio, pelo menos, mas não é nada com o que eu não possa viver.

Confira: https://youtu.be/RBqQAkYWBGA?t=60 : tada:: tada:: tada:

Obrigado novamente a todos que ajudaram a encontrar essas soluções alternativas!

Eu também confirmo o sucesso! Alguns gráficos travam atualmente, mas não tenho certeza se é o jogo ou rodando no Proton, já que isso acontece às vezes até no Windows, infelizmente ...

Posso confirmar que a correção acima funciona para mim, adicionar apenas o seguinte ao meu arquivo SpaceEngineers.exe.config resolve as quedas frequentes de desempenho e o jogo roda a sólidos 120fps para mim com configurações altas no meu i7-7700k / GTX 1070. O modo multijogador também funciona bem.

Também é necessário instalar dotnet472 e xact via winetricks ou protontricks.

<runtime> <gcServer enabled="true"/> </runtime>

\já existe pra mim então eu só tive que colocar o \

Depois de voltar ao .NET FW com o servidor GC, você teve algum problema de inicialização, como no Mono, travamentos na tela de carregamento, travamentos ou algo assim?

Depois de voltar ao .NET FW com o servidor GC, você enfrenta algum problema de inicialização como Mono, travamentos na tela de carregamento ou algo assim?

dotnet472 não tem esse problema para mim. Tudo funciona conforme o esperado até agora. Posso iniciar o jogo com segurança e iniciar qualquer jogo personalizado que experimentei.

Pessoalmente, tive um travamento ao iniciar um novo mundo uma vez e dois travamentos que exibiram uma caixa de diálogo de travamento do driver gráfico (o driver não travou no sistema, pode ter sido apenas DXVK desistindo), mas depois disso foi uma experiência muito suave.

Passei algumas horas jogando um jogo MP em um mundo modificado com 5-6 outras pessoas por perto, baguncei o script enquanto estava lá, e tudo isso estava hospedado em uma máquina Windows (apenas um mundo local na máquina de um amigo, não DS).

Havia picos aqui e ali que ainda podem estar relacionados ao GC, mas ele estava rodando a 120 FPS bastante estáveis ​​no meu 3GB 1060 e Core i5 4460, tudo enquanto rodava em uma janela com a composição ativada no meu ambiente de desktop. Caiu mais tarde conforme começamos a construir muito, o que não é surpresa, não tenho certeza de quanto de uma perda de desempenho foi devido a qual fator naquele ponto.

No geral, eu diria que é completamente jogável: +1:

Sim, acho que isso o qualifica para uma classificação de ouro no ProtonDB, que funciona muito bem com pequenos ajustes.

Uau, isso realmente explodiu (meu e-mail). Parabéns por encontrar uma correção / solução alternativa, consegui iniciar e brincar com dotnet472 e xact, definir a opção de configuração do gc e acabei precisando de PROTON_NO_ESYNC para evitar travamento durante o carregamento.
Enviei um relatório ao ProtonDB com uma classificação de ouro. Obrigado por sua perseverança Linux74656 e pelo insight InflexCZE!

Então, o vcrun é desnecessário ou algumas pessoas ainda precisam dele?

Eu não instalei o vcrun2015, mas o Steamplay pode já ter instalado, não verifiquei.

O jogo correu bem para mim.
Posso criar um jogo com mods, os scripts estão ok.

Não consegui instalar o vcrun2015, mas com dotnet472 e a mudança de configuração funcionou bem.

Acho que o vcrun2015 é instalado pelo Steam como um pré-requisito na primeira inicialização. Ele provavelmente também tenta instalar o dotnet, mas isso requer algum hackery em prefixos de 64 bits que são manipulados por winetricks, por isso ainda precisamos executá-lo separadamente. Quanto ao xact, acho que pode ser pré-instalado ou vem como parte do DirectX ou algo no Windows. Com o tempo, talvez possamos pular isso também, mas o FAudio ainda não suporta o formato de arquivo usado pelo SE, então estamos presos às bibliotecas nativas do Windows por enquanto.

FAudio pretende substituir o Xact, mas parece que não funciona neste caso.

@jarrard pelo que li em sua página de recursos, é provavelmente o formato de arquivo XWM, a versão regular que é instalada pelo Steam não o suporta.

Curiosamente, como eu sei que Skyrim usa o mesmo formato de arquivo, eu procurei e encontrei isto:

https://github.com/Kron4ek/FAudio-Builds

Parece que alguém o construiu com suporte WMA e supostamente funciona no Skyrim. Pode valer a pena tentar isso para SE também, isso significa que nos livraríamos de mais um requisito nativo.

vale a pena tentar, eu vou dar uma chance algum dia, não sei quando, as chances são de 10 de vocês vão chegar antes de mim, se for assim, diga-nos como foi. (Faudio com WMA).

Como atalho, ouvi que a próton-GE já tem um faudio com wma, mas pode estar errado.

@ Onyx47 tente instalar d3dcompiler_47 em seu prefixo. Eu tive uma falha gráfica ocasional também, mas depois de instalar isso parece ter desaparecido (é claro que era tão raro no início que ainda pudesse acontecer).
Também acabei de criar um novo prefixo usando winetricks para instalar faudio em vez de xact, parece ter resolvido o áudio popping. Modificarei o guia para incluir ambos, se parecer corrigir os problemas das pessoas.

o que é necessário para permitir a reprodução dos arquivos de filme usados ​​pelo jogo?

Parece que a reprodução real de arquivos .wmv não é provável por enquanto. você pode verificar o problema # 1464 para obter mais informações.
Eu tentei instalar o Media Foundation e usar / substituir várias DLLs de um laptop com Windows 7. Não teve nenhum impacto na reprodução.
Não sei que tipos de formatos de vídeo o jogo pode carregar, mas tentei converter a introdução em algumas dezenas de tipos diferentes, quando pensei que a gagueira poderia estar relacionada ao áudio e aos vídeos de fundo no menu principal, nada realmente deu certo. Tenho certeza de que alguém descobrirá a tempo ... mas, por enquanto, apenas desativar o vídeo de introdução é a melhor opção.

Tentei Proton-GE e acabou de carregar um mundo de forma que não parece funcionar se alguém estava se perguntando. Acho que vou precisar compilar meu próprio faudio, também é importante notar que o som do jogo funciona bem sem o suporte a faudio wma, o suporte a wma é o que o MUSIC usa.

https://github.com/Kron4ek/FAudio-Builds

Eu esqueci que existem versões compiladas .. oops, sim, compilar você mesmo é uma dor de cabeça, tenho que definir meia dúzia de caminhos de dependência que eu não entendo completamente. (Eu posso compilar o faudio básico, mas o suporte wma requer 5 configurações de caminho extras)

@jarrard Instalei faudio através de winetricks (em um novo prefixo sem xact) e pareceu funcionar bem.

ok, talvez o winetricks / protontricks use a versão com suporte do wma, o que é bom, pois sem o suporte do ffmpeg ele torna o faudio muito limitado.

Confirmando que faudio de winetricks funciona para mim: +1:

Ok, então faudio claramente funciona melhor, mas ainda há uma coisa que está me incomodando.
Sempre que um navio chega à sua localização, por exemplo, o som do motor vai persistir e girar continuamente até que você carregue outra área ou saia.
Ainda não joguei sobrevivência, mas pelo menos isso ocorreu na campanha. Precisamente, lembro-me de ter acontecido neste exato momento: https://youtu.be/6MihPOJUrQ4?t=2623
Claro, os sons persistentes do motor ocorriam sempre que um motor estava desligando, se bem me lembro, mas esta cena deve permitir replicar o problema.

Tive problemas com sons "travados" no Windows, embora não com tanta frequência quanto você faz soar. O que significa duas coisas:

1. Antes de começar a resolvê-lo como um problema de Proton, precisamos estabelecer um cenário que produza de forma confiável um som travado no Proton, mas não no Windows
2. Em última análise, pode não ser estritamente uma deficiência no Proton, mas pequenas diferenças no tempo fazendo com que uma condição de corrida seja atingida com mais frequência. Nesse caso, será praticamente impossível solucionar o problema e desaparecerá da noite para o dia se Keen conseguir consertar o bug original.

Sempre que um navio chega à sua localização, por exemplo, o som do motor vai persistir e girar continuamente até que você carregue outra área ou saia.

Talvez refaça seu prefixo com XACT e teste esse cenário novamente algumas vezes e veja se ele ocorre lá. Se isso acontecer apenas com faudio, pode ser necessário um relatório de bug nessa seção?

Tive problemas semelhantes com blocos de som, o som não termina, mas apenas ecoando o início da amostra. Por exemplo, um som que deveria tocar por 2 segundos tocaria por 1,5 segundo, e então os primeiros 0,5 segundos seriam tocados novamente, ao invés dos 0,5 segundos finais (números para fins ilustrativos apenas de couse, não cronometraram). E isso foi com o xact, não cheguei a testar com o faudio ainda. Alguém pode confirmar?

Se isso acontecer com o xact também, pode ser apenas um bug do Wine ou possivelmente do PulseAudio. Se alguém ainda executa ALSA puro em um sistema, pode tentar reproduzi-lo?

Recebo esta mensagem de erro quando tento iniciar o jogo ou quando executo o comando WINEPREFIX.
É possível que eu tenha --force executado o comando várias vezes no mesmo prefixo com xact e FAudio.
Eu recentemente mudei para o Linux e não estou familiarizado com o Wine ou quaisquer programas relacionados como Proton ou Winetricks. Eu tenho um amigo Linux (que finalmente me fez mudar) que me ajudou até agora.

Editar: fiz o jogo funcionar (pela segunda vez, pela primeira vez também o fiz, mas com bugs de som muito óbvios e desagradáveis. O áudio seria atrasado, como se o arquivo de som tivesse que terminar totalmente de tocar antes de tocar o próximo um em um estilo de fila. Portanto, quando você constrói muito rápido, os sons são enfileirados e reproduzidos um por vez, o que significa que, quando você para de colocar / soldar, os sons da construção continuam até que todos os sons sejam reproduzidos). Não sei o que fiz para que o jogo funcionasse desta vez em particular, mas o jogo funciona relativamente bem com um problema. O áudio ainda está claramente bugado, mas não da mesma forma que antes. O som é abafado em algumas partes e o arquivo de som é cortado no início / fim às vezes e alguns sons não são reproduzidos aleatoriamente.
Ainda recebo a mensagem de erro quando inicio o jogo.

Quando adiciono "PROTON_NO_ESYNC% command%" aos parâmetros de inicialização, ele não executa de forma alguma. Apenas diz "Executando" e depois "Sincronizando" e volta para nada.

Tentei instalar o xact e dotnet472 usando winetricks ou protontricks. A instalação do dotNET está corrompida e o jogo precisa do dx11. (ArchLinux fella)

provavelmente winetricks desatualizados

@CrafterSvK Você pode tentar criar um prefixo usando dotnet48 (isso exigirá a versão mais recente do winetricks, winetricks --self-update ) Eu usei em vez do dotnet472 e parece funcionar da mesma forma. Embora eu ainda receba os pop-ups rundll32 ao iniciar, basta clicar em não quando ele aparecer e o jogo deve começar bem.

você pode dizer ao wine para desativar rundll32?

Tentei desativá-lo e parecia funcionar. O erro não aparece mais, e o jogo parece funcionar bem com testes limitados.

sim, acho que também cometi esse erro algumas vezes, não sei por que isso acontece.

Eu tentei winetricks --self-update nada mudou e instalei dotnet48 , a versão do sistema operacional agora é windows xp que é estranho primusrun %command% trava instantaneamente, ENABLE_PRIMUS_LAYER=1 optirun %command% parece gerar janela por 1 segundo e os gráficos da Intel não fazem nada. : / (Eu tenho o prefixo de 64 bits, isso é um problema?) Este parece ser um problema que eu realmente não consigo trabalhar com o Vulkan no meu laptop. Consegui executá-lo em gráficos integrados, mas apenas no menu. Depois de carregar o jogo, ele trava.

Finalmente de volta ao PC. @ thorsten-passfeld quando você reproduzir os sons em loop infinito novamente, você pode verificar esta tela (Ctrl + F11) para ver se você encontra o som que está incomodando você. O jogo registra aqui todos os sons que estão jogando no momento, pelo menos de seu PoV.

Se o som estiver lá, significa bug no jogo. Se não, provavelmente está em algum lugar na reimplementação do XAudio e devemos rastreá-lo lá.

Ofc, quanto mais simples a cena, melhor para depuração.

@CrafterSvK Você pode compactar e fazer upload dos registros da falha, tanto SpaceEngineers.log quanto VRageRender-DirectX11.log.? Eles devem estar localizados em "INSERT / DIRECTORY / TO / SPACEENGINEERS / pfx /" + "/ drive_c / users / steamuser / Application Data / SpaceEngineers /"

Além disso, se você pudesse postar as especificações do seu sistema em Steam "Ajuda> Informações do Sistema", em um arquivo txt e carregá-lo, isso pode ser útil.

info.zip
Aqui está. Muito obrigado. (Atualmente estou fazendo coisas para a escola, mas mais tarde hoje vou tentar nvidia-xrun oposto a bumblebeed com primus_vk)

Parece um problema com o player de vídeo. Tente excluir (ou renomear) todos os vídeos em "SE_INSTALL_PATH / Content / Videos / *" e veja se leva você mais longe.

@CrafterSvK Qual placa de vídeo nvidia seu laptop usa? E você tem os drivers proprietários da Nvidia instalados?
Nenhum deles está listado nas informações do Steam.
Além disso, o jogo roda 64 bits, portanto, um prefixo de 64 bits é necessário, portanto, é bom que o seu prefixo seja 64 bits. Também parece que a maioria dos usuários tem mais estabilidade quando o prefixo da versão do Windows é definido como winxp, então isso também é normal.

Bem, o Steam não deve funcionar em gráficos da nvidia quando o abelha é usado. Instalei o nvidia-xrun e tudo funciona bem e estável. 70 fps nas configurações mais baixas com 950M

@CrafterSvK Bom saber! Ainda bem que funciona bem!

Tudo corre bem e sem problemas, visualmente, no entanto, há um estalo de áudio muito perceptível, e é bastante perturbador - tanto a música quanto o sfx do jogo têm o problema.

Os problemas de áudio foram discutidos extensivamente nesta discussão e existem soluções para reduzir o problema. Só preciso ler acima seu post! na maior parte usando faudio para muitos trabalhos, às vezes você precisa mexer com os tempos de sincronização de áudio de pulso também.

@ Linux74656 Prolly deve ser adicionado ao guia também

Entendi! A seção de problemas do guia foi atualizada!

Atualização: O PULSE MSEC não funcionou para mim. Parece que tenho uma placa de som mais antiga que não oferece suporte adequado para reprodução de pulso sem falhas (TIL!). Encontrei instruções alternativas aqui: https://www.reddit.com/r/wine_gaming/comments/83j0mh/wine_and_pulse_audio_latency/dvk60mp/

Basicamente, altere a configuração do áudio do pulso para carregar com tsched = 0 e fragmentos menores (aparentes) tornam o áudio perfeito. Isso agora recebe uma classificação de ouro no próton. Coisas brilhantes. 6 meses atrás eu tentei e não conseguia nem começar. : +1:

Existem problemas com o foco do teclado quando em tela cheia (mesmo em "tela cheia com janela"). Se eu tentar mudar para outra janela / aplicativo, o jogo imediatamente recupera o foco do teclado. Este é um problema ao copiar / colar scripts dentro do jogo de um editor externo. A solução alternativa que encontrei é alternar temporariamente para uma janela quando preciso sair do jogo.

No entanto, a área de transferência FUNCIONA e parece que os scripts do jogo estão 100%.

Conforme solicitado anteriormente, agora temos um canal especial dedicado a SE no Linux em nosso KSH Discord oficial. Sinta-se à vontade para se juntar a nós lá:
https://discord.gg/keenswh

Só para informação, tenho resultados muito melhores com xact contra faudio.
No último teste, instalei o xact e o xact_64.
E eu fiz a mudança mencionada aqui: https://www.reddit.com/r/wine_gaming/comments/83j0mh/wine_and_pulse_audio_latency/dvk60mp/

E, honestamente, o jogo corre muito bem.
Poucos erros de áudio quando eu inicio o jogo e depois de alguns minutos tudo está funcionando bem.

Com faudio tenho um lag de áudio estranho, é muito chato.
E parece afetar o desempenho.

Talvez isso dependa do hardware ou do sistema, não sei ...
Mas as pessoas que têm problemas com faudio devem tentar com o xact.

Existem problemas com o foco do teclado quando em tela cheia (mesmo em "tela cheia com janela"). Se eu tentar mudar para outra janela / aplicativo, o jogo imediatamente recupera o foco do teclado. Este é um problema ao copiar / colar scripts dentro do jogo de um editor externo. A solução alternativa que encontrei é alternar temporariamente para uma janela quando preciso sair do jogo.

No entanto, a área de transferência FUNCIONA e parece que os scripts do jogo estão 100%.

Na verdade, isso é um problema no Windows também, então nada específico do Wine / Proton / Linux.
Existem alguns relatórios de bugs flutuando em algum lugar sobre esse problema.
É muito bom quando eu mudo para o bloco de notas ou discord para digitar algo, e o jogo começa a desencadear um monte de ações também. / s

Encontramos o problema no Windows e ele será enviado com o próximo patch do jogo.
Esperançosamente também corrigirá o problema no Linux.

Eu modifiquei o guia e escrevi um novo (modifiquei fortemente o antigo) autopatcher para cumprir um propósito diferente, ele agora corrigirá o arquivo de configuração para você, então (tente) criar o prefixo. Deve ser pelo menos funcional. Esperançosamente, isso ajudará a reduzir a confusão na criação de prefixo para alguns dos usuários mais novos ou inexperientes.

Depois de usar o autopatcher, consigo iniciar e jogar - porém, ele engata a cada 2 segundos ou mais. Usando o hud DXVK completo, ele mostra uma linha vermelha no gráfico sempre que engatar. Fora isso, obtenho cerca de 70-90 fps na Terra.

i7 6700k, 1080ti, 32gb DDR4 3200mhz

Parecia assim ?

Parecia assim ?

Sim, é verdade, onde você define isso?

é mencionado como, basta ler alguns posts. você usa o comando de inicialização do Steam.

é mencionado como, basta ler alguns posts. você usa o comando de inicialização do Steam.

Sim, desculpe, ele estava oculto (https://github.com/ValveSoftware/Proton/issues/1792#issuecomment-536643269)

Defina minhas opções de lançamento para: MONO_GC_PARAMS = berçário-tamanho = 32m, menor = par simples DXVK_HUD = PULSE_LATENCY_MSEC completo = 60% comando%

Ainda entendendo, aqui está a aparência do gráfico:

Eu acho que isso só é útil com mono: MONO_GC_PARAMS = berçário-tamanho = 32m, menor = par simples
Você tentou construir seu prefixo com xact em vez de faudio?
Tenho um desempenho muito melhor com o xact ... Faudio Tenho exatamente o mesmo problema que você ...

Sim, é apenas para mono.

@ matty-r verifique se o autopatcher executou as etapas 3 e 4 corretamente (por exemplo, o servidor GC está presente em sua configuração) https://github.com/Linux74656/SpaceEngineersLinuxPatches/blob/master/README.md#step -3

Sim, é apenas para mono.

@ matty-r verifique se o autopatcher executou as etapas 3 e 4 corretamente (por exemplo, o servidor GC está presente em sua configuração) https://github.com/Linux74656/SpaceEngineersLinuxPatches/blob/master/README.md#step -3

Foi isso que aconteceu. Só precisava adicionar gcServer enabled = "true" ao arquivo .config. Funciona perfeitamente agora. Surpreendente.

Obrigado.

@ matty-r Se o autopatcher falhou por algum motivo, seria bom saber o porquê para que possa ser consertado para outros. Alguma mensagem de erro quando você aplicou? Além disso, você pode nos dizer o caminho completo para o arquivo de configuração em seu sistema? Aparentemente, o caminho difere em alguns sistemas.

@ matty-r Se o autopatcher falhou por algum motivo, seria bom saber o porquê para que possa ser consertado para outros. Alguma mensagem de erro quando você aplicou? Além disso, você pode nos dizer o caminho completo para o arquivo de configuração em seu sistema? Aparentemente, o caminho difere em alguns sistemas.

Tentei executá-lo novamente, mas parece que ele aplica a configuração gcServer agora - um pouco estranho. No entanto, ele parou de funcionar completamente depois que eu o executei novamente e apenas mostraria a caixa de diálogo do relatório de falha após a tela inicial. Tive que adicionar novamente o gcServer manualmente e excluir o KSH.wmv.

Portanto, não tenho certeza por que quebrou da primeira vez - o caminho corresponde à string concatenada no arquivo de script Python.

Acabei de conseguir que os engenheiros espaciais trabalhassem com bastante facilidade no Linux, usando um pequeno script bash baseado no script Python de @ Linux74656 .

Estou executando o Fedora 30 em um sistema com uma GPU AMD RX 580.

Digno de nota é que eu realmente não poderia fazê-lo funcionar a menos que _não_ instalei vcrun2015 .

Aqui está o que você faz:

1. Em sua biblioteca Steam, clique com o botão direito em Space Engineers -> propriedades -> marque "Forçar o uso de uma ferramenta de compatibilidade Steam Play específica" e escolha "Proton 4.11-7" e clique em Fechar.
2. Instale o SE.
3. Inicie o SE, aguarde o erro sobre uma biblioteca desatualizada, clique em OK. SE deve criar um prefixo de vinho ao fazer isso.
4. Vá para um shell Bash e execute o comando abaixo.
5. Se tudo na etapa 3 for bem-sucedido, inicie o SE. Deve funcionar agora.

Comando Bash para a etapa 3:

export WINEPREFIX=~/.steam/steam/steamapps/compatdata/244850/pfx && winetricks --force -q d3dcompiler_47 && winetricks --force -q faudio && winetricks --force -q dotnet48 && winetricks --force -q winxp && sed -i 's/<runtime>\r\?$/<runtime> <gcServer enabled = "true"\/>/' ~/.local/share/Steam/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.exe.config && mv ~/.local/share/Steam/steamapps/common/SpaceEngineers/Content/Videos/KSH.wmv{,.bak}

Isso parece exagero.

É importante notar que isso não parece funcionar com o Proton 4.2, mas eu queria usar o 4.11 por padrão de qualquer maneira.

Espere aí, você está tentando especificamente usar o FAudio, não está? Eu senti falta disso. d3dcompiler_47 ou winxp não devem ser necessários, no entanto. (Estou surpreso que winxp não quebrou o jogo, para ser honesto.)

O Windows XP é necessário para que o jogo funcione. Não consigo fazê-lo funcionar no Windows 7 ou superior.

Olá @duckinator , fico feliz que o jogo funcione bem para você.

Atualmente, temos outro usuário em nosso Discord que está tendo problemas com winetricks no Fedora (linha 443):
https://pastebin.com/5Y1s7xjG

Você pode compartilhar conosco qual versão de winetricks você usa?

@roothorick com base no seu comentário, excluí o prefixo wine para que pudesse tentar novamente.

Acontece que isso é o suficiente para fazer funcionar para mim:

WINEPREFIX=~/.steam/steam/steamapps/compatdata/244850/pfx winetricks -q dotnet48 xact && sed -i 's/<runtime>\r\?$/<runtime> <gcServer enabled = "true"\/>/' ~/.local/share/Steam/steamapps/common/SpaceEngineers/Bin64/SpaceEngineers.exe.config

Adicionar a opção de lançamento -skipintro aos engenheiros espaciais não é necessário, mas faz com que pule o vídeo de inicialização que não é reproduzido. Se você não definir essa opção, você verá uma tela preta e você precisará clicar ou pressionar uma tecla para continuar.

@InflexCZE aqui está a informação da versão do wine + winetricks:

~$ wine --version
wine-4.17 (Staging)
~$ winetricks --version
20190912 - sha256sum: 31d37bf18f1503ec46cedf8889e447901e746454e9c3de465f9cc57193e0c90b
~$

Meu simplificado acima pode funcionar melhor, apenas por fazer menos coisas. Além disso, eles provavelmente vão querer rodar rm -rf ~/.steam/steam/steamapps/compatdata/244850/ e então rodar novamente o jogo uma vez (para regenerar o prefixo wine) antes de tentar novamente.

~ Usando suas soluções alternativas, o jogo só funcionará por cerca de um segundo depois de carregar um mundo, onde então congelaria, mas o áudio continuaria sendo reproduzido.

EDITAR: funciona bem após o relançamento.

Aqui estão algumas informações sobre meu sistema, caso seja relevante:

• Ryzen 7 2700
• AMD Radeon RX 580
• 16 GB de RAM
• Executando o Fedora 30
• O Steam é instalado a partir dos repositórios RPM Fusion

Alguém que conheço com hardware semelhante (Ryzen 7 1700, Radeon RX 580) conseguiu fazê-lo funcionar no ArchLinux usando meu último comentário, mas não tenho certeza se eles precisaram fazer algo extra além disso.

@duckinator Sua linha acima funcionou totalmente para mim no F30. O jogo funciona quase perfeitamente. Estou em um 2700X com um RTX 2070

Problemas ao copiar coordenadas GPS para a área de transferência. Posso fazer isso uma vez, mas a qualquer momento depois disso, quando clico no botão copiar para a área de transferência, ele trava por alguns segundos e não copia as coordenadas para a área de transferência.

É no Wayland Matty?

É no Wayland Matty?

Nah, x11.

Tenho recebido dois outros problemas:

1. Depois de sair do jogo pelo menu principal, ele fica em segundo plano e não fecha de fato. O Steam continua relatando que o Space Engineers está funcionando.

2. Após cerca de 30 minutos de jogo, qualquer movimento do mouse se torna instável. Posso mover o personagem sem problemas usando as teclas e não tenho problemas, mas assim que olho ao redor com o mouse, ele fica nervoso novamente. Sair do jogo e reiniciar corrige o problema temporariamente.

Olá @ matty-r, a segunda parte parece # 3316, consulte https://github.com/ValveSoftware/Proton/issues/3316#issuecomment -565734041 para obter uma solução alternativa.

Olá @ matty-r, a segunda parte parece # 3316, consulte # 3316 (comentário) para uma solução alternativa.

Obrigado cara, vou dar uma chance a isso amanhã e ver como vai.

Olá @ matty-r, a segunda parte parece # 3316, consulte # 3316 (comentário) para uma solução alternativa.

G'day @ kisak-valve, que parece ter resolvido os problemas de travamento na saída e de movimento do mouse em uma máquina (ainda para tentar a outra, mas estou confiante de que funcionará lá também), obrigado por isso.

O único problema que vi agora é https://github.com/ValveSoftware/Proton/issues/1792#issuecomment -565758685 - Incapaz de copiar as coordenadas GPS para a área de transferência após a primeira tentativa.

Depois de sair do Space Engineers, um processo permanece aberto em segundo plano e o Steam informa que o jogo ainda está em execução.
Proton 4.11-11

Depois de sair do Space Engineers, um processo permanece aberto em segundo plano e o Steam informa que o jogo ainda está em execução.
Proton 4.11-11

O mesmo aqui, o jogo funciona bem, mas eu preciso matar manualmente muitos processos depois de jogar (vinho, engenheiros espaciais, ..).

O mesmo aqui, e matar os processos não é suficiente para fazer o vapor dizer que não estou mais jogando, tenho que matar o vapor também. Tão estranho.

Para todos que ainda têm problemas com o jogo - encontre e elimine o processo SteamChildMonit, que também não fecha corretamente e fará o Steam parar de mostrar que você está jogando.

Matar os processos não é o problema.
mas veio com a atualização 4.11-10 e ainda está lá.

Matar um processo vai resolver o problema. Algo, seja SE
si mesmo ou um dos vários processos fictícios, está pendurado.

Veja bem, isso não resolve a causa raiz, mas funciona

Na quinta-feira, 2 de janeiro de 2020, 10:32, diKsens [email protected] escreveu:

Matar os processos não é o problema.
mas veio com a atualização 4.11-10 e ainda está lá.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/ValveSoftware/Proton/issues/1792?email_source=notifications&email_token=AB5DMRGXZSSVUSETAH4RG6LQ3YCHTA5CNFSM4F6IMNRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH6TJ6A#issuecomment-570242296 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AB5DMRAEVHS5P3XPDP2QZN3Q3YCHTANCNFSM4F6IMNRA
.

Não consegui iniciar o jogo inicialmente, para fazê-lo funcionar com o Proton versão 4.11-11 tive que instalar a última versão do winetricks com o comando wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks && chmod +x winetricks && sudo mv -v winetricks /usr/local/bin depois executar o script wget https://raw.githubusercontent.com/Linux74656/SpaceEngineersLinuxPatches/master/autoprefix-patcher.py && python3 autoprefix-patcher.py

System:    Host: asimov-MacBookPro Kernel: 5.4.6-050406-generic x86_64 bits: 64 compiler: gcc 
           v: 9.2.1 Desktop: Cinnamon 4.4.6 wm: muffin dm: LightDM Distro: Linux Mint 19.3 Tricia 
           base: Ubuntu 18.04 bionic 
Machine:   Type: Laptop System: Apple product: MacBookPro13,3 v: 1.0 serial: <filter> Chassis: 
           type: 9 v: Mac-A5C67F76ED83108C serial: <filter> 
           Mobo: Apple model: Mac-A5C67F76ED83108C v: MacBookPro13,3 serial: <filter> UEFI: Apple 
           v: 263.0.0.0.0 date: 10/30/2019 
Battery:   ID-1: BAT0 charge: 52.4 Wh condition: 53.3/76.7 Wh (70%) volts: 12.7/11.5 
           model: SMP bq20z451 serial: N/A status: Full 
           Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard serial: <filter> 
           charge: 55% status: Discharging 
CPU:       Topology: Quad Core model: Intel Core i7-6920HQ bits: 64 type: MT MCP arch: Skylake-S 
           rev: 3 L2 cache: 8192 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 46398 
           Speed: 3363 MHz min/max: 800/3800 MHz Core speeds (MHz): 1: 900 2: 900 3: 900 4: 900 
           5: 900 6: 900 7: 900 8: 900 
Graphics:  Device-1: AMD Baffin [Radeon RX 460/560D / Pro 450/455/460/555/560] vendor: Apple 
           driver: amdgpu v: kernel bus ID: 01:00.0 chip ID: 1002:67ef 
           Display: x11 server: X.Org 1.20.4 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa 
           resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: 
           renderer: AMD Radeon RX Graphics (POLARIS11 DRM 3.35.0 5.4.6-050406-generic LLVM 7.1.0) 
           v: 4.5 Mesa 18.3.0-rc4 direct render: Yes 
Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel v: kernel 
           bus ID: 00:1f.3 chip ID: 8086:a170 
           Device-2: AMD driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 1002:aae0 
           Sound Server: ALSA v: k5.4.6-050406-generic 
Network:   Device-1: Broadcom and subsidiaries BCM43602 802.11ac Wireless LAN SoC vendor: Apple 
           driver: brcmfmac v: kernel port: 3000 bus ID: 03:00.0 chip ID: 14e4:43ba 
           IF: wlp3s0 state: up mac: <filter> 
           IF-ID-1: docker0 state: down mac: <filter> 
Drives:    Local Storage: total: 465.92 GiB used: 104.53 GiB (22.4%) 
           ID-1: /dev/nvme0n1 vendor: Apple model: SSD SM0512L size: 465.92 GiB speed: 31.6 Gb/s 
           lanes: 4 serial: <filter> 
Partition: ID-1: / size: 455.46 GiB used: 52.10 GiB (11.4%) fs: ext4 dev: /dev/dm-1 
           ID-2: /boot size: 704.5 MiB used: 319.2 MiB (45.3%) fs: ext4 dev: /dev/nvme0n1p2 
           ID-3: swap-1 size: 979.5 MiB used: 25.0 MiB (2.6%) fs: swap dev: /dev/dm-3 
Sensors:   System Temperatures: cpu: 76.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/additional-repositories.list 
           1: deb [arch=amd64] https: //download.docker.com/linux/ubuntu bionic stable
           Active apt repos in: /etc/apt/sources.list.d/amdgpu-pro-local.list 
           1: deb [ trusted=yes ] file: /var/opt/amdgpu-pro-local/ ./
           Active apt repos in: /etc/apt/sources.list.d/graphics-drivers-ppa-bionic.list 
           1: deb http: //ppa.launchpad.net/graphics-drivers/ppa/ubuntu bionic main
           Active apt repos in: /etc/apt/sources.list.d/kubernetes.list 
           1: deb https: //apt.kubernetes.io/ kubernetes-xenial main
           Active apt repos in: /etc/apt/sources.list.d/lutris-team-lutris-bionic.list 
           1: deb http: //ppa.launchpad.net/lutris-team/lutris/ubuntu bionic main
           Active apt repos in: /etc/apt/sources.list.d/nodesource.list 
           1: deb https: //deb.nodesource.com/node_10.x bionic main
           2: deb-src https: //deb.nodesource.com/node_10.x bionic main
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb http: //ftp.acc.umu.se/mirror/linuxmint.com/packages tricia main upstream import backport
           2: deb http: //archive.ubuntu.com/ubuntu bionic main restricted universe multiverse
           3: deb http: //archive.ubuntu.com/ubuntu bionic-updates main restricted universe multiverse
           4: deb http: //archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
           5: deb http: //security.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse
           6: deb http: //archive.canonical.com/ubuntu/ bionic partner
           Active apt repos in: /etc/apt/sources.list.d/skype-stable.list 
           1: deb [arch=amd64] https: //repo.skype.com/deb stable main
Info:      Processes: 307 Uptime: 2h 31m Memory: 15.54 GiB used: 2.85 GiB (18.4%) Init: systemd 
           v: 237 runlevel: 5 Compilers: gcc: 7.4.0 alt: 7 Client: Unknown python3.6 client 
           inxi: 3.0.32 

O jogo não começa com GPU NVIDIA usando drivers proprietários (testado em 435 e 440), mas começa usando GPU AMD integrada (mal).
Continuo recebendo a caixa de diálogo "Atualizar as janelas ou os drivers GPU".

• wine versão 5.0-rc3 (experimentado com 4.0.3 também)
• winetricks versão 20191224-next
• próton versão 4.11.11

Histórico:
SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Experimente uma versão proton-tkg e veja o que acontece. Acho que as placas NVIDIA são tipicamente falsificadas como placas AMD, mas talvez isso não esteja mais acontecendo, você pode falsificar manualmente sua GPU para AMD.

Não tenho certeza se esse método ainda funciona para prótons, mas esses são para AMD (basta pesquisar os valores).

dxvk.conf no diretório do jogo:
dxgi.customDeviceId = E366
dxgi.customVendorId = 1002

Acabei de tentar usar proton_tkg_5.0rc5.r0 , mas não funciona nem mesmo com o arquivo dxvk.conf.

Vou fazer um test drive em breve no tkg.

Usar Proton GloriousEggrolls 4.15-ge-1 parece fazer o jogo reconhecer minha GPU real, mas VRageRender continua falhando:
VRageRender-DirectX11.log
SpaceEngineers.log

ATUALIZAÇÃO: Meu problema foi corrigido graças a @ Linux74656 :

• Wineprefix contém faudio vcrun2015 dotnet48 e d3dcompiler_47.
• Proton 4.11.12
• Parâmetros do jogo Steam: DXVK_FILTER_DEVICE_NAME = "GeForce"

Não consigo começar com todos os patches e recomendações, e não consigo dizer por que, mesmo com as informações de registro:
steam-244850.log

Alguém pode me ajudar?
Informação do sistema

Olá @MajorLunaC , err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"SpaceEngineers.exe" cannot be loaded parece a linha de interesse do seu log. Parece que o suporte .NET quebrou em algum momento de seus ajustes.

Sistema:
AMD 2700X refrigerado a água
32 GB DDR4 3200 MHz CL18 RAM
RX VEGA64 refrigerado a água
Jogo em SSD

OS Manjaro kernel 5.5 Mesa 20 git (com RADV_PERTEST = aco no lançamento do jogo), Wine 5 RC4
em comparação com Win10 1909

O jogo está rodando, mas trava aleatoriamente, o log de prótons gera 50-150 + MB a cada execução, a renderização do jogo parece instável até não funcionar a 120 FPS. e nas mesmas configurações, o jogo rodando consideravelmente mais lento (70+ FPS stabel no Win, 28 no Linux. 4k High settings preset. No mesmo local no mesmo mundo salvar.) (Depois de carregá-lo novamente, ele me deu no contador fps 60 fps, mas o jogo parecia instável, exatamente como antes. Se fosse assim, a renderização iria funcionar bem, mas o motor do jogo está com um desempenho péssimo.)
Windows-VRageRender-DirectX11.log
Windows-SpaceEngineers.log
LINUX-VRageRender-DirectX11.log
Linux-SpaceEngineers.log

log de prótons (50 MB)
Google Drive

Sim, eu me lembro da sensação de gagueira mesmo que o FPS fosse alto. Não me lembro com certeza se corrigi ou não, mas você pode tentar habilitar o vsync.

Olá @ kisak-valve, Na verdade, não ajustei nada além do SpaceEngineersLinuxPatches . Eu tentei as correções padrão do Steam que falham exatamente da mesma maneira, então os comandos listados nesta conversa de problemas, bem como SpaceEngineersLinuxPatches. Pelo que eu percebi, parece provável que o .NET não está sendo instalado corretamente - Veja Como instalar o .NET 4.5 em prefixos de 64 bits , e eu nem sei quando o modo WinXP ou Win7 deve ser habilitado durante a instalação e corra (aparentemente faz diferença). Eu acho que o problema pode ser de diferentes versões do Winetricks, que obtém instaladores de diferentes fontes.
Tenho o Winetricks 20191224-next e limpei /HOME/.cache/winetricks/ para que novas versões fossem baixadas. Supostamente, o .NET deve fornecer uma nova versão do mscoree.dll com mais de 100 kb se instalado corretamente, mas parece que nunca muda. Uma solução alternativa é fazer o download da versão mais recente de mscoree.dll (versão 10 algo) de <Link removed by moderator> e colocá-la diretamente dentro de SpaceEngineers / Bin64 / (bem como ucrtbase_clr0400.dll e vcruntime140_clr0400.dll que ele pergunta para depois), e o jogo começa e posso navegar pelos menus do jogo. Ele trava o jogo em algum momento ao carregar um novo jogo com o seguinte no SpaceEngineer.log:
2020-01-23 15:28:50.210 - Thread: 1 -> ERROR Entity init!: System.IO.IOException: Too many open files.

Posso pedir a alguém para me dizer sua versão winetricks que funciona? Ou, eventualmente, até mesmo todo o diretório pfx que funciona?

Enquanto estou nisso, @ plasticbomb1986 , para possíveis ajustar o registro (faça backup do diretório pfx antes de fazer), particularmente alterando a chave VideoMemorySize para a sua atual, a chave GLSL e a chave DirectDrawRenderer, também qualquer coisa no Direct3D e relacionado a texturas ou shaders. Experimente um de cada vez, revertendo todas as alterações antes de tentar um novo, então você pode tentar combinar.

@MajorLunaC , embora eu não vá comentar sobre as soluções alternativas que você está tentando, pode valer a pena verificar se ulimit -Hn gera um valor alto e não 4096.

Além disso, um dos links em seu comentário é legalmente problemático e foi removido.

@kisak-valve Opa, desculpe pelo link, eu não percebi. Estou muito acostumado a tentar descobrir o que há de errado e exigido por todos os meios necessários.

A saída de ulimit -Hn é 4096. Há algo que eu possa fazer sobre isso? Posso aumentar com segurança e para quanto?

Proton usa esync (ou fsync com kernels capazes) por padrão, então é provável que tenha contribuído para o que você encontrou. A primeira seção de https://github.com/zfigura/wine/blob/esync/README.esync deve ser útil.

@ kisak-valve Uau, funcionou, posso tocar perfeitamente! Obrigado por toda sua ajuda!
Eu ainda gostaria de descobrir como ter certeza de que tudo é instalado corretamente com os instaladores fornecidos por meio do winetricks para obter alguma consistência, já que os instaladores não parecem realmente verificar se fizeram o trabalho direito. Acho que a ferramenta de reparo do .NET Framework pode funcionar através do wine. Não é prático para todos copiar dlls de uma versão do Windows que possuem ou a maneira "legalmente problemática" de encontrar dlls online.

apenas use protontricks para facilitar a instalação do dotnet.

Dotnet pode ser instalado até 472 eu acho (ou é 492 agora?), Mas muitas de suas funções podem não funcionar corretamente. O Windows Mono é uma alternativa, mas, novamente, muitas funções podem não corresponder bem.

Jarrad

Sim, eu me lembro da sensação de gagueira mesmo que o FPS fosse alto. Não me lembro com certeza se corrigi ou não, mas você pode tentar habilitar o vsync.

Verifica. Parece um pouco melhor, menos gaguejante, mas o fps ainda não está perto de onde deveria estar. Além disso, às vezes ainda está falhando.

MajorLunaC

Enquanto estou nisso, @ plasticbomb1986 , para possíveis ajustar o registro (faça backup do diretório pfx antes de fazer), particularmente alterando a chave VideoMemorySize para a sua atual, a chave GLSL e a chave DirectDrawRenderer, também qualquer coisa no Direct3D e relacionado a texturas ou shaders. Experimente um de cada vez, revertendo todas as alterações antes de tentar um novo, então você pode tentar combinar.

Vou dar uma olhada! Obrigado pela dica!

Ohh, e mais uma coisa. Algum de vocês consegue usar Alt + F10?

Alguém obteve um file not found Erro na inicialização?

@BeauBouchard Você está usando uma versão personalizada do próton ... Recebo esta mensagem quando uso a versão mais recente do próton personalizado Glorious Eggrolls.
Se for o caso, tente com a versão oficial do próton mais recente. Nota: você pode ter que deletar e recriar seu prefixo, pois GE destruiu meu prefixo Space Engineers, mesmo depois de mudar para 4.11-12.

Hoje o proton teve uma atualização no meu pc (do próton 5 para o 5.0.2?), E desde então o jogo fecha com erro de falta de memória mesmo estando apenas no menu principal.
SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Há uma merda de coisas acontecendo, com uma sessão média de jogo de 2-3 horas, o log de prótons faz um log de 400-500 MB facilmente.

Hoje o proton teve uma atualização no meu pc (do próton 5 para o 5.0.2?), E desde então o jogo fecha com erro de falta de memória mesmo estando apenas no menu principal.
SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Há uma merda de coisas acontecendo, com uma sessão média de jogo de 2-3 horas, o log de prótons faz um log de 400-500 MB facilmente.

Depois de recriar o prefixo, ele ainda fará o mesmo.

SpaceEngineers.log
VRageRender-DirectX11.log
steam-244850.log

Esqueci a especificação do sistema: Ryzen 2700X 32 GB DDR4 VEGA64 e vários ssds (troca em nvme ssd).

kernel 5.5 mesa 20git Manjaro Gnome DE

o mesmo aqui.
SpaceEngineers.log

steam-244850.log
Aqui está meu último log, caso ajude. Não passei da tela inicial.

Mesmo erro, mas não estou executando o Proton (lutris-5.0) e meu jogo travou hoje de repente depois de jogar um mês sem problemas.
Reinstalei o prefixo / jogo do vinho, desativei a nuvem de vapor, sem efeito.
Eu inicializei no Windows 10 e vejo uma notificação pela primeira vez: Default Radeon WattMan settings restored due to unexpected system failure .

Pode jogar no Windows, mas após a reinicialização / inicialização a frio, mesmo erro no Linux.

Config: Ryzen 5 2600, AMD RX470, 16 Gb RAM, SSD / Lutris-5.0 / ArchLinux

Este é um erro realmente estranho. Está completamente fora do SE, em algum lugar dentro da biblioteca .NET.
A partir do rastreamento da pilha, parece comunicação de rede, talvez análise ou algo assim.

Você pode tentar desconectar sua internet por um segundo e rodar o SE sem nenhuma conexão para que possamos descartar a possibilidade de uma resposta insana do servidor remoto.

Este é um erro realmente estranho. Está completamente fora do SE, em algum lugar dentro da biblioteca .NET.
A partir do rastreamento da pilha, parece comunicação de rede, talvez análise ou algo assim.

Você pode tentar desconectar sua internet por um segundo e rodar o SE sem nenhuma conexão para que possamos descartar a possibilidade de uma resposta insana do servidor remoto.

Tentando reinstalar agora. O script Linux74656 travou aqui: 01a0: erro: ole : ifproxy_release_public_refs IRemUnknown_RemRelease falhou com o erro 0x800706be

Sem uma conexão com a Internet, o SE pode ser iniciado como antes.
Assim que a conexão com a Internet for estabelecida e os servidores consultados, ele trava imediatamente.
SpaceEngineers.log

Eu o tenho com Proton 5.0-2 e dontnet472, bem como dotnet48.
também tentei com Proton 4.11-12 e dotnet472.

@ plasticbomb1986 Para a instalação, você ainda precisa de uma conexão com a Internet para que os instaladores possam ser baixados.

@ plasticbomb1986 Para a instalação, você ainda precisa de uma conexão com a Internet para que os instaladores possam ser baixados.

Isso teria sido um momento no rosto, mas não, a rede estava ligada no momento.

Acabei de voltar do cinema, nas últimas 4 horas parece que acabou no final, mas vou repetir, só para conferir.

Também posso confirmar que desativar a conexão com a Internet evita o erro.

Também posso confirmar que desativar a conexão com a Internet evita o erro.

Sim, se depois do Se iniciar e aparecer a primeira "tela" de carregamento, eu desligar a rede, ela está carregando e funcionando bem, se eu não desligar a rede, ela está carregando, mas o áudio falha, e depois alguns segundos está dando o erro de falta de memória.

Os caras do Keen SWH Discord (https://discord.gg/keenswh) encontraram uma solução nesse meio tempo.
O jogo envia análises para 81.0.234.196 e 88.146.207.227 (servidores de análise Keen SWH), que aparentemente envia de volta algum lixo que causa o problema (sem intenção).

A solução é bloquear este serviço via:
sudo iptables -A INPUT -s 88.146.207.227 -j DROP

Todo o crédito vai para Rölli: +1:

A solução é bloquear este serviço via:
sudo iptables -A INPUT -s 88.146.207.227 -j DROP

Legal, obrigado! Isso funciona bem!

Parece que algumas pessoas diferentes estão recebendo alguns erros diferentes aqui, e nenhum deles parece corresponder ao meu. Eu também obtenho a tela inicial por um curto período de tempo e, em seguida, uma falha, mas meu log parece diferente dos mais recentes carregados por outros. A frase mais interessante para mim é
[000000000000003C:] EXCEPTION handling: System.TypeInitializationException: The type initializer for 'GameAnalyticsSDK.Net.Logging.GALogger' threw an exception.

Este é um prefixo limpo (removido steamapps/compatdata/244850 ), testado com e sem as alterações do arquivo a partir daqui .

O comando iptables não ajuda para mim.

steam-244850.log

@captaincrutches Por acaso, você aceitou a caixa de diálogo de informações do contrato GDPR quando o jogo foi iniciado? Pode estar ativo e ser a origem do problema.
Você pode verificar aqui: ... / 244850 / pfx / drive_c / users / steamuser / Application Data / SpaceEngineers / SpaceEngineers.cfg

e mudar:

<item>
        <Key>GDPRConsent</Key>
        <Value>
          <Value xsi:type="xsd:string">True</Value>
        </Value>
</item>

PARA:

<item>
        <Key>GDPRConsent</Key>
        <Value>
          <Value xsi:type="xsd:string">False</Value>
        </Value>
</item>

@ Linux74656 Nunca recebi uma caixa de diálogo GDPR e não tenho esse arquivo. Na verdade, não consigo encontrar SpaceEngineers.cfg em nenhum lugar do meu sistema.

Essa pasta contém um SpaceEngineers.log que carregarei aqui para ser completo - parece ter uma exceção de ponteiro nulo.

SpaceEngineers.log

Você está executando o jogo via Mono em vez do .NET framework. Prefixo provavelmente instalado incorretamente.

Qual versão de distro e winetricks você está usando?

Estou no Gentoo, usando os últimos winetricks (20191224) e protontricks (1.4.1) no portage.

Exclua o prefixo do jogo e crie-o novamente. Enquanto faz isso, salve o log de saída para que possamos ver se há algo interessante.

Ah, bem, adivinhe? Eu estava tentando fazer o patching via linha de comando usando protontricks / winetricks ... mas eu tentei com PatcherGUI.jar e eis que o jogo agora começa! Obrigado pelo empurrão ~

Não tenho certeza se devo postar neste tópico ou não, mas quando eu digo aos engenheiros espaciais para sair, ele não fecha os tópicos corretamente. Além disso, apertar "Stop" no STEAM também não o mata. Preciso matar os processos manualmente.

Estou tendo o mesmo problema, o que me deixa perplexo é que mesmo que eu mate todos os processos relacionados ao SE, Wine ou Proton, ele ainda se recusa a ver o SE como encerrado no Steam. Na verdade, eu tenho que matar o vapor para poder reiniciar o SE depois. Um tanto irritante. Eu não examinei o problema muito além de matar todos os processos relacionados a SE / Proton no Steam, mas é algo que provavelmente precisa ser analisado

Estou tendo o mesmo problema, o que me deixa perplexo é que mesmo que eu mate _todos_ os processos relacionados ao SE, Wine ou Proton, ele ainda se recusa a ver o SE como encerrado no Steam. Na verdade, eu tenho que matar o vapor para poder reiniciar o SE depois. Um tanto irritante. Eu não examinei o problema muito além de matar todos os processos relacionados a SE / Proton no Steam, mas é algo que provavelmente precisa ser analisado

Eu tenho uma dica para você. Estou no Ubuntu, então isso pode ou não se traduzir na sua situação.

Depois que existo Engenheiros Espaciais, trago o "Monitor de Sistema". Na guia "Processos", clico no menu do hambúrguer empilhado (três linhas horizontais) para habilitar 'Mostrar dependências ". Isso transforma a seção" Processos "em árvores.

Em seguida, procuro as áreas com "Steam" em execução e procuro especificamente por "SteamChildMonit" e sua árvore. Se houver múltiplos (provavelmente apenas um), procure aquele com o filho "SpaceZEngineers". e um monte de coisas de vinho.

Eu então primeiro clico em "SteamChildMonit" para realçá-lo, seguro a tecla Shift e clico no último filho da árvore (geralmente "winedevice.exe"). Em seguida, clique com o botão direito na seleção, vá matar, e isso mata todos eles.

Isso me permite reiniciar o jogo (ou posso iniciar outros jogos) sem ter que encerrar todo o STEAM.

Na verdade, descobri que se eu sair do SE "normalmente", preciso encerrar manualmente vários processos, conforme descrito acima ... mas se eu kill -9 $(pgrep SpaceEngineers) do terminal em vez de sair do jogo normalmente, todos os processos relevantes morra como desejado.

O problema do processo zumbi não é um problema do Wine / Proton, ele também ocorre no Windows para mim.

Veja isto: https://github.com/Linux74656/SpaceEngineersLinuxPatches#issue -8

Pela primeira vez desde que adquiri o jogo, posso realmente fazer com que ele passe da tela inicial com o Proton 5.0-8rc, não tenho a menor ideia do que estou fazendo no jogo, mas pelo menos posso finalmente jogá-lo. :)

Estou enfrentando uma falha após sessões longas o suficiente. O steam-244850.log tem 900 MB, mas o log do jogo é menor. Terei que esperar um pouco antes que o upload termine.

O registro do jogo:
SpaceEngineers_20200626_220158938.log

Registro do Steam (compactado): https://mega.nz/file/gxxAnKzS#gunhdGQRfYJLIbnEGadOWQ6PNC2j4eMYgssjh -IJHPg

Especificações do sistema: https://gist.github.com/FurretUber/e105309ff4c58e197c3b2f65318cd8e1

Sim, os engenheiros espaciais travam para mim após um período aleatório de tempo e, observando os registros, não vejo nada surgindo, então não tenho certeza do que fazer a respeito :( Isso acontece com bastante frequência.

Podemos obter uma correção para prótons para engenheiros espaciais que não desistem ao sair do jogo, por favor?

"O jogo não é iniciado na sandbox do Proton e pode ver a estrutura de diretório normal do Linux" - resumo de uma das muitas pessoas realmente versadas em programação que me ajudaram hoje. Da minha perspectiva, vejo uma tela inicial por um ou dois segundos, então tudo volta a um estado como se eu nunca tivesse clicado em reproduzir. O log está anexado.
SpaceEngineers_20200708_180142615.log

Informação do sistema

• GPU: X.Org Radeon RX 570 Series (POLARIS10, DRM 3.33.0, 5.3.0-62-genérico, LLVM 9.0.0)
• Versão do driver / LLVM: 4.5 (Perfil de Compatibilidade) Mesa 19.2.8
• Versão do kernel: 5.3.0-62-genérico
• Link para o relatório completo de informações do sistema: https://gist.github.com/HalberdGuard/c623a4f14676e77e6f401b3c62a2e9b7
• Versão do Proton: 5.0-9

Você tentou o arquivo jar de instalação? Eu descobri que isso é bastante confiável, mas sim, esse material deve ser incorporado ao próton com certeza.

Na verdade, isso foi o resultado de ter usado a versão automatizada e, mais tarde, a versão manual, com a ajuda das já mencionadas pessoas amigáveis ​​e instruídas (e pacientes!) ... Suponha que eu devesse ter mencionado isso. : p
Devido a outras circunstâncias provavelmente não relacionadas, provavelmente terei que reinstalar o Steam do zero em breve, talvez não seja mais estranho? Veremos!