-
Posts
697 -
Joined
-
Last visited
About Ripcord
- Birthday 10/04/1968
Personal Information
-
Flight Simulators
P3D, FSX-SE and DCS Various
-
Location
Houston TX
-
Interests
Flight sims mission & campaign dev
-
Occupation
Sales Operations, Finance, Analytics, IT
-
Website
https://ko-fi.com/ripcordmods
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Ah hold on, a UH-1 will pick up that stationary JTAC infantry troop - you gotta land right on him almost, but he just disappears and the Huey flies off. EDIT: actually the UH-1 will land right on them and kill them. So that's an interesting twist.
-
I would like to add 3 observations/gripes.. 1. So, do JTAC infantry objects not move? What's up with that? I guess that means no way to embark/disembark a JTAC group? 2. We have RPG-toting insurgents... Can we not get this as regular infantry ground guy? I mean, it's just a different model, really, same in-game logic. 3. Is there no way to allow for 'embarking' a downed pilot? This seems like such an obvious feature to have, after all these years... You need a lift? Nah, I'm good...
-
I disagree, to some extent. Sure as mission builder, you have to have specify where the embarkation takes place, but you can still offload them wherever. And that destination could be dynamic. Not that ground troops are super effective or anything in terms of firepower, but they can serve as a package to be defended, delivered or recovered in a mission. And, maybe the mission involves getting your vehicles across town to pick them up... so there is the potential of additional challenge there, particularly when the player has to pick the route to get to them, and deal with random threats along the way. The challenge is getting from point A to point B, and how to do that is still left to the player or tactical commander, and whatever pilots are in the mission. Of course, it would be far better if we could just embark troops on the fly, in game, without pre-programming anything.
-
I was experimenting a bit with this. I learned the LAV-25 only carries 6 troops. So if you have a group of 3 LAV vehicles, for example, then you can still take up to 6 ground pounders per vehicle, but as stated, the ground pounders have to be placed in groups of 6 or less. Also I see that the AAV-7 does embark up to 21 ground troops.
-
You wrote a User Story. Are you in software development?
-
One problem model out of fifty... need help
Ripcord replied to Ripcord's topic in Static/AI Mods for DCS World
OK upon further review, I think perhaps there may have been some interference, for lack of a better word, between mod folders. I removed the old one and left the new one, which I have been working on. And guess what.. now that one building shows up and looks good. So yeah - now I feel stupid, but also relieved. Thanks again for your help and your cool mods to learn from, sir. EDIT: Actually, TeTeT please reach out if you are interested in testing these things. Just armed buildings, but kinda fun. -
One problem model out of fifty... need help
Ripcord replied to Ripcord's topic in Static/AI Mods for DCS World
Please give me a little more context on what you mean by configs. If you are referring to the lua code etc, all of that is good. Remember I had them all working not that long ago. And other 49 still work great. That's not it, but I'll revisit just in case. What I changed out was the model in blender. -
I used the FARP template to create armed static buildings/houses, 50 of them in total. There is another thread about them in this section, you'll find it. Had all 5 of them working in game, just needed to clean up the textures. So I went through and redid many of them, and for many object, I'll say this effort did result in real improvement. Except now, for whatever reason, I cannot load one of these objects. It shows up fine in the mission editor, when I view it (see attached image). I am trying hard to determine what setting is different with this one, vs the other 49 objects - reviewing the blender files, etc. Nothing helps. What in the hell did I do? Ideas?
-
There are couple of buildings, I guess, that offer some interesting design features that might lend themselves to things like this: Fun with Insurgents
-
I think this is a good place to post a correction (possibly). Testing has proven this to be exactly backwards - for some reason, and I've had ongoing debates with ChatGPT on this (he is not convinced), it seems like the first angle and second angle are reversed. Or in other words, for a rear-facing gun placement aimed at 180 degrees, to have coverage from 135 degrees to 225 degrees, you want to go in COUNTERCLOCKWISE order, and not clockwise. So this (below) is wrong, according to my testing. For a rear-facing MG: GT.WS[2].reference_angle_Y = math.rad(180) -- gun faces rear GT.WS[2].angles = { {math.rad(135), math.rad(225), math.rad(-10), math.rad(30)} -- covers rear arc Instead, this seems to produce the correct behavior (below): GT.WS[2].reference_angle_Y = math.rad(180) -- gun faces rear GT.WS[2].angles = { {math.rad(225), math.rad(135), math.rad(-10), math.rad(30)} -- covers rear arc Here is a building that only fires forward and rear, covering a 120 degree field of fire each way - in testing I park trucks on the left and the right, and the building does not engage them. --DCS Middle Eastern Armed Building template-- GT = {}; GT_t.ws = 0; set_recursive_metatable(GT, GT_t.generic_stationary); set_recursive_metatable(GT.chassis, GT_t.CH_t.STATIC); GT.chassis.life = 50 GT.visual.shape = "MEArmedBldg10"; -- edm name GT.visual.shape_dstr = "s3_crush" -- using destroyed shape model from existing object GT.CustomAimPoint = {1,1.5,1} --Burning after hit GT.visual.fire_size = 1.2 --relative burning size GT.visual.fire_pos = {0.5,0,0}; GT.visual.fire_time = 600 --burning time (seconds) GT.visual.min_time_agony = 20; GT.visual.max_time_agony = 120; GT.sensor = {}; set_recursive_metatable(GT.sensor, GT_t.SN_visual); GT.sensor.height = 3.0; GT.sensor.max_range_finding_target = 1000; local __LN_PK = {}; set_recursive_metatable(__LN_PK, GT_t.LN_t.machinegun_7_62); __LN_PK.connectorFire = false; __LN_PK.distanceMax = 800; for i=2,10 do -- 1000 rnds __LN_PK.PL[i] = {}; set_recursive_metatable(__LN_PK.PL[i], __LN_PK.PL[1]); end __LN_PK.BR[1].pos = {1,0,0}; GT.WS = {}; GT.WS.maxTargetDetectionRange = 1500; -- Reset inherited angles __LN_PK.angles = nil __LN_PK.angles_mech = nil -- Reset other rotation fields to prevent leaks __LN_PK.reference_angle_Y = nil __LN_PK.omegaY = nil __LN_PK.omegaZ = nil __LN_PK.pidY = nil __LN_PK.pidZ = nil -- Front-facing MG local ws = GT_t.inc_ws() GT.WS[ws] = { pos = {3.5, 2.7, -1.7}, -- {x,y,z} = (front+/back-, up+/down- , left-/right+) angles = { {math.rad(60), math.rad(300), math.rad(-10), math.rad(35)} }, reference_angle_Y = math.rad(0), omegaY = math.rad(120), omegaZ = math.rad(120), pidY = {p=10,i=0.05,d=2,inn=3}, pidZ = {p=10,i=0.05,d=2,inn=3}, } add_launcher(GT.WS[ws], __LN_PK) -- Rear-facing MG ws = GT_t.inc_ws() GT.WS[ws] = { pos = {-3.5, 1.5, -1.5}, -- {x,y,z} = (front+/back-, up+/down- , left-/right+) angles = { {math.rad(240), math.rad(120), math.rad(-10), math.rad(35)} }, reference_angle_Y = math.rad(180), omegaY = math.rad(120), omegaZ = math.rad(120), pidY = {p=10,i=0.05,d=2,inn=3}, pidZ = {p=10,i=0.05,d=2,inn=3}, } add_launcher(GT.WS[ws], __LN_PK) GT.Name = "MEArmedBldg10"; GT.DisplayName = _("Armed Building10"); GT.Rate = 5; GT.DetectionRange = 0; GT.ThreatRange = __LN_PK.distanceMax GT.mapclasskey = "P0091000076"; GT.attribute = {wsType_Ground,wsType_Tank,wsType_Gun,wsType_GenericFort, "Fortifications", "CustomAimPoint", }; GT.category = "Fortification"; add_surface_unit(GT) Please offer comments or evidence if this is incorrect.
-
Another key point. The left and right thing obviously depends on point of view. So imagine you are IN the house looking out the front door. I had been doing it wrong, thinking I was looking at, or facing the object. The Z-axis value (left/right offset) is: Positive (+Z) → Right from the object's own point of view Negative (−Z) → Left from the object's own point of view
-
Also I think I have the gun angle settings all jacked up. Again, more explanation from ChatGPT... any old-salts around here can jump in an correct if something is incorrect, but I found it useful... GT.WS[2].reference_angle_Y = math.rad(150) What It Does This line defines the default yaw orientation (left/right direction) of the weapon station (in this case, WS[2]) relative to the model’s forward axis. In simpler terms: It tells DCS: “This gun should face 150 degrees to the right from the building’s forward direction.” How the Angle Works DCS uses a clockwise angle system based on degrees from front (0°): reference_angle_Y = math.rad(0) → faces forward reference_angle_Y = math.rad(90) → faces right reference_angle_Y = math.rad(180) → faces backward reference_angle_Y = math.rad(270) → faces left (or -90°) So: GT.WS[2].reference_angle_Y = math.rad(150) Means: The gun on WS[2] is angled slightly to the right of rear — facing between right-rear and rear Useful if your gun is placed on the rear-left corner of a building and should cover the rear-right approach Related Properties You Should Know angles = {{ left_limit, right_limit, down_limit, up_limit }} This defines the arc of movement for the weapon station. Example: angles = { {math.rad(120), math.rad(180), math.rad(-10), math.rad(30)} } Can move between 120° and 180° in yaw Can elevate from -10° (down) to +30° (up) maxLeft and maxRight These are soft yaw constraints for aiming AI. Combined Use For a rear-facing MG: GT.WS[2].reference_angle_Y = math.rad(180) -- gun faces rear GT.WS[2].angles = { {math.rad(135), math.rad(225), math.rad(-10), math.rad(30)} -- covers rear arc }
-
I have been playing with this yesterday and today, using ChatGPT to assist with the coding. So far, no go. In fact, here is what ChatGPT has to say after further review/discussion on the topic: Thank you — that clarifies everything beautifully. Yes, the "Armed House", "Armed Barracks", and similar assets in DCS are indeed listed under Ground Units > Fortifications, and they do not move, even though they're technically registered as surface units (not static objects). They’re a special hybrid: DCS "Fortified Buildings" Are: Surface units, using add_surface_unit(GT) Stationary (GT_t.generic_stationary), so no AI movement Equipped with simple weapon systems (e.g., 7.62mm or DShK) Have no crew, no mobility, and minimal sensors Often use simplified launcher templates like machinegun_7_62 Why RPGs Cause Trouble The standard DCS “armed building” types do not use complex weapons like PG_7V or RPG launchers — because: These launcher templates are often tied to infantry or vehicle platforms They expect behavior (like turret movement, reloading animations) that fortifications can't provide Even though your unit is a "ground vehicle", it's functionally a static target with guns, and DCS has limits on what launchers it supports in that category So I guess it is machine guns only for these objects. However any novice mission builder would have no trouble adding ground insurgent objects on foot, near or even inside these buildings, to appear when needed - using any number of triggers or just regular placement. Yeah I am working on these again. Life just gets in the way. Not even trying to improve textures at this stage, just trying to align the gunfire positions (X/Y/Z) so it doesn't look wonky.
-
Military Assets for DCS by Currenthill
Ripcord replied to currenthill's topic in Static/AI Mods for DCS World
I have thought about trying to add RPGs and/or Stingers into the armed buildings, but decided it might be better to just walk first, then try to run. -
Thanks @currenthill I saw this but somehow missed the mortars and others in this pack. I really hope ED will start integrating a lot of your contributions into the standard game.