Aqu

Heh. I was thinking about bit that kind of anims. Not running around but screaming and 'dancing' in flames before collapsing. Â Not sure if there are already suitable anims for all that. No idea how to make own anims. I added yesterday a feature that small flames stay on corpses bit longer and small trails of smoke and puffs come out. I remember looking at that, but I decided to name the selections like in the BIS mlods. I used iirc M4 or AK-74 as an example. There are some differences to the manual you mentioned. For example Arma weapons do not seem to have "zbran" ("weapon") in the memory lod. In the resolution lods they have used only "magazine" and "zasleh" (muzzle flash). Of course I could experiment with "zbran" and other OFP style

Yup. But if you already have the whole plant, then it will be faster to copy paste all leaves than go through all faces and pressing F6. Just note that if you copy-paste, you'll have the vertice two times (F6 only adds a face, not any vertice). So if copy pasting, it would be useful to select the whole thing afterwards and use points/merge-near to reduce vertice count back to normal. Otherwise it wouldn't be closed geomerty and cannot be copied for example into shadow LOD directly.

Mmmm... The model is quite simple. At the moment it has no animations (or bones). I have no named selections which I would have used in the config to somehow define the gun part which moves with the hands (there is a named selection for a muzzle flash, but no other special afaik). Not made guns before so I have no indepth knowledge of making them. If there is a way to define part of the model as 'immune' to hand movements I would like to know. I guess there are no other hand held weapons with such a requirement, so no big surprise if there isn't a way to do it in a single model.

At first I have to say, I'm no expert in textures, but... Never heard of two sided textures. A face is seen in O2 and in game only if the face is towards the viewer. Usually you should not see the other side because objects are normally closed. If your plant leaves are sort of 2D (they have kind of no depth) you could make the face (the leaf) two sided. Select the face and press F6. It adds another face to the other side. That is just AFAIK information (which is not much), so no guarantees and I might be talking complete bull.

Looks like cat got out of the bag  Don't get too excited, it is still heavily WIP. It was originally just kind of prototype or proof of concept. As you can see no textures or the gas bottles yet. It has a pile of technical problems still (game technical that is). One of them is what to define the bottles to be. If you make them part of the flamegun, then they move same way as you move the gun (not good). If it is part of the soldier model, then how could you drop them and pick them up (to be used by any solider class). Also making it MP compatible is bit tricky (in a nice way, without messing very much around). At the moment I'm thinking making the bottles same way as the RPG (even they are not weapons). As you mentioned the Pacific...I actually got the idea when I watched some USMC footage of taking Iwo Jima. I thought we got to have one of those in ArmA (not the island, but the flamethrower...well the island would be nice too ). About flame tanks. The file comes with the backpack flame thrower plus the vehicle mounted one which has a bit more range and bigger tank. USMC used couple of Sherman types with a flamethrower, but no idea if they were used elsewhere. The vid doesn't give a full idea what it can do already. The gas is sticky (like IRL it was thickened gasoline) so it gets stuck to walls or trees. It also stays burning on surfaces for some time like shown in the vid. Night time the flames light up the surroundings. Even if the burst doesn't hit you directly you can get burns from splashes.

Yeah yeah. The meaning what I said at least was that the armor can be as good as some modern tank. I didn't mean we copy them 1:1 from Abrams to Tiger for example. Of course we should work some formula to convert the real data in the game data. Just like with the weapons hitpoints. That's my opinion. There is some basic armor value system for different vehicle parts in the config. So I don't think we have to use just some average. The script system suggestion...Well I guess that might in some situation, but what happens when the hit kills the tank straight away? To my experience you cannot bring dead back to life. I suppose it would work with the setDamage command? If so, it won't work because you cannot set what parts in the vehicle the damage goes. E.g if you have 50% damage and you get damage 60% and then you try to negate it with setDamage 0.5 It won't work quite right because the set of damaged systems would be different. I tryed that some time ago and what happened was that using the  setdamage it seems always to clear e.g wheel damage. Someone who has more information on this could comment, but AFAIK with setdamage it won't work quite right.

