That's intended behavior, controls group should not scale based on their contents. In many situations, you'll want it to remain static, while the content is scrollable (notable examples: diary text, field manual, functions viewer, welcome screen, etc.)
Since you are in control of its content, you can resize it manually (using https://community.bistudio.com/wiki/ctrlSetPosition), ideally applying some limits so it won't overflow outside of the screen.
I believe I explained a little incorrectly, I was referring to the scrollable overflow are rather than the actual controls group itself, but looking at those examples I see that the intended use is slightly different than I imagined. But I'll find a work around. Thank you for the reply.
The fact that onDrop doesn't fire on controls inside a controls group does need addressing though I think. I've made a mission and uploaded it to this bug report:
Thank you for the feedback!
I think this could be a lot more complex to do than we think.
Priority sure isn't high either, but if its not hard to do i don't see why not.
Good idea. I hope BIS will implement this kind of feature.
This would be a splendid addition!
Yeah i understand that thing i already had a big name in game almost like one =7Cav=SPC.Tandel.K but still you can get a option to optimize if got inside settings to put in profile section for optimizing this Chest rig . Making a new option with limited letters will allow us to produce this feature very well.
It would need some special consideration. how is XxX1337Y01o360nO5C0P3S247$WAGXxX going to fit his name in such a small area? Maybe it would be better to define a simple small last name.
Most of the people i see doesnt keep that much big names only few people use them .
Would be a neat feature, though it would just be easier to add a new chest rig and backpack called (Name) instead of (Kerry) to avoid clogging up with the one worn by Ben Kerry in the campaign.
Ok, well I cannot test it, as I do not have the RC branch code.
Only someone who has it could test your issue.
Basically what happens is that whenever the tail rotor gets destroyed, my main rotor is still intact, status white (obviously). But the MROT seems to be gone, even though it rly is still there. It's just the graphics that disappear - in other words, this is a graphical glitch.
Also, this problem is in regards to the RC build!
Any time I lost the back rotor, I did a sweet back flip into the ground.
I cannot reproduce this.
My ATRQ does not even break into a damaged model like yours. It just spins slower and the main rotor is still intact.
Although I think it is very wierd that you spin if you lose your tail rotor. Normally your tail falls like a brick and pulls your down to the ground.
If you integrate it they way it's described in the original post this is going to add a very powerful tool for addon cross compatibility.
Please consider this.
True. It would be the greatest config feature ever.
BI, please consider to add this feature.
It's very important for island makers.
This command is the only way to make all islands compatible with each other.
Island maker must override (instead of appending) global vehicle classes to add his own dust effects for his terrain.
So end users can't properly use several islands simultaneously because every island override dust effects of all other islands.
More info can be found here: https://forums.bistudio.com/topic/176156-how-to-customize-terrain-dust-sound-and-ocean/?p=2918406
+= certainly is "interesting", but not really useable outside of a few exceptions at this point.
You could say that this report is a feature request for that.
Thats exactly the issue I described. The grenade launcher class is inherited and therefore += doesn't work as expected.
As exemple with throw:
class CfgWeapons
{
class GrenadeLauncher;
class Throw : GrenadeLauncher {
muzzles[] += {"MGI_LacrymoMuzzle"};
class ThrowMuzzle: GrenadeLauncher {};
class HandGrenadeMuzzle: ThrowMuzzle {
magazines[] = {"HandGrenade"};
};
class MGI_LacrymoMuzzle : ThrowMuzzle {
magazines[] = {"MGI_Lacrymo_mag"};
};... then you need to repeat all grenade classes with their magazines (like handGrenadeMuzzle above)!btw, i never found the way to add a magazine for the GL_3GL_F launcher. It works for UGL_F (EGLM) but no way for the GL_3GL_F (commonly used in plenty of addons). Seems to need rewriting all guns just for that!
It doesn't. There is no difference whether you put stuff inside one config.cpp or into multiple aside from loading order.
Also for the record, += doesn't even work with "arrays with unkown previous values". In practice it ONLY works with Throw, because there is no reason to inherit from that class as every soldier uses it.
You can't for example add a custom silencer to the MX (compatibleItems[]), because the MXSW inherits from that.
Thanks for the explanation. Could you give an example usage (with Throw)?
I'm still trying to get my head around this operator (out of mere interest as it seems a fairly niche thing).
Slightly off-topic: Is there already a feature-request to turn += into a more general tool that *could* handle things like adding a custom silencer to the MX's compatibleItems[]?
When you say "not meant to work with inherited classes" does that also include inheritance inside a single config file?
I.e. what will the following produce (single config file only):
config1:
class A {
property[] = [a,b];
};
class B: A {
property[] += [c];
};
The description is correct - this feature was never meant to work with inherited classes. The goal was to create a simple tool to work add into array with unknown previous values (e.g. Throw muzzle with various grenades) and it works just like that.
There is currently no plan to change the feature, it may be possibly done in the future, but I cannot promise anything.
Still the same issue with version 1.34.
Any news on this?
Hello,
thank you for submitting the ticket. There is unfortunately no crash dump uploaded(crashdump is rpt + bidmp + mdmp file with same name). Did it create for you?
It would be great but i doubt it will happen
i think a nice 80s cessna 172., a ratty old beat to heck bush plane or even a piper cub, and some sort of small private jet would be perfect additions. but at the very least the bush plane.
Alot of the BI-milsims had atleast one civilian aircraft and since Altis is pretty big, it would be good to have a plane.
A few examples:
Operation Flashpoint - http://www.ofpec.com/COMREF/cfg_images/OFP/Cessna.jpg
Arma 2 (Well, a helicopter) - http://img2.wikia.nocookie.net/__cb20131205133343/takistanlifeuprising/images/e/e3/Mi17_Civilian.jpg
Arma 2 OA - http://img2.wikia.nocookie.net/__cb20131205132818/takistanlifeuprising/images/9/95/An2Aeroshrot.png
A twin engine prop plane would be pretty,
like this: http://img.planespotters.net/media/photos/original/083000/PlanespottersNet_083575.jpg
or this: http://www.travelizmo.com/archives/tecnam-p2006-personal-sport-airplane.jpg
I hope they make better civilian helicopter pilots though, because now we only have some with those "Worker" clothes.
Updated category: changed to Gameplay.
there is a pilot unit (C_man_pilot_F) but it seems to have been overlooked for the config ('crew' value i believe, oddly enough 'typicalCargo' lists a B_Helipilot for the M900). i'm sure this will be fixed soon enough. +1
Also, this is a gameplay issue, not a feature request. But I agree, the civi pilot should be in the pilot and copilot's seat.
An easy fix is just repaint the current helicopter helmet in white color and also any pilot coverall in a neutral color without banners.
Tow ropes would be nice. being able to tow anything rather. it would be nice to trailer logistics containers and tow disabled vehicles.
http://www.youtube.com/watch?v=RpF2TaU2SfA
This is what I mean, being able to have this in game would be amazing but to also have a good physic system in place to handle it would be good.
Related to #20084
Reproducible every time for me.
AI become unstuck if they can heal themselves, or are healed by an AI medic. Being healed by the player doesn't seem to work, even if the player is a medic. Being healed by another AI with a FAK results in that AI going into a repeating healing animation loop, during which the stuck unit is healed but remains stuck.
for reasons unknown then, the main island selection display does drill down, and does not show 'bohemia interactive'
Inheritance works fine, but "author" property ignores it deliberately. If it wouldn't work this way, all objects, weapons or terrains which are inheriting from the official content, but has no "author" defined, would be marked as "by Bohemia Interactive".
done!
FIXED, Mark as resolved
Fixed in v1.34
In the editor. Maybe it's fixed in the dev branch but not stable? I guess we'll see when Heli DLC is released.
Oh, that ticket again... http://feedback.arma3.com/view.php?id=7804
Are you executing it where vehicle is local? Tried it just now with Huron and MH9 on dedi, works like charm.
I have tested stable and dev.
Dev - works.
Stable - doesn't work.
It seems like this fix has been lingering for awhile in dev, but hasn't moved over to stable yet. So far it has skipped 1.30 and 1.32.
Mass-closing all resolved issues not updated in the last month.
Please PM me in BI Forums (http://forums.bistudio.com/member.php?55374-Fireball) if you feel your bug was closed in error.
Meh, haven't checked the SmokeLauncher itself...
It indeed has a magazine reload time of 60 seconds:
magazineReloadTime = 60;
So not a bug, please close.
Takes about 60 sec for the launcher to become usable for me. Removing and adding weapon cuts this time to 2 sec
vehicle player removeMagazineTurret ["smokelaunchermag", [0,0]];
vehicle player removeWeaponTurret ["smokelauncher", [0,0]];
vehicle player addMagazineTurret ["smokelaunchermag", [0,0]];
vehicle player addWeaponTurret ["smokelauncher", [0,0]];
That I know... Yet it doesn't happen for other turrets or mags, thus it is a bug.
This actually sounds thought-through and rather curious. I have to agree that a "gearbox" system would be more beneficial than the fast/slow/regular driving modes, especially on systems without analogue controls; Analogue controls, as well, could get the benefits of the system as well (incremental throttle).
As an extra thought, slight modifications of the existing vehicles' dashboards would be needed to reflect the relevant information (I believe helicopters do so as well).
Yeah we can still wish =)
It is your ticket, if you think it is not resolved then it is not resolved. As for "why not" commands, I know first hand how difficult it is to get even essential commands added or to fix broken ones. On the other hand, stranger things have happened in the past.
Hi. It's your decision to close it. I don't see why though. IMO it's a valid request and just because there's another way to do something doesn't mean that there shouldn't be an simpler array variant of the command.
I mean, we didn't "need" any of the addItemToXXX commands to begin with... could have just used other ways to do the same thing, akin to your example above. Which we were already doing until the commands came along.
My 2C. Cheers.