Jump to content

Splash

Members
  • Posts

    883
  • Joined

  • Last visited

  • Days Won

    18

Posts posted by Splash

  1. Beautiful !

    Photoshopped ?

    Thx

    I edited out the LOS height tank clock and AAR pane in the corners. Nothing else. (I wish Alt-H worked in AAR.)

    I was experimenting with artillery smoke in a tweaked version of the Camp Hornfelt Tactical Movement sce, and was struck by the effect of the sun through the smoke. Thought to myself, "Self, you gotta get a shot of this."

    If this is an unfinished implementation of particle effects, I'd like to see what they were aiming for.

  2. Well, I'm pretty sure I got the bumper number wrong, but I tried to do it for the first tank in 1st Platoon, B Coy, 2/34 Armor. If anyone points out an error, I'll gladly fix it.

    And yes, it will work with Desert, Woodland and Winter. Just copy and drop the file into the corresponding folder(s) in the us mod folder and choose us2000 as camo in the mission editor.

    Merry Christmas and thanks for your service.

    SS_18_55_52.png.1cef29a0e26774d6ec647c93

    SS_18_55_52.png.1cef29a0e26774d6ec647c93

  3. Well, you're welcome to that file if you want it. It took, literally, a few minutes to work up.

    But I'd like to do an accurate one. Unfortunately I don't have a good grasp of the Army symbology to make it credible. What would the bumper numbers be? How many stripes on the barrel? Any emblem on the turret front?

    What does 11> denote, anyway? 2nd Platoon, A Company, 1st Battalion? ??

  4. First, this discussion should probably be moved to the mods forum.

    When you speak of the dds file for Gimp, are you talking about the plugin you downloaded as a zip?

    You don't open that with Gimp. That is to be extracted then dropped into the indicated folder. Once you've placed the plugin in the plugin folder of your Gimp installation, you'll then be able to open, edit and save dds files with Gimp.

  5. the .dlls go in the Gimp2\bin folder, and the plugin file goes in the Giimp2\lib\gimp\2.0\plugins folder (I think). Should be a simple drag-and-drop, so I'm not sure in what manner you're computer won't "let" it happen.

    Maybe something with admin permissions? Are we talking Win7 here?

    Anyway, is this what you're looking for?:

    SS_18_23_38.png.0301bb373417a94d35856109

    SS_18_23_38.png.0301bb373417a94d35856109

  6. Grenny's solution "sucks" :wink2: because your wayward unit's call sign will be different depending on where it spawns. At least my idea makes the unit's call sign constant.

    If you're looking for 2A, finding 3C isn't quite right, is it?

    Attached is a small test run based on a mashup of my idea and Hedgehog's.

    See if that doesn't at least get you on the road to what you want.

    test_zip.9f70c5d66fe1fd0ed3a0ee8e1c1e6d1

    test.zip

  7. Won't they still appear on the map once they spawn? I'm trying to force the player to find the visually only.

    Well, yes. But with both approaches, they don't spawn until they COULD be seen by your searching unit.

    I suppose it's imperfect in that just because they can see you doesn't mean you can see them. But realistically, they're not going to hide from you, are they?

  8. This might work:

    Place your "stranded" unit WAY off-map. Choose a spot ON the map where they might be stranded, and use the LOS tool to get a sense of field of view from that spot. (would see farther on a hilltop than in a valley, for example) Make a region about that size. Repeat for one, two or more other possible locations (for the randomness you want).

    Now draw a "jump to end if ..." route from your off-map "stranded" unit to each of those regions, and make the condition for the jump to end be a presence of friendlies in that particular region (don't use "known") plus a variable.

    If I'm figuring this right, your missing unit will only appear when you get close enough to be seen -- assuming the randomness variable is also met. If the variable is not met, they won't be there and you keep looking.

    I'm assuming this isn't some sort of wander-in-the-woods-blind-man's-bluff sort of thing, so you'll probably need to add something the "jump to end if" conditions to correspond to whatever intel you have about the missing guys.

    If you don't want your lost unit visible even off the map border, maybe you could add a "spawn if" to the stranded guys that matches each of the jump variables, but that's getting complicated and I don't think it's necessary.

  9. Well, yeah. Thanks.

    I probably should have mentioned I know my way around the mod folders, themes & etc. even with the new caching squirreliness.

    Modded skins are ignored for these "attachments"; the default is loaded. Do you see something different?

    I might add that the miclic shows this behavior, too, in addition to the M1 mine plow and the Biber's bridge. Haven't checked others (mine roller, etc) because I don't have modded skins for them.

    EDIT: Let's add the MT-55 to that. Zipuli's Finnish version gets the modded hull but carries a green Soviet bridge.

  10. My apologies. It seemed to be exactly what you were saying: "(placing a desert skin in a desert mod folder will still oddly have parts of the skin drawn from somewhere else)"

    I used the TC unbuttoned view as an illustration of the fact that this type of behavior has always been maddeningly present. I looked at the linked thread, and it seems to be a similar thing.

    But the more I think about your case, the more I think it is a bug.

    For no rational reason, the T-62 is drawing its external ammo boxes from another file. I'm guessing it's the default woodland folder and something has been overlooked in programing where the sim looks for the texture for that part of the model.

    As another example I ran across recently, the Biber pulls its bridge texture from a file other than the BIBER.dds file in my mod folder. Probably the same glitch.

    Hopefully eSim will have the resources to look into it.

    EDIT:

    I just want to follow up by saying I'm pretty sure these are two separate issues you've raised: The cacheing issue of camo changing with the theme in the 3D view; and the pathfinding for textures on certain pieces of certain models.

  11. Well, there are quite a number of models that draw textures from two, three or more different .dds files. If you don't have a modded version of every referenced file in every mod folder you use, you'll get the stock one.

    For example, the TC unbuttoned view in the Leo 1 calls for leoturrettop, an older Leo1A5DK file for the engine deck and gun barrel, and yet another (leo2A5intDK I think) for the hatches. Modded versions of all three must be in the de mod folder, or the game goes looking elsewhere.

    It took me forever to figure out why I still had Danish camo on the gun barrel and an off-color loader's hatch despite all efforts to the contrary.

  12. I can't speak to the "mixing and matching," but there's a post or two around somewhere about this. IIRC, the new version made a change in cacheing.

    If what you are doing is "viewing" these units in the 3D world after placing them on the map, rather than actually playing the scenerio, the anomolies you describe above WILL happen if you don't follow a certain order in the process.

    You have to first change the theme. Then change the camo nationality. Then place the unit.

    If you place the unit first, it will keep the skin from one "viewing" til the next, no matter what theme you apply in between.

    The sim will, however, load your chosen nationality/skin if you actually hit "test" and run the scenerio.

    It's a real drag when trying to check skinning projects.

×
×
  • Create New...