Combat mod, will it ever re-surface?

1235»

Comments

  • NordicNordic Long term camping in Kodiak Join Date: 2012-05-13 Member: 151995Members, NS2 Playtester, NS2 Map Tester, Reinforced - Supporter, Reinforced - Silver, Reinforced - Shadow
    @soul_rider, is that what happened to CTF? It was a very interesting ns2 mod. I thought it was very worth playing, even though I could never get a game of it.
  • sotanahtsotanaht Join Date: 2013-01-12 Member: 179215Members
    Soul_Rider wrote: »
    _Grendel_ wrote: »
    I herd the biggest reason they stopped supporting 32 bit was they removed (or set a higher limit) the entity limit. You could 100% run combat on 32 bit, but you might crash do to maxed out memory. So (and this is an assumption) they wanted to leave room for expansion beyond the limits of 32 bit.

    Read my previous post. Combat is also only a 32bit application. IIRC FLG dropped 32 bit back then to avoid having to support and deal with player who have to less memory to play (NS2 had a lot issues with memory leaks back then (got fixed around build 265/266).

    In case someone wants prove: just have a look at the details of this virustotal report

    I think you'll find that there are more issues than that.

    For example, when developing CTF with the intention of being a new game mode for Combat, after adding 3 new kTechData types, we hit the limit of the max number of datatypes in 32bit, so as this is a 64bit exectuable, datatypes was changed to 64bit, to hold all the relevant data.

    Although CTF is no longer part of the game, with the additional items added in the last few updates, I am fairly sure they are again over this 32bit limit, which means they would have to cut tech from the game to make it 32-bit compatible.

    ---Edit---

    My point being with all the items in techtypes in NS2 and Combat, in a single group, combat would need a lot of it's custom items cut.

    Can you explain this in a little more detail to someone who doesn't understand coding at that level? It sounds to me like you are saying that NS2 is the most complex game it can possibly be in 32bit and adding anything more would make it incompatible, but there's no way that could be true.
  • [AwE]Sentinel[AwE]Sentinel Join Date: 2012-06-05 Member: 152949Members
    They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
  • MaxAmusMaxAmus UK Join Date: 2003-12-26 Member: 24779Members, Constellation, NS2 Playtester, Reinforced - Shadow
    Quick question: How many Gamers (you Guys) Play on a 32-Bit setup?

    I get that some computers / laptops are 32 bit, but 64 bit i would say is a must.
  • [AwE]Sentinel[AwE]Sentinel Join Date: 2012-06-05 Member: 152949Members
    Does that matter if you sell a game as 32bit game? Also, even 64bit-user had problems at that time. But that discussion is very old and we had it a few times already.
    forums.unknownworlds.com/discussion/132243/32-bit-crashes-whats-going-on-natural-selection-2/p1
  • IronHorseIronHorse Developer, QA Manager, Technical Support & contributor Join Date: 2010-05-08 Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
    They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
    Models, not skins, are what increase the memory usage. ;)
  • BeigeAlertBeigeAlert Texas Join Date: 2013-08-08 Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
    edited October 2015
    IronHorse wrote: »
    They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
    Models, not skins, are what increase the memory usage. ;)

    Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.

    EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).
  • [AwE]Sentinel[AwE]Sentinel Join Date: 2012-06-05 Member: 152949Members
  • RejZoRRejZoR Slovenia Join Date: 2013-09-24 Member: 188450Members, NS2 Playtester, Reinforced - Shadow
    I wish Combat would become an official part of NS2. Sometimes I just want to slug it out with others without waiting for half an hour in the lobby and then losing just because half the people were sleeping. Besides, Combat is a good training of aiming skills as well as certain tactics.

    I've bought NS2:Combat for that purpose and the game is dead. 3 servers available with no people playing even at otherwise peak hours. Sos tupid and I really liked the game and it was huge fun for the first few days after release.
  • UncleCrunchUncleCrunch Mayonnaise land Join Date: 2005-02-16 Member: 41365Members, Reinforced - Onos
    BeigeAlert wrote: »
    IronHorse wrote: »
    They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
    Models, not skins, are what increase the memory usage. ;)

    Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.

    EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).

    It depends on how things are done and what method was selected.

    1 / Model + Animation (bone, ragdoll etc.). Lowest consumption but makes the program (or ragdoll stuff) work more. Hardware is pretty efficient at it now.
    1B/ You can save CPU/GPU cycles by rendering in memory every animation frame before using it. Pre-calculating takes more memory and rendering time after loading. Useful if you want to draw an army running on a field and as the camera is IN the action, the model have to be detailed (lot of vertex). Animation stuff would probably slow down everything in this case.
    2 / model + vertex animated (each animation frame is already rendered). So it's N vertex * N frame. Not really something any coder should do. But in the mean time, no need for 3D animation function/library stuff in the code. You just select the right frame and use the vertex.

    Animation data can be tricky too. having only key frame saves storage. It require the program to rebuild the entire animation (ex: with IK data).

    Same goes for textures. More pixels means more work... simple as that.

    You can have any system you want actually. Then for each method there are downsides.
  • BeigeAlertBeigeAlert Texas Join Date: 2013-08-08 Member: 186657Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, NS2 Map Tester, Reinforced - Diamond, Reinforced - Shadow, Subnautica Playtester, Pistachionauts
    edited October 2015
    BeigeAlert wrote: »
    IronHorse wrote: »
    They added more skins to the game and 32bit-user started to crash regularly. I can believe it. But that might had been a problem with sparks and not 32bit alone.
    Models, not skins, are what increase the memory usage. ;)

    Actually, skins should increase the memory usage just as much. 90% of a model is just the texture data. Models themselves are relatively light.

    EDIT: Maybe not... not sure about this exactly... animations take up a ton of memory... but similar models should share animation data... (eg shadow skulk, kodiak skulk both inherit animation from skulk).

    It depends on how things are done and what method was selected.

    1 / Model + Animation (bone, ragdoll etc.). Lowest consumption but makes the program (or ragdoll stuff) work more. Hardware is pretty efficient at it now.
    1B/ You can save CPU/GPU cycles by rendering in memory every animation frame before using it. Pre-calculating takes more memory and rendering time after loading. Useful if you want to draw an army running on a field and as the camera is IN the action, the model have to be detailed (lot of vertex). Animation stuff would probably slow down everything in this case.
    2 / model + vertex animated (each animation frame is already rendered). So it's N vertex * N frame. Not really something any coder should do. But in the mean time, no need for 3D animation function/library stuff in the code. You just select the right frame and use the vertex.

    Animation data can be tricky too. having only key frame saves storage. It require the program to rebuild the entire animation (ex: with IK data).

    Same goes for textures. More pixels means more work... simple as that.

    You can have any system you want actually. Then for each method there are downsides.

    Spark stores a compressed version of the model's bone animations. It does not use any sort of IK system, rather all the poses are "baked in" when the animation is exported.

    And yes, models share animation data.
  • Locke504Locke504 Join Date: 2010-04-23 Member: 71511Members, NS2 Map Tester
    RejZoR wrote: »
    I wish Combat would become an official part of NS2. Sometimes I just want to slug it out with others without waiting for half an hour in the lobby and then losing just because half the people were sleeping. Besides, Combat is a good training of aiming skills as well as certain tactics.

    I've bought NS2:Combat for that purpose and the game is dead. 3 servers available with no people playing even at otherwise peak hours. Sos tupid and I really liked the game and it was huge fun for the first few days after release.

    Join the combat gather group for game invites and info on games.

    http://steamcommunity.com/groups/combatgather
Sign In or Register to comment.