Jump to content

gliderace

Members
  • Posts

    12
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://www.coldwaterdesign.com

Converted

  • Location
    Dallas, TX USA
  • Occupation
    Designer, Pilot

gliderace's Achievements

Junior Member

Junior Member (1/3)

0

Reputation

  1. Wups! Forgot to mention that the ZIP file of the probe mission is in the Repository.
  2. Hello, all! I have started a small extension of the templated mission triggers (as generated by the Battle Generator). I've made a PROBE type mission and have added variables (with generous comments) in the "init" trigger of "triggers.ini" This is meant to simply extend on the great triggers that are already in place, and also provides for random enemies and random reinforcement availability. Of course, the mission can be played "as is," but for the explorers, I have commented the Init trigger with instructions how to create more types of the same mission and change the variables. Right now, if "random enemies" is ON, you must define four different enemy battle groups and they will be turned on or off, 25% chance, per. Dead simple. Please take a look, if you have the time and I'd appreciate any comments. Thanks!
  3. Hi all! I just updated the submission to have actual ammo for the Panthers (he he he...sorry about that) as well as to enable Fog of War. As for the historical battle, the small AT team did not stop the advance, and seven rounds were horribly too few. What the team did, however, was to knock out the lead tank and have the others bunch up... This caused enough time to elapse to allow the engineers at the bridge at Amblieve to demolish it. That was the overall task: simply delay the panzers. The AT crew suffered heavy casualties and deaths, but the survivors high-tailed it out to the north. Peiper's tanks were going to take the shortcut by going over the Amblieve, but now had to go very far to the north to proceed west. It was a suicide mission. The task is to simply delay the Panthers from getting to Point A before 10 minutes elapse. If you can do that, the bridge is blown and you have won... You may die in the attempt, however....
  4. Arzok, Thank you very much for testing. I will get to adding the ammo for the German tanks (yikes! I had them in my initial test, here, but I perhaps saved an earlier version and released it). As for the OOB on this one, this is pretty much the historical parameters. Just one U.S. 57mm AT team supported by one lieutenant and a captain (oddly). The halftrack back at the crossroads was what they piled into after the gun was destroyed. Incidentally, the US AT gun only had 7 rounds for the battle! In the original, historical battle, the Germans actually came down the road with no less than 19 (!) Panthers. Peiper, at that time, was barreling through the countryside with only his panzer units and did not have recons for the majority of his rapid thrusts toward the bridges. Your suggestions, however, are what would -normally- be found in a typical German offensive; very good points! Again, thank you very much for testing. I will upload again and send out a notice. Sure, it is a rather small battle, but part of this is to recreate a scene for a very good friend of mine. Perhaps someday, a screen capture of this can be used in educational situations or AAR visualizations for history buffs.
  5. Good idea, Arzok. I am looking into the various _Recon_Activate... triggers that are generated and am going to try modifying or adding a new one whereby the "Probing" unit has an actual goal to drive toward and then a time limit to stay there and observe. I may even have something whereby the observing/probing unit must observe at least N numbers of enemy or stay in the observation rectangle for X minutes. My idea is that a Mission Win would be a result of the probing unit having observed N numbers and made it back to their safe zone or simply sat in observation for X minutes and then go back to the safe zone. This could be an interesting exercise in concealment and stealth. Even more interesting if the enemy has random observation aircraft!
  6. I am interested in extending the templated triggers that are created whenever one uses the Battle Generator. I was wondering if anyone was already doing this and/or if work had been done. One example that I can see is that for the given templates that are created (which, by the way, are pretty good!), there may be room for a few other types of battle. For example, taking a page from the CM book, we could have "Probe" and "Meeting Engagement." Right now, in the templated [init] trigger, I see that there are basically two types of options set forth for the global variable @@action: ATTACK and DEFEND. I wanted to create a PROBE action and then perhaps set forth a conditional within [initMission] whereby a unit must perform the following: 1) Probing unit must move into a certain "Probe Rect" rectangle area 2) Probing unit must stay in that Probe Rect for a certain allotted time period to simulate reconnaissance 3) Probing unit must not be Panicked or otherwise depleted beneath a certain percentage of original strength (possibly using the @army_rate variable from [initMission] 4) Probing unit must return to their original disposition rectangle to complete the task --- With an extension of the given templates, perhaps we could have other such types of @@action(s) available to us. Has anyone gone down this path? Thanks!
  7. I have just uploaded a new single mission and custom map to the ToW Repository. The mission is The Battle of Trois Points. This is an historical mission, modeled after the brave, but suicidal defense of the bridge at Amblieve during Peiper's rapid advance toward the Meuse in December 1944. The map is modeled after current photos taken at the battle site as well as topographical data. I have restricted it to only the area concerned around the defense. It is a small and short scenario...only 10 minutes, but that was the case of the real-world defense. If you are able to stall the panzers before they reach the tunnels, within the 10 minute time limit, the bridges at Amblieve can be demolished and the task is successful. I would love to hear any feedback on this submission. Thanks!
  8. I am attempting to create a map whereby the actors (either player or computer AI) may have to pass beneath a bridge. I have noticed that for the "View Pathfinding" option, I find that the computer marks any area beneath the bridge's borders as red. This, no doubt, indicates that the AI will never go beneath a bridge. True to form, in play-testing, I find that the AI does not go through a bridge/tunnel object, but rather will attempt to go around it, even if it is placed on an array path. Has anyone had this same problem and is there a workaround? Thanks!
  9. I have a problem exactly as the original poster describes. That is, I have modified the clear summer map and added terrain and statics. No statics exceed 1000 and the same goes for trees and far trees. I only have a few hundred per set, actually. The land, however, does go from below water level (32) to +230m height. The mission crashes after about halfway loading (progress bar) and exits to desktop. Note that all other missions load fine and play fine. I have modified another similar map but the only difference is the height; there is not as much -dramatic- terrain changes, and that one loads fine.
  10. Hello, all, I asked this to Support and received some excellent advice. I will recreate that, here, for anyone who is interested. With regard to water, it is "fixed" at a certain height. In the NearHF.raw file, that corresponds to about 32,32,32 RGB value (dark grey). Therefore, if you wanted to make your entire map at or around water-level, lighten the NearHF.raw to that 32,32,32 value. Lighter values are higher, darker values are lower. Support staff has also advised me to stay away from the two edge values (1,1,1 and 255,255,255). I hope this helps!
  11. Hi all, I have found (through excellent emails from the Support staff) that TOW1 has the file "NearHF.raw" for heightmaps. This is greyscale and is in RGB values anywhere from 1,1,1 to 255,255,255. Note, however, that you should stay away from the extreme values, above. The water level in any map is around 32,32,32 (dark grey) and that is where you want to paint in any areas for that lower, water level. As for using DEM data, I have always wanted to do exactly as you describe. I have tried it, however, with no luck to date. I now use the Builder's terrain brush to perform height manipulations, as cumbersome as that is. One thing that does help, however, is that I simply save the topographical data as you have, above, with isolines, as the "maintex.tga" file in the correct proportions and then simply use the Builder's tools to raise terrain to the proper isoline levels. In the Builder, I suspect that the indicated height is similar to the RGB values in the afore-mentioned NearHF.raw. That is, if the height says "33," I find that it is almost always at or around water level. Therefore, if the height is indicated in the Builder as 133, then it is 100 meters above the water level. I have opened the resultant NearHF.raw in Photoshop to see how it looks after editing heights with Builder, but it appears to be not as easily graduated as your screenshot shows. There are isolines of a sort, but I am not quite sure how they are to be interpreted.
  12. Hello! I am creating a new custom map and textures for the Luxembourg-German border and Siegfried Line. Right now, I am simply working in the "Clear_Spring_wet_map" directory. Here is my process [please steer me in the right direction if I am off!]: 1) I copied the "maintex.tga" and renamed it as "maintex_bak.tga" to be used as a backup base file. 2) I am placing ground textures on my "maintex.tga" file 3) I am defining the height in "NearHF.raw" by shades of gray (black=lowest, white=highest) ___ The problem I am having is the lack of a reference for the heightfield colors to actual meter values. In other words, 1,1,1 is the absolute lowest you can go (black) and 255,255,255 is the highest (white). Does anyone know the corresponding shade/meter values? I have found through the wonderful support site that 32,32,32 is roughly where the water level (sea level?) is located. Therefore, would something like 40,40,40 be around 20m above sea (water) level ... ? Ideas? Also, I have read that 1px = 1m... That is for both "maintex" and "NearHF," right? Many thanks!
×
×
  • Create New...