Macser

Yeah.Dusk or very early morning tends to look best,because of the good contrast between light and shadow. You can try putting smaller values into each subsequent lod.Something like 0.0,0.2,0.3 etc. That should have the effect of stepping down through them more quickly.Obviously it won't look as dense at a distance.But it should be a decent trade-off.

I don't think there's much you can do about it.OFP's lighting system is per vertex I think. So it could be just a product of it's inaccuracy. Have you tried setting all edges to sharp?Or triangulating the faces? On the other hand,if the faces are pointing away from the sun you would expect them to be shaded.The only way to make both sides the same,regardless of lighting conditions,is to set them to "shining".Of course it doesn't make them shine.It simply makes the faces shadeless.

Again.Great work.Lots of nice detail without going bananas on the polycount. So the small display to the left,visually updates the ammo count,yes? About the blue green area.You could use Blender to paint some of the glow colour onto the surrounding area.It's a cheap way to sell the illusion of a light source. :)

It won't happen if there's code in common with the newer titles. That's what I was getting at in the second paragraph of my post. But companies do release source code for older games. :)

Confirmed. Proxy objects are generated without issue up to version 2.72b.

For me the sad part is not being able to get at source code.Not me personally.Someone with the right knowledge.I wouldn't expect a company to invest work in an old title after this length of time.But source code would allow for someone else to make some improvements. It's possible there's too much code in common between the titles.I don't know.It's possible the company doesn't want to give people the ability to create something that may or may not offer a lower res alternative to the newer titles.Although,aside from the limitations,that's what the older titles are for many folks. But whether it's been mentioned or not,even with access to source code,you'd still have the hurdle of scant documentation.And of course,who would want to take on such a project?It wouldn't be a weekends work. :)

Thanks Lenyoga.It should be ready to release soon enough. :) Blender's paint layer system made the texturing much easier to deal with. Even though it's not perfect in operation,there's no substitute for painting directly onto the model.

Nice work Lenyoga.Some really good quality models there.Looks like the study has indeed paid off. :)

Are you using Alwarren's Arma toolbox?Do you have the addon enabled in the user preferences section in Blender? What version of Blender are you using? Is the file you are trying to import a sample model(Mlod)?Or is it a binarized game model(Odol format)? The toolbox will only open Mlod format P3ds.

You should post in the official thread for the toolbox. I'm sure Alwarren would be happy to help with any genuine issues. If by default,you mean current A3 content,then there are no mlods available for those models,as far as I know. They would be in the binarized Odol format. The toolbox does not open Odols.

Functioning but experimental speeder.

You can keep your Config in cpp format until you're ready.Have a look here. This worked for me when some animation issues cropped up. :)

Sorrow? :) There's nothing sorrowful about it.Whether I or anyone else wants to use an ancient game is of no consequence.It's just the way it is.For some it's nostalgia.For others it's ease of use.And for some it's a game that can run on low-end hardware.Where's the problem? There's nothing to move forward to.They're just games.You either play/mod them,or you don't. When they were made,or what they look like isn't all that important.

Aah.Right.I haven't used Texview in quite a while.I didn't realise it accepted JPGs. :) The other info about moving to top or bottom and separating textures should still be valid.

Hey guys.I don't think jpg is the best choice for game textures.I've had this discussion with Vektor and others before. Although the jpg is relatively small on disk it apparently can't be used in the same way as dxt textures with video memory. Despite both being compressed formats. Do you get the same issue with 24bit tgas(no alpha)? Also keep alpha textures separate.Rather than incorporating them into the main images. In your models try selecting all the faces that are causing an issue,and "move to bottom",or "move to top" in O2. Although if it works,and there's no complaints............. :)

This isn't very advanced.But it might do until a more experienced scripter comes along. In the example below I put two units on the map.The player obviously being one of them. I set the redfor unit to careless,and faced away from me,so I could make sure the unit was responding to the trigger. Then I put down a trigger with the code shown.The trigger can be any size. You could also use "Knowsabout" to instantly tell a unit the whereabouts of the player or other unit,when a condition is met. Here's a good source for OFP mission editors,if you haven't already got it.

