Tanelorn

Hey there. As you may already know by reading my other post (multiple scripts in event handlers), I am trying to link my unit's weapons to an energy pool. This pool loses energy when weapons are fired, and equally replenishes weapons every time they fire. This is for high-energy weapons such as gun towers, artillery, etc. I am doing this by using event handlers to call internal scripts that handle the behaviors. It works great! Except... 1. You must manually reload magazines as they are given to you. 2. The AI won't reload their replacement magazines. They sit there and never fire. Wierd eh? I've done alot of research and I can't seem to overcome this problem. I use the "unit" ammo "magazinename" command to detect when the ammunition runs out. At that time I issue a new magazine if the energy pool has enough energy for it. But then I hit the problems listed above. I have tried using the command : myunit action ["MAGAZINE", "magazinename"] This is supposed to make a unit reload his weapon, but it does nothing for AI or for live players. My magazine names are the same as my weapon names, so it's not a naming problem. So close, but so far away... Any ideas? Your help will be greatly appreciated.

Good job DragoFire. I would add some scripts to the addon and use an init event handler to run them. In these scripts I would have the wings automatically fold when your altitude is 0 and speed is less than 10 kph. It saves trouble of people having to do it manually. However, manually is more realistic of course. Then again, you will have to take pains to make the AI fold their wings at the right time, so the automated method works well there. Oh Sharpshooter, if your DM will let you play a GithZerai, do it! You'll get 5% magic resistance every level after 3rd! My character got (due to an awesome random treasure roll by the DM ) a cloak of protection +5 in a 5th level adventure. With that and his magic resistance, he consistantly shrugged off all kinds of dangers while the rest of the party feared for their lives. On top of that, GZ are wanderers, so your outer planes lore will be quite extensive. They can also planewalk at will, which is an incredible ability (but is more dangerous than teleportation like Baatezu and Ti'nnari have). THe downside is that you must be chaotic, and I mean CHAOTIC! GithZerai value personal freedom over everything else, so they refuse to be bound by anything, even friendship.

This post is 3 tiered. =P -- TIER 1: answer to sharpshooter: It will depend on your scripts, but yes, for every unit you place, those scripts will run. You can get around CPU burden by using lots of @ statements so the script only runs when something happens and is paused the rest of the time. Using loops would be bad. Also, of course, if it's just a script that runs once and exits, you won't have any CPU burden. -- TIER 2: cleaning up the code Now that since 1.85 we can use {} to enclose strings, I am able to use this cleaner version of SUMA's code. Unfortunately I can't break it up further. // this event handler allows the vehicle to continuously regenerate it's ammunition class eventhandlers { init = "[_this select 0, {TA_VTOL_EMG}] exec {\ta_units\scripts\reload_freegun.sqs};[_this select 0, {TA_EMG_Gun}] exec {\ta_units\scripts\reload_freegun.sqs}"; }; -- TIER 3: SHarpshooter and Zerthimon I loved Dak'kon and the GithZerai so much that I can repeat all the teachings of the Wheel of Zerthimon nearly word for word. I also created the WHeel of Zerthimon out of ireregularly cut sheet metal plates, polyethylene molds and a few other knickknacks . It had locking mechanisms in the center that allowed you to remove the plates and turn them about to read the scriptures. If you didn't know the sequences the scriptures were garbage because each scripture was engraved across several different plates. The history of the Gith races is one of the most incredible stories from the AD&D monsteous manual and later elaborated in Planescape itself. I liked him so much I roleplayed a GithZerai for about 3 years in an AD&D campaign. He was on a hopeless quest to discover the long lost history of the Gith races before their capture by the Illythid. I even perfected my speech to sound like a GithZerai (on top of speaking the Kant, of course). My character was able to guide us through certain parts of YsGaard, Ghenna and Avernus (Baator). Briefly hit the Abyss but even the toughest cutters steer clear of that place. Heh heh, good fun.

