Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Ssnake

  1. We're better than I thought, it seems.
  2. Well, it was literally a "no budget" production. Then we advanced to a "shoestring budget", which was already a considerable improvement. These days we have about seven programmers working, three full-time artists, paid beta testers, and more. So I'd consider us as "still lean" but otherwise sufficiently funded for sustained operations. All this thanks to organic growth, and that thanks to your continued support. Yes, it is true that there once was a texture for, I believe, an Unimog truck (or a MAN KAT I, not sure which). It was planned to go into the final update but the artist couldn't finish certain model changes due to a wild story involving him helping out a neighbor moving house, a non-trivial amount of narcotics hidden in the furniture, a police raid on the moving van, extended pre-trial detention, ... at some point I gave up trying to keep tabs on what was going on. Another artist dropped out to become a professional spammer, yet another artist told other wild stories that I don't want to rehash. Let's just say that not every artist made it into the team. But, at least the Unimog eventually made it into SB Pro still (well, the ambulance variant is still pending).
  3. No. There were of course of lot of ideas what else could be done, and much of that went later into SB Pro, but the biggest change that happened between the first demo version (or maybe even shortly before it) and the 1.0 release was the total make-over of the sounds. Neither Al nor I had realized how much of, literally, a game changer good sounds were until Volcano came along and showed us what was possible, and I think that the initial reactions from critics and players alike demonstrated that people took notice.
  4. Right-click unit ... Options ... Status ... Blind (or impotent, if you like them to shoot back but do no harm)
  5. Any specific reason why you removed the ammo from the Armatas, rather than simply setting them to Blind status?
  6. With brass casings, I suppose this is the equivalent to lap loading taken to the extreme, but it's not inherently unsafe. The advantage is that you don't have to unload the gun if the commander has a change of mind or the target disappears. That would strike me as the one significant advantage. It may also be a reflection on legal regulations in the Argentine Army. Maybe there is a general directive that the gun must not be loaded at any time except immediately before firing; in that case, that's what such a regulation will get you. Or unloading guns is forbidden, or made very uncomfortable ("to unload the gun, request form sheet 1893-C/2(III) in triplicate from range control, fill it out using CAPITALIZED LETTERS, and hand the white copy to range control, the pink one to ammunition handling, keep the green for your records, and file a gun unloading report no later than 0800 the next day with written testimony of the turret crew and their next of kin").
  7. I don't remember anything specific, certainly not an unreleased expansion. Remember, up to 2009 Steel Beasts was the product of but a single programmer, and we had about only one or two artists at any given time, Volcano for sound, and then me for customer relations/tech support/beta testing etc.; imagine a lot of 16 hour days for a lot of people for quite some time. If we had had the time and energy to prepare an expansion, we would have released it. Almost nothing was ever wasted during that time. The exception are the menu backgrounds that I added to the video. We ultimately rejected them because they turned out to be too inflexible for a changed manu structure (note the "Map Editor" entry in the wrong font and without the embossing effect), or because there was no coherence in the art style (camo pattern for the main menu, render shots for some elements, a simulated CRT for the options, ...)
  8. Verschleppen could also be translated as "dragging one's feet" or "delaying a process" (Verschleppungstaktik is even a viable legal strategy that was mastered by Big Tobacco as the most prominent case), but in this case it refers to the lateral vector component caused by one's own vehicle movement while firing the gun ... and the compensation thereof.
  9. My 141% where honestly earned with random chance overlapping a dead and a live target, not by deliberately lining up a dozen vehicles behind each other, or using 3P or KETF rounds. I'm not going to risk the legend, however. It would probably require a lot of retries (although I'm confident that I could still do it, given the right circumstances.
  10. I summarize this under "Backsteering" (negative feedback loop) even though that's slightly imprecise as the backsteering does a bit more than this; Verschleppungskorrektur alone is more like "lateral inertia vector compensation". (...and for once, German needs only 24 characters to describe a thing while the shorter English needs 35 - hah!)
  11. Okay, I took what I could from what you sent and made that report #8074.
  12. From what I'm seeing in the video, the lead isn't technically "acting up" but behaving as designed; maybe that design is slightly wrong if the M1A2 SEP received a fire control system upgrade to include the equivalent of backsteering (as your email suggests), but given a 1.5 seconds sampling duration, stopping the vehicle from full speed within that sample duration must deliver the kind of deviations observed (except maybe that one freak shot in the middle of the video). Say you have a sample rate of 5Hz, a sample duration of 1.5 seconds, you'll get 8 samples where the own vehicle speed enters the ballistic computations like this (I'm going by reducing energy from the moving vehicle at a constant rate, not velocity), Sample 1: 40.0 kph Sample 2: 37.4 kph Sample 3: 34.6 kph Sample 4: 31.6 kph Sample 5: 28.3 kph Sample 6: 24.4 kph Sample 7: 20.0 kph Sample 8: 14.1 kph Sample 9: 0.0 kph Average of samples 1...8 = 230.4 : 8 = 28.8 kph. This assumes the own platform comes to a full stop just before the 9th sample displaces Sample 1 in the calculation of the moving average) when you fire. Even with backsteering added to increase overall precision, as long as you build a moving average of 1.5 seconds there will always be a 1.5 seconds delay before the moving average is clear of non-zero velocity movement (and thus of turret angular motion to compensate for it since, technically, we're measuring samples of the turret turn rate here; I used velocities for simplicity, just to illustrate the principle). With samples 10+ all being zero, of course the calculated average quickly drops off to 23.8 kph, 19.1, 14.8, 10.9, 7.3, 4.3, 1.8, 0, 0, 0, ... Now, if the sample duration were not to be 1.5 seconds, or if the vehicle velocity isn't part of a moving average calculation, the picture changes of course. That's why I'm asking for such details.
  13. So, the conclusion is that the system behaves wrong with a blind/no commander (IOW, that's the bug), but everything else works as it should?
  14. The fastest machine in my household is now a notebook (i7-9700K, RTX2070M); the second-fastest machine is another notebook (i7-8700, GTX1080M), the still-adequate machine on which I can run Steel Beasts 4.1 is a six year-old desktop machine (i7-4770K) that received a memory(16->32GByte), and a graphics card upgrade (GTX980). So, notebooks can be good gaming rigs (if pricey) these days. I wouldn't bother with them if I weren't forced to travel, and demonstrate our software occasionally.
  15. Everything, really everything is better now. I only added this on special request and because it was super easy to make.
  16. The Lecleo is mostly a marketing gimmick to show that they can merge the vehicles after merging the company.
  17. a. this is entirely off-topic b. looking at inter-human relations strictly from a commercial/transactional point of view is a rather bleak philosophy. Maybe "it works" but I'm not sure I would want to promote this attitude.
  18. Ummmm.... yea, thanks. There's a bit of a spectrum between being nice, and being a boot licker. The basic lesson is, if you "win" in a marital dispute, you still lose.
  19. Okay, so just that we're on the same page. Fire Control Systems may sometimes behave slightly unexpected in certain extreme cases. The way I understand it, the M1 does not make a distinction whether the turret's turn rate is caused by the own platform's movement, or the target's movement, or both. They get conflated into a single lead angle. (Contrast this with the Leopard 2's concept of the Backsteering/negative feedback to compensate for the own platform's lateral movement, or the fact that you're supposed to press dynamic lead only if the target is, in fact, moving (otherwise: Leave it off)). So, if there is a rapid change in the tank's own movement and if that rapid change happens in a shorter duration than the moving average of the turret's turn rate sampling there could be deviations that result in a miss. Not saying that this is exactly what happens here, but I'd like to rule it out before sending the programmers on a wild goose chase. Another question would be how long, exactly, the sample for the moving average calculations really is in the M1A2 - 1.5 seconds? two? 2.5? Our sample rate is higher (=every frame, I believe) which should actually result in a better quality overall, so we need to make sure that the sample duration is correct. Even then, if the tank comes to a full stop in a second and if the sample duration is 1.5 seconds, you'd still have a third of the sample with the tank moving at full speed, and two thirds of the sample with the tank moving at half speed, and only the newest samples will have "zero" as the own platform's movement rate. So this is what we need to disseminate before we can decide that something's really wrong, and if so, what needs to be done to fix it. If you could help us with that, that would be super.
  20. I'd expect that machine to perform at least as good as my new notebook, and that ran the 4.0 benchmark scenario (converted to 4.1) with no less than 55 fps, so it qualified as the first computer that I could test as "great" for SB Pro PE 4.1. Maybe I should install 4.0 on it and compare the framerates, so we have a baseline how much the engine efficiency was improved from 4.0 to 4.1...
  21. I would not approve of intentional lags in the user interface, unless there was a functional reason. Right now I can't remember a reason why such a lag would have been "built in". Thanks for the feedback. May I ask about your hardware, specifically the graphics card model and driver version?
  22. 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.
  23. Well, my interest ends at about the point where the first propellant case goes off inside the crew compartment. Whether a fast or slow chain reaction follows, who knows. Maybe it is as you say. Maybe it depends on additional factors, e.g. if multiple cases are ignited (near) simultaneously. In the Leopard 2's hull bunker each round is surrounded by an aluminum tube which arguably fulfills the same role as an individual round's brass shell casing. The exposed parts are the projectile heads themselves and the aft caps. From the photos of Turkish Leopards in Syria we can see that this is no absolute protection; if there's a direct hit that might ignite multiple rounds simultaneously, clearly the gas pressure build-up is so rapid that the turret gets lifted from the hull; in fact, some hulls ripped apart at the welding seams, so it's obvious that it can be a very violent event. From the cases where M1 ammo bunkers were hit and we saw the cover plates flying, my take is that even if you have 17 rounds in close proximity an explosion is not guaranteed, but a 30...40 second long intense fire can just as well happen. So, examples of similar events that show different behavior. The conclusion for us is: It's a random selection of what kind of effect we show. Maybe we can reduce the chances of spectacular effects if there is little ammo left in a future version; if it's something that need to be done on a per-vehicle basis (something that we still need to find out) this may take a good while before it happens. It's certainly not a top priority thing, to be honest. 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. Yes, I can get now consistently 55+ fps in our 4.0-turned-4.1 benchmark scenario with a new notebook, but that requires an absurd investment in top of the line hardware (RTX 2070, i-7 9700K, 32 GByte RAM). We squeezed out of the old engine what's possible with version 4.1, and while it's good progress over 4.0 I still can't say that I'm entirely satisfied. I want everybody to be able to experience solid 60 fps even in big scenarios. That appears doable I'm told, but it will absorb a fair bit of attention from our team to pull it off.
  • Create New...