Registered Users
  • Content count

  • Joined

  • Last visited

  • Days Won


jwilly last won the day on May 6

jwilly had the most liked content!

Community Reputation

200 Salty

About jwilly

  • Rank
    WWII Online Builder [GOLD]
  • Birthday

Profile Information

  • Preferred Side
  • Preferred Branch
  • Preferred Unit
    River Boat
  1. CRS's variable operating costs...bandwidth and certain infrastructure costs related to it, such as provisioning server capacity...don't depend on what modality a player plays. A sub only plays one modality at a time anyway, so a full-access sub would have the same operating costs as a limited-access one. Maybe things have changed, but it used to be the case that variable operating costs were a major share of total operating costs. If that's still the case, CRS might actually lose money on a limited-access sub...or maybe break even. Include in the reckoning the chance as Quincannon notes that existing full-access subscribers would switch to the limited-access accounts, much like quite a few previous-subscriber customers now are playing via Free accounts, and it sounds to me as if CRS would be running a huge risk.
  2. I think most long term players would agree that the game's fighter array is well advanced past its bomber array. Of course, one of the goals of Steam introduction is to add new subscribers to the game, and I'm sure CRS will be paying attention to what those new subscribers say would excite them the most. So I'd think a late-tier fighter set including the Me262 would be a possibility.
  3. The game is packet rate limited, not CPU limited. If a packet doesn't arrive, the CPU can't magically go out and get it. It has to run code to estimate what the packet contained. The game's packet rate is based on how many players the central servers are designed to support, and the costs of operating the game which directly drive what CRS has to charge for subscriptions. If the packet rate was say 4x its current value, then a single packet loss on an otherwise reliable connection would have much less effect. But, most players with packet loss issues have a continuous borderline QOS issue, not just a loss of a single packet one time. CRS could kick every player that had any packet loss. That'd kill the game, but it'd end movement jitters.
  4. Slight packet loss can occur in your connection or the other guy's. If it's the other guy's, you see just that one guy jittering, and there's nothing your client can do about it except try to fill in the missing packets...which is hard. If it's your connection, of course, you see all other rapidly moving units jittering. There's no such thing as packet loss "at the server". Packet loss occurs in the legs to the clients...either going or coming...basically always in the last leg. CRS has no control over the last legs. The internet backbone and the leg to the server array are easily shown to have very high QOS. That's not an excuse. It's how client-server OLGs work. Maybe someday there will be enough coding resources to write better predictive/analytic software to guess at where a player is going when no packet shows up from that player. When that player is moving evasively, though...that is, intentionally moving so as to be hard to aim at...that's a hard predictive job no matter how good your code is.
  5. CRS said in the early days that each AI position was intended to represent 10 or 20 actual positions, in an interlocking network, but they didn't have the coding resources and server power to actually do that so they went the stand-in route..
  6. AI was mis-thought at game inception. The game has allowed attackers to operate as defenders since its beginning. Attackers arrive first and camp the defenders' spawns. The defenders then have to frontally attack the campers. That's dumb as a design of a supposedly realistic tactical game. Instead, the attackers should be prevented from getting to the defenders' spawns for a period of time sufficient to allow defenders to get into actual defensive positions. Victory should be gained by pushing the defenders out of their defenses, not by camping their spawns. The period of attacker hold-out should begin upon attack commitment. The number of attack commitments permissible at once should be related to defensive population. Holdout should be implemented by impervious AI. That AI should rapidly fade out when the holdout timer expires. It should be possible for defenders to set up in AI positions. Superposition of a live defender on an AI position should cause that AI to delete.
  7. We've been doing automatic translations at my work for a while now. We've found the general accuracy to be good, and only a few instances of technical terms and homonyms that are incorrectly handled. I'm no coder, but doesn't this Google API provide means to do that across a wide range of languages? https://cloud.google.com/translate/docs/
  8. There have been lots of opportunities over the years to listen to what CRS tells us about how the game is designed. Some people choose to so listen. Others aren't interested in what CRS tells us because they know better.
  9. The stats that matter are the ones CRS uses for design. They design for side vs. side lethality balance...not just AA vs. infantry. Gophur once commented that AA with armor would be highly gameplay-disruptive as a camping weapon, AA without armor works fine as AA, and not being able to deploy AA for AA purposes within rifle range of enemy infantry isn't high on CRS's priority scale. Of course, that was a number of years ago, and maybe CRS thinks completely differently now.
  10. A key design principle for a game of this kind is that efficient killers have to be readily killable...most often by a modality they are effective in killing. AA is very effective at killing infantry. So, the original CRS team designed AA guns so that the most common infantry type, riflemen, could kill AA guns. There's always been demand for game elements that are effective at killing, but are less killable themselves. It's human nature in a game like this for players to want to kill and not be killed. CRS has always ignored that demand, since it would destroy the basic design principle of the game: everything is killable in proportion to its ability to kill.
  11. My understanding is that capability would involve major changes to the game engine, much greater in work-scope than just modeling another set of vehicles. If you want to run a recon team as a driver, take an infantryman as the observer-rider. Or, run two accounts yourself.
  12. I actually agree with rodsantos' comment to do the M3 first. I think all of the existing incomplete sets...at least for ground weapons, for which the coding and resource hurdles are lower...should be completed before we start more. The Jeep/Austin Tilly/Laffly V15R/Kubelwagen recon vehicle set will be new. The SdKfz 251/Windsor Carrier/M3/Lorraine 39 APC set is missing three elements. The French 50mm/German 50mm/British 2 inch/American 60mm mortar set is missing one element. The LMG set is missing an element, which may already be modeled. The HEAT RG set is missing three elements, two of which are already modeled. I think there might also be priority for the first SPAA set, because it's needed to balance the introduction of new, more-lethal kinds of aircraft ordnance that I think Scotsman and Hatch have ready to go. That set should involve modeling the Laffly S25TL truck, a new version of the existing Morris truck model, and a variant of the M3 HT model, plus a variant of the Bofors 40mm, a variant of the Hotchkiss CaMle 39, and new models of the 20mm FlaK Vierling and the Maxon-mount quad .50 M2HB. AFter that, it'll be time for the recon vehicle set. If the Steam intro goes well, it should be possible to add modeling resources, and it'll go quickly.
  13. The French would get the Laffly V15R 4x4 reconnaissance car. Extensively used for recon and coordination from pre-1940 onward.
  14. I think among knowledgeable players there isn't doubt that the MG34 could be fired from the hip. The questions at hand, instead, are: 1. How does reloading work? In videos of the MG34 reloading process, it appears that two hands are needed. If the weapon is in the air, it must be supported. As shown in the video we just saw, the carrying strap for hip firing is attached to support only the breech end of the gun, with the muzzle end supported by the left hand...but the left hand is needed to participate in the loading process. And, actually the process requires three hands if you don't have someone there to hand you the full canister, since the norm for German LMG soldiers was to carry them in a rucksack or combat pack that obviously had to be worn or carried by someone..and if it was on the back of the LMG soldier, he couldn't effectively reach over his shoulder into it with one hand while holding and loading the gun. That makes reloading a two man operation, or requires that it be conducted while sitting or prone. 2. What's the payload of the LMG soldier? What's the weight of the gun plus all the allocated ammo canisters? Are all of the other infantry types allowed that much payload? 3. Could a real infantryman run or jog normally while carrying an MG34 in hip firing position? How about rapidly turning? In ordinary life, it's quite possible to lift and handle loads while relatively stationary that would practically prevent the handler from running or rapidly spinning. 4. Does the game code deal with the issue of running through doorways and halls while carrying a metal object that sticks out horizontally a meter in front of you? What are the odds that a running soldier in that configuration in real life would make it into a building and down a turning hallway without jamming the gun barrel into a wall or doorframe, thereby coming to an abrupt and violent stop? Of course, all of these questions pertain to other nations' LMGs, automatic rifles and other infantry weapons as well, at least to some extent. Realism should apply to everyone, not just be an excuse for nerfing one weapon. I think reasonable critics of the current questionable situation want realism for all weapons. For sure I do.
  15. That's the reason for the 750 milliseconds...to carefully tailor the mechanism so it only applies for bombers that are powered into the target with the bomb release a few hundred milliseconds before impact. Maybe some testing would show that 250 milliseconds would be enough. I think a 750 ms time window would exclude the intending-to-pull-out-but-killed-on-the-way-down instances you outline, but if not, then the time window is too long. It should be possible to identify a time window that will almost always distinguish bombers that suicide into targets, from those that are on a different path from the bomb and are killed almost simultaneously with the bomb impact. An alternate approach would be to define a minimum free drop time before impact, or the bomb fuze doesn't actuate and the bomb duds. There is documentation for that as a realistic approach, but I think it'd be more gameplay-disruptive.