I do alot of mirroring with more simple objects. It's not too tough, especially if you are smart about the merge near funtion. I have it set to 0.01 most of the time, and only if I have tons of little vertices does it mess it up. So if you have trouble just shorten the range to 0.001. There is also the detect nearest function which is cool but sometimes detects the wrong vertex. SO my process is.. Copy Paste 2D transform -> mirror x (or mirror y) W (flip faces) drag zoom and drag to perfection highlight nearby vertices for joining merge near done.

As the Zerth Dak'kon would say, DragoFire is seeing with "Vanquilar's Eye". It's such a classic. If you want the whole story, you must play Planescape Torment. But the gist of it is... when you want something badly, you tend to see everything in the perspective of your goal. You become narrow-minded due to your strong desires, and are easily fooled by things that are illogical but seem to bring you closer to reaching your goal. This tunnel-vision mental state is called "Seeing with Vanquilar's Eye". Vanquilar was betrayed and killed, by the way. In any case, THANK YOU VERY MUCH SUMA! I too saw with Vanquilar's eye, as I put strong emphasis on clean looking code. I didn't realize that I couldn't break up the code sections like I do for other parts of the config file. My desire to keep the code clean (no code long enough to wrap across the screen) kept me from realizing my errors in syntax. Thanks for setting me straight Suma. THis is a real life-saver. Now if I can only figure out how to make a vehicle with a turret that doesn't raise dust clouds, the KBOT will be mine!

I think thats off the mark. In my experience the hit-points don't register hits well unless the weapon has area-effect damage. Bullets don't hurt tanks because their blast radius is low and it doesn't register on the hit-points. I've tested this with my TA units. I had to increase the blast area of all my weapons to register hits properly with laser / bullet type weapons. So if you want to maximize damage to a tank, use a weapon with a considerable blast area. Light damage or not, it's the blast, not the direct hit, that maximizes the effect.

I noticed on soldiers that damagestructural had a direct effect on how much damage they could take in the arms and legs before they would die. In this case, they actually could absorb massive amounts of damage to their extremeties and still live, if the structural damage was set high. I thought about raising that from the normal settings to show how you can shoot a person several times in the arm or leg and not kill them. But, unfortunately, most soldier poses place an arm in front of the chest, so it became very difficult to get that torso shot.

