Jump to content

Gijs-Jan

Development Team
  • Posts

    329
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Gijs-Jan

  1. 1 minute ago, Chris said:

    It's under My Documents >> My Games.

    There's definitely a crash in the game that occurs if you complete a project and there's another project in the queue after it; if that's the cause of the bug for you then don't worry - pretty sure we'll hotfix that one tomorrow!

    Aw man, I already lost so much sleep the past few weeks :'-(

    Kidding, we're glued to the issue tracker at the moment and patching what we can!

    • Like 1
  2. There are a lot of different things contributing to this issue, and it also depends on what type of rendering setup you are using (forward/deferred, lightmapped / realtime etc).

    One of the big underlying causes is that Unity doesn't really deal well with dynamic environments where there are a lot of non-static GO's.
    This in particular starts to break down when certain rendering paths don't properly support batching. The end result is that the CPU spends a lot of time creating dynamic batches that are straight up ignored and cause individual render calls in parts of the render pipeline (stalling the GPU).

    The solution we've tried inhouse is to manually combine meshes and objects for those parts of the level that are indestructible after the scene loads, which already gives a mighty speed boost and solves both above issues.

    The other issue is that Unity simply doesn't like runtime combining of scenes with lightmaps, which is making completely randomized maps quite a pain to implement.

    I want to assure everyone that we know the issue, and we've been testing solutions to this throughout development and I'm confident that we can get orders of magnitudes of improvement in FPS.
    We simply haven't implemented those solutions as they would slow down the work being done on nailing down the level design workflow.

    • Like 2
    • Thanks 1
  3. 3 hours ago, drages said:

    If devs add the option, why not.. pathfinding and attack code should be there. The game should able to calculate more then one tile units, able to target it as one.. it can attack to other things too.. AND we need to able to add totally new enemies with the models and animations, which is the hardest part for a modder..

    Lot of assumptions there!
    Adding in multi-tile pathfinding will definitely require a bit of extra code. I'm not saying it's impossible, but it'll definitely require some work.
    This is mostly because Chris wants to avoid the various issues that multi-tile units introduce.

  4. @Skitso

    To be honest, I'd refrain from blaming anything on your end before I really start on the optimizations!
    And when I do and you still have issue, and you have the time, we can probably take a look at what specifically it is on your machine that might be bottlenecking it. :-)

    • Thanks 1
  5. 1 hour ago, raidsoft said:

    Would be great if you could separate the graphics settings to be adjusted manually and separately in the final game instead of only presets. Being stuck with the unity presets is extremely restricting in terms of tweaking settings to increase performance for individual cases. Not everyone values settings the same either so just giving people the option to tweak it if they want would be great, or at least have the option to tweak it in an .ini file if making UI assets for it would use too much time.

    It's definitely planned.

     

    9 hours ago, Skitso said:

    @Chris

    A quick test: Camera on top of the building left from the starting position so that the roof is removed.

    Fantastic - 29fps

    Beautiful - 34fps

    Good - 37fps

    Simple - 44fps

    Fast - 68fps

    Fastest - 68fps

    As you can see, even with my relatively powerful gaming rig, the only playable (60 lock with vsync) settings are the 2 lowest.

     

    Hmm, interesting. I wouldn't expect such a hard drop-off, especially with your hardware (I've got a 1070 here as well).
    And you're right in that the Simple to Fast is the point where all dynamic lights get shut off. 
    Suspect it's the shadow handling then, which is also tied to the lightmaps.

    Earlier you mentioned that there wasn't any AA btw; the whole reason we're still using forward rendering at the moment is for AA, and it should be enabled upper tiers.

  6. Yeah, this is definitely due to the lighting setup in that case (per pixel lights is too high on the Fantastic setting).
    It won't be an issue in the main game.

    It should be fixed once we sort out the lightmap issues, or alternatively something more drastic to fix it.
    (There are issues with the lightmapping in the rendering path we're using in Unity, which was used because it supports hardware AA)

    The transparancy effect is a side effect of how Unity deals with it, and we'll probably need to write a different shader for it.

  7. The FPS drops I've not seen on similar hardware. Have you been able to tie it to specific cases?
    (Units walking, or shooting destructible terrain, etc)

    As for the performance:

    There are a tonne of optimizations we've simply disabled because they just consume development time while things are up in the air.
    There are "minor" ones such as logging and debug code that cause most of the "stutter" currently in game.
    There are "major" ones such as mesh merging, lightmapping (for those knowledgeable, a bit more problematic in our setup) and optimizations on the materials, or even rewriting shaders such that they're not just plug-and-play shaders.
    The mesh merging alone, although mostly benefiting lower-end hardware, bumped FPS about 3x-5x (from 60ish to 300ish).

    And then there are the cases where some code is still doing way more than it should be doing, because we're experimenting with certain mechanics.

    You can expect a lot of improvement in speed as we continue development the coming few months because a lot we haven't been able to do as we were still changing, well, almost everything.

    I'll bring up performance in the morning meeting tomorrow and see if we might be able to put out a comparison build now that the pressure of the Kickstarter is partially behind us.

    • Like 1
  8. I think I properly understood it then; and it's still a bit of the same issue.
    Design-wise one of the things we're considering is putting an emphasize on the strength of individual aliens. That would mean we'd have only a couple of aliens on the battlescape, the opposite from having dozens of aliens on the battlescape.

    Having said all of that, I've still noted it down. Maybe an idea would be to have the Androns fill this role in a terminator-esque horror-scenario. The planned swarm-based alien could exist in support roles to the larger individual (normal strength) Andron units.
     

  9. Yeah, I like the sound of that. After the release pressure on the Kickstarter and the closed Beta I might look into this in my spare time.
    I do think it'll be generally straight forward to mod into the game if we don't include it ourselves.

    I would imagine that balancing it in terms of how the aliens would feel could be an issue.
    As in, I don't think that most aliens work well for large-scale battles. The idea being that aliens are rather exclusive / in the background.

    Fighting a host of mind-controlled soldiers backed up by an alien might not be interesting enough. 

    • Like 1
  10. 10 hours ago, Max_Caine said:

    I think that grenades have too random a distribution when they miss. When I first tried throwing grenades, the grenades would detonate to the right-hand side of the soldier who threw it. At first, I thought the grenades were bugged, but it was after throwing other grenades that I realized just how wild the distribution is when a soldier misses with a grenade. Could something be done to make a missed grenade throw less wacky? 

    It was set at a random range around the point of impact, and we're changing it up to be based on the distance of the throw.

  11. Yeah, the development build is bound to run a lot slower sadly. However, there are some performance fixes we can still do; I'll look into it.

    > I tried to aim the grenade, then I switched to other solders.  When I switch back he's still in grenade mode and clicking on rifle does not switch it back.
    Switching weapon, however, can switch him back to pistol and rifle, so it's a workaround.

    Noted and fixed!

    > I haven't tried to reload but I don't see any clip in the reload panel.

    Noted and we'll look into it.

    > Crashed in second turn on enemy overwatch, so haven't got much else to report for now.

    We're having a hard time reproducing this one. Is logging enabled for you?

  12. Quite a bit slipped through in this release. But luckily most bugs reported were easily fixed:

    @Sheepy

    1. Hit chance is weird.  I can make 2% burst that all hits.  Actual hit rate feel like 95%.  Some bullets hit obstacles but still damage the target.
      Fixed! Small SNAFU where the target getting damage was always the original target.
    2. Because it is too fast, I am not sure but I think the first five bullets deal 8 damage and the last five deal 11.
      Same with two shotgun shots, all hits in first volley deal one damage and second volley another.  How is armor degradation applied?
      Degradation is applied per bullet.
    3. Sniper rifle reload cost 1 TU.
      Fixed!
    4. Haven't accidentally destroyed any cover or UFO object even when I expect to.  May be related with all hits.
      Fixed, see the first fix! :-)
    5. I get no overwatch after enemy movements and reaper attack, and the aliens didn't make any overwatch either (auto-resolve off).
      Fixed!
    6. I can't find the gameplay log.  Has it been moved?
      It should be in "My Documents\My Games\Xenonauts 2\Logs"

    Edit: almost forget the usual feature requests!

    1. Free camera?
      This is an option settable in Options in the next build.
    2. Jackal armour can be hard to spot when next to some rocks, may be a standby animation will help.
      Up and coming in a future release
    3. Can we show enemy facing in their ground indicator?  I find myself reading a drone for a few cycles to make sure where he is facing.
      Noted down, and personally I agree!

    @Pave

    Quote

    - According to this game, even the ground bleeds blood (as in popping-up up the "bleeding-message"-box once hit).

    This is probably tied with the fact that the original target would always get damage, so it should be fixed.

    @Larry Burstyn

    Quote

     Interesting every time I hit him I got stun damage and resist at the same time...perhaps one was stun and the other health damage?

    Yes, the resisted message is for the damage not applying any damage. 
    It's a bit confusing as the Stun Baton never deals direct damage, so I'm removing the popup for that case!
    Fixed in hotfix build!

  13. On 3/21/2017 at 3:00 PM, Larry Burstyn said:

      In fact the enemy fired thru the wall to one shot kill one of my men while another was standing INSIDE the ship right next to him.

    This should be fixed in 0.6.0 (the build released today).
    As for the crashes, would you mind sharing which CPU & GPU you've got?
    We don't get any identifiable information in the bug reports, but I would be able to narrow it down a bit.

    Most crash reports we get, do get fixed in the build following them. (So within 2-4 weeks tops)

  14. 6 hours ago, Skitso said:

    I agree. Hidden movement pop up screen looks dated and breaks immersion. I'm not sure if you are familiar with my Sleek AI turn -mod I made for X1 to remedy this problem (link in signature), but feel free to check it out for further reference. :)  (it just darkened the screen a bit and added a slight vignette while adding a small white "ALIEN TURN" text on top)

    Yeah, I was a fan of this approach as well. If not for the fact that the implementation of it is also far easier to get right! :)

  15. Given that X2 is reimplementing the game mechanics of X1 currently; I would suggest waiting until we expose the codebase to the community coders again.
    We're tagging the code in the repo appropriately so you should be able to get the codebase into the state where it implements X1 when we do start diverging, but with the added benefit of a modern working environment.

  16. 11 hours ago, Chris said:

    Maybe we also need some kind of debug information to be printed to the screen or a log somewhere so we can figure out if those misses / hits going on are just the RNG or an actual error in the game mechanics. It's impossible to know if you've got a problem or if you're just unlucky otherwise.

    I agree, it shouldn't be too much work to create an ingame log.

    As an aside; if you submit a bug report it will contain a recording of the orders given to soldiers and aliens.
    That way we can inspect if its an actual bug or not. 
    You can also attach the recording to your forum post, it resides in: "My Documents\My Games\Xenonauts 2\Logs"
    No need to worry as the recording only contains the orders given to soldiers/aliens and no identifiable information. :-)
    (For those curious, it's a zipped JSON-encoded serialization of the Actions.)

  17. On 12/5/2016 at 9:55 PM, Max_Caine said:

    EDIT 2: Have now discovered the .json files and am pleased to report that itinerant modders fiddling with the stats doesn't cause any issues. Personally would have preferred a greater degree of separation of the data from the code, but you takes what you gets. 

    @Max_Caine Could you elaborate on the "greater degree of separation"? 
    Also, this still is an extremely early build. The combat setup JSON is a temporary placeholder at best.

  18. 11 minutes ago, malthaussen said:

    @Chris: "Should be a red button in the bottom right of the screen, no? What screen resolution are you playing on?"

    1024 X 768. My eyes are not happy at finer ones.

    Hmm, yeah that would explain it.
    I'll check if I can jury-rig something that'll make sure that you can get to the basic elements at that resolution.

×
×
  • Create New...