tetryds

Banido por banimento temperamental

@Heimder desculpe, mas como desenvolvedor eu me sinto na obrigação moral de dizer que você está errado em grande parte. Primeiramente, sim, o Unity tem suas limitações, e a maioria delas se dá devido ao seu caráter generalista. Porém isso não é "desculpa" para um jogo mal otimizado, existe uma série de fatores que fazem com que isso aconteça, dentre elas a facilidade em implementar features através do motor gráfico. Sério, quem já brincou com ele irá concordar que é extremamente fácil fazer alguma coisa qualquer rodar no Unity, e a maioria dos desenvolvedores indie têm pouca experiência e poucos recursos para ir além e achar soluções melhores para seus problemas. O Unity é capaz de dar conta de uma quantidade enorme de efeitos e vértices, mas a maioria das ferramentas que ele dá são genéricas, não por que ele é um motor gráfico ruim, mas por que esse é o papel dele, facilitar o desenvolvimento. Se você for um desenvolvedor sério ou analisar o que desenvolvedores sérios que utilizam motores gráficos de terceiros fazem, irá notar que é extremamente comum reescreverem as funcionalidades mais utilizadas pelo projeto, e não utilizar as provenientes do motor gráfico, otimizando-as para seu uso próprio. Porém isso tem um custo, e um custo alto. Reimplementar funcionalidades requer uma habilidade de programação grande, exige tempo, testes e principalmente uma organização de código impecável para que esse framework possa ser mantido e expandido caso necessário, e todos sabemos que isso está muito longe da realidade da maioria dos desenvolvedores. Por exemplo no meu projeto estamos desenvolvendo um sistema inteiro de módulos próprio, para permitir modding. Imagine algo parecido com o sistema do KSP, só que muitas vezes mais robusto e otimizado. E isto está nos custando caro, sem um plano de desenvolvimento adequado seria muito fácil inviabilizarmos nosso projeto por tentar reimplementar mais coisas do que precisamos, ou não podermos confiar nos próprios sistemas por termos feito sem o devido cuidado (também estamos implementando um sistema interno de cenas, que provavelmente irá remover qualquer tipo de delay entre menus e acabar completamente com a necessidade de uma tela de loading). Agora, sobre escrever um motor gráfico próprio, isso requer um tempo gigantesco de desenvolvimento, desenvolvedores muito experientes e mais um monte de outras coisas, principalmente tempo e dinheiro, e é inviável até para empresas muito grandes. É justamente por isso que muitas franquias e jogos de uma mesma empresa tendem a utilizar o mesmo motor gráfico. É um esforço gigantesco para gerar uma plataforma de desenvolvimento tão ampla, nem preciso dizer que isso é inviável mesmo para um jogo como o KSP. O que muitos jogos bilionários fazem é modificar algumas funcionalidades do motor gráfico para satisfazer suas necessidades. Pode perceber que sempre que algum desenvolvedor indie aparece com o próprio motor ele geralmente é extremamente específico e o jogo é um pouco mais simples, chega ao ponto em que não existe de fato um motor gráfico isolado, as funcionalidades do jogo acabam incrustadas junto com o motor, o que pode dificultar sua reutilização, o que significa mais um bom tempo de desenvolvimento jogado fora. Logo começaremos a escrever blogs, aí caso queira saber mais sobre como esse tipo de sistema é (re)implementado e o que eles fazem é só dar uma olhada lá, vou postar aqui no fórum quando isso acontecer.

Banido(a)

Não irei, ganharia mais inimigos do que eu estou disposto a ter, haha. Mas talvez no meu futuro blog eu postarei sobre isso, mas não prometo. Mas resumindo, as features do KSP sempre foram decididas pensando quase que unicamente na próxima versão, e cada desenvolvedor é responsável pelo design da feature que desenvolve, e isso acarreta em uma série de problemas na integração, consistência e desenvolvimento dessas features.

Não, eu só fiquei muito decepcionado com o jogo em certo ponto, depois alguns bugs na minha live stream me desanimaram e agora que eu estudo game design o jogo me decepcionou mais ainda por perceber (que) tudo que ele faz (tá) errado, a não ser por poucas coisas por pura sorte.

Aquele momento em que se começa a perder interesse pelo fórum aos poucos...

Banido por ficar inativo observando.