YAAAAAHOOOO! I discovered the perfect workaround! Works like a charm! In your rocket you want to glow, add a proxy object. THat proxy will point to another model of your rocket that is all shining. Make sure both rockets are set to shining so one disappears (otherwise you won't see the shining through the non-shining). Now in the config file, add this: class CfgNonAIVehicles { Â Â class ProxyWeapon {}; Â Â class Proxymyproxyname: ProxyWeapon {model = "\myaddon\myproxymodel"; simulation = "alwaysshow";} }; YOu will use your own names of course. Wala! YOur rocket model will disappear when it runs out of fuel, but the proxy that tags along with it remains aglow. ALL HAIL GLOW-IN-THE-DARK ROCKETS!

AA, I just posted a thing on this. The dismal fact is... all shining faces on a rocket are considered to be part of it's rocket flare, and they disappear when the fuel runs out. SO if your missile was supposed to glow, now it will just disappear.

that buglist is really short. THere are several other issues that really deserve to be addressed as well. I'm suprised they aren't taking more time to release a larger patch. With the handguns, they really need to allow for all three movement modes (walking, jogging, sprinting) like with the rifle. My AI are always walking around with their pistols up and ready to fire, even in careless mode. It really ruins missions where people have handguns but aren't provoked yet. Have you also noticed that if the unit has a handgun only, all his animations are still as if he had a rifle slung? Try holstering your pistol and walking around, you'll see what I mean.

Yes and it's gotten very bad lately. There's alot of modeling and config file editing knowledge out there that just isn't being posted.

this issue is really ruining my mod. I had to bump it for good measure.

Hey folks. Ever since 1.76 I have noticed that tanks tend to fire over the heads of their targets at ranges over 700m. This is quite consistant. I have sat in a HMMWV 1200 meters from a T72 with high skill on flat ground and it misses me shell after shell. This isn't as noticable with the high velocity tank shells, but it's VERY obvious if you use an addon with slower shells. I have made tanks with initspeed 300 shells, and they always fire 25-50m past their targets. because these problems exist with non-addon units as well, I figured I'd better report it.

I have sucessfully done this for our VTOLS. It's great because you include the scripts with the addon, and use the eventhandler "init" to run them. These scripts toggle folding wings / undercarriage as the vehicle lands / takes off.

OK I've come to learn alot about this stuff so I'll share what I know. But please, if you know something extra or if your knowledge conflicts with mine, post it. 1. Materiel: THese are numbers that you put in the user defined slot within Face Properties in Oxygen. This allows a hit to that spot to darken the face, showing damage level. This is how the tanks / APCs show damage as you hit them. This must coincide with the hit points LOD so it knows you have actually struck the track / turret / etc. 2. Armors: All armor values other than the main "armor = #" are ratios compared to the full armor level. So, armorgun = 0.5 means that if you do half the vehicle's armor level of damage to the gun, it will be disabled. I can't understand the redundancy of the armor classes and the armor values. Some of the information is stated twice, and makes me wonder if one can override the other. Also, you must remember that damage to a vehicle is additive. 200 points of damage to a turret does 200 points of damage to the overall armor as well. There is no way to make one section of the tank absorb damage. Damage is damage. However, if you damage the "engine" hitpoint enough, it will cause the destruction of the vehicle. So this is a way to incorporate vulnerabilities to a vehicle.

Ok folks, tell me if I'm seeing things, but in my Resistance (and I'm at 1.90 now) if a BMP is not in the first LOD and it is moving, a large triangular object rotates with one of the wheels on the right track. It's really obvious for me, you see this giant triangle (one quarter the size of the vehicle) coming out of the right track and turning as the BMP moves. Again, this is not present in the first LOD but all others seem to have it. P.S. for those of you who don't know what a LOD is... Most objects have 7 Levels of Detail that show less detail as the object is farther away. Each LOD is a model with less and less complexity to it. Together, all LODs make up an object (plus other special LODs and other supporting files).

Howdy all. THis is extremely odd, IMHO. I am using proxy:zsudriver.01 for the pilotview of some of my vehicles. Tha proxy is of a man with his hands about at his legs, holding onto two driving sticks. In-game, the zsu driver is of that same position too. Meaning when I get in a SHilka, I am sitting down with my hands on driving sticks next to my legs. However, in MY MODEL when I play it in-game, the man is in the T55driver position laying quite flat and his hands are raised holding a horizontal bar! Now can someone tell me why my zsudriver proxy is not behaving as a zsuproxy in-game???

Allrighty, I got them KBOTS to walk! Now it aint that pretty, but it's definitely an animation that gives the illusion of walking. If all my screenshots didn't return pictures of my desktop I'd show you. <:/ But I have another serious problem. DUST! These KBOTS are hidden in their own dustclouds. Anybody know how to make a tank not produce dust? I've taken out the STOPLL, STOPLR, etc memory points and my landcontact is not labeled. THey run fine but still kick up dust. I really don't know what to do about this one. What are your thoughts?

HellToupee, what part of this post makes you think my KBOTS are presentable? The whole point is that they are not ready because of the friggin dust! Bratz, the land contact points are still there, I just removed their labels. Wether everything is defined or not tho, there is still dust. If I can only get rid of this confounded dust, it will be problem solved!

nope. every attempt to assign more than one animation to a single selection results in failure. THis is more a toy soldier walking animation. I JUST NEED TO REMOVE THE DUST!

