The intermediary text sizes, and a number of other GUI related things too. At this point it's impossible to make an accurate prediction about specific features implementations; the point of 5.0 is to implements a new software architecture that allows us to adapt development processes, rather than the implementation of a specific catalog of new features. But, it's safe to say that reworking the user interface is going to be a major component of the task, and that will bring, among other things, the end of rasterized fixed size fonts, so it will work with Windows font scaling (and thus, implicitly, with 4K and higher screen resolutions; once that we can do Windows based font scaling we can also have near-seamless in-application font scaling for map graphics).
It absolutely should. Even if we may not be able to address each and every issue right away, it should at least simplify things enough that we can adapt the GUI to customer requests with much less effort than has been the case since about, well, "always". Redesigning the GUI framework is another major development effort - somewhat comparable to a new terrain engine - less sophisticated maybe, but the UI by definition has ties to about every component in Steel Beasts.
I expect the next update before July, maybe even around end of April/early May.
I don't like this variable numbering. That is why it was abolished again - however, this is a bugfix, which is probably only used in version 4.2.
Q: Will there be an upgrade soon?
A: Not in 2020, probably not in 2021 either. An update? You bet. A big one.
Thanks for the kind words. There may be a misunderstanding, though. I wrote of a "significant update" (not upgrade) (and this year, not 2022), so it's not going to revolutionize everything. Still, more than a patch, and more than just a patch with a token feature addition. 8)https://www.steelbeasts.com/topic/14157-update-for-sb-in-2022/?tab=comments#comment-205107
Just to clarify the wording - 4.161 was an upgrade to previous versions, we charged classic license owners money for it.
All the versions since last August were patches - free bugfixes, no new features.
Updates are in between. Mostly bugfixes, free of charge, and with some new features.
We'll develop a new Steel Beasts engine. I hate being dependent on the whimsical decisions of other developers. We'll make sure that there will be, in the worst case, a migration path to convert old content (like what happened with the new terrain engine in 4.1). Ideally however the new version would be capable of reading legacy files without requiring any user action.
Converting files sucks, so the "migration path" is a distant second option for me. But like in version 4.1, sometimes there is no other way, and then it's better than nothing. Implementing that kind of backwards compatibility probably cost us a year and a half in development and testing, and it wasn't fun for the beta testers at all, but the alternative would have been a total catastrophe. We take preservation of your time investment into the stock of scenarios and map files very seriously.
The major uncertainty about the release date has been resolved. I expect something in late autumn, but well before Christmas.
The point of this thread is to let everybody voice his preferences. That, if multiple people express their wishes, some of them may be contradictory, is pretty much a given. The community is not a hive mind. Insofar I find this critique unfair, as it juxtaposes different opinions from different people as if they were coming from a single body. That simply isn't the case.
Also, I think I made clear that eSim is working on an entirely new engine that will no longer use DirectX 9, that an explicit and major goal of this engine is to separate the render loop from the simulation loop, and as a natural consequence of that a server that doesn't need a graphics card in order to host a session appears quite feasible, possibly via command line switch. Insofar we'll be able to maintain established hosting procedures as well as allowing people with a dedicated gaming server to run SB Pro without the need for a graphics card.
Everybody wins.
Can we move on now, please?
Quote from: stormrider_spIs it still too early to ask what api will the new engine have?We picked one. We're trying to make it work. If it doesn't, we'd pick another. As far as end-users are concerned, it could be powered by a hamster in a wheel ... as long as it works, right?
It's not the lack of profitability, it's the lack of excess manpower (and the resulting opportunity costs). Once that we have completed the work on the engine change and everything else related to 5.0, we'll free up some capacity to work on exotic or historic vehicles again.
The question is, how many controls to we want the user to fiddle around with. Personally, I think that for selected vehicles we've already gone too far with depth of focus plane shifting in the thermal view, brightness and contrast for some thermal sights, or the brightness of reticules. It's selected in some vehicles (not the M1A1) because Steel Beasts is used in containerized crew simulators, and the changes for these simulators are seeping back into the Personal Edition.
I don't like it because it's distracting the player from the big picture. Now, you could say that this is something he'd have to deal with in real life, but IRL you have two hands and ten fingers and analog switches and dial knobs all around you, and you're four people in that tank and not just one. In Steel Beasts, you have a keyboard, and a mouse. In Steel Beasts, even if you're in the gunner's place you're usually still in the role of tank commander, platoon leader, and maybe even company team leader, and you need to maintain adequate tactical situational awareness. In Steel Beasts, you're in the gunner's place at this moment not just because it's fun, but also to make up for limitations of the AI, at least at times. And now you're confronted with the switchology of a number of different vehicles in your company team with which you have minimal to moderate familiarity.
IMO, as far as the Personal Edition is concerned, fewer controls are better. Yes, many of you are veterans of one or two systems simulated in Steel Beasts and you'd like to see more - but even if you're an M1 master gunner and you know everything there is to know your familiarity with the CV90/35 (ah, but which one?) will be minimal, and here we are, today's scenario is a company team of T-72s paired with CV90/30 because it's set in Finland, and all the work you invested last week in learning the Danish CV90/35 doesn't help you. :o
Maybe, in SB Pro 5.0 we'll make the level of detail configurable. But even then we won't have the same level of detail implemented for every vehicle because some are in and tailored to a specific customer demand, and some are in because we went and added them on our own initiative, to the level of detail with which we felt comfortable/that we had researched at the time of creation. And the M1A1 is our tank #1. The first fire control system we ever created when we were young and didn't know better. And we never had a military customer for it who was interested in the switchology. So it doesn't have these controls, and I think you're better off because of it.
With the advent of TerraSims world map sever, does Esim have any plans to utilize their services?
That specific server? No.
Will the classroom version 5.x be capable of utilizing such servers in general? Yes.
Asking for advice with a five-year hgorizon and a "guaranteed" framerate >40 is a task for which a serious answer is not possible. I might luck out, but I can only tell you what our design goals are.
SB Pro PE should always run decent on whatever current mid-range hardware is available at the time of release
For eSim Games visual quality is not the top priority; SB Pro shouldn't look deterringly ugly however. Therefore, if the artists want to take the route of physics based rendering I won't stop them. If they came to me demanding that we immediately switch to real-time raytracing, I'd say No.
Future SB Pro PE versions shall take advantage of most hardware capabilities that the given platform offers, especially parallelization. I would not want us to cap the usage of available CPU cores to four or some other arbitrary number when 16-core Ryzens are already pretty affordable today. Not every task is parallizable, so simply throwing more cores at Steel Beasts isn't guaranteed to eliminate bottlenecks, but when I recently made the choice between a 12-core and a 16-core Ryzen, I did not think very long about the extra expense.
With all that being said, I'd definitely go for 16 GByte RAM.
I'd go for the mostest-core CPU that still fits into the financial and thermal budget of the notebook (certainly a factor to consider too)
I'd consider a GTX1070 the absolute lower boundary of a five-year notebook's GPU. That being said, think out of the box for a moment. There are external GPU adapters for notebooks. You might be better off with a solution that has Thunderbolt sockets through which you'd connect an external GPU which might even be something that can be switched later. That way you could rely on integrated graphics for non-game applications and pull out the big iron only when the task demands it. You could pay for a reasonably-priced GPU right now, and a reasonably priced GPU of the future to upgrade later. I cannot guarantee that this is going to be the cheaper or more-potent-for-the-same-budget solution, but it may be something worth exploring.
Coming back to the question of "thermal budget", you should ask yourself if you want to be wearing headphones all the time. I have a notebook with a GTX2070, and whenever a game is on it's almost like an effin' leafblower on my desk. Without noise-cancelling earphones it's just not bearable.
If you value silence in operation most of the time, a small tower is always going to be superior and cheaper for the same performance, or faster for the same budget. They just suck in transportability.
I don't think that the RAM requirements will grow massively beyond 16 GByte. Sure, more is always more, but 16 should do it for a good while.
WRT the 144Hz thing, this is primarily a VR/3D shutter glasses requirement so that each eye gets updates at 72 Hz.
Yes, Steel Beasts can't take advantage of faster monitors right now because he have a framerate cap at slightly over 60Hz based on the experience that high framerate variations were more detrimental to the game experience than a smoothed out version at a lower framerate.
Nevertheless, future versions of SB Pro might lift this artificial cap, assuming that the new engine actually manages to maintain much higher framerates in all situations. Even then, though, I don't see us reworking all vehicle interiors to accommodate the requirements for a VR/3D glasses version.
Quote from: KoenRE "the mostest-core CPU": the pricerange I'm looking at (1500 EUR) seems to be limited to max. 6 cores => is this OK for today's SB ? (or is it already old hat ?)Six cores aren't bad and will do in the future, but I suspect that most notebook models that you checked so far are Intel CPU based, and Intel simply is way behind AMD at the moment. AMDs Ryzen 4000 series offer more core bang for the buck, but notebook manufacturers are slow to adapt AMD solutions; they simply remain an unconventional solution (and in computing that's not necessarily a compliment). But if you find a model with a Ryzen 4xxx CPU, it may be worth a second look to see if it fits all other requirements.
It'll get better with the next "major major" release (in the sense that it's too early to say when exactly it'll be ready for the general public, so there may still be 4.x releases that I'd rate as (just) "major").
Target prioritization is a notoriously difficult topic. I think that most of the time the AI vehicle commander is relatively competent. But of course, the few cases where he acts really stupid are the memorable ones. As there is no perfect formula that can consider the perfect solution for every possible constellation of target arrays - a complete enumeration would create about a fantastillion permutations, probably more - we have to rely on heuristics, rules of thumb, applied by brain-dead zombies.
If it is of any consolation, we'll try a new approach in version 5. I can't promise a solution in version 4.x
Would require the cooperation of the Israeli Army, which is notoriously secretive (and I'm not very optimistic that this will change anytime soon, or that they'd make an exception for us). I'd like to have a playable Merkava in Steel Beasts as much as the next guy with a passion for armored combat vehicles, but even if we would create one with a speculative (and thus largely wrong) fire control system for first person usage it would require us to devote substantial development time which, right now, is absorbed by the development of a new render engine, a new graphical user interface, a new sound engine, and the associated integration tasks.
So, it will take a good while before we may find the time to follow our passion again. Right now, it's a time of necessities.
Quote from: Maj.HansThe current implementation of the AVEPS vehicle protection system is freaking outstanding. But let me ask, can we get some more variants of this implemented based on simply modifying what conditions will trigger the current AVEPS system we already have?It's our prototype for other launcher based active protection systems which, once implemented, will receive different characteristics.
Right now I don't think that it makes a lot of sense for us simply because the GUI isn't made for resolutions above FullHD, and FSR seems to gain performance by rendering at a lower resolution, and then to upscale the image with sharpening. Which is a clever way to handle 3D scenes and "punch above your weight" as a graphics card, but only if we're talking about 4K resolutions and the like.
As long as Steel Beasts doesn't scale text elements in the GUI, anything about 1920x1080 is going to be painful in any case. Likewise, scaling gun sight reticules doesn't sound like a terribly brilliant idea, so that might be another not entirely trivial problem to solve.
That being said, I have utmost confidence in our programmer team to look at any solution that promises performance gains. And as soon as we have the new GUI framework in place we can then consider support for 4K and higher resolutions.
For version 5, we're planning to add integrated filter tools to help you search for certain categories of scenarios much quicker.
Of course, automated scenario scanning can do only so much, if the forces you control gradually expand with events, or if they depend on random variables.
I went through this once, when there were neither line nor fill tools.
The version 5 map editor will make much simpler for all of you, promise. Up until now its purpose was to touch up an existing map, not to create them all by hand. You import map features first, then do a bit of nip and tuck. That at least was the intention. It's like if the only tool you have is sand paper, and you're supposed to create the "David" statue from a large block of marble, with no hammer and no chisels.
More cores help to reduce scenario load times. Here we're parallelizing as much as possible (also with legacy map conversion, which however isn't the typical use profile). Also, certain tasks (such as simulating the vehicle suspension, HE/frag grenade terminal ballistics) always run in separate threads.
SBPro version 5 will use parallelization much more aggressively, but is still a good while ahead. My new PC has a 16 core CPU, just so you know what my own expectations are.
Well, I purchased the 16 core to be able to fully test the more extreme parallelization cases, which will probably be used to scale up certain details (of increasingly less relevance), not necessarily to "run faster". FEX, we might be able to trace more individual fragments with HE detonation events if more cores are present, but since we're going from high mass to low tracing the smaller fragments will yield only minor (and at some point vanishing) improvements in fidelity. Or, to test out a server function hosting multiple sessions, something of relevance probably only for military customers. So, I don't think at all that you made "a bad choice". Your new CPU should serve you well for years to come.
We do want to take advantage of the latest generations of GPUs with version 5, if they are available, to enable actual and significant performance boosts with the new architecture. But at the same time I think we will still want to make sure that the higher tiers of older generations of graphics cards (such as the GTX1070) will still perform well.
The RTX3000 series is impressive as hell I must confess; it's a shame that it is so well suited for crypto currency generation that these miners ruin the entire market for gamers. At recommended retail price levels I'd buy one in a heartbeat. At the same time we can hold out with our older cards until this storm has blown over, so I'm not too worried about the situation, just, admittedly, annoyed.
I'm not particularly comfortable talking about our plans (even if we are already working at them rather than just blowing pipe smoke). Everything that we do must adapt to the conditions of our work (finances, time, and manpower available), and these conditions change over time. So, they are not promises of a certain future performance, or specific feature sets. They are the general direction into which we're heading, and we'll see how far we come. There's still a number of "known unknown" issues that will have an effect on final performance and schedule, AI being one of them. Then again, looking back at the road already behind us, I suppose we could have done much worse, so I remain optimistic about what we can achieve in the next years.
In any case, like I wrote, the formula "more cores=more fragments" is going to offer diminishing returns (and it is but a single example of the kind of scaling that we have in mind), and 4...8 cores should deliver good performance for years to come. Likewise, 8...16 GByte of RAM is the "comfort zone" that I wouldn't want to leave unless there was dire need. There'll be increasing need for storage space for maps and graphics textures, but then again many games these days already want 40...80 GBytes of harddisk, so we're still well below that margin.
Version 5 will come with a new GUI middleware, and as a result, better options for adapting it to high screen resolutions. But it's still a good way out. One does not simply walk into Legacy Code land to replace the GUI, as a software developer legend once said, in a galaxy far, far away.
We'll concentrate on developing the new engine and converting existing artwork first. That's the big one. Once that that is out of the way, I expect to shift our attention towards more atmospheric/environmental elements.
I guess you last checked with version 4.0
The performance there wasn't great - the death from a thousand paper cuts.
Like I wrote back in 2016, we knew what had to be done about it, but fixing it took until 2019 with 4.1, where we had numerous improvements in a lot of places, all of which gave us 1% more framerate here, 2% more there, sometimes just half a percent - but with enough of these fixes, eventually we could pull ourselves from the swamp.
Then again, we have pretty much exhausted all potential for optimization with the current engine. To make true progress with higher detail levels in maps, supporting more units, bigger maps, the current engine simply won't cut it. That's why we're working on 5.0, but that one breaks with a lot of old design concepts (how could it be any different), so it's really a major undertaking that will keep us busy for a good while.
Quote from: Major duck35 mm KETF ... the Dutch requirement to have a high probability of knocking out every optic of a T-80U MBT with a single salvo.Yes, it's a limitation of the current engine as far as tank components are concerned (yet another reason to work on 5.0).
... i still haven't seen it work like that in SB yet
It's scheduled for a facelift, but "facelifting" actually means to develop the model completely anew. For that we need an opening in the regular artwork development pipeline. So, not in 4.3 ... but it will be done.
There will be map layers, in version 5.
The artillery system is scheduled for major changes. They won't make it into version 4.3 - too much needs to be changed to make that a "safe" feature addition at this point - but for whatever it's worth, we're working on it. It touches internal messages and processes in the code, the user interface, network messages ... in short, it's pretty "hairy code" with connections going to many places, all of which need to be redesigned. But, in the end we'll have artillery that's going to work well even in mountaineous terrain, when firing from uneven ground, possibly with ordered high/low trajectories, and all from a standardized user interface with dialogs closer to real life call for fire procedures (that can then be tailored to the specific national demands of the different customers that we have).
Quote from: GibsonmPart of my aim for this is to settle an internal concern that I have that extra detail results in maps that the AI has issues with. Part of me loves the detail, part of me thinks detail = clutter = troubles for the AI.That concern isn't unfounded. But it's probably solvable, if we can at least address the most frequently observed issues. And if we can't solve it in version 4, then maybe we need different approaches to pathfinding in version 5. Either way, we can learn from it, and I'm determined to make high-detail maps work. Otherwise the whole new terrain engine effort would have to be chalked off as a complete waste.
A new engine is in the works. It's too early to say what will be technically feasible (and at what price, as far as computing hardware and development effort are concerned) ... but of course we don't change engines just to keep things exactly the way they are. At the same time, as long as we're working on laying the foundation of coming work, we can't keep the feature mill cranking in high gear.
As mentioned in other posts, once that the visibility limit exceeds 14,000m, certain render anomalies will occur. In this case, a quirk in the render engine that obstructs an ever growing part of the scene being rendered in four directions so that when looking in a specific direction much of the landscape disappears. It's a small angle at 14,000m, but pretty large at 18,000m, so we don't advise going beyond 14km.
I no longer remember the specific reason for it. "It's always been like that" was one statement from the programmers - and (since that doesn't excuse anything), "No, it's not easy to fix this, I tried." the other. I then made the decision to not pursue this topic because we have bigger fish to fry, and I expect that no such anomalies will occur with version five.
Well, there were some probing questions, in all fairness. And in our simulator projects, some loader's places have been enabled, but typically without 3D visual representation, and they require no AI for the place.
If as a human player you not only want to look out of the hatch and observe, but also operate the AA MG, possibly also service the coax MG and do some pointless click action to load the gun, that requires a disproportionate amount of effort to replicate the capabilities in the absence of a human player. And keeping things how they are except when human players occupy the position, gibing human tanks extra capabilities, goes fully against all the design principles that I tried to establish in Steel Beasts.
In version 5 we may reevaluate some of the fundamental design assumptions, and as a consequence we might then also get the capability to have a more versatile (AI) loader that could be substituted by a human if so desired. But the thought of all the crew animation that go along with this do not fill me with appreciative joy, I must confess.
Okay, Fool's day is here, can we please put the topic to rest now?
I don't think how I could express myself any clearer, it's not going to happen anytime in the next two or three years.
Well, with version 5 we're working on a new engine, and of course we want to take as much advantage from new technologies as we can. (Rewriting the existing engine to accommodate new frameworks would have cost at least as much work while getting less performance out of it, so it was no serious alternative (in case you were wondering).)
The problem is,
a. screen space. A COY task force can have a lot of callsigns that need to be organized in a way that you can access them easily, but also without blotching out the whole screen.
b. line of sight. How do you give, in a GUI, the command to flank an enemy that you know to be in a certain place, but you can't see?
It's easy to give a verbal command to that effect, but it's quite another to design a GUI that might allow you such a thing.
Whatever we can think of, at the end of the day this will require the development of an entirely different GUI concept, which is what we're doing for version 5.
In the meantime, the map is the primary command interface at the company level and beyond.
No immediate plans for the Abrams family. The US Army isn't as good as a customer as one might hope for, so maintaining that line is one of the tasks that we have to squeeze into the rather narrow gaps of our general workplan.
To say it bluntly, our priority is work on the new engine. Everything else is a distraction from the important task; some of these distractions are necessary or mandatory (but they are distractions nevertheless).
The new engine, however, would allow to have more than two coaxial weapons (say, one 100mm gun, a 30mm autocannon, and a 7.62mm coaxial MG, to give a completely random example). Or to have more than one gunner on a vehicle, where one would mount some AA MG. That's among the reasons why we're making the rather painful effort.
Not in this update; 4.3 continues to use the (heavily modified, lighting-improved, high-res terrain-enabled) Viper Engine that we adapted with version 3.0. So all this talk here is about version 5.0 and beyond. It's quite likely that there will be a Version 4.5 and/or 4.8 release before 5.0 is in a shape and form that it's suitable to replace the existing SB Pro PE.
Depends on your definition of "distant", but yes, it's definitely not "around the corner". It can't be. If we want to get rid of parts of the legacy code that impede further development - there are some - and if those parts needing replacement have deep roots that touch all parts of the rest of the code (they do), then you can't just replace the render engine and call it a day. The UI middleware needs to be replaced (well, "a UI middleware needs to be added" in the first place). The render engine needs to be replaced (DirectX 9 will be discontinued eventually, and doesn't allow the performance boosts that we want to achieve). AI code needs to be re-written from ground up. And then, every (combat) vehicle we have in SB Pro needs to be converted in code and in scripts. Often, that will go along with a 3D artwork facelift. These are the four major dragons that we must slay. It's doable, but it's not trivial. And in the meantime our customers still expect updates and a functional Steel Beasts for training or entertainment.
TBH, I'd rather they scrub all the 4.xxx development and go full blown 5.0 all in. Makes no sense dangle all this 5.0 stuff infront of us, meanwhile all the work goes into the 4.xxx series.Ssnake has a post which may answer your statement: https://www.steelbeasts.com/topic/15856-loose-ends/#comment-225949
I don't expect it to take that long. But of course, predictions, particularly those about the future, are a fickle thing. For our military customers it will be a gradual transition. You, on the other hand, want a new version that basically delivers what you already have (and then some). That means, we can make it public only after the bulk of all conversion work is complete.
I certainly won't rule it out. But one of the reasons we're moving to version 5 is the increasing complexity of the current AI code. So I'm predisposed to schedule this as a "5 activity".
There'll be a minor feature shown in a video later this week. There were bug fixes that shall be listed in the Release Notes, and those will contain a chapter about each editor (among other chapters).
Our development focus is on a completely new Map Editor for version 5 (not ready yet, obviously), and on bringing the features and vehicles developed over the last two or three years into this PE version. So, don't expect revolutionary revelations.
Memory: You can have decent Steel Beasts performance with 16 GByte. There may be (rare) occasions where 32 GByte are better, but we will design SB Pro 5.x to perform well with 16 GByte if possible. If you must save, 8 GByte will still be tolerable for the next few years, hopefully even longer. More than 32 GByte seems like waste to me.
That we're working on version 5 is not a secret to any regular reader on this forum. I'm usually not reporting much because we're still in early stages of the development, and talking about a pie in the sky isn't helping anyone right now in the best of cases, and might create a wrong impression that version 5 is just around the corner in the worst case.
That the Map Editor is in the most urgent need of renovation is also rather obvious. We neglected its development for a long while. I could go into the reasons behind these decisions, but it's probably sufficient to say that we originally were too optimistic about what 3rd party software could deliver, then we tried to find a stop-gap solution that effectively went out of the window with the transition to the map packages data format. Last but not least, when faced with prioritization decisions, for every feature to win, a dozen others lose.
So, yes. The Map Editor needs improvements most urgently, so it seems to be the logical starting point for practical version 5 development.
Version 5.0 will do away with DirectX 9. The first version 5 application will be finished this year. But we will have to develop a number of version 5 applications that we may then fuse into one integrated package later (or keep separate; e.g. from a functional perspective a Map Editor could be kept a separate program without loss of convenience for the user) before we can present it as a "Steel Beasts version 5" to the general public. The execution phase with all the combat vehicles and explosions, the fun part, will take longest to convert. So, in all likelihood there will be one or two more intermediary versions, shall we call them "4.5" and "4.8" or something like that.
Quote from: CharlieBIs there a way of prininting the mission maps but with map symbols for key building types as opposed to the black blocks.No.
I think that version 5 will offer such options, from what I'm seeing in the prototypes. But not version 4. I have no idea about a practical workaround either.
Hopefully, the SB5 engine will satisfy my technical demands for night-fighting. Because, frankly, I have yet to see games that do darkness justice beyond mere visual effects.
It should be noted that this will be yet another pure PE feature, once implemented, because training usually doesn't want it.
The V4.x and earlier Steel Beasts Engines will always have a problem with large building numbers on a given map.
V5 is going to change that (up to a point), but of course that's not helping anyone, right now.
While individual 5.0 applications will appear for .mil customers as early as 2023, it will take much longer to fully migrate the current functionality to version 5, and to integrate the different components.
So, there probably will be a 4.5, maybe 4.7 PE release before version 5 is ready.
1) A copy CTRL+C / paste CTRL+V in the mission editor that lets you select any unit and copy it and paste that copy anywhere on the map to speed up mission making by magnitudes.
Perhaps copied and pasted units could assign new numbers to them so that it doesn't mess up the logic? For instance, if a unit that's coped is named 1/A then the first copy and pasted unit would be something like 1/A(2) and then the next copy and pasted unit would be 1/A(3) and so on, so that each copy and pasted unit is different in name, but identical to the original in all other respects.
2) Better multi-core support for multi-core processors. Seems like the sim still utilizes one core more than taking advantage of multiple cores like most modern PC games do.
3) Better UI scaling for the menu. Tried to play this at 2560x1440 but ran into two issues. First was Windows 11 scaling causes the mouse cursor in the game to be invisible. Also, text inside of the gray text boxes within the game overlapped letters and even ran outside of the text boxes. I had to reduce scaling in Windows 11 down to 100% from 175% (Recommended) to get the mouse cursor to appear and to get text to fit inside the boxes. But it was so teeny tiny that I could not read it and so I had to reduce resolution down to 1920x1080 to be able to read anything, and even then it's still pretty small. It would be nice if the game had its own UI scaling system that allows users to increase text scaling and able to play at higher resolutions.
4) Heat blur for all vehicles in the game.
5) Maybe some mud and dirt effects that dirty up the vehicles in the game if you got time. Nothing I hate more than a clean tank or a man with a pickup truck that ain't got a spec of dirt on it or someone who's got a fast sports car and drives it the speed limit. 🤦♂️ The hell did you buy it for? And I was a police officer. I remember I used to consider pulling over law abiders with those nice sports cars that drove them the speed limit. Felt like it gave me probable cause to search them. Why you acting so suspicious driving so legit with that sexy fast sports car hmm? 🤔😆
#1, version 5
#2, version 5
#3, version 5
#4, can you give me an example where this isn't the case?
#5, version 5 - eventually (but probably not initially)
No, SB Pro is still plain Stereo. Version 5 will eventually get a new sound engine too; how quickly we'll get there remains to be seen, but clearly things need to improve.
I'm sorry about that, but support for your networking is beyond the scope of what eSim Games can deliver. The multiplayer part of Steel Beasts was designed when things were simpler (and less secure).
For version 5, I hope that we'll be able to set up a game session brokerage server. You'd connect to that, and it would then hand over your connection to whatever game session was available. That should make things a lot easier. Unfortunately, it's the future, not what Steel Beasts can do for you right now. :o
I don't think that there's going to be a PE version 5 within two years. We can roll out partial updates to our military customers, but a PE version will require that the full content with all features has been converted (minus items that we bay decide to discontinue). For some elements the conversion will be relatively easy, for others, it's going to be a lot of work. I don't want to kick off a whole new "version 5" debate again. If you search the forum for this keyword, you'll find plenty of statements from me.
The issue at hand is getting the network games with you and your buddy working. If you search this forum for your router brand and model you may find some tips for its configuration.
We release major upgrade about once every three years, 2013 (3.0), 2016 (4.0), 2019 (4.1), 2022 (4.3). Extrapolating from that quite linear trend suggests that there might be a 4.5 release in 2025. Whether there will be a version 4.4 for SB Pro PE, who knows. I wouldn't rule it out. It might be a free update. The point is, we do not have any specific plans or a roadmap yet. Our development is a continuous process. Usually we wait until enough changes have accumulated that they justify the release of something in the $30...$50 price range.
V5 is supposed to be a software architecture that should make code maintenance and component replacements easier for us, so that we can react faster to shifting market trends. We're not going to end all development there. Quite the opposite, once that we have technology barriers out of the way, hopefully we can speed up innovations that are more relevant for your Steel Beasts experience.
Also cosmetic. Be nice to be able to paint or fill an area with debris/wood/bricks/ metal etc. in the map editor.
Similar to what we can do with bushes/ rocks etc.
The battlefields, especially around city's and roads especially look much too clean.
a. I agree, that our environment is too sterile
b. I agree, we need better AI/navigation before this would be possible
c. it's something for SB Pro V5/V5+
As identified in Bugzilla entry 11418.
Introduce the ability for the AI to use GLA rounds, both Smk and HE, as part of the Infantry weapons capability.
Something for V5, we need different approaches for AI decision-making.
Quote from: Apocalypse 31You guys made that sweet UI for the UAVs.Yeah, it's a bit of a prototype/study for our future work. Mostly an outlook to V5, not something that we'll implement for everything in future versions 4.
I suspect that the tool you're using doesn't show the saturation of individual cores of the CPU, but just the total load. Which is misleading, obviously. If on an eight-core machine the CPU load is 12.5%, most likely that means that one core is operating at maximum load.
The next obvious question is, why don't you use parallelization more?
Because it's hard to add that as an afterthought to a software project. You either build it in from the start, or you can parallelize only certain parts (like, scenario loading, road leveling in the map editor). Which is one of the reasons why we're developing a completely new software architecture for version 5.
This is a change reserved for version 5. A higher resolution for the current tile map has the potential to create a lot of unforeseen consequences elsewhere, it simply isn't worth the risk.
But 10km is awesome! On my PC any higher than 11 km and hills and forests flash.
Yes, it's a known engine limitation. On my machines the problem starts with 14km+ (up to this point I thought this was universal, seems like it isn't). With version 5 we expect to eliminate these quirks.
Quote from: RedWardancerTo keep up with the trends and the gaming world, I want to know what to get so I'm not behind the power curve the moment the new PC arrives at my home.Certainly not for SB Pro, now, or in the foreseeable future. SB Pro V5, once available (and V4 is still going to stick around for a while), isn't supposed to require dramatically stronger hardware than right now.
Do I need 64-128GB of RAM to play today's games such as SB PRO, ARMA 3, Skyrim SE, etc?Quote from: RedWardancerDo I need an NVIDIA 4090?No.
Personally, I settled for an RTX3070, and I don't expect to need anything dramatically better in the next years. NVidia's latest generation graphics cards seem to exhibit a nasty habit of spike power demands. There seems to be a bit of a disagreement between power supply vendors and NVidia who, exactly, is at fault. Whichever way you lean, the fact remains that these top of the line graphics cards require an equally top of the line power supply, all of which contributes to ballooning costs, increased noise from all the heat that needs to be fanned out of the case, not to speak of the electricity bill.
Maybe Linus Tech Tips has a particular axe to grind with NVidia, but just check a number of the videos they made over the last six months about the RTX4090 ... maybe it's not quite so bad, but the point stands that it'll cost a lot more for diminishing returns.
The actual performance, like I wrote, will depend on the terrain theme, and the spot on the map and your viewing direction. "Before" may have been in places where ther number of to be rendered ground clutter billboards was close to, buit still under the limit of what your graphics card could handle. Except, this time it wasn't, and the framerate went down and you noticed it. Or this time, the ground clutter objects were tall, resulting in a massive overdraw situation as an extra load on a hardware that was already at the upper limit of what it could handle.
These are two possible explanations. There isn't enough information to know whether thone of them or both are the explanation, or if there's something else at play. Nevertheless, the 100% slider setting routinely overtaxed beefy hardware in the past. Seems like beefy hardware of the present can almost handle it. By the time that substantially more powerful graphics cards are out, hopefully we can give a roadmap to V5, rendering the whole issue moot (because then we'll have a different engine, with different characteristics).
With V5, all screen elements and text will be scalable. Right now, I can but recommend to pick a lower resolution. Which also sucks (I'm aware of that) - but it sucks in a different way.
The problem I'm having is that the lighter and "less tanky" a vehicle gets, the doctrinal role gets fuzzier (or "more versatile" if you wanted to give it a positive spin); therefore, between scenarios, the eras in which they are set, and from one light vehicle to the next whatever one might considered "adequate behavior" will vary, and that's not even taking into account different national concepts of the army (e.g. USMC, Canada, New Zealand, and Australia all have or had at some point a LAV with 25mm autocannon; their doctrinal use will be/was different in each case).
That being said, I'm hopeful that we'll allow for different AI concepts in version 5 that might also result in a step towards more flexible responses depending on what type of equipment a vehicle might carry.
Hello i just bought the last upgrade version form 4.1 and i have a 4k resolution monitor and i have this issue, I tried to move the text Size in window 10 and still having this issue. I only can play it in windows mode that also doesnt look right. Please this post is from 2016 and now we are in 2023. Did you found a fix?
We call the fix "Steel Beasts version 5", but it will still take some time before it can replace version 4.
I'd love to invest more time in this, but the reality is that the development of the new engine will keep us well occupied for a few years. Once that version 5.x is ready for general roll-out, I guess we'll look at this topic again.
V5 will no longer use DirectX 9, but the Vulkan SceneGraph.
Frankly, I do not expect Intel to achieve more than barely to keep pace, with a small chance of slowly catching up. They have never shown any interest in computer games, barely any in 3D graphics other than "it's necessary because our customers expect it".
If there is no visible support from top management, rarely will the employees muster sufficient drive to do something extraordinary anyway (the Volkswagen Golf being one notable exception to the rule).
That being said, currently our new engine delivers up to 5,000 frames per second. That level will never be achieved again, so please don't read more into this than is actually justified. As we add more and more fancy elements, there's only one way for the framerate, and that's down. Nevertheless, if we could preserve about 200 fps on a then top of the line graphics card in two years, that might still mean 60 or even 90 fps on an Intel ARC. At this point, it's all but speculation. But there's a non-zero, if small chance that the performance on low-end graphics cards may actually turn out to be quite decent.
We got to get the new engine working, write an entire new GUI, replace the network code, develop a new AI, facelift the 3D artwork, and convert all models of the various fire control systems to the new architecture. Once that this is done we can shift our attention to the fancy things again.
First of all, the tiniest "hill" that the current Steel Beasts engine can render is .78m in radius, and .39m in elevation. That's about 30 times higher in resolution than your "5m hill every five meters" example. Second, at some point we's be talking about mole hills which may block an ant's line of sight, but we're not simulating ants, so that level of detail is completely irrelevant for our task, generating valid simulation results. The current Steel Beasts V4 engine can handle road embankments and similarly small detail without problem, the next engine will improve on that even further, but we don't need to become much better because functionally the current resolution limit is sufficient - we'd just like to have nicer-looking infantry trenches and road ditches.
Yes.
With version 5 we'll be introducing a new, more capable sound engine. Until then you're stuck with stereo, unfortunately.
In any case, I hope that we'll be able to make certain parts of the AI better that will help reducing the severity of traffic jams ... in version five.
The way I see it, the easier we make it to move big formations, the bigger formations you will be tempted to put into your scenarios. ;)
Seriously, up to this point all the things we did to improve performance basically resulted in customers making bigger maps (unless restricted, like the Personal Edition) with more units and more parties until performance dropped again to the point where they are dissatisfied again. Better AI as demanded will require more computational effort. Yes, we'll multithread a lot more in V5, and that alone will widen the neck of the CPU bottle considerably, but if we allow for four simultaneous threads to run everything instead of the current one thread, and the AI will then require twice as much CPU calculations as before, you'll get only twice as much perceived performance out of the new version. At which point you'll be tempted to add another party of combatants (plus layers of civilians) to your scenarios to make things more interesting.
Feels a bit like playing Diablo - you loot monsters for better weapons to help you kill more and better monsters that drop more and better weapons to loot, so you can kill even more and even better monsters that drop more and better weapons to loot. Progress!
On one hand I'd say that we're making progress about as quick as I expected and we're not lagging much behind the optimistic projections. On the other, for PE users it will still take at least three more years before there's a realistic chance for a release, and there's a non-zero chance that it'll take longer.
There will be at least one more major V4 release, possibly two, before we can offer a version 5 to the general public.
The Milan on Marder ... it's complicated. I decided that we'd postpone that development until we have a code base that's more flexible. The SB V1 ...V4 code architecture was devised when we had little idea in which direction Steel Beasts would develop, and for how long. After we made the decision to enter the military training market (2002) I had always hoped for a 25+ year future, but it was very uncertain. Now that we can be relatively certain about the market in which we're operating, we are developing a new code architecture that will ensure that this software can be developed for decades to come, giving us more flexibility and ease of code maintenance at the same time, and certain performance bonuses.
Hopefully, that will then also free up the time for small side jobs such as adding a dismountable missile launcher half of the vehicles in a platoon - which currently would be a big side job.
You are right, in the current code base such a "reverse search" is impossible to do. I'll try and make sure than in the new architecture this will be made possible.
Ah.
Referring to party colors by one letter may not be the most reliable identifier, I'm afraid. Space constraints being the next impediment. Localization may eliminate the difference in first letter between (E)vent, (C)ondition, (T)rigger, etc.
Rather, I'd like to have something more luxurious in the future (=V5), e.g. you click on any such entry and it'll pop up a window with the option to directly inspect the condition, possibly marking it for change after the end of the test mode. Or have a mouse-over to create a help bubble that describes what it is/shows the name. Or something else entirely. This will be part of our user interface redevelopment project.
Of course, these are all just immature, brainstorming-quality ideas. Whether this will actually be implemented and when, I can't say at this point. But we want to implement the new GUI framework so that GUI changes will be much easier than they are right now, and while we're doing that I want to remove as many restrictions that we identified with the old code as we can to regain flexibility - including copy & paste throughout the whole user interface without the quirky workarounds or selective implementations. When the original GUI was made, we simply didn't think of the full implications if Steel Beasts would remain in uninterrupted use for 30+ years.
I suspect that this is a case where we "invent" a dismount unit that's actually the vehicle commander, so in that sense we're technically not dealing with a duplicate ID. That said, V5 is all about getting rid of these hacks and organize things properly rather than squeezing functions from the last bit available in unit status bytes.
Quote from: GibsonmSummary:No.
Is there some way to ensure Blue has priority over Green on roads?
I understand why one would be interested in this and see the justification for such a feature; alas, it's not a feature and unlikely to become one in version 4. Version 5, I see at least the potential to implement this, it's then a question of development priorities.
Advice for the moment is, reduce the amount of Green traffic on the critical routes, re-route Blue to secondary roads which are less likely to be taken by Green traffic.
Quote from: CharlieBIn my day job there is always a drive for the rapid generation of synthetic terrains for both virtual and constructive simulations, including the support to live training through synthetic wrap. There must be a better way of generating.There are, and we're working on them.
...
Lots of commonality in the experience.
Everything from seeing if your models are in the Joint Training Data Services (JTDS), to entity enumeration, to DIS / HLA, to common terrain databases, to the various network connectivity issues, ...
But most who come to me seem to think its just a case of joining a "World of Tanks" server.
If it is of any consolation, we're working on all those aspects, or have certain ideas how to tackle them. In V5.
Not an option in V4. V5 will use a different approach for a number of reasons, this being one of them.