Banidos por inatividade.

Estou pensando em fazer tutoriais de C# junto com o @VintageXP, o maior problema é tempo, mas acho que seria interessante.

Banido por que faz muito tempo que não jogo KSP, as vezes até me esqueço que esse fórum aqui é sobre o jogo.

Banido por julgar os dados do coleguinha que são muito precisos 10/10.

Banido, desta vez sem motivo real, é só por causa do tópico mesmo.

Banido por que você sabe o que diz. @Sturmgeschutz: http://imgur.com/0NabvK5 http://imgur.com/EwEMlJ9

Banido por stalkear o coleguinha, que coisa feia.

Ok, se o problema for falta de recursos de hardware isso não é problema do Tryos, e sim da SQUAD, que deve fazer o refund da compra do jogo e corrigir a propaganda enganosa. Ou arrumar o jogo para satisfazer aqueles requisitos mínimos.

Banido por também falar em código, protocolo "língua portuguesa".

@VenomousRequiem yeah, baha used a weird orientation for bombs and missiles, but we didn't update it because that would take a while. You can use the fake COL setting on the bomb module cfgs as a hotfix but I cannot guarantee that the bomb aim will be precise.

Já falei, isso não tem nada a ver... O notebook dele é muito melhor do que os requisitos mínimos, se ele não conseguir jogar o jogo normalmente sem problemas há algo de errado com o jogo. Que teimosia

As especificações dele estão bem acima das especificações mínimas na steam, o problema não é o pc dele.

@Scoppio no, but it changes the default weight of your wing parts so that they don't rip apart as easily. The default mass strength multiplier with FAR is a bit overkill but ferram had to do that because people were suiciding and complaining that airplanes were not standing their 15G mach 2 turns (also a keyboard's fault, but that is no excuse now with MAF).

@Tryos Torregan diminuir os gráficos não vai ajudar, sua gpu consegue rodar KSP com um visual decente até. Pra eu poder te ajudar responda essas perguntas por favor: Está utilizando algum mod? Qual o uso da memória RAM quando o jogo está aberto com um foguete pequeno na launchpad? Ele crasha mesmo se vc não fizer nada? Ou precisa passar de uma certa altitude? Isso é no modo carreira ou também no sandbox? Seu sistema operacional é 64 bits? Algum outro aplicativo faz ou já fez seu computador travar da mesma maneira? Já deletou e baixou o jogo denovo? Se não souber responder alguma pergunta é só pedir e te ajudamos. Acho mais válido analizar o problema que pular pra conclusões precipitadas sobre o sistema de alguém pedindo ajuda, o KSP é vendido como totalmente compatível com um sistema como aquele, e isso é um bug gravíssimo.

BIRLnido.

Banido por discutir moderação. Vc raramente saberá se foi feito algo à respeito.

You almost nailed it. What happens is that the point where the Cl drops is the point where you stall and the moment you stall the wings lose lift and gain a lot of drag. Depending on the design this can generate a lot of pitch down torque, your craft quickly goes back to an AoA where it stops stalling, but the deflection brings it back up and that happens again. On the worst case it will gain so much momentum that it stalls pitching down too, and keeps doing that without any input. Be careful though, as applying what I suggested does not guarantee you won't stall, if you have enough pitch up momentum and little damping you will slingshot past the stall point and bounce back (or die). It is actually possible to balance your airplane in such a way that the stall effects are neutral, the airplane does not bounce back nor flips backwards, you maintain stupid high AoA, only losing effectiveness on your control surfaces and bleeding a lot of energy. I made airplanes which behaved like that a few times, it's fun, if you throw some artificial stability on it you get top notch control over your aircraft when dogfighting, as long as you don't overstress it. I can share an airplane that does this later

It's on my signature What you have there is that when you fully deflect your elevators for pitch up you stall, you can notice that because the yellow line crosses the zero after the blue line drops. First of all edit every other control surface to not respont do pitch up, then edit your elevators to deflect less. (also make sure to make all control surfaces do what they are meant to do) Reduce deflection until the yellow line crosses the zero line before the blue line drops, the closer the yellow line zero cross is from the point where the blue line drops, the harder you will turn, draining energy. You can balance that until you find a point that is both great to fly with a keyboard and will still turn well for what your airplane is capable of.