Hey all, you've read the title, now read the post. I have been experimenting with making KBOTS, those 2-4 legged war machines from Total Annihilation. I've had mixed success. What has been holding me up you may be asking... well I'll tell you. It's not the modeling, it's not the config file, it's not the scripts... I think it's the engine itself. We are creating walking animations with clever use of custom animations. This is the general process: 1. Axis points are set to every joint on the leg, named selections are set up for the different parts to be animated. 2. In the config file, we define these animations, and create several animations according to how the legs are supposed to move. 3. Finally, we have a script run for the unit that detects when it is moving, and animates the legs accordingly. Here are some screenshots of how we set up the model with named selections. http://ta.opflash.org/loading_dock/forum_screens/o2_hip.jpg http://ta.opflash.org/loading_dock/forum_screens/o2_shin.jpg http://ta.opflash.org/loading_dock/forum_screens/o2_foot.jpg And here are screens of the memory points. You will see that we have named selections in memory that mirrors that in the resolution LODs, so that the memory axis move with the animations, ensuring that things turn where they are supposed to. http://ta.opflash.org/loading_dock/forum_screens/o2_hip_m.jpg http://ta.opflash.org/loading_dock/forum_screens/o2_hip_m_ax.jpg http://ta.opflash.org/loading_dock/forum_screens/o2_shin_m_etc.jpg In a bulldozer demonstration, let me show you how it is SUPPOSED to work: 1. The entire leg is elevated using three custom animations. Each animation takes the hip, shin, or foot and rotates it 90 degrees using the hip axis. http://ta.opflash.org/loading_dock/forum_screens/bdz_1.jpg 2. Then, the shin and the foot are rotated back using two other custom animations who use the shin axis. http://ta.opflash.org/loading_dock/forum_screens/bdz_2.jpg At this point, the leg is fully extended while the shin and foot are facing the ground. As a follow through, the animations are reversed to bring the leg back to it's initial position. Unfortunately, this doesn't work in OFP. When these animations are run in the scripts, we see the hip, the shin, and the foot all operating independently. When I try to take a screenshot in OFP, I end up getting my desktop or a black screen. So I must show you what is happening using bulldozer screenshots: http://ta.opflash.org/loading_dock/forum_screens/bdz_3.jpg http://ta.opflash.org/loading_dock/forum_screens/bdz_4.jpg As you can see, the hip rotates, but it does not pull the shin or the foot with it. Even though there are animations that specifically tell those sections to rotate along the hip axis, they refuse. The problem: You can not define two different custom animations for the same named selection. When I remove the animations that tell the shin and the foot to use their own axis, the entire leg is able to move again. It seems that custom animations compete for control over a named selection. I have also tried having the hip contain all sections in the model, the shin containing itself and the foot, and the foot defined by itself. This also fails, making the hip swing forward leaving the shin and the foot behind. So what are your thoughts folks? Can we make KBOTS, MECHS, etc. with some more work and tweaking? The possibility is there, it's just that the animations conflict with eachother. If we can figure this out, it will be revolutionary.

sigtest?!!? WTF? prepare for moderator retribution! =P

do not despair though, as the new command "setvelocity" will allow you to have vehicles on a carrier that has a roadway LOD. SO long as you have a script that constantly adjusts the vehicle's velocity to equal that of the carrier, they will stay on without much trouble. You may need to re-teleport them from time to time to adjust for slight deviations due to the time between update loops.

As anyone who has played TA can tell you, you can take out even the biggest enemy with enough Flash Tanks. Well that idea works in TA, but not so well in OFP. The problem: If a unit's weapon does low damage, and the enemy has high armor, the unit will refuse to attack. Now this is a huge problem for me, I don't know about the rest of you. I am asking if any of you know a way around this issue. I'm not too happy with fielding a swarm of Flash Tanks just to watch them drive up to the enemy and sit there to get killed without firing a shot.

I'm pretty sure this means: hiddenSelections[]= { "doorSelectionName","windowSelectionName" }; the hiddenselections index is an array of hidden selections. an index value of 0 is the first element of the hidden selections array, an index value of 1 is the second element, etc. Just like when you use arrays in scripting. THis is really great as it allows us to have multiple retextured units without having to include multiple models in an addon. The big question is: "Just how much can we get away with?" Can we set the majority of a unit up with hidden selections and give them an entirely different camoflague scheme? Or for people, can we let them change clothes in the field, like a spy would do?