Like the topic says, is it possible to make nonlinear indicators? I should make a speed indicator, but in real life it was heavily non-linear, meaning that the speed change from 0kph to 100kph made the needle move much more than what it made at 600-700kph. I would be happy if I could make it even piecewise linear as I tryed to divide it to ranges 0-100,100-200,200-... and then using script to animate it. But it seems I cannot change the animation phase anywhere except 0 or 1 (with the animate command).

I have looked too much of the config and it won't surprise me if there is some dumb mistake. I'm not even sure anymore is the value the speed source gives in m/s, km/h or 0..1 relative to the top speed. Tryed all of those, but all work wierdly in some way. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class IndicatorSpeed100 : Rotation { Â type = "rotationZ"; Â source="speed"; Â sourceAddress="loop"; Â selection="needle_speed"; Â axis="axis_ind_speed"; Â memory=0; Â angle0=0; Â angle1="rad 40"; Â minValue=0; Â maxValue=160.9344; }; class IndicatorSpeed150 : IndicatorSpeed100 { Â angle0="rad 40"; Â angle1="rad 90"; Â minValue=160.9344; Â maxValue=241.4016; // 150mph }; class IndicatorSpeed200 : IndicatorSpeed100 { Â angle0="rad 90"; Â angle1="rad 135"; Â minValue=241.4016; Â maxValue=321.8688; // 200mph }; Â class IndicatorSpeed250 : IndicatorSpeed100 { Â angle0="rad 135"; Â angle1="rad 190"; Â minValue=321.8688; Â maxValue=402.336; // 250mph }; class IndicatorSpeed300 : IndicatorSpeed100 { Â angle0="rad 190"; Â angle1="rad 235"; Â minValue=402.336; Â maxValue=482.8032; // 300mph }; class IndicatorSpeed400 : IndicatorSpeed100 { Â angle0="rad 235"; Â angle1="rad 265"; Â minValue=482.8032; Â maxValue=643.7376; // 400mph }; class IndicatorSpeed700 : IndicatorSpeed100 { Â angle0="rad 265"; Â angle1="rad 340"; Â minValue=643.737; Â maxValue=1126.5408; // 700mph }; This particular example works without shaking, but starts from 300mph (when speed=0). It seems almost like it is showing only the class IndicatorSpeed400, but not correct.

Yes, that's true, but that's why it makes no sense doing that. This WWII stuff do not have to fight against the modern BIS equipment, so let's just add Tiger the same amount of armor as Abrams. I commented some time ago that if we do not try to scale these to modern equipment but use happily bigger armor values and bigger hit point values in guns, we should minize the MG can hurt tank problem. @rip That new terrain looks a lot better now Maybe you could add few rocks here and there?

Good suggestion, but it doesn't seem to work. Those indicator classes fight against each other for the same needle. Even if the speed is outside the range of a class the class wants to place it constantly at the boundary place, so it seems. The result is erratic moving and constant shaking. Â

I looked through it many times, but I cannot find any clear mistakes. Are you absolutely sure it fires something out of it (not just reducing the ammo count) so that you see the bullets hit somewhere? Sometimes tracers are hard to see in daylight so try night time too. Maybe you could try replace your bullet class temporarily with some BIS rocket class and shoot those out of the gun. If you see them, you have something wrong in your bullet class

Still having a problem? Do you mean it doesn't shoot anything or that you just cannot see the bullets? When I made rockets and missiles I added "rocket_1" and  "rocket_2" into the memory lod as the generation place same way as the gunend with MGs. Then I added in to the vehicle config in CfgVehicles something like... <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> memoryPointLMissile = "Missile_1"; memoryPointRMissile = "Missile_2"; memoryPointLRocket = "Rocket_1"; memoryPointRRocket = "Rocket_2"; But I have never tryed to make bullets out of rockets BTW: you weapons classes etc have lot of unnecessary stuff which do not work in weapon anyway (AFAIK), like the count.

Well, true in a small amount. It depends also where you stand. If it hits a wall (building or armor) and you are behind the wall the blast effect can be very lethal. Anyway I would not model it same way as normal high explosive rounds. Actually after thinking it bit more I think it could be modelled as almost fully kinetic (yes, you read it right, kinetic) ammo, but if using the variable "typicalSpeed" in the config and setting it very low, say 1 (dunno if it works with 0) it should have the same penetration power no matter how fast or slow it travels. e.g. a very limited ammo config example (only the relevant data shown). <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class myHEATround { Â hit=500; Â indirectHit = 1; Â indirectHitRange = 5; Â explosive = 0.05; Â maxSpeed=800; Â typicalSpeed=1; // <-- for HEAT!!! };

The deflection for example is not just the hit angle, but depends on the size of the shell and the relative thickness of the armor (i.e if shell is bigger than the armor thickness it is more likely to go through). Â It is also dependant of the shape of the round and how it affects is dependant of the angle it hits the armor. To make this even more tricky you could take into account the armor and the shell hardness and quality. Often multiplier tables were used to convert the armor value of a plate in an angle to get the effective thickness against a certain round. For example German AT rounds against a plate in 40 degree angle: APCBC: 1.60 APCR: 1.85 HEAT(any): 1.30 What I'm bit annoyed is that there isn't a way to change the flight characteristics of different ammo types. Some ammo types which had a better penetration in closer range could lose more power with distance and at some point they could even go below the otherwise worse ammo. Also some types are clearly problematic. Think about HEAT (shaped charge anti tank round). The penetration value is not in any way dependant of the range (or actually the velocity) because it is not a kinetic ammo. So should you put the explosive value to 1.0 in the config? I say heck no, unless you want people to use it against infantry. Also the HEAT penetration value doesn't change same way with the armor angles, like kinetic types. For HEAT type the effective armor thickness is more like the triconometric distance throught the armor

AI shoots insanely accurately. Maybe the AI dispersion should increased for the weapons? Hard to say was it realistic if don't know the distance, what part it hit, were you damaged already... IRL also the angle it hit plays a major role. About historically... Especially the Jagdpanther sidearmor (and rear) wasn't very thick (40-50mm), but the slope (30 or 35 deg iirc) helped. It is a tank destroyer (without a turret), not a tank, so it is better in a defensive role.

This got to be some sort of a language problem that we have problems to understand each other fully  The above script you had used is the same as I have used, except changed it slightly, but the principle is still the same. I try to explain it bit differently. You shoot all the bullets from the same memorypoint (in your case the left MG). It only moves every other bullet after it has been shot into the line with the second MG. It might look like it shoots from both MGs at the same time if the rate of fire is high and the config is set that it shoots 2 bullets per burst. That is just good because that's what the script tryes to mimic. If you still wonder what it is doing, put the script to add some global variable for each handled bullet and also from which barrel. You have 1000 bullets for the MGs (unless you have multiplied it by the number of guns, then 2000). It should give 1000 bullets and 500 of those moved to right. You could also put the rate of fire really low, like 30 per min.

Mmmm...you want both 7.92mm guns to shoot at the same time, but they do not currently (a) or they just happen to shoot at the same time which is not wanted (b)? AFAIK (a) is not possible. What I did, I used the same script, but tweaked it a bit. Because I have 4 guns of the same type, I multiplied the rate of fire by 4 as well as the number of bullets. This way the output of metal is same as having 4 different guns. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _unit = _this select 0; _gun = _this select 1; ?(_gun != "Browning_M53x4") : exit _ammoCount = _unit ammo _gun; _bullet = nearestObject [_unit, _this select 4]; ?( isNull _bullet ) : exit _n = (_ammoCount mod 4); ?(_n == 0) : _offset = [ 0.190, 3.2, 0.398]; ?(_n == 1) : _offset = [-0.190, 3.2, 0.398]; ?(_n == 2) : _offset = [ 0.110, 3.2, 0.528]; ?(_n == 3) : _offset = [-0.110, 3.2, 0.528]; _wpos = _unit modelToWorld _offset; _bullet setpos _wpos; exit The plane (P-38) has a 20mm cannon too, but the script does nothing to that ammo. This shoots all the bullets from the same memory point, but move the MG bullets to the end of the MG barrels.

It is there. Your problem is that it is not in the same list as rest of the German tanks. If placing buildings in the editor, you should be prepared to adjust the height. Sometimes they are automatically on the correct height, sometimes not. Buildings have normally a thick base so that they can be placed on slopes without exposing bottom of the building. Change the height, so that the stairs start at the ground level. Maybe that helps. (i.e put in the init line: "this setpos [getpos this select 0,getpos this select 1,(getpos this select 2)+xyz]" and replace xyz with the amount you want to raise or lower the building)

Not quite sure what you mean here. I do know these planes what we have now did not have a radar, but in default Arma it is found in vehicles not having a radar in real life either. Finding anything without it is hard. I have tryed stopping V1s in spitfire and it is really hard to spot them in time. Also...the 40mm AA...do you have time to look for that, because AI does absolutely nothing to stop V1s. My guess is that the max speed a target can have is too low (maxLeadSpeed).

Few problems: - spitfire (and possibly other planes) do not have that compass string on top of the screen and no "radar rectangle" to show the nearby objects (red and green squares). - 40mm Bofors AA gun: This might be because of the max leed speed or Ai engage range or something, but AI doesn't want to engage objects flying fast (>500km/h?) at low level. It does raise the gun barrel but shoots nothing. Human player has damn hard to hit anything either: No tracers or they are so dim that no idea where the shells end.

Some planes have this problem that it sounds great at one rpm level but not so good in other. Like the Spitfire sounds good in flight, but starting the engine and taxing slowly it sounds odd. I had to tweak the Allison engine sound in P-38 a lot to make it sound ok in all the rpm range.

Thanks for the suggestion. I tryed all sort of combination with logic last night. I was able to put logic into the crew parameter of the vehicle config (crew="Logic"). The vehicle was set to Opfor side and it indeed was shown and recognised by bluefor as an enemy. Bad thing was that it behaved in many sense like a true pilot messing up the scripted autopilot (or actually I don't know which one gets messed up - the pilot or the autopilot, but it ends into vertical dive or heads into some wrong direction). It can even eject. I haven't been able to put any other crew position into a 'plane' class without first making a turret into it for the other crew member. But that doesn't mater since AI doesn't seem to care so much other crew members in a plane class. Pretty frustrating, but maybe I have to leave it unmanned. I doubt would AI be even able to hit it. A small object going fast at low altitude means little time for AA guns to track it. EDIT: Now I managed to make it work. The the problem I had was "ejectDamageLimit=1.0" didn't seem to stop them from ejecting. It was fixed either by when set it to 0.99 or that I added "ejectSpeed[] = {0,0,0};". The crew is now 1 logic gunner in an invisible turret.

I have tryed to make an unmanned vehicle (kind of a cruise missile) so that it is considered a threat to the enemy AI. That is in a way that AI shoots at the vehicle. It seems the vehicle needs to manned (and also looks like needs to have a driver/pilot). When you create an unmanned vehicle it is neutral and after putting there a soldier it turns to green or red. It stays in this color even after it gets unmanned again, but that doesn't make AI attack it. It seems it is only based on the manning crew side and is it alive. So far what I have tryed: - putting a 'zombie' driver -> doesn't work, because it interferes the 'autopilot'. (i.e. Â driver vehicle disableAI "MOVE", ....) - kill the zombie driver -> doesn't work because AI stops shooting the vehicle after that. - putting some other crew member than driver/pilot (e.g. gunner) -> doesn't seem to work in planes Also it would be good if nobody can see anybody boarding or ejecting the plane. IF you kill the pilot, the rest want to eject. Any more ideas?

I have a problem that the very dark areas, especially black, shows transparent. In a tinted way, like looking through dark sunglasses. The darker the color, more transparent it is. I saved the texture as png in a paint program (gimp) and converted it into paa in Texture Viewer. The black areas do not look transparent in Gimp or Texture Viewer. The oddest part is that some polys of the object become invisible when looking through the black transparent part. You could think this is some sort of occlude thing, but the polys actually belong the same object/section (wing).

Civilian/Ship/Isolda