charonos

Maybe i am missing some information , but who says that the variables pointing to the components haves to be named "Component"? They just happen to be named that way and numbered incrementally by the "find component" function of oxygen. But i might be wrong. What happens if you make a simple cube and in geo lod you re-name the component "XYZ". If the functionality of the geo LOD isn't any different, then it probably doesn't matter how they are named.

The biggest flaw in the Arma engine is that it does not consider breaking glass in objects. It takes a major effort to simulate it, i had the same problem with a busstop and a phonebooth. It kills all realism if you are standing inside with bullets flying around you and there is no shattered glass. And shooting through a window with a glass texture on it feels unreal.

@[APS]Gnat: Thanks for taking your precious time to confirm that bug. Last thing i tried was stacking up little cube components of very small proportions (3m x 3 m x 3m) in the shadow LOD to see if maybe the large faces would cause the problem, but same bug again. Like you said it's a limit, most likely in the matrix transformations for ray intersection checks when calculating the shadows. AT NOON ! Man what an easy solution!

The small boxes are unconnected but they don't overlap, i can try that. What is an elegant way to use the different addons that you talk about, but for usage in visitor. Would i have to put let's say these 4 .p3ds on top of each other in the exact same position? I wanted to make it easier for map makers, this would be quite odd, but worth a try. Maybe it is possible to add the shadow p3ds as proxies to the main model? The thing is i experimented with how high can the shadow LOD objects be until the error occurs and it is only 20 meters. So i would need like 6 shadow p3ds. As the Telek1.p3d is 30 meters high, it must be all due to the dimensions of the individual components used. That would very fast get me above the 1000 triangle limitation for the shadow LOD.

It happens in bulldozer too, so i'm not sure if it could be down to the ingame settings. I have tried to use many small components in the shadow LOD, but still the same bug. I have only used Shadow LOD 0.000 and adapted the settings from the BIS hotel. (Very weird model by the way, some resolution LODs are totally empty ?! sbsource = shadowvolume prefershadowvolume = 0 Seems that if the hull of all components inside the shadow LOD exceeds certain dimensions then the bug occurs.

@[APS]Gnat: I agree, OFP handled it better. And certainly something that BIS should look into for future patches. The thing is that i am modelling a whole downtown scenario, and it is really annoying when you run around under high rise buildings and constantly have disappearing shadows, it kills the whole illusion. I will try to add more polygons to the shadow LOD, like double walls kind of thing, see if that helps. Shadow correctly rendered Shadow breaking up

Hi there, has anyone found a workaround for the shadow bug that occurs with big models? I am working on a high rise building (120 m high). I have tried to break the shadow lod into 3 polygons each smaller than 50x50x50, as this solved geometry lod issue with the guys that are modelling carriers. And i have followed all Biki advice on how to triangulate and sharpen the edges plus name the properties. However no luck, it seems that when the player has a certain viewing angle (mostly when the actual shadowcasting model is behind the player) then one face of the model will not be recognized as shadow casting and lets the sunlight through unoccluded. Anyone an idea?

Well like i said, use Eventhandlers! Attach this Eventhandler to your firing howitzer: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> NAMEOFYOURHOWITZER addeventhandler ["fired",{_this execVM "Shellcheck.sqf"}]; and then use this script (i called it shellcheck.sqf) <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _shell = nearestobject [_this select 0,_this select 4]; _shellpos = getpos _shell; while {alive _shell} do { if (format ["%1",getpos _shell] != "scalar bool array string 0xe0ffffef") then {_shellpos = getpos _shell}; sleep 0.0001; }; [_shellpos] exec "NAMEOFYOURSMOKESCRIPT"; where the impact position of the shell will be passed to your smoke script. If i were you i would convert denoir's sqs script (with his permission of course) into an sqf script, they excute faster generally. EDIT: I have not been able to attach EHs to ammo, that would be more elegant. Maybe try to confirm that with own tests in case i had a bug in my tests. Hope that helped you.

You won't have another chance than to use scripts, there is no ammo type in the game that simulates anything close to chemical damage, it is all direct/indirect hit damage that the engine processes for ammunition types. And why not use a script? I have no time to test it and it might not work with ammo, but you could try to "attach" a "killed" or "hit" EH to the shell and upon impact (destruction) the script will be called. Sometimes EHs refuse to work with object/ammo types though, you need to test it. Using a smokeshell for the artillery might not work because the smokeshell never gets destroyed (therefore also no EH would be called) and the smoke will be released right after the smokeshell is "shot". So you have to stick to normal types of shells with really small hit values like 1 or lower to focus more on the secondary chemical effect. Good Luck!

Hey Sigma-6, absolutely phantastic modelling job on those cars! It would be great to have some low-poly models of them for dense urban scenarios where the cars are more like static objects than actually usable vehicles. I have around 20 of your vehicles on that mission and the loading time is sky high. Maybe you consider adding some low poly ones in the future, would be much appreciated! Keep up the good work!

Does the information in this thread help you? :Environment sounds

For big battlefields the current AI sucks. For Arma2 i'd really like to see a new waypoint attribute, a mixture of "careless" and "combat". That would enable a mission maker to have the troops actually move as they are intended too when the AI "fails" and still have their weapons ready to fire and react to incoming fire but only if it really is incoming to the specific group of course. For example: As long as there is enemy aircraft or remote tanks in the area that are not even in the waypoint path the group leader is issuing that damn "Cover" command FSM. That kills all the action needed for frontline crossing troop movements. The AI just seems to scan the area for more powerful threats like infantry< tank and then make all decisions according to this simple assessment. And they stay in this command state way too long, sometimes 2-3 minutes pass after the threat is gone that the group leader "decides" to issue a "move" command again. I think that needs to be fixed badly.

Maybe i understand you wrong and you were not really specific on at what viewing situation the squares occur, but i assume the squares are due to the low resolution of your sat map. It might appear enough high in Photoshop, but if you stretch it onto the terrain it will introduce squares. Try the 10240 image and see if it changes anything.

@Opteryx: Exactly like that! Try it, it should work. Here a screenshot of my custom streetlamps: It is annoying however that we can't change the light's attributes that way, but at least we can place the right models in the map and one day we hopefully find a way to config that.

@Opteryx (and everyone else who needs the info) I made it work with a little "hack"!!! - Rename your custom model to "lampa_sidl.p3d" - Then browse for that model in VISITOR3's artificial objects definitions and place it on your map. Your custom model might need to (should) be also placed into an addon in the addons folder, i have it in there. Arma seems to check for predefined streetlamp model names when preparing the mission and only those models will be used as streetlamps. Odd, but what to do.