Now that I think about it, having a 'Stance Modifier Key' again, along with being able to set the 'specific' key for each direction of stance, would be about as complete as one could make it.
So someone with a gaming pad or mouse with a bazillion buttons can tweak it out however they like.
Just checked it out, it is still not proper.
You can assign mouse buttons, but you still cannot assign a mouse button in combination with another key.
The current default is 'LCtrl + W (A/D/S)'. What people are asking for is the ability to either map 'separately' the modifier key to whatever they choose, and that work with WADS. As it was before.
Or, allow for combination mappings for mouse buttons with WADS. Example being 'MouseBtn4 + W'.
I'm having trouble appreciating the removal of a 'control' mapping/binding option that has been here from the start.
I would agree with either putting it back or improving the control options to be inclusive of options we now don't have. Doing both would be pro I suppose.
I can think of several other places where being able to control properties of the ropes would be highly advantageous. And if a ball joint is way out of the question, this is currently the best 'rigged' option. /sadface
Technically, if you place a ShipX vehicle with a Roadway LOD in it, next to any other vehicle class with a Roadway, the same happens. As in the video.
Where all of those models have the same Roadway LOD in them.
Chatted with Dwarden, I'll add some files this evening to make this painless for you guys. :P
How much more info is needed here?
Turns out ShipX vehicles are the only negatively affected vehicles. Roadways in the other classes (TankX, CarX, etc..), appear to be fine.
Well, I'm going to release the boat this week with the Roadway in it.
I do not know what else you guys need regarding info. This was/is a simple to reproduce issue. If you put a Roadway LOD in a ShipX vehicle (and only ShipX class), and then place two or more of those vehicles in close proximity to each other, there is a direct, measureable, consistent, drop in FPS.
Does not matter where on the map you place them, in view or not. Happens 100% of the time. And when I say 'close to each other', it seems that is a precise distance, relative to the size of the roadway itself.
The more detailed the Roadway, the more FPS hit there is.**
Example of the same roadway (plus the already present roadway), in one of Milkmans little projects. Class "Truck_F". Note the FPS.
Really cool toy btw. :P
https://www.dropbox.com/s/wwzubwf9bxaha9t/arma3%202014-11-19%2019-36-14-65.png?dl=0
Current testing suggests, that the number of faces IS what has measurable influence on things. And not at what I would consider 'normal' counts. Much, much lower.
For illustration purposes, this is the current MkV roadway I'm testing with: https://www.dropbox.com/s/y3o2fizaselyvmg/current_roadway.PNG?dl=0
The roadway I created for the sample boat as mentioned earlier, looks like this: https://www.dropbox.com/s/9i5k7ol5ey46mg3/sBoat_roadway.PNG?dl=0
I've since increased the counts in the sample boat model (where I thought it was fine), and I can basically control my FPS via face count at this point. Which again, really makes me think there is perhaps some kind of background calculation going on. Given how the proxied roadways act on the vehicles (ie.. won't hook properly, regardless of autocentering), it seems almost like there is water interaction occurring.
https://www.dropbox.com/s/8rtebvnqfcnkc4i/carrier_roadways.PNG?dl=0
For what it's worth, every square meter of this roadway for the carrier, works, 100% of the time, with no FPS issues. However that is not a ShipX vehicle.
**Also note: If I remove the roadway LOD, there is no performance issues at all. But that is completely against the direction many of us modelers/modders would like to go with the new water features and the assets (you guys dont have..) to support it.
Hey Iceman, not really aware of a current asset that features a roadway? At least not in a physx vehicle. Konyos MH-47's have proxied roadways, does not behave like this. Although studying those models, I can not account for many things going on there.
I'm thinking it's tied to physx things, and have a sneaky suspicion it might have something to do with the water functionality.
I'll throw a roadway in the sample boat tomorrow, and report back. (haha, not sure if that qualifies as standard/unmodded model. we hope so right?)
This and a number of other animation sources really need to be compatible across all classes. Or at least wherever it's even remotely feasible.
@japa, I apologize for not getting back on this sooner. However, from the model making side of things, I don't think (or can't sort rather) how this is functional for us.
The issue I'm seeing is that the command is looking for vehicle 'name' apparently the 'vehcileVarName' equivelent. For me this is tough thing to work with as I'm creating a mod, and need to be able to work with the command via an init eventhandler.
The vehicle name is empty by default unless otherwise specified in the editor. I'm aware that vehicle will assume the players name if a player is in the vehicle. But again not really a solution for what we need as model makers need. I can see how it improves things on the mission making side though.
We really need to be able to check if the vehicles lights are on/off without having to rely on things such as the current vehicle name, or having a player in the vehicle. Which is historically the same issue.
Perhaps an actual animation source controller is whats really needed here. Again the primary issue being, using the 'light' key in-game will kill all reflectors, but there is no intuitive way to shut off related illuminated textures.
Hopefully this note gets seen. (?)
@japapatramtara, well played Sir! Testing shortly, thanks for quick documentation also! ;)
I need this so badly right now. Specifically for better/simpler control of illuminated textures and lights sources in a more realistic fashion. (ie.. if lights are killed in a vehicle via the default 'L' key, we could then intuitively automate shutting off relative illuminated materials. as pressing that button will kill all Reflectors on the vehicle, but nothing else.)
animSource = "headLights"; or something..
Currently finding myself fiddling with these things. Unfortunate nothing seems to work. Have a carrier, semi-submersible and super tanker that would all benefit from this.
Not to mention all the other cool stuff that could be built to make better use of all the A3 sea features and whatnot.
Super cool stuff. I'm all for getting everyone on the same page. Seems like the timing is providing a reasonable opportunity to do such. Let's not miss it!
Would really like to see the FBX importer, even if not fully functional. Those that are capable will utilize whatever does work. Which is surely better than most things we have currently. (3DSM locally)
Ooo just saw the FBX importer in the tools available for testing (hidden as exporter..). All pro. Don't remove it please!
Fair enough, and many thanks for the SITREP update and information relating to these things. Keeps us motivated and doing ;)
All of the above is mostly true to the best of my knowledge. Granted not dying by just running through the doorway is a welcome enhancement. :P
One the 'wth' moments I'm sure everyone goes through. I have managed to get through a few though. So not sure if it's an animation thing or perhaps some building weren't constructed properly. Can not say it happens all the time, but would say, most of the time you can not.
I will add credible/relative information to this. Need a couple days to strip a model and sort my thoughts on the topic though. This is something we've been trying to sort over at AlphaSquad for a bit now (man class related things, Mk V, VLCC, Semisubmersible). Anyone with insight/experience, please take part and share your knowledge.
If this is something that simply will not or cannot be addressed, it would be nice to know now. Before investing more time in what appears currently to be a still fruitless venture. :)
I'm all for the option of being able to turn it off. Even if by a less complicated config entry or similar would suffice. At this point in the game I don't think building it into the current dialog structure is feasible. Not that I would have issue with it of course.
Removing it altogether, would perhaps be a simpler task. Not sure what the general end-user opinion would be on that. But as it stands it is less than pleasing once you notice it. Looks like an unneeded overlay of sorts. That creates some arbitrary effect, of something. :\
+1 (+ a few others I know, who don't frequent this place)
Not much I can add beyond what Robalo posted, except that I hope this is given some very serious consideration. This is something that will be utilized and put to use for the community as a whole. Much like the ASR_AI package. (hint, hint, ... hint)
Just seems like a logical and manageable solution to something that could greatly enhance the gameplay at a new depth. Not to mention make life easier for everyone wanting to address these types of things.
None of our players over the weekend could join a JIP mission that had already started. This being in a remote dedicated environment. The only working solution we had prior to todays patch, was to disable or modset (@CBA_A3;@ACRE;@ASR_AI). Which was noticed when a player who did not have the mods loaded managed to JIP in.
[DEV] [AS] AlphaSquad.net | SquadServer | CBA/ASR_AI/ACRE
[DEV] [AS] AlphaSquad.net | PublicServer | CBA/ASR_AI
IP: 209.190.105.50
Version: (whatever is was :\ )
Can confirm everything appears to working as usual with todays patch. Very much appreciated!
In one of the largest sandboxes of a game that there is! With over a bazillion places for AI to hide and fight! Where every door, floor and battlefield can be a unique experience that you build!
It is completely fail, due to the lack of anything intuitive to utilize in building these experiences.
Doesn't take much brain power to sort out why this has always been a needed feature. The fact that doesn't come by default, seems to 'wow' new users daily.
For as long as this has been an issue, and as much of an impact that it makes on the overall look/feel of things ... I'm wondering if there is a complicated issue with implementing this.
If not, then I think the OP suggestions are spot on. Even a more abrupt, on/off for bloom/blur would be excellent.
I speak for myself and everyone I play with on this topic. Don't know anyone who actually cares for the motion blur. Granted some must exist somewhere, I'd be willing to bet it's not the majority.