Jump to content


  • Content Count

  • Joined

  • Last visited

About Captain_Colossus

  • Rank
    Senior Member

Recent Profile Visitors

5,589 profile views
  1. i do not think it would be worth the erffort. the early playable leopard 1 tanks have dimensions closest to the smaller russian tanks, but not the armor model, nor the ammo options, which of course you cannot change. with a little imagination, the df-30/df-90 and centauro piranha based vehicles look similar to some chinese wheeled ifvs and mobile assault guns; the non heavy armor versions of the m1/m1a1 probably look closest and may arguably perform closest to a chinese type 96 with some cosmetic changes, i do not think however anyone will have the skill to mold a playable nato tank to look like a russian t-90 or armata tank by messing with alpha channels- it works better for minor changes, extremely difficult to make a box turret look pan shaped with reactive kontakt armor attachments, say
  2. Version 1.0.0


    M60A3 desert skin for Egyptian forces (ver. 4.161). Includes optional stowage file, which renders the Egyptian flag on ID panels, although Steel Beasts will sometimes display the panels at 45 degree angles. Place all files in your Egyptian mod folders. Note: the program will render conspicuous large blank white ID panels which look a bit out of place if you elect not to use the included stowage file.
  3. Version 1.0.0


    M60A3 desert skin for USMC forces (ver. 4.161). Includes optional stowage file, which renders USMC divisional standards on ID panels, although Steel Beasts will sometimes display the panels at 45 degree angles. Also includes blank decals file, which prevents the program from rendering early US Army markings on the ID panels. Place all files in your desired US mod folders. Note: the program will render conspicuous large blank white ID panels which look a bit out of place if you elect not to use the included stowage file.
  4. notwithstanding the effects on tanks, it's the impotence against soft targets that is rather noticeable. just a couple days before this thread popped, without any exaggeration i tested a scenario where several rounds of enemy tube artillery landed two or three meters within civilians standing intermingled with my technicals out in the open not behind armor- and no effects on any of them after several rounds landed within the mix.
  5. not that i know enough to dispute that, but the card is NVIDIA GeForce RTX 2080Ti, 11 GB . other than the sky turning colors, the scenes do not appear to be having issues at all. the scenes are rendered without stuttering, they are fluid. furthermore i have also seen it with just a flat water and no ground clutter and detail settings to factor into it
  6. unknown mechanism, very intermittent- seemingly randomly the sky will change to a monochrome color, this seems to occur when in the TC view only, panning around will may force the color disappear and reappear (as you can see from the inside of the T-72 tank commander's hatch), but it is always temporary and likely does not show up again for the rest of the session
  7. i have steel beasts with several sound mods running in a new install of windows 10 - no issues like you describe. having said that from a user standpoint and not a software developer, there is nothing that Windows 10 offers that I would have upgraded for were it not preinstalled on my new system, it seems like change for the sake of change in order to sell a new product which is basically microsoft' s scheme to collect as much as data as possible on customers. the file structures and user interface isn't an improvement, other than occasionally activating cortana by mistake, which I have no interest in using, it's just different rather than better. then I can guess what the next iteration of windows will be a similar sort of thing- repackaging a product that was more or less perfect from a user interface standpoint when they rolled out windows xp. every version since then was just charging more money for a 'better' newer version
  8. the map already has grid squares overlaid on- across the entire map. again, this is only to make the grid squares functional. how someone would use it is up to them- if they want to use it in select areas, that's fine. like i said in the beginning, the point is to make it scalable and user defined however they wish- say a 10 x 10 grid, or 5 x 5, or perhaps 3 grids, 1 that is 10 x 10, 2 that are 5 x 5. in my example above, this is just showing what it might look like. it's not a prescription. in this example i am using a larger grid to help visualize the key areas in relation to areas that may not be as relevant, using a large grid does not mean that all grid squares need be functional and have some behavior assigned to it, but it allows me to see things in relation to one another. so again, the map already inherently has a grid overlaid across the whole thing, there is nothing unnatural about this.
  9. i don't mind if people want to discuss the merits of alternatives to what i'm proposing, as long as what i am suggesting doesn't presume to be thrown out in the debate. the whole point of my grid is to plan the computer opponent's moves, which doesn't have the benefit of company grade or field grade officers making decisions in real time against a human who does- to reasonably orient the computer's forces to the map, to predict and to react to conditions in the future, and to refine those behaviors. it's not in itself a doctrine or a template: it's simply to orient those routes and any planned movements and behaviors. it can facilitate a detailed plan with contingencies or behaviors whether they are in the field manual or not (for example, i want to simulate a guerrilla unit failing a morale check, panicking and retreating to different areas). in sum, the grid allows the mission designer an easier way to visualize future events and plot more complex behaviors rather than sit in place die or move forward on only one or two routes through a kill zone like zombies. in a way there already is the map grid, it's just that the scenario logic does not recognize the inherent map grid squares for purposes of defining functional areas, nor are the grid squares resizable.
  10. if i understand your question, it still retains the waypoints and routes as the inherent system. it doesn't change anything from what already exists- you can create an area now and plot movements to or from that area, all it does is permit more areas to be drawn at the same time and overlaid wherever you like
  11. i have been scripting behavior for computer opponents using a area grid system- a grid overlay is created out of several rectangular areas, and then computer behavior and movements are plotted based on conditions of each individual area. for example, a tank platoon in area 5 will embark to area 7 if an enemy tank unit is detected in area 23. in theory this creates a reasonable system which allows a computer opponent to react to conditions anywhere on the map. it can be a bit tedious to create these grids by hand though- if this makes sense or seems like a good idea, i request a feature that the program can automatically create grids without having to size and place every individual square by hand this way (eg., a user defines the size of the grid, say, 8 X 8 50 m squares, or 10 x 10 1km square grids, and so on, and then the program generates the grid).
  12. the iraqi artillery is much less likely to be on call, it is pre-registered to hit assumed routes against an attacker attempting to negotiate the typical defensive setup of a minefield then a sand berm, perhaps another minefield, then the static positions behind that- it worked reasonably well against iran, in 1991 what little was available was very in accurate and sparse
  • Create New...