• Announcements

    • Dodger

      Seeking Squad Leaders!   04/09/2017


      We are seeking Squad Leaders to volunteer their squads to help us test the upcoming Squad Forums system. This system will integrate squads who wish to participate into a self-sustained "forum within a forum." You will be able to add members to your squad, assign permissions, and create forums/calendar events on your own. The idea behind this system is part of our commitment to support squads as a integral part of our community. This service will be offered free of charge to all squads of World War II Online upon launch. Our goal is to offer all of the services a squad off-site forum can offer but free of charge and tied in to our existing forum service. So what do you need tested? We need willing volunteers to test the whole system - make forums, post threads, assign permissions, etc. The idea is to have several squads giving it a test run to point out any flaws before we launch it publicly. What are the requirements? We are ideally looking for medium to large squads - Ideally ten people or so plus, but smaller squads feel free to apply - and a willingness to use our platform. It's important to note (as of now - these may be included at a later date) we are unable to convert posts from a private forum if your squad previously used one, and you (or your XO's and recruiters) will need to assign individual members permissions. It is entirely possible that in the future this system will be automatically linked to the game's squad roster, but as of now developer priorities are elsewhere (1.37 and steam, w00t!) How do I sign up? PM me ( @Dodger ) on the forums, or email me at dodger@playnet.com - Please indicate your squad name and how many members you have. I will get back to you with more instructions.


      Recruiting drive.   04/16/2017

      With the anticipated influx of new players on the heels of this summer's Steam release, there is a reasonable expectation that forum traffic will increase. I'm looking for volunteers, not just to moderate, but to help answer new players' questions or direct them toward the correct answers. The forums may be a player's first contact with the game and we want to ensure that it is a positive experience. A happy player is a player who sticks around and the more new players we can retain, the more resources we will have for development.
      With that in mind, we are looking for current players with a positive attitude and posting history. PM me if you are interested.


Registered Users
  • Content count

  • Joined

  • Last visited

  • Days Won


jwilly last won the day on April 15

jwilly had the most liked content!

Community Reputation

120 Salty

About jwilly

  • Rank
    WWII Online Builder [GOLD]
  • Birthday

Profile Information

  • Preferred Side
  • Preferred Branch
  • Preferred Unit
    River Boat
  1. The latter part of Blakeh's response above has been the historical CRS response. (I.e., the first ~15 years, prior to the current Rat team.) Additionaly, the infantry collider model--the volume of the body that can be hit by a projectile--is smaller than the visible body so that "flesh wounds" to the periphery of the limbs and torso are excluded. The game concept was that flesh wounds would be taken care of by implied medics or other soldiers. The modeled hittable areas are ones for which a bullet, fragment or shell impact is eventually or immediately fatal. A bullet through an arm or leg that hits a bone or goes through any part of the torso, for instance, is not going to be fixed with a bandage and some morphine. The only wounds that are modeled are those that are eventually or immediately fatal. CRS had discussed in the past that medics could be added to the game, not to return wounded players to fighting--if medics were given that functionality, the game also would have to model a second kind of medic-treatable wound around the periphery of the existing damage volumes--but instead as a new kind of marketable gameplay. A wounded player, either before despawn or for a short time thereafter, that was reached by a medic-player and wasn't "dead" yet might be able to be saved. For a despawn on the field, attribution of the despawn status would be held for a brief time. If a medic was able to stabilize the wounded soldier and the conditions allowed rescue, the injured player would get a Rescued. All other wounded despawns would be KIA. There would have been a lot of work involved in creating that gameplay, and the resources never were available.
  2. Three key factors in game design-for-marketability are finding ways to decrease lethality; not providing effective hiding and camouflage; and achieving overall lethality balance between the sides. These are essential so that players with the most firepower don't just wipe everyone else out; so that well-hidden defenders don't just wipe out attackers; and of course so that players will play both sides. So, a weapon like this may have a lot of gun climb, or a lot of aim point scatter, or odd choices of ammo. Some game elements seem to be oddly survivable; others the opposite. Everything in the game starts out based on historical data. The game however has to be marketable, or it wouldn't matter at all how good a weapons-simulation it was. So maybe some weapons are less-faithful simulations than others by the time they get to release. I suspect from Doc's prior comments that the gun recoil force is simply calculated from the shell mass and muzzle velocity, and this acts on an overall weapon mass parameter, ignoring the presence of the recoil mechanism and the design of the mount. If you start with such an oversimplified physics model, and if you assume that because some infantry automatic weapons have recoil-climb, autocannons should as well, then a gun like the FlaK 30 could end up with quite a bit of climb. The gun's overall mass parameter must affect its game-movement, keeping in mind that this is a simplified simulation. Doc's comments might have been alluding to the inability within the constraints of the game engine's physics code to change the recoil behavior except possibly by dramatically increasing the weapon mass parameter. And my guess is that it's relevant to the matter that the ineffectiveness of the FlaK 30 model in comparison to the CAMle 39 and Bofors helps to offset the high lethality of other German weapons compared to their French and British counterparts, and therefore helps to satisfy the core lethality-balance requirement for marketability.
  3. Discussed many many times over the past sixteen years. Search out the prior threads for various proposed mechanics and game effects, and information on past CRS responses.
  4. None of the game's guns are fully modeled physical systems. The game doesn't have physics-based reciprocating barrels, recoiling within the mount against the recoil spring and damper. The game's gun models instead simulate the designer's idea of recoil effects by means of whole-gun motion parameters, based on the designer's determination of what the gun should do, possibly influenced to some extent by what was determined to be needed for the game to be marketable. I think that non-reciprocating barrel approach to modeling cannons was driven partly by the limitations of much less powerful computers in ~1999 when the game was first conceived. It also might have been the case that some of the early designers were better at achieving simulated physics-realism than others, or more aware of what it should look like.
  5. So accepting the premise that the FlaK 30 has too little lethality as a gun, compounded by the multiple shortcomings of the early-days model (hopping, bad sight, etc.): What existing Allied model needs a similar quality audit and re-parameterizing to make it work realistically and game-effectively?
  6. Certainly there were differences in ruggedness of plane designs, but a starting point for evaluation of bomber ruggedness is payload. Higher max payload = more wing root strength and probably tail strength. That's in real life. I don't know of any aspect of the airplane modeling process that would lead to a simulation-based ruggedness factor. Planes aren't modeled like tanks, where the armor has well understood characteristics and is a key determinant of damage behavior. So the damage behavior of planes has to be mostly CRS-plugged-in parameters, which presumably were originally set with some reference to overall balance requirements.
  7. Comments like this aren't consistent with the game's design concept: both sides are entirely unequal in every way that history provides, but they are very nearly statistically equal overall per CRS data mining of all the gameplay. So every expression of "the game needs to be more balanced" misses the point that the game is intentionally unbalanced everywhere, with each side having some areas where it is superior and others where it is inferior. A request that an area where your preferred side is inferior should be beefed up because it's "unbalanced" indicates either a failure to understand, or a willingness to break the game's overall-balance concept. Neither side can have all of its weaker areas made equal to the enemy, while that side's stronger areas remain stronger.
  8. The photo of course is a FlaK Vierling...4x FlaK 38. I doubt if modeling the FlaK 38 would be tops on CRS's list, but I don't know of any reason why they can't re-parameterize the FlaK 30 to make it operate as a 38. As to "balance": CRS has told us over and over for the past sixteen plus years that this game is not balanced weapon to weapon. Game balance is one side overall vs. the other side overall. It's total statistical lethality vs. total statistical lethality. The two guns are historical. They are what they are. Maybe the FlaK 30 model isn't very good...the jumpiness is entirely a modeling problem, not a simulation of anything real. But the two guns weren't equal to each other in real life. They shouldn't be equal in-game either. Any improvement of one side's lethality because they want a better replacement for something that's not as good as the other side's comparable item, has to be offset by an equal improvement to the other side's lethality. That's fundamentally how an overall-balance, realistic-weapons game works.
  9. This thread isn't particularly because of that thread, other than that the latter reminded me that I'd been meaning to write this up. As to your proposal, I don't think it would improve realism. It just would repalce an underkill situation with an overkill one. The fundamental problem is that the two-state, entire-building damage concept is way too simplified to be even close to realistic. The game needs modular- or smaller-zone construction plus a four-state damage approach for each zone. This thread was intended to point in that direction.
  10. Sometimes it looks like the game has aiming-assist code. If you aim very close at long range, the game occasionally gives you a hit. Judging by results, lots of players aren't capable of aiming close enough to benefit from the aiming assist. Other players don't try. Wayne Gretzky said "You miss 100% of the shots you don't take." Maybe my perception is wrong, but it wouldn't be unheard-of in gaming to have a small degree of aiming assist in the code to make up for the easy-to-learn but very crude AA gunsights, compared to the historical predictive sights used on many of these guns, which took two or three men to operate and therefore would be impractical to include in a game like this one.
  11. Note that phosphorus "smoke" shells, such as were carried by some late war American tanks, are not like other smoke systems. Phosphorus pentoxide, generated by combusion of phosphorus in air, is extremely toxic and corrosive to the eyes and lungs at concentrations as low as 0.1% of what's common in the cloud formed by a shell burst. Phosphorus pentoxide instantly becomes phosphoric acid on contact with moisture, including the human eye or nasal/bonchial/lung tissue. One lungful of concentrated phosphorus smoke results in a level of pain that causes physical collapse within seconds, disrupts breathing, and is likely to result in death. Exposure of the eyes, i.e. presence in the smoke cloud without a tight-seal face mask, results in profuse tearing within seconds, involuntary closure of the eyes, and blindness if not immediately treated and if death does not otherwise occur first. If WP shells are introduced to the game as a smoke mechanism, the game code also should take into account their incendiary behavior--which is a primary cause of death for infantry near the burst, who are struck by burning particles, in addition to the effect on buildings, forests, etc.--and their rapid corrosive debilitation and lethality to unprotected personnel.
  12. Smoke and HE. Smoke will be very significant for the infantry game if CRS works out how to have smoke go from a concentrated cloud to a much larger smoky area, slowly drifting, with additional smoke contributed by every explosion and fire. HE will be very significant for the infantry game as soon as Scotsman finishes his latest frag revisions.
  13. AI generated contextual sounds as a sort of audio background, not originating with another player, isn't what this game needs. This game advertises itself as every unit on the battlefield being human directed. Adding AI-selected, non-player-communicative "voice" sounds would be contrary to the #1 marketing theme. Ummm, I don't think so. If I'm operating in proximity to six other infantrymen, I don't want them all talking with the same voice, and I don't want what they say to be noticeably repetitive--which means not hearing the same message twice in a given gaming session, or even less often that that if it's significantly memorable. And, what they say needs to make sense in that moment's game context, which makes the non-repetition problem harder because it makes messages more memorable. The avatars near me would be actual players, but my client would have to treat them as multiple AI elements because the actual players would have no role in the "communication". Think the problem through...it's actually complicated to manage unique interactions with several AI elements when it's necessary to keep them uniquely identified. What the game needs is for more players to be running voice comms, so there's actual voice communication between nearby units. Death screams are fine, and they already exist. Obviously players aren't going to provide those...at least until CRS upgrades the game to that higher level of realism.
  14. Live objects in game (i.e. an infantryman or vehicle) are located at a reference point. The visual and collider models are located with reference to that point. It's that point that interacts with other collider models. My understanding is that when an infantryman moves in the world, the refence point stops when it gets X vertical distance or Y horizontal distance from a collider surface. I think the values of X and Y depend on the infantryman-position, i.e. X and Y are different for standing, kneeling and prone positions. Prone infantrymen rotate about this reference point. It's been the case since the game-beginning that when located close to a building wall, sometimes the prone infantryman's feet stick through that wall, are visible and are subject to injury. There's been discussion over the years of the "flying in formation" concept as a way to manage player-directed-AI bombers, naval convoys, trains and truck convoys. "Flying in formation" involves one player-managed live object plus one or more AI objects that automatically maintain a certain X-Y-Z offset distance from that player object, and generally operate following its lead, i.e. their AA capabilities would engage the same target as the player object if possible. For a train, the player-object locomotive would proceed along a string of terrain marker points, with the goods wagons following behind. A truck convoy more simply would have the player-object excort vehicle as the leader with the goods trucks following behind. A bomber formation would have the associated bombers arranged near the player bomber. A naval convoy would have the freighters following the player escort vessel in a specified formation. One of the limitations of a single game object is that it has a single reference point for interactions with nearby colliders. Would it be possible to think of a single game live object instead as a formation of objects? There could be significant uses of such a concept for modeling multi-player bombers and ships, but for this post, think about infantrymen. Say an infantryman's feet are separate AI objects, each with a reference point near its toes. They "fly in formation" with the rest of the infantryman's body, so they're always located visually correctly. This then allows the infantryman's primary reference point to be moved to his head. That would fix the longstanding problem with the infantryman eye point being at mid-torso. And, the formation-infantryman now would have three reference points...head and each foot. With the addition of some code for the feet to communicate to the player that he was bumping into something while trying to rotate or whatever, the clipping-through-a-wall-while-prone issue would be resolved. The existence of reference points at each body end also would make it code-possible for an infantryman prone position to follow a terrain slope, instead of remaining horizontal and sometimes clipping into the ground. Of course, I wouldn't be the one to have to write the code involved.
  15. There's been discussion in the past, and also in another current thread, that the current building technology is inherently projectile-proof at the collider level. (That is, something like a tracer may penetrate visually at times, but there is no corresponding event in collider-space that can cause damage.) Tanks of course are modeled differently...they can be penetrated by projectiles, which lose energy as they penetrate but still can cause damage with their remaining energy. Tanks are live models...they are managed by a client. Buildings are part of the environment, though of course clients sometimes impose damage on them that causes them to change to their damaged state. What if buildings and other environmental objects were modeled like tanks? They'd still be part of the environment, but their interactions with projectiles would be different. Instead of there being a second state for the building, there'd be the building-equivalent of a hulk-model representing a destroyed state. (Or there might be three progressively degraded states if the database could be expanded and another bit of state-status could be sent, and heightened realism was judged achievable.) A projectile arriving at a wall might penetrate and injure someone on the other side, with a semi-persistent wall-damage decal applied to the model where the penetration occurred. It might go through the next wall as well. An HE device detonating on the outside of a building face or brick wall might generate a cone of "fragments" of the building material out the other side. Such a project might also make large buildings modular, so that state-change damage could occur to them in smaller volumes than the whole building. I'd envision a roughly one-room volume (one story high, four or five meters wide) as the standard damage volume. One 75mm or 88mm HE shell or one HE sapper charge would be the standard amount of damage energy to destroy such a standard volume. A large bomb would damage multiple standard volumes; smaller HE shells and other explosive and solid-shot destructive devices would apply cumulative damage energy, and eventually the volume would change to a destroyed state. A modular building technology would be a precursor to progressive fire functionality, enabling new visual immersion elements, addition of fire-causing weapons, and new injury mechanisms.