jostapo

Hey Walk. =) Drop me a line sometime. My patch satisfaction is fine... everything surrounding the delivery is not. It cost me an evening of game play with friends and resulted in the cancellation of a tourny practise. -Joel a.k.a. Jostapo

So much for my CoC mates being supporting. Bn880 sucks! (kidding)

I used to develop exlusively in VC++ and should have remembered the string formatting. Lately all I've been working in is Delphi, VB, or .net stuff... and each of those languages has a way of 'dumbing down' the floating point displays. I thought the - was a seperator! I promise to flog myself duly.

Sorry. Â I've been up all night tinkering on MLRS special effects and Cruise missile guidance scripts... and stumbled over that problem in some debug lines I had. It freaked me out for a minute as I thought we'd have to revisit a lot of code. Just goes to show you that all night coding sessions can lead to little ASSumptions. Thanks and sorry for wasting your time guys.

Try the following code snippet: _blah = sin 180 player globalchat format["SIN180 is: %1",_blah] It should be 0 but is returning -8.74. Â If you run: _blah = sin 180.1 player globalchat format["SIN180 is: %1",_blah] It returns the correct answer just off 0. This is running 1.91 of the beta patch. Â Can anyone at bis shed a little light on this? Â Many of the functions and scripts CoC is currently using use cardinal compass headings, and these results are a little alarming. Thanks, Jostapo, aka Joel I should add that both SIN and COS both misbehave on cardinal compass headings. SIN being correct for 90 and 270, and COS being correct for 0 and 180.

Plamen is indeed a named memory point applied to the flare of the rocket. As of patch 1.85 (I believe) this flare stops burning after thrustime is ellasped... so for an LGB, plamen is ineffective. As for the addon itself, it is a joint project between UKF and CoC (Chain Of Command). Presently we have limited modelling 'skillz' at CoC, and Jonno of UKF graciously agreed to do the MLRS truck modelling for us. The screen shots of rocket launches and DPICM field effects are based upon the scripting that CoC is doing for the addon. With UKF's help, we're hoping to make the MLRS picture perfect.

FYI: Dammage: Law = 500 Carl = 800 Hell = 900 Mavr = 1900 LGB = 5000 Armor: Abrams = 900 T72 = 400 T80 = 700 BMP = 200 Given these values, I don't think the formula is quite right. I think the game engine might take into account hit locations and locational armour as opposed to any static kind of formula. To illustrate this. Grab a LAW and precisely fire it at the front armour, side armour, turret armour, and rear armour of a T72. You'll find that two solid hits in almost any location other than the sides will take it out. Hit it on the sides though, and it takes 3 rockets. It would also seem that luck plays some part in it as well, as I have seen T72's take a direct hit from Maverick and miraculously survive.

I tinkered around with some of the possible solutions. Drop was out, as it would seem none of the particle system particles create any ambient light. the fire and shotillumination simulations were out. Specifically, objects using the fire simulation seem not to take well to setvelocity. You CAN setpos, but trying to keep up with an object moving 600m/s wouldn't do the trick. Ultimately, the solution I've come up with is to create a 1cm rocket with a plamen component. You can't see it during the day or night, and it lights up bright as can be at night. The pertinent details are thrust = 0, thrustime = 3 (approx burn time of an MLRS rocket),simulation = missile. We are currently tracking each fired rocket via an event handler, for the create of the smoke effect. I plan to name the first dropped particle (outside of a loop), and do a getpos on it. This will give me the arse end coordinates of the rocket with proper elevation adjustments (the smoke particles re drop'd and bound to the rocket with a -y). I will camcreate the CoC_RocketFlare at that position, and then give it the same setvelocity vector as the missile. The net effect will be a 'rocket' (lgb) being chased by a rocket (the dud). I'm not sure how convincing it will be at this point, but it's the solution that ought to yield the ride balance between few lines of script code (to write and execute), and appearance. There shouldn't be any MP concerns as the eh fires on all clients (a bonus if you ask me).

I'm not sure that will work. The MLRS unit we are working on isn't your standard OFP vehicle. Player's cannot directly fire the rockets. Dinger and I are working on a true ballistic weapon that can fire out to 33km. The rockets themselves are 100% unguided. By using ballistic flight tables, we impart velocity into the rocket via setvelocity, and then a fuze time. Once the fuze runs out, the rocket explodes whereever it happens to be (usually on target). So whether the rocket can track anything at all doesn't matter, since once it is setvelocity'd, there is no guidance whatsoever. All we need is something capable of lasting 2 minutes and that can be fired from a turret mounted launcher. Through my testing, I've found the only way to get something to last 2 minutes, is to set the Thrusttime to 0. Regardless of the simulation (shotmissile, shotrocket,etc), setting this to ANY value other than zero results in the rocket self destructing after about 10 seconds (about 3.2km). This isn't even within the minimum range of MLRS. The addon is almost 100% completely working at this point. While setting thrustime to zero allows the rockets to last long enough to get out to 28km or so, the down side is, the plamen memory point does not light up. This fine for day missions, but in night missions, it's not so great as the M26 rockets really do light up the country side and our sustained smoke trails. See http://www.ostapowich.com/joel/gaming/ofp/mlrs/ for some shots. While we could just setvelocity ANY object, and have no problem with it lasting sufficiently long, we want the rocket to lethal along it's full flight path. So buzzing an MLRS battery in your chopper while they are firing would be unwise. Ditto being near the landing point. If struck, it will not deploy the submunition field, but odds are, will take out of the heaviest of airborne targets (as the missiles weigh quite a bit). That brings me back to the original question. How to make a 'shot' glow regardless of it's thrust time value. (i'm still convinced that setting thrustime to anythign but 0 causes the rocket to explode prematurely). Thus far I think the solution either lays in 1) Finding out if DROP can be used to spawn a brilliant particle with ambient lighting effects. The beauty of this is, the particle could then be bound to the arse end of the missile and would work seamlessly regardless of how laggy your machine is. 2) Create a static light object with high ambient effect and setvelocity it after the missile trailing by ~1 meter. So far I haven't been having too much luck with this, as it would appear as though you cannot setvelocity something using a lightsource with ambient effects. Aka, something using the "fire" simulation. Basically I created a jeep shell, as I know you can toss jeeps around with ease. Changed the simulation to "fire" and added a light source. Prior to making these changes, I could toss the 'dummy rocket' around to my hearts content. Changing the simulation broke that. I would setpos the illumination effect (which does work), but because of varying machine speeds, this isn't an option. The rockets at moving at 600m/s and it would create a very annoying stuttered light movement.

Here are my cpp settings for our MLRS rocket as setup to test AXE's assertion: maxControlRange=0; inittime=0.0; thrustTime=2.7; thrust=0; simulation=shotMissile; The rocket flies WITH a light, but self destructs after 9.8 seconds. Changing the thrustime to 0 allows the missile to fly for 2 minutes. It's pretty clear that thrustime is the setting that 'turns on' the LGB simulation.

That's interesting AXE. I played with the CPP extensively last night, and referenced the commented CPP on the laserguidedbomb class. Changing thrusttime to anything but 0 caused the missile to die after 9.8 seconds or so. Setting it to zero allowed the missile to travel much longer than that. The maxcontrol range of LGB in the commented config is set to 10,000 with the comment (unlimited control range). I'm not saying you are wrong. I will test and repost on this shortly. -Joel

Hi folks. I was wondering if anyone out there has had success with adding a light to an laser guided bomb. It seems that setting the thrusttime to 0 on ammo with the shotmissile simulation TURNS ON the LGB simulation which allows 2 minutes of flight time (important for MLRS). Unfortunately, turning this simulation on turns OFF the innate lighting effect that rockets and missiles normally get. Does anyone out there know how to: a) attach a permanent light source to a missile regardless of the simulation it uses? b) how to use the drop command to create the flare (NOT FIRE) effect? What model do flares use? and do they generate their fire when dropped? The end goal is, I need to be able to light up the countryside as the rocket takes off. If we haven't any luck with this, we'll likely have to settle for rocket takeoffs without ambient lighting, as the solution we have is 100% ballistic (ie, the way it oughta be). Thanks in advance.

Polling is a problem in MP. We are doing some presently (and I hate the fact). Here's my reasoning for having asked the question in the first place. If you build a model, you create your GEO and fire lods TYPICALLY to match the shape of the detail lod. When a collision occurs between something HEAVY and something light, the ONHIT and ONKILLED event handlers are triggered. So the object is actually detecting collision dammage. I've noticed there are varying degrees of this collision detection in the BIS object collection. For instance, shooting a mine barricade with an m16 will not register a hit... but shooting a grave does. Armed with that bit of knowledge, it would only make sense that some combination of CPP setting and model setting, could make a super sensitive model that will detect a player colliding with it. You could then exagerate the geometry lod for your objects, and thus make a mine easy engouh for a player to step on, (say a 1 m disc for the geo lod), while not requiring a trigger. That and it'd be very likely to work well in MP with no polling or monitoring at all. -Joel/jostapo

Hi. Dinger and I have been working on a mine pack for Chain of Command. So far we have claymores working as well as we'd like (nicely), and have some bouncing betty mines (they jump into the air and detonate). I was wondering if it's possibly to make an object that is hyper sensitive to anything bumbing into it. Specifically, if a person steps on the mine. So far, with the cpp and model combination we have, the models detonate appropriately when a heavy tracked vehicle or they are shot. However, they do not detonate when some steps on them. For this we are having to use a trigger for each and every bouncing betty (it works but it's not as polished as we'd like). I've tried numerous combinations of cpp tweaks, and model tweaks in an effort to make the mines hyper sensitive. Basically, i'd like a strong breeze, let alone someone stepping on them to detonate the mine. What am I missing? I've noticed that various objects, all have differing sensitivity as to what actions cause them damage and how much damage is given. For instance, some objects will only register a hit when rammed by a fast moving tank, while others will register a slow moving jeep. Is this a CPP issue? a model issue? a combination of both? and can an object be made so sensitive that it detects footfalls? If any of the guys from BIS happen to see this post i'd sure like your input. In fact, i'd be equally happy if you said "It's not presently possible." At least I could put this to rest. Thanks, Jostapo,CoC