Sniperwolf572
-
Content Count
3304 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by Sniperwolf572
-
My current Arsenal wishlist is: Deferred loadout changes (Create a local dummy unit, display appearance it, on confirmation apply to the actual unit) Partial loadout loading (i.e. Cases where you want to load a loadout which contains an item currently not available in the game/arsenal. No need to block loading of the entire loadout if the current instance of Arsenal is missing just the hat you saved) Searching and filtering (i.e. Checkbox filters to only see RHS content, search bar so you can type in "Spar" and filter just those.) Unrestricted item use (i.e. Put mags for weapons that you do not have in your backpack, put facewear in vest, etc.) And a bit of a hail mary: Implement Arsenal as gear selector on the briefing screenGenerally, the Arsenal UI as it is, feels more geared towards a lightweight "browsing" experience. When used in missions to bypass equipping people from crates, I find myself fighting it a lot.
-
triggeractivation west seized. How to make it happen for debug
Sniperwolf572 replied to Tankbuster's topic in ARMA 3 - MISSION EDITING & SCRIPTING
Yes. 'this' in the context of trigger condition is a reference to the condition you'd set up with setTriggerActivation or when manually configuring the trigger. You can omit or combine it as you please. If you remove 'this', the trigger basically ignores the triggerActivation conditions and becomes a something like a waitUntil which executes the activation code after it is met. So for example, with the condition you can do the following things: this // Will activate according to triggerActivation myVariable // Will activate when myVariable becomes true this && myVariable // Will activate when triggerActivation is met AND myVariable becomes true this || myVariable // Will activate when triggerActivation is met OR myVariable becomes true -
[Solved?] Uhh... What the? (Head bug)
Sniperwolf572 replied to ahmedslimkw's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
The files are probably binarized. You'll need to unbinarise them with one of the tools like Mikeros to read them as plain text. Basically what is happening is that the material is modifying how your texture looks. For example, you might be using a material for a bald head, which tries to make the part of the texture where the hair is, appear like skin, and it alters the color somewhat. For example, this also happens with the "custom" face option in the profile, so someone made a mod to correct it, you can see there how the material can tweak the textures drastically. Unfortunately, I can't help you much further as I haven't really dealt with rvmats extensively. Someone in the modeling/texturing subforum might be of more assistance. -
[Solved?] Uhh... What the? (Head bug)
Sniperwolf572 replied to ahmedslimkw's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
No, the texture is the same, the material changes. This is the line that sets the default material for the head: material="A3\Characters_F\Heads\Data\m_white_04.rvmat"; These lines affect the material of the head when you are wounded: materialWounded1="Path_to_Face_Material_when_Wounded.rvmat"; materialWounded2="Path_to_Face_Material_when_Wounded.rvmat"; As you can see, the wounded material (.rvmat) is different. I'm assuming "Path_to_Face_Material_when_Wounded.rvmat" doesn't really exist, so there is no material applied to the head when wounded. If you want the head to have the same material as when wounded, you'd change the material property. However, pointing to a non existent material is probably throwing errors somwhere. You probably just want to create a new .rvmat file that does behaves as you want it to and point all the materials to it. Some docs for .rvmats can be found here and here. -
[Solved?] Uhh... What the? (Head bug)
Sniperwolf572 replied to ahmedslimkw's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
This is probably due to materials (.rvmat) and wounds. You use a default material for your regular material, but the wounded material is either different or it doesn't exist, so when the head transitions into the wounded state, a different material is applied that does not alter the diffuse texture (the .paa texture you used). -
As far as I'm aware, this has been an issue ever since alpha/beta. First noticed it while I was working on the fluid door/hatch opening.
-
Yeah, I mean, connecting to a remote computer on the internet, this so called "server", and letting it dictate to my game where the objects in the game should be? Not on my watch.
-
I'm not preaching to you, I'm just arguing for considering this in a rational manner. And I get what you are saying. Maybe someone at BI currently reading this thinks the same as you do and I'm providing my opinion why such thinking is not rational. Not implementing a good thing for the fear of blame when used badly by modders is disappointing. Especially considering there are already tons of ways to tank the FPS and crash the game anyway. Hence my comments about per frame execution. Might as well limit models to 5k polys, textures to 512x512, sections to 1, remove the ability to proxy in things, force all SQF to be executed in scheduled, remove callExtension or simply just lock "the platform" down and prevent modding altogether. Nobody will be able to harm FPS besides BI then.
- 52 replies
-
- 2
-
-
- sqf
- feature request
- (and 7 more)
-
You can also kill someone with a hammer or use it to build something, that doesn't mean it shouldn't have been invented since you can also hit a nail with a wrench. With that kind of logic, (on)EachFrame is absolutely dangerous and should be removed. Hell, why not remove scripting altogether, after all, even spawn and execVM have their performance impacts when abused. How about callExtension? And so on. Anyone who understands the difference between scheduled and unscheduled already knows the tradeoffs and probably is conscious about performance anyway. And there are millions of other ways to nuke performance anyway even without such commands. As you say yourself, isNil and various other commands that have been used to get the desired results aren't intended for this, but people who need to scratch this itch will use them. It'd be much saner to have an intended way of doing this, especially when reading such code and in case the current set of commands that are "exploited" for this change their behavior. Let's not repeat the same crap and all the solutions that happened over the years when people needed to execute code per frame before tools like onEachFrame were added.
- 52 replies
-
- 1
-
-
- sqf
- feature request
- (and 7 more)
-
RHS Escalation (AFRF and USAF)
Sniperwolf572 replied to soul_assassin's topic in ARMA 3 - ADDONS & MODS: COMPLETE
Not sure if you know about this, or if there is a different problem at play, but you actually can update your mods yourself on PW6 if you wish to do so. You just need to claim it if you haven't already. Might help avoiding people like me who actually use PW6 but want the update ASAP from racking up your bills. :P -
The major problem here is how you would you then deal with magazine reload animations? Different shaped magazines are usually not held/loaded the same way. For example M249 box mags vs STANAGs. What would define which animation is used? Weapons can't account for each possible magazine. Magazines can't account for each possible weapon. What if the mag is so big it requires holding the weapon differently? Does DayZ even deal with that or are there only mags in the similar shapes? Sure, it's just cosmetics, but hey, people have counted rivets in the past.
-
Task Force Arrowhead Radio
Sniperwolf572 replied to nkey's topic in ARMA 3 - ADDONS & MODS: COMPLETE
Fortunate timing, CBA now implements a settings framework for addons. :) -
I've recently experimented with various ways of moving the vanilla trawler around, including this one. It can work for animating it as a prop, as long as you don't care about the following: - The driver AI refuses sees the ship as an obstacle and will keep adjusting course to avoid the object. - The above can be avoided by spawning the ship with createSimpleObject. - The physics of smaller boats, their turn radius and the way they oscillate on the sea make the ship look very unnatural. - The AI, when forced to drive at a lesser speed than their usual one, will not drive at a constant rate, but will accelerate in intervals, which in turn results in problems noted above.
-
The Car base class has a set of default values. That should cover anything with wheels (besides bikes).
-
Custom vehicles that do not define new properties for the new AI driving simply inherit them from their base classes.
-
Spatial Awareness Improvements
Sniperwolf572 replied to solzenicyn's topic in ARMA 3 - DEVELOPMENT BRANCH
Considering the squad radar is meant to be "close range spatial awareness", I think that would be out of scope for it. -
Well, common sense applies certainly. But as I said, if the content features prominently and adds value to the campaign, I'd have no problem with "3 weapon mods and some hats". Problem is actually making those things matter. And that's where the question really comes in for the author: "Can I do what I want without this". And I believe that is the better measure. Could the author have gone without something, is anything of substance lost if that was not used, etc. Yes, optional content like "more weapons" which you can inject dynamically would work. But most of campaigns that can do that for all the content are of the "dynamic sandbox" type. You can't really craft a focused campaign and story around Bundeswehr, with voice acting in german and all, but if you don't have the BW mod, they're dressed in american NATO uniforms and riding Hunters. You can't really dynamically inject an island. All I'm trying to say is that it isn't as simple as "depends on mods = bad".
-
First things first, I'm loving this thread, it's full of interesting, thoughtful posts. Anyway, I'll disagree with the sentiments expressed above with regards to mods. What would be the point if every single campaign was limited to the narrow scope of the vanilla universe and assets? There would never be a modless campaign with Spetsnaz, Bundeswehr, USMC, WW2 factions in environments other than "arid greek island" and "lush pacific jungle island" where the civilians are "people in shorts, t-shirts and flip-flops" driving "luxurious car in 2 variants and a jeep wrangler". What I find more important is the campaign coverage of any content used. Requiring RHS because you want to use a single weapon/vehicle? No. Requiring RHS because you want to tell a Russia vs CSAT story. Hell yeah. Requiring 5 mods that cover the same thing? Nope. Requiring 10 mods that add something actually worthwhile throughout the campaign. Do it. Sure, if you need something small and simple, you'd include it in the campaign PBO. But you most certainly will not include terrains, factions and entire collections of weapons in them. Common sense is important.
-
This is usually caused by the units still having assigned roles (check with assignedVehicle) in the vehicle. Have you tried manually unassigning the units with unassignVehicle?
-
Well, that of course means that a mission should not last longer than 20 minutes. :P
-
I mentioned this a year ago in Skype chats, and even started writing something I was going to propose here, but I never really found the motivation to finish it, as it didn't seem like anyone would have given it the time of day. I'd kill for a source-style console. RPT already logs all the info such console would need. I'm not sure if writing to the RPT is still not async, but in reality, all this really needs is an ingame dialog that can be called up with a keypress that displays the same info the RPT's do.
-
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
It just looks that way because of what it is and how it's written. Rewriting the same thing in SQF would look complicated as well, but maybe a bit more familiar because you're more familiar with SQF at this point. Some things are impossible to do with SQF, some things are done differently. When/if the time comes, you'll get used to it and laugh at what you put up with in SQF. Think of it a bit like moving on from 2D editor to 3DEN. :) -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
So far the only assumptions as to what it might/will look like are from the Take on Mars implementation, which you can see an example of here, and this tweet. -
Scripting Discussion (dev branch)
Sniperwolf572 replied to Dwarden's topic in ARMA 3 - DEVELOPMENT BRANCH
Because it was developed more than 15 years ago, nobody modified it much since then and now they're developing EnScript for their future Enfusion engine. -
Bleh, I just realized you guys are talking about proxy magazines on weapons. That I agree, would probably be easier to do. I somehow got this mixed up with someone asking for damageable inventory items.