Exactly,yes.That's the kind of thing I've tried myself.Although only in short bursts.As a boost. It's pretty effective too,in the hands of a player.The problem is the AI.They just aren't built to handle that kind of flight. The best they can manage is to fly around in circles in a vane attempt to stay in formation. Or until they crash.Which is not surprising as they can't switch the script off as and when needed. If I can get something working with getbankpitch,I'll be trying to keep the fire rate as low as possible without making the weapons ineffective.That should at least help to offset any looping. I know I might sound very negative.But honestly,I appreciate any input.Cheers. :)

The CfgVehicles section likely did it.Specifically the Cobra class.Missiles as energy "bolts" works well with the helicopter classes.There's no visual oddities. But planes are a different situation.If you observe the craft as a spectator the missiles disappear even though the ammo and weapons would be the same as on the helicopter variant.This is from my own observations. I had considered basing the craft off of a helicopter class.But I didn't think the handling would suit it. Simulating a plane might be possible with scripting.But that would be something constant,rather than being tied to the life-time of a bullet.Which as you know is short-lived. Still.It's an option. :)

@impala174 I personally have nothing against these projects or the people who run/play them.It's just another aspect of gaming.Although it's not a subject I'm familiar with. Unfortunately the activities of A3life staff is linked with the genre on these boards.If you want to engage with members here you'll have to provide more information about your project.Obviously there's no obligation to do so. But it's the best approach. :)

Thanks Von Knudenberg,for the compliment and advice/help.Much appreciated. :) I'm glad to see yet another person getting some use out of the files.Although I think I may need to update them again. I can't use Blender's default naming conventions for all of the bones.By that I mean leftarm.l,or leftarm.r. Which would allow the user to mirror poses accurately across the x axis.Very handy.Especially for looped walk/run cycles. The engine requires the correct bone/selection names for the default animations to work. I'll have to experiment and see if renaming the controllers would be enough.It's not a deal breaker. But it might be nice to have.

You mean CloudletsMissile? Although I'd prefer to keep it as self-contained as possible,I'll certainly keep that in mind.

Hey Lenyoga. I tried missiles in this context.class zuni. From what I've observed,getting rid of the smoke trail makes the rockets invisible unless you're the pilot of the craft.This seems to affect planes only. Acacyn's old Star wars addons exhibit the same behaviour.

Hello Arctor.I'll try the last part first. :) If I understand correctly you're wondering how the control bones can manipulate the mesh yet be disregarded at export time.Yes? If so,it's because the actual deformation bones are on a different Armature layer. You'll find these have no @ prefix.As these bones are part of an ik chain the controls are the only thing you really need to see while animating.You can of course make them visible by switching the layer on,in the armature tab. Ok.The hand animations. I confess I haven't done much in the way of experimentation with hand anims. From what I can see it's more likely an issue with the hand anims themselves. By that I mean how they're configured.Rather than the rtms. I say that because it looks like both anims are off by the same amount,relative to the character model.But I can still see that the pose itself appears intact. Particularly in the second image. I can't tell you off-hand how to sort that out.But I don't believe that's the first time I've seen this happen.There must be a thread dealing with just such a situation. One other thing.If you bring in another object,for reference,make sure you parent it with the appropriate bone.Otherwise you're just moving a disconnected object around the viewport.Select the object then the appropriate bone,while holding shift.With the selection made hit CTRL-P and choose "Bone".The object should now follow that bone.

Sadly.Yes.Only one config based animation per selection.At least that's what I've observed. Otherwise it would be possible to animate complex objects from the config.And run them via script.For example the joints of some kind of mechanical biped. I can't for instance rotate a limb forward and back and up or down like a hip would move. It's either rotate forward and back,or,rotate up and down. Which is why those kinds of animations always look so strange.You can't add any kind of dynamics.

Thanks for the reply Faguss. Unfortunately my strongest skills are modelling,unwrapping,sculpting,texturing etc. :) I can see why it won't work trying to adjust the roll of the tracer object in it's current form.Not using "animate" at least.As you can't have more than one animation per selection. Creating two separate objects makes sense with that in mind. So I would assign a variable to the output of the GetBank function.Which is called by the craft. The output of this gives me a value which is then used to find the position for the created objects. Correct?