Jump to content

Ammo stowage hits


ChrisWerb

Recommended Posts

21 hours ago, Ssnake said:

Our top priority is the development of a new software architecture to make Steel Beasts more efficient, so we can achieve high framerates even witrh mediocre PC hardware

Amen! Anything that speeds up load times in the editors would be very welcome also. I think the way that explosions are handled now is excellent. It doesnt happen too often, and when it does, it looks great.

Link to comment
Share on other sites

  • Members

Loading times depend on the amount of data that need to be loaded from disk, and the processing time for the data once that they are in memory. While I think that some progress can be made I would want to caution against too high expectations. In many areas we already have a high degree of optimization; after all, the programmers too want minimal loading times since they are the ones to start Steel Beasts and scenarios several dozen times per day for test runs, so they are the ones who are directly affected by loading times more than anyone else. They like to wait as much as any other guy (=not at all), so they already do what's possible to minimize this.

 

Looking at the Task Manager's performance graphs when starting Steel Beasts up until the beginning of the execution phase of some randome scenario, this is what I'm seeing: While I have SATA SSDs in my machine the transfer rate usually stays in the 30MByte/sec time when it could be ten times faster, simply because the data need to be processed. We're already organizing the gazillion of small texture and sound files into large MRF chunks to profit from the (usually higher) serial (read) data transfer rate and not waste time with seek accesses. Where we can parallelize tasks (as you can see from the CPU load), we do. We could squeeze a few seconds by forcing you to embed navmesh data in the scenario files again, but that creates a pain later if the way how the navmeshes are built is being refined, so old scenarios need to throw away those navmeshes and generate new ones (we've seen this with the 3.0 style navmeshes). Navmeshes can in some cases become rather large (a hundred gigabytes or more, per scenario), so given enough scenario files you would run into disk space issues; generating them on the fly typically costs well below a minute in bad cases - which we considered "tolerable" and a reasonable tradeoff between disk space usage, convenience of use, and loading times (also, embedded navmesh files would make the scenario file transfer from host to multiple clients unbearably long).

 

There are other tricks to speed up the perceived UI responsiveness but from the fact that we haven't implemented them yet you can deduct that they are the kind of optimizations that are difficult to implement, and they aren't really reducing data loading times.

 

 

So, some improvements can be expected, but it's not going to be a "night and day" kind of a difference.

Link to comment
Share on other sites

On 11/3/2019 at 6:02 PM, ChrisWerb said:

And that's where I'd much rather your effort went, even if it meant an end to new vehicles or changes to the damage model for the forseeable future. What we've got is entirely workable - it just throws up an occasional anomaly which we can easily chalk up to "unlikely stuff happens in war". When I request something on the Wish List thread these days, it's either something I think won't take a staggering amount of effort (for example, a guided round for the Armata) or it's something that might take significant resources, but will have a huge benefit to realism right across the game (subtley more realistic infantry behaviour). I often just post stuff out of curiosity about how things work, particularly when I see apparent anomalies and things I don't properly understand, and, because of my poor communication skills, it's sometimes taken to be a request for a huge amount of time and effort to be spent on something with negligible training benefit and thus unlikely to generate a financial return, which I really don't want.

new vehicles and changes to the damage model are separate from the programmers tasks. so you will see new vehicles, and updates to old vehicles happend parallell to updates to the structure of the SB engine. 

this is thanks to efforts by Al delaney years ago to improve the accessibility of vehicle implementation years ago. 

however, this is only for non-playable vehicles, which is why you see waves of non-playable vehicles appear every update. 

for playable vehicles, you still need the attention of the programmers. 

Link to comment
Share on other sites

Sorry, Dejawolf. I know Ssnake is (justifiably) reticent about discussing his business model, but I always assumed that, besides community sourced material like tutorials and skins, everything in SB was made by paid staff and therefore bore a significant cost to ESim Games. Do I understand from the above that Al Delaney's accessibility of vehicle implementation work made it possible for unpaid community members to get involved in implementing new, non-crewable vehicles, or doing the non programming work in creating crewable ones? If so, I'd love to have a go at that.

Link to comment
Share on other sites

On 11/8/2019 at 12:40 PM, ChrisWerb said:

Sorry, Dejawolf. I know Ssnake is (justifiably) reticent about discussing his business model, but I always assumed that, besides community sourced material like tutorials and skins, everything in SB was made by paid staff and therefore bore a significant cost to ESim Games. Do I understand from the above that Al Delaney's accessibility of vehicle implementation work made it possible for unpaid community members to get involved in implementing new, non-crewable vehicles, or doing the non programming work in creating crewable ones? If so, I'd love to have a go at that.

 

Well, i've created the majority of the vehicles in Steel beasts, and been paid for every vehicle i've finished, and a few other people on the team are former SB community members, namely Roguesnake and Dark, both of which i pulled aboard and trained back when i was "lead artist" for Esim games. i since stepped down from that position because it interfered with my true passion, which was making accurate 3d models of tanks, and instead Volcano, who has far more leadership qualities than me took over that role. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...