Tanelorn
Member-
Content Count
82 -
Joined
-
Last visited
Never -
Medals
Everything posted by Tanelorn
-
I have thoroughly playtested these events and here are my discoveries: TESTING CONDITIONS: Clean mission editor environment. One 10 man group with live players in the group leader and one other slot. Rest are AI. One UH-60 under AI control, flying. SITUATION: In a multiplayer game: Group is placed in helicopter using "moveincargo" command. UH-60 is given "transport unload" waypoint. Group attempts to disembark when heliciopter lands. RESULTS: The group will disembark one at a time in order of group arrangement. Live team leader disembarks. Â Rest of team disembarks successfully until it is the next live player's turn. Then, the other AI units still in the vehicle refuse to disembark. DEDUCTIONS: THe AI are given a disembark list and wait in turn for the unit before them to leave before they attempt to leave. There is a bug in the code where live players don't report properly that they have left the vehicle, so the AI wait forever to exit. I have run across a few other posts similar to this one. It is a serious destroyer of MP games.
-
Unfortunately you can only define cloudlets for vehicles. ANd since a man is a vehicle, you can set it up for him. Unfortunately, the cloudlet will be the same for all guns.
-
If you can get the legs to move properly I will be very interested in this as I have had no success making one named selection usable by two separate animations. Proper leg movement requires that the leg move along one axis while rotating on another. Two animations with 1 named selection = errors. At least in my experience.
-
The forums are no place to discuss internal MOD team issues. Both of you should go back and edit your posts, deleting anything off-topic. This is a very valuable thread and deserves to be unmolested by MOD team internal bickering. In my opinion: The manactReloadAT works with secondary because it is a series of commands for the secondary weapon. The manactReloadMortar works with primary weapons because it is a series of commands for the primary. These commands are in the cfgManActions classes and some other sections in the main config.cpp file. I'm sure the .rtm files get involved too. So, basically, if you can make a new manaction using the two listed above as a guide, you may be able to use the reloadmortar on a secondary weapon. If not, you may need to use that new animation editor to create a reloadmortar .rtm file for the secondary and define it in a new manaction class, then call it from the cfgWeapons class of the new rocket launcher. Lots of work but a great payoff.
-
Mod Team Leader is in the building. =) I have extensively experimented with multiple animations. I actually have a very detailed post about this kind of stuff floating around this forum, complete with screenshots. You'll have to do a search for my posts tho, cuz I haven't a clue how far back in the history it is now. Anyway... for vehicles we are in trouble. 1. We can only rotate. Translation is only possible if you make an axis very far away, and it's only believable if you animate a small object. 2. You can not assign more than one animation for the same named selection. This is even true if you group sections together with a different named selection. Believe me, I've tried. <8/ 3. You CAN NOT use custom animations on memory points. 4. you CAN NOT animate hit point LODs (to my knowledge) 5. You CAN animate land contact and vertices on the resolution LODs. 6. you CAN animate geometry LODs.
-
Same problem here. In my experience, I could use the custom grenades if I was not the unit leader. Very strange eh? So I guess for now the best thing to do is to use a script to remove the grenades and add them again at mission start.
-
Ok folks, much to my dismay I discovered this bit of O2 trivia: Any face on a rocket model with vertices set to "shining" will disappear when a rocket's fuel runs out. Now you may be thinking... "COOL! Now I know how to do rocket flares and all that neeto stuff!" Well you're right, that's how to do it. However, theres a serious downside... WHat if you want your entire rocket to be shining? Consider an aircraft that fires energy bolts as rockets so they will alternate from left to right when fired. Actually, the only way to fire anything but a bullet from an aircraft is to use rockets or missiles. SHells don't work. So, if you do like I have done, and make your rockets all shining (so they glow in the dark without the lens flare), be prepared for your rockets to disappear on you.
-
Request for another new scripting command
Tanelorn posted a topic in OFP : MISSION EDITING & SCRIPTING
like it says, this is very important especially for camera scripting. THere's currently no way to detect the direction of a tank turret. Unless, getdir gunner vehicle works... Never tried it. -
YOur textures are quite nice. Make them yourself?
-
YOur textures are quite nice. Make them yourself?
-
That awful yellow flash! get rid of it!
Tanelorn replied to -~1ncognito~-'s topic in OFP : CONFIGS & SCRIPTING
no its the lightsource that produces a flare and lights up everything around it. shoot the BMP machinegun at night and you'll see it. Problem is you get that same effect for everything that fires bullets out of a vehicle, regardless of its properties -
Oberon, what 3D program are you using to make this before import into O2? Looks very clean.
-
Combining simulation types is really asking alot. It's a major change in the source code. Many of our problems can be solved, however, if BIS can allow more than one animation per selection. If that can be done, we can use scripting to animate anything the way we want to. Another important extra would be the addition of the "translation" animation that allows selections to move in straight lines. Der Bastler, you wouldn't be interested in forming an alliance with the TA Mod would you? We both are trying to create units that stretch the capabilities of the OFP engine. I won't go so far as to try to recruit you, as you have your own mod (very nice dropship and Pulse Rifle by the way), but I do offer our hand in friendship. =) Of course if you did want to join us, we could very much use a modeler and a map maker.
-
All these solutions are elementary and are answered in the tutorials and FAQs. I'm glad you have read them, but you should read them more thoroughly if these simple solutions solve your problem. Hey, is it just me, or have the forum discussions really deteorated recently?
-
Please give me a link to COl. BLink's robots that would be of very great importance to my MOD team. Also using custom animations is very limited right now as you can not give a selection more than one animation. So it is very difficult to animate legs because they have multiple sections that must animate differently yet in unison.
-
That awful yellow flash! get rid of it!
Tanelorn replied to -~1ncognito~-'s topic in OFP : CONFIGS & SCRIPTING
I am in the same boat as you, and I have not discovered a way to avoid this. -
Howdy all. Tanelorn here with another brain twister for ya. I am using tons of encapsulated scripts in my mod, since there are so many special behaviors for all my units. Well wouldn't you know it, the time has come for me to need more than one script to be run at unit initialization. Rather than have TONS of scripts in my scripts folder that are solely designed to be run for a particular unit, I am trying to keep all the hassle in the config file and shovel it out from there. It's a great idea, in fact, it looks darn near perfect. My problem: I have no idea how to do it! I'm running into syntax errors left and right when I try to cram two script calls in one event handler. Any ideas? I've tried tons of combinations. I'll bet there's one that will work if we put our heads together. Heres a sample of a non-working config snippet: // 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";      };   };
-
makes sense. Sigma, I think the main reason why your APFSDS rounds are able to inflict full damage is because the blast radius actually extends beyond the limit you set for high damage weapons. I made artillery addon shells, and even with a blast radius of 5, they killed people out to like 20 meters due to their high damage. All I know is that I can gun away at a BMP with a .50 cal forever and not touch it, but if I shoot it with the weak grenades it will take damage fairly quickly. The difference: blast radius.
-
Multiple scripts run from one event handler
Tanelorn replied to Tanelorn's topic in OFP : CONFIGS & SCRIPTING
Thanks for working with us throughout this topic Suma. Your knowledge really helps everyone who reads this make better and more complex addons. I didn't realize that @ caused cpu burden. In the future I will use timed loops instead. -
Yes that's nice but when you do it you can't fire your weapon and must hit switchweapon key first. TOo bad about that.
-
I just wanted to say that all this math is really impressive. It's a great exercise in setvelocity. However, it's much more efficient to use scripts to determine time of flight and createvehicle the shells about 50m over the target zone, using setvelocity from there. THis way you don't have to worry about making all those calculations and you still get the same effect. If you use the flysound to generate the screaming sound, it's going to loop and sound terrible when it does. By creating a shell close to the target you guarantee there will be no looping. So, while all this math is great, the best solution is using createvehilce near the target IMHO.
-
Request for another new scripting command
Tanelorn replied to Tanelorn's topic in OFP : MISSION EDITING & SCRIPTING
Also very useful for artillery pieces with turrets. It would allow you to fire an invisible round out of the gun, but use scripts to detect turret direction and use createvehicle / setvelocity on a tank shell to lob it. -
Using scripts to dynamically add magazines
Tanelorn replied to Tanelorn's topic in OFP : MISSION EDITING & SCRIPTING
Actually this entire problem can be solved if I can make weapons that do not consume ammunition, suck as strikefist and strikegun. Then I will just issue a hold fire order to the unit when energy is depleted. -
Using scripts to dynamically add magazines
Tanelorn posted a topic in OFP : MISSION EDITING & SCRIPTING
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. -
Multiple scripts run from one event handler
Tanelorn replied to Tanelorn's topic in OFP : CONFIGS & SCRIPTING
Re: to SUMA and others. Using ~.0001 still causes the script to loop alot and burden the CPU. Its a better idea, but I'm suprised you recommend a loop that runs so often. In my scripts, I use a toggle and @ statements to reduce the burden. example (not in proper syntax, only for example): #geardrop @(height myhelo < 5 AND speed myhelo < 10) myhelo animate ["gear", 1] goto "gearraise" #gearraise @(height myhelo > 5 OR speed myhelo > 10) myhelo animate ["gear",0] goto "geardrop" This code really reduces CPU burden because it waits until a specific event before continuing. It only needs to check for raising when the gear is already down, and visa versa. This way, it is very efficient with no repetetive looping. Oh, and sharpshooter. use the ABS command. It automatically converts negative numbers to positive ones, it will save you trouble in your if statements. example: ?( speed myvehicle > 10 OR speed myvehicle < -10) can be: ?( (abs(speed myvehicle)) > 10)