corvaillian

Hi. When I use attachTo to attach object A to a moving object B, using an offset of [0,0,0], object A first moves to a position ahead of object B by a distance relative to the velocity of object B, before glitchily moving back to its proper position and attaching correctly. At first I hypothesized that attachTo was using object B's position in simulation time when first setting the position of object A, before settling on updating on the render time position of object B, which would have explained the positional gap increasing as object B's velocity increased. However, when I had a friend test the same, nothing of the sort happened. Instead, object A attaches to object B directly on the offset, no additional movement at all. Additionally, I tried deactivating the framerate limiter (and vsync) and attempted the same again. Same results. Both of us were testing with no mods and no startup parameters, on an empty VR map, with various different vehicles and objects. Ideas for what this is and/or how to fix it would be appreciated.

I'd like to report that in ArmA3 clients with aspect ratios at or wider than at least 21:9, the 148 is zoomed in in such a way that the switches on the top of the radio cannot be seen or interacted with, rendering the radio less functional on any such client.

Could you express what exactly you mean by it being the best you can do? Do you refer to the clipping issues or time issues? I guess I was unclear about that. I think what gives the ingame BR55 its strange look is a combination of its reflectivity and its dark texture since, say, the ODST medic does not seem to have this problem. The reflectivity seems to make the texture appear darker than it actually is, and it becomes an issue when the texture is already pretty dark.

If any of the modellers are available, I'd like to provide a bit of feedback. The first thing I'd like to talk about is reflectivity and lighting. I recall one of the modellers some pages back somewhere commenting that the reflectivity is fine, and that it looks as it would in real life, but I have to disagree. The screenshots of your model renders do indeed look fine, they look amazing in fact. But in the ArmA3 engine, dark-coloured textures like the BR55 or the ODST armors get a peculiar visual effect in the light where the textures look much more black or gray than they would look in certain other rendering engines, to the point where the textures start to look flat. This is especially noticeable on the BR55 and the ODST uniform, the ODST uniform appearing black-ish where it should be more gray and tan. Compare the BR55 ingame model to the darkest-coloured vanilla weapons like the Katiba or the Sting. Those two guns' textures can clearly be seen even in bright daylight while still looking metallic. Do you agree with this? Could using reflectivity and/or a colour scheme closer to the vanilla weapons improve the look of the ingame models? The second thing I'd like to discuss is the ODST uniforms. Ever since the first screenshots of the ODST renders there's been something bugging me about the design, but I haven't been able to put my finger on it until now, when I have been able to play around with the unit ingame. Anyone who has ever looked at Spartan, ODST or other full-body armor cosplay might have come across a couple of cosplays that look unusually pudgy or thick. The reason why is not necessarily because the wearer is fat (though this is certainly the case in some pictures) but rather because making a suit based on models where the armor is molded so tightly around the human body is quite hard. Cue ArmA3's outfit+vest system where the vest is rendered on top of the base outfit model. As I understand it - and please feel free to correct me here - there are various clipping problems with making a vest fit too tightly around the base model, and so the ODST body armor sits slightly outside of the undersuit with some space inbetween. As a side effect, this makes the ODST body look awfully chunky compared to the rest of the suit, reminiscent of those bad cosplays. Do you agree with this? Is this something you were conscious of during modeling? Lastly, do you think there is any way to produce a more compact vest armor? Would it be possible with scripting to make the undersuit model change to a slimmer version when the vest is put on?

So the MA5 shadow glitch is obviously the most jarring bug in the mod currently. Is there any chance you'd push out a hotfix for that in the near future?

Just have to make a quick post to say that you have totally nailed the Warthog physics. I'm just driving this thing all over the hills of Stratis and it's so satisfying.

So my client crashes on startup when I have both @TEI and all my other mods running, but not with just the CBA. I'll try and locate the specific mod folder that's causing it after I've played around with everything.

I honestly think spartans could work if carefully balanced by the mission maker. If the players are the opfor and they are made aware of a spartan's insertion into the AO through one way or another, then the spartan could maybe become less of an unfair killing machine and more of a high value target akin to enemy armor. And if, say, the players are blufor and they have a spartan on their team, the mission could maybe be balanced so that the spartan's assistance is required to safely complete the mission. Obviously, it'd be pretty gimmicky and full teams of spartans or TvT with spartans probably wouldn't work well. I still think it could work to some degree. The hype is real.

Sadly, the amount of work needed to make all-new skeletons and animations for each of the races and then implement them is way too great for any mod team to handle. The covenant is one of my favourite sci-fi factions of all time though, so maybe I can dream about it.

Oh god yes

Really? That's a shame, because I think the map's biggest bottleneck when it comes to visuals right now is the mid- to long-range look. Unless you have your object drawing distance at the exact same as your overall drawing distance, the jungle is just... non-existent in the distance, which can get jarring, especially if you spend some time in the air or high up. (When you stay purely on the ground it looks great otherwise) It'd require some ingenuity, but I think it is definately doable to make the long-range map textures decently show and represent the vegetation and urban structures, even when high in the air and no tree models are drawn. I'd suggest studying Bohemia's Altis and Stratis textures to see if there's anything to learn/copy from that. Also, speaking of mid-range: If you've got the know-how, I think it would be worth it to have a look at tweaking the various tree textures/models that change with range. Currently, the textures, or perhaps the lighting, goes from dark to bright to dark again as you move away, which can also get jarring if it's brought to your attention.

Out of curiosity, is the current long-range map texture a placeholder?

Holy shit, you are my lord and savior. Thank you, thank you, thank you. I've up until now been banging my head against the wall trying to figure out why my scripting attempt to get this same result refused to work, and I was getting afraid of my skull cracking soon. ...I'm still very curious as to why my script wasn't working though: zeus1Module addEventHandler ["CuratorObjectPlaced", { zeus2Module addCuratorEditableObjects [[(_this select 1)],true] }]; zeus2Module addEventHandler ["CuratorObjectPlaced", { zeus1Module addCuratorEditableObjects [[(_this select 1)],true] }]; As far as my knowledge goes (Not too far), this should have worked in theory.