drahcir_dier

I have been developing an addon and am attempting to include an MFD in my vehicle config. I have copied an existing MFD class from a vanilla vehicle, and replaced the Draw{} elements with the example polygon from the MFD Config reference wiki. The memory points, corresponding to the corners of the MFD exist in the memory LOD, and the names match those defined in the config file. Despite this, I have yet to achieve a visible MFD in game. When I open the vehicle in the config viewer all of the MFD declaration is there, but doesn't show up in game. Working under the assumption that I have missed something, is anyone able to address the following points of clarification that I have been unable to find info on elsewhere: 1) - It appears that the corner points in the memory LOD are the only features required in the .p3d file for an MFD to work. Is this correct? I don't need to add anything to the sections[] array in the model.cfg or name any components in the visual LOD or anything of this sort? 2) - Can all vehicles that inherit from LandVehicles have an MFD? I am currently working under the StaticCannon class .. Will this class support an MFD? (note that I have tried moving to using Tank, as I know tanks can have MFD's but this did not help) 3) - Should class MFD; be added to the class inheritance tree, and if so where. Namely, what is the highest level entity in the Land -> LandVehicle -> StaticWeapon -> StaticCannon hierarchy in which the MFD would first appear? 4) - Are there any restrictions on who, in a vehicle, can see an MFD? ... Am I not correctly declaring that the MFD should be shown to the gunner? .. Similarly are there distance restrictions on how far the MFD can be from the player to be visible? See below my current Config ... Hopefully someone can offer a suggestion or two as to what is going wrong .... class MFD { class MFD_keyPad { topLeft = "MFD_TopLeft"; topRight = "MFD_TopRight"; bottomLeft = "MFD_BottomLeft"; bottomRight = "MFD_BottomRight"; borderLeft = 0; borderRight = 0; borderTop = 0; borderBottom = 0; color[] = {0.85,0.85,0.85}; alpha = 0.5; enableParallax = 0; font="LCD14"; class material { ambient[] = {1,1,1,1}; diffuse[] = {1,1,1,1}; emissive[] = {1000,1000,1000,1}; }; class Bones {}; class Draw { color[]={0.61,0.62,0}; alpha=1; condition="1"; class PolygonTest { color[] = { 0.082, 0.408, 0.039 }; // use to define color class Polygon { type = "polygon"; texture = "a3\Data_f\Images\Mod_Base_logo_ca.paa"; points[] = { // space where texture should be drawn { { { 0, 0.1 }, 1 }, { { 1, 0.1 }, 1 }, { { 1, 1 }, 1 }, { { 0, 1 }, 1 } } }; }; }; }; }; };

I have modelled an ammunition box with an opening lid; When I preview the animations in Bulldozer, everything works exactly as expected, however then I put the object in the game the animation switches instantly to the end point, without the transition. The animation source is defined thus: class AnimationSources { class lid_source { source = user; initPhase = 0; animPeriod = 2.5; }; }; I can force the lid to an intermediate position using: _box animateSource ['lid_source', 0.5]; and I can manually implement an animation using: [_box] spawn { _val = 0; while { _val <= 1 } do { _box animateSource ['lid_source',_val]; _val = _val + 0.01; sleep 0.01; }; }; but in all cases the animateSource statements move instantly to the specified source value. Has anyone encountered this behaviour before? ... I have copied code from other objects in the same project that work flawlessly so I'm a bit stumped. The box is modelled as an Item_Base_F type ... Do some of the base classes not support animations in the same way as others?

Some good news at least: The "Greying out" effect I talked about above can be re-created by removing the "NoZWrite" command from the renderFlags array. Although no improvement on the latest problem.

My mistake ... it's right there in the wiki ... derp.

The lighter-darker effect with the new RVMAT is actually the window texture vanishing, as seen here: https://drive.google.com/file/d/1VH0ZEZ0BdQnllqlxoZIGugSNYeSjzrUB/view?usp=sharing The angular dependency is strange ... Faces -> Move Top doesn't help, which makes sense considering the texture is actually displayed correctly most of the time. I will look into the renderFlags and see if that helps. Is there any documentation as to what values the renderFlags can take?

I tried each of these to no avail. I did get some improvement by changing the rvmat of the glass to another "Window" texture in a3/data_f/ that fixed the "greying out" effect, and now simply causes the texture to get a bit brighter or darker .... Seems its related to the glass rvmat then ... Will continue digging.

A bunch of more digging around and I managed to fix the lighting issue; Moving to the "multi" shader turned out to be the solution. However another strange pathology has come up with regards to viewing the textures through windows. My building is assembled in five pieces, where each asset corresponds to one floor of the building. I am having a problem where the textures on level four vanish when viewed through the widows on level three, but ONLY when viewed at a particular angle: Textures appear correctly: https://drive.google.com/file/d/1trCD7ecHayZXgF9krpk10XPAzvYSGFTp/view?usp=sharing Move viewing angle slightly and fourth floor textures vanish: https://drive.google.com/file/d/10I-EXk0Sw8puhv4c7dWKfXQ6IG5-2mah/view?usp=sharing As another example, here is the second image again but this time with the upper left window pane shot out: https://drive.google.com/file/d/1gQUSdwy3GMtTsexi5HyyBmDlRz5QyvqX/view?usp=sharing Has anyone encountered this before? I have already raised the window textures using "Faces -> Move Top" without success; I am guessing because the windows and and the problem textures are not actually part of the same model. A Similar effect occurs with the ceiling textures when I stand outside the building and look up through the windows. Any tips?

As an additional test, I created a highly exaggerated nohq texture for the wall. The normal mapping is very apparent when viewing the model in Bulldozer, but appears to have no effect when loaded in game.

Okay; I can confirm that the example house in "Arma3_Samples", which has no rvmats, exhibits the same lighting problem. Seems like my nohq is not working at all and I'm getting the "default" lighting. baby steps .....

Unfortunately that Rvmat produces the same error. Subtle changes in the light levels because of the "ambient" and "diffuse" values but no change to the broader problem. I suppose one question is, how would we expect Arma to light faces in the absence of an rvmat? What is the default behaviour. It seems reasonable to calculate lighting based on the face vertices in the absence of any pixel data .... I might try copying one of the vanilla buildings and strip the rvmats to see if that replicates what I'm seeing in my building. Other things to consider .... - Do the nohq files require an Alpha channel? I am wondering whether the alpha is absent or set to zero and therefore the nohq may not be doing anything. I will double check my files. - Are there any issues associated with textures above a certain number of pixels? The wall texture is 2048x2048.

I'd tried triangulating and sharpening the edges earlier, with no luck. I can confirm though, by examining the lighting patterns, that the faces are being lit based on the illumination of the vertices only. Pointing the torch at the corner of a face strongly illuminates the half of the face closest to that vertex. Strangely, the lighting is maximum when illuminated from 45 degrees rather than dead on, which is inconsistent with the vertex normals shown in Object Builder. Based on the "whole face" lighting effects, therefore, it appears my rvmat isn't working as I thought. It is attached below ... hopefully I've missed something elementary ... #define _ARMA_ ambient[] = {0.9,0.9,0.9,1.0}; diffuse[] = {0.9,0.9,0.9,1.0}; forcedDiffuse[] = {0.0,0.0,0.0,0.0}; emmisive[] = {0.0,0.0,0.0,1.0}; specular[] = {0.5,0.5,0.5,0.0}; specularPower = 10.0; PixelShaderID = "NormalMapSpecularDIMap"; VertexShaderID = "NormalMap"; class Stage1 { texture = "iranian_embassy_addon\data\Wall_nohq.paa"; uvSource = "tex"; }; class Stage2 { texture = "iranian_embassy_addon\data\Wall_smdi.paa"; uvSource = "tex"; }; And here are the NOHQ (Created from the _CO texture using the normal map generator plugin in GIMP 2.0) https://drive.google.com/file/d/1OLzUb--85PdTm6MXQf7mgA29k5IOE3hg/view?usp=sharing and the SMDI file (R=1, G=grayscaled _CO, B = 0.8) https://drive.google.com/file/d/1_d7MlMzNGMoMvTZVgS5AtutS3Szb2Nru/view?usp=sharing

Thank you for the response @Jackal. Unfortunately, none of the solutions offered appear to have helped. I have played with the nohq textures a little more, and they certainly appear to be working as expected based on the visible lumpiness of the surfaces. But the specular lighting under torch light still tears in weird ways. I totally removed the shadow LOD and set the LodNoShadow variable to true in all remaining lods, and the problem persisted. I'm almost certain its not a shadow issue... which is one step forward. The tearing seems to occur along the diagonals of quad faces, as shown here: https://drive.google.com/file/d/1cdGSiT6G-nufkC9u1cQ1M2OuKQ_iSgYF/view?usp=sharing I had a lot of hope that changing the edges to "sharp", and thereby aligning the normals to the faces would fix the issue but it hasn't. A particularly striking example of the problem is shown here: normal lighting: https://drive.google.com/file/d/1FoaLxIiN2km_97YKh2A2MSyzWfCMyRd4/view?usp=sharing torch lighting: https://drive.google.com/file/d/180PYfFAoC3dFpY8P7cdh6hnKv4zzP53c/view?usp=sharing It's bizarre that of two adjacent faces, mapped together with the same texture and rvmat, and sharing the same properties, one is approximately correct while the other is totally black. It is like an entire face is either lit, or unlit, depending on some angle between the torch and the wall. Turning in place makes different triangular chunks of the wall light up or go dark. Walking up close to the wall doesn't result in the expected round spot, but rather a totally black wall. I was hoping that there was a simple issue with an in correctly chosen check box property.... Is someone able to clarify the function of the following settings in the "Face Properties" menu: In the "Lighting & Shadows" tab, how do the 'normal', 'both sides', 'position', 'flat', 'reversed' modes work, and to precisely which shadows does the property "Enable Shadows" apply. Does it mean those cast by the Shadow LOD, or something else? Similarly the "Z-bias" settings of 'low', 'middle' and 'high'. To what does this refer? Thanks for any help ....

I am looking for advice with regards to a lighting anomaly encountered with a custom building I have been working on. Under normal lighting conditions the wall textures display normally, however while using a directed light source, such as a torch, the textures exhibit bizarre shadowing. When the torch is pointed directly at the wall the texture turns completely black. Its obviously something to do with the texture settings or the nohq file or something, but I am not experienced enough to know what might be causing this issue. I have linked to two images below demonstrating the behaviour. Under normal lighting conditions: https://drive.google.com/file/d/106PQNgVPha1C9dwr5ViXWPFii-287op_/view?usp=sharing Under directed lighting from a torch: https://drive.google.com/file/d/17mkLZVnIfgTJAHycIu_SeEb15BeW3eBs/view?usp=sharing Any help would be appreciated. Cheers!

Thank you for the replies to this topic. The reason I was against the UserAction method was because I want players to have to manually shoot out the lock. Context menu actions are too easy. For future generations, I managed to achieve the behaviour I was after simply by placing a hitpoint at the lock location of the door, and adding the following conditional to my door opening script: // Check if door has been breached if ((_structure getHitPointDamage (format ["Door_%1_handle_hitpoint", _door])) > 0.95) then { _structure setVariable [format ["bis_disabled_Door_%1", _door], 0, true]; }; The realisation dawned that I did not need the "bis_disabled_Door_%1" variable toggled until a player actually TRIES to open the door. It doesn't have to trigger the moment the hitpoint takes damage. Duh ..... Thanks again 🙂

Thanks for that; However that mod appears to work on the nearest door, rather than the specific door a player may be looking at / attempting to breach. I'd like the locking / breaching behaviour to be intrinsic to the building itself. I'm aware of how the hitpoint /fire geometry system works; As noted in the original post, I've already implemented breakable windows in my building. However I am not sure I understand your reference to the UserAction class. I do not intend for breaching to occur via the context menu / user action system that is normally used for opening or closing the doors. Rather, I'd like to use the hitpoint to toggle the BIS_disable_door variable to allow the door to be opened once the appropriate area is shot out.