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.

Hi, has anyone successfully created a CUSTOM streetlamp model, placed it in Visitor 3 and had it lighting the area ingame? Placing "lampa_sidl" form buildings/misc works ingame. I have used the same named properties in the geo-LOD as the BIS lamp model and the same named memory LOD section. Don't think it is needed, but i even defined the lamp also in a config under class CfgNonAIVehicles. EDIT: A config is definitely needed, because i have renamed the model "lampa_sidl.p3d" into "xxlampa_sidl.p3d" and placed THAT in visitor3 and no light ingame. I will now reference the renamed model to my config and see what happens. RESULT: no light. Okay here is the config i have used: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgNonAIVehicles { class StreetLamp; class CHN_StLamp1 : StreetLamp { scope = 1; //model = "\CHN_UrbanPack\StreetLamp1.p3d"; model = "\CHN_UrbanPack\xxlampa_sidl.p3d"; }; }; I don't think it is possible to make a mistake in such a short config, but maybe i did something wrong. Maybe someone can help?

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!

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?

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

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.

withdrawn

In the second picture at the top, you can see where the problems are. The darker an area the denser the faces/point distribution there. So as already said before he should simplify the wheels and gearpods and ALL the stuff inside the back of the plane, that is not visible most of the time anyway, can be reduced A LOT! Then the model will be a nice addition to ArmA (once he's done with texturing/config)

GOOD ONE ! HEHE When your neighbours knock on your door just tell them that you'll shut up when they explain you how to correctly build an ArmA road layout

You can export from maya to obj and import obj to oxygen2. Watch out for normal orientation on individual segments of the object you import as they are reversed. You can reverse them back in o2. Also you have to check invertx in the import options to get the correct axis orientation. UVs are imported nicely to o2, which makes texturing much easier in maya than doing it in o2. The textures have to still be assigned in o2 to the faces though, as the obj import only brings in a name-placeholder of the shading group for some reason and not the texture file. Mass texture name change is advisable.

Hi, after 3 weeks of intense research and coding TroopMon V0.8 is ready for release. It features ground-breaking methods of ArmA dialog control and 2D to 3D selection functions, never seen before in OFP/ArmA dialog tools and will inspire everybody that is working on dialog-based addons. Changelog for update to V0.8: - New GUI feature: Viewport mouse-double-click unit selection! - Waypoints and any map markers can be moved and put now using the mouse on the map screen ! (before it was control buttons) - Waypoints can now be created in the 3D view by mouse click. - The camera can now be moved,rotated with the mouse. - New startup method (Thanks to Snakeman and Gaia for the inspiration) - Armament is now additionally displayed with images. - Key addon config attributes are shown in the details display. - All waypoint types are implemented now and working - Ammocount and efficieny display implemented. - Commandline option added. - Individual mouse action sounds created. - All ExecVM's replaced for spawns (Big thanks to sickboy for having the idea and doing it) - All _filename variables removed and moved&replaced by CHN_TroopMon_xxxx global variables in MonInit.SQF - CreateCenter.SQF if's replaced for switch with cases. - All static script paths replaced by (CHN_TMPATH + "scripts\scriptname.sqf") - 2 new viewmodes implemented, V5 suggested by Snakeman. - Many many bugs, mostly with the unit display and waypoints have been fixed. - cleaned up config.bin ---> no entries in ARMA.RPT anymore (suggested by KeyCat) - A comprehensive PDF-Manual that explains the usage has been written What is TroopMon? TroopMon is a GUI console for Armed Assault that is designed to help mission makers to monitor the combat behaviour of the placed units in their missions. FEATURES: - A camera with 6 Viewmodes: 1. A fixed 3rd Person view 2. Free/fixed camera mode that can be positioned around the watch-unit or independently moved around the whole scenario. 3. A gunner's view through the ironsights of the watch-unit's weapons. 4. A 1st person view to find out where the watch-unit is looking at. 5. A 3rd person view that cycles through a random selection of units. Primarily, units that are in combat are shown. 6. A top view onto the watch-unit suitable for CQB or urban scenarios. - Crucial battle data is constantly updated such as: which enemy is targetting,firing at or wounding the watch-unit with the ability to switch the view to that enemy to evaluate it. which enemy is the assigned target of the unit and which enemy is being fired upon by the watch-unit. - Troopmon works with all kinds of current/future soldier/vehicle addons and island addons. - The GUI console allows for very intuitive unit selection even in high unit count battle situations, selections can be made with the mouse. All status data can be shown or hidden by little toggle switches. - Statistics are calculated for a numerical overview of the combat behaviour. - New groups can be created and sent into the battle to try out new attack strategies or enforce groups of isufficient strength without having to edit/restart the mission. Waypoints for created or existing groups can be created and groups can be combined. Infantry can be moved around with transports using TroopMon-created waypoints. - Favourites and camera positions can be saved/loaded for repeating battle scenarios. Demonstration videos: This tool is also perfectly suited for addonmakers that just want to have a look at their model in ArmA using the freely positionable camera. If you have any suggestions for future versions or have noticed a bug, feel free to PM me about it. You can also let me know, how this helped you to improve your missions. Download links: ArmedAssault.info : TroopMonV0.8 Armaholic : TroopMonV0.8 TotalArmedAssault : TroopMonV0.8 freedatahost: TroopMonV0.8 file size: 641 kB

It might have to do with the size of your p3d. I remember that you have posted in another thread that your p3d contains a dozen buildings or did you just make it one building now? Also your paths differ from each other or you have just added the (my map dir) as a comment.

Ah i see, that explains something. The dimensions of the single .p3d must have been quite large and the .p3d in itself much more complex than a single cube. Interesting issue. The main thing is that you got it working finally.

Well, i am not sure about this limitation with simple models. I am aware of Gnat's old OFP carrier issues, but with low poly cubic houses, with most buildings i have made, i have no issues with geo or roadway (rooftop) LODs in any way and they are 215m high! If there is issues with the geo LOD, the problem can be solved by re-doing the geo LOD, checking normal orientation (not sure if this matters) and component name presence. @ hedcrusha : Did you try to re-do the geo LOD? I think the limitation is bound mainly to the roadway lod area covered to be less than about 60x60 meters.

Check your geo lod, it can't be the grid-relative size only, i have made huge skyscrapers that also work "outside the grid" as you call it. But i have run into that mistake too with big models, i suspect it is due to using one big polygon as geo lod, that sometimes creates errors. Re-doing the geo lod has fixed it sometimes.