Yeah kinda!
But I mean it doesn't have to be one of those specifically, anything will do really. Could be a picture of a potato for all I care as long as it's functional :)
Yeah kinda!
But I mean it doesn't have to be one of those specifically, anything will do really. Could be a picture of a potato for all I care as long as it's functional :)
Can anyone recommend a fix for this in Linux? It's basically unplayable without it...
Those "markings" are explosive cords that would shatter the canopy before ejection. The Harrier need this since the pilot might have to eject while in a hover where no wind resistence can help the canopy get out of the way before the pilot is ejected.
The A-10, or A-164 does not need these explosive cords, so adding them would feel unrealistic.
Not down-voting, just stating some facts.
Related to this:
http://feedback.arma3.com/view.php?id=5076
I'm almost glad to see I'm not the only one with that problem.
It's a really annoying issue that leads to the game minimizing and accidentally clicking on another window on another monitor.
I could observe strange mouse movement behavior when doing this:
With these steps I can reproduce the error easily in no time (min. 2 Monitors needed to reproduce):
I found a tool that will lock the mouse to the active monitor, even got a profile management, so the mouse can just be locked to active screen while Arma 3 is the active window:
http://sourceforge.net/projects/mousenitor
For now a good solution to me until BI will fix this issue.
Hope I could help in any way, cheers :)
I use Windows 7. My second monitor is on the right side of the primary monitor.
I am unsure whether starting the game in windowed mode, then switching to full-screen, or something similar, might be a factor here.
Good to see this has been reported. I'm surprised there is not more chat on this topic. The task status is just "reviewed" and not "assigned"? How odd.
Strange that A2 had this feature working fine, but not in A3.
I think in A2, when you pressed Esc to open the main game menu, the mouse would appear and the mouse boundaries were then turned off, so you could click on a 2nd monitor to switch to another program.
But now in A3, the mouse boundaries are turned off all the time. In one game I was switched out of A3 5 times and given that the fire button is associated with the mouse button click, the consequences of this to the gameplay can be detrimental.
Even if you don't get switched out, it's also annoying as you turn/look around in game seeing all of the other active program windows "highlight" or show a selection scroll or seeing your task bar hints or nested windows lists appear in game.
Do you mean 'fences' or 'stone walls'?
This important ticket is now almost exactly a year old! Please BIS - assign this to someone.
Issue is still present and very annoying now that can't alter BIS functions with a new config anymore!
Yes, this is still an issue... Player is not respawned on start but moved to respawn_side marker.
Bumping. I think this ticket needs to be given priority! Come on BIS please allocate this to someone.
As a another workaround, attaching every respawn module to a trigger prevents them being used until the trigger is activated.
This results in the initial spawn being as planned in the editor.
The trigger can then be activated at any point to enable the spawn points, allowing "MenuPosition" to work as it should.
Unfortunately this does not affect players joining in progress, therefore this still needs to be fixed.
Soon would be good too.
A few more months and this important ticket will be a year old! A moderator will probably just close soon due to inactivity. I had this happen before. You have to wonder how that works - we the customers go to the trouble of reporting issues and keep the ticket alive - but due to BIS inactivity it gets closed!? Go figure. Well all we can do is hope - and keep annoying them with stupid messages like this one until it gets assigned or we die of boredom.
Confirm, problem still exists... push...
This is related to #14585
respawnOnStart=0 Doesn't work when using "MenuPosition".
Would be nice to have this fixed.
I am using version 1.38
This really is a major bug, I have spent 3 days trying to find a solution and only just came across this page, so it should be noted that a great many more people are likely to be experiencing this and simply giving up.
*Please fix this soon!*
1.38.128937 and its still a problem.
Confirm still not fixed as of end Jan 2015.
respawnOnStart = 0 has no effect - on start players are spawned at respawn_west or alternative spawn points and not at mission start position.
Would really appreciate it if you could fix this issue.
We can work around it but it's kind of IMPORTANT!
Confirm this issue still exists post 1.26 (yawn). It's now four months since this ticket was created and still no fix. This is a very serious issue and makes mission editing very tricky. I think it's fair to say that all players expect there to be a reliable working respawn (and revive) system in Arma3. And as far as content creators go, we expect a simple reliable method to incorporate this functionality into the levels we make - without this feature breaking our missions every few months when a new patch is released.
Please escalate this issues importance.
This issue also relates to the respawn module and BIS_fnc_addRespawnPosition / BIS_fnc_removeRespawnPosition. It seems if you add a respawn position at startup via any method (module, respawn_west marker, or BIS_fnc) with respawnOnStart = 0 - players are spawned to one of the predefined spawn points as previously mentioned.
The most reliable work around seems to be to delay the creation of a respawn point until post mission start. I'm sure there is a proper work around but since this is a really important issue I don't see why we (BIS customers) should constantly have to find solutions to these kind of problems!
Also experiencing this issue while designing a mission. Thought I would give this a bump since we just had a version change.
Really wish this issue would be assigned to someone. Don't understand why it hasn't even been reviewed yet. It's a fairly serious issue.
I can confirm, that
respawnTemplates[] = {"MenuPosition"};
affects your playable unit's spawn location/start position and will not have them start the mission from where you've actually placed them in the editor.
This is some kind of a major issue for mission building.
The ticket title doesn't describe the problem. (Too general)
Added repro mission.
This makes no sense at all. Of course mission makers want their units to start the mission where they placed them in the editor... not at a RANDOM location.
Like it is right now, teams don't even start at the same location sometimes.
Same applies to JIP, they are starting at a RANDOM location.
This is unacceptable and breaks a lot of missions. (Must add setpos workaround just to start where it is intended)
Hi,
although I cannot confirm the issue with respawn markers, I can with loadouts ("MenuInventory"), because those are selected randomly as well.
A workaround I found on the forums is this: put 'allowFunctionsRecompile = 1' in your missions's description.ext and 'BIS_fnc_initRespawn = {true}' in your soldier's init line. Made the random-loadout-thing disappear.
Anyway, this is not how it's supposed to be.
Hi, will process the request to bug report. Thanks :)
Bug\exploit is also actual in A2. If solution will be implemented in A3 it will be great to have it ported to A2 as well. Please do not just prevent pre-placed buildings to work with attachTo command as this feature is very important for missions where you need to remove certain buildings.
Here is related ticket to the problem of unremovable pre-placed map buildings and objects: http://feedback.arma3.com/view.php?id=6783
Can confirm. In my experience the issue is only present when hosting missions on dedicated server. Client hosted MP missions are able to use the predefined mission parameters. I assumed it was due to the idiosyncrasies of setting up a dedicated server. Our dedicated server uses arma3server.exe.
I have the same problem in Win 10. Just reinstalled Arma 3 and crash with the same msg every time I attempt to start my server (non-dedicated, both LAN and Internet). I have ticket# 25701
hi whenever i try to host the mission on both (lan and internet) my game crashes to desktop and getting the error: "Include file a3\functions_f\Params\paramWeather.hpp not found", i'm running latest version to-date also its the first time i experience such problem.
any solution would be appreciated.
Regards
Still experiencing this issue.
@heeden02 add " at the end?
You're right. I've tried it incorrectly (in SP).
hello i have the problem
include "\a3\functions_f\Params\paramWeather.hpp
everytime i want to launch serverand the game crash what is the solution?
@sms for me with the repo above, 1.27.126636 produces "ErrorMessage: Include file a3\functions_f\Params\paramWeather.hpp not found."
Same as before
I've tried this in lates dev, it looks like
#include "\a3\functions_f\Params\paramWeather.hpp"
works now.
Included in the zip are the crash files and a repo mission
Hello,
thank you for submitting the ticket. Also special thanks for the repro mission and the description, it made finding the problem much easier. We have reproduced the crashes and assigned them to programming department.
Have a nice day!
fixed now.
Still not fixed.
Hi,
thank you for reporting the issue. It has been assigned to our animation department.
Have a nice day!
This is really annoying in MP because if you're in the gunner position of an MRAP or something, you can't hear what anybody is saying because the noise is so loud.
Thank you for the video.
I've already reported this, but no one voted it up. The title of the issue is "Sound of vehicles and airkraft is too laud". You cannot hear notthing!!!!
I'm sorry I forgot to say that the sound is when you are inside the vehicle. I uploaded a video that show this.
Hello,
thank you for submitting the ticket. I was not able to reproduce the problem, would it be possible to upload a short video describing it? It would be a big help.
Thank you very much.
Mass closing tickets marked as resolved more than 1 month ago.
If the issue is in fact not resolved, please create a new ticket referencing this one and ask for it to be re-opened.
Hello,
as the_Demongod points out, it is necessary to reproduce the problem with vanilla game without any mods.
If you succeed reproducing it, please type a note and I will reopen the ticket. Otherwise it is resolved as "No bug." Thank you.
Yes true.
the only part of that I understood was "red damage" and "toolkit." I don't know why the Breaking Point Forum directed you here, but this is a place to deal with Arma 3 issues, you are talking about mods which are not affiliated with Bohemia Interactive, so reporting this issue here will not get your question answered.
If you can reproduce the bug with vanilla Arma 3 aircraft you can post here, but otherwise please direct this issue to the makers of your aircraft mod.
Its still a problem, using allMissionObjects is bad approach because it is VERY slow command unlike entities or vehicles.
Its ok to close this.
vehicles, entities, nearEntities do not pick up GroundWeaponHolder.
nearObjects and nearestObjects do pick up GroundWeaponHolder.
It seems that entities and nearEntities pick up everything in "ReammoBox_F" but not "ReammoBox". Legacy issue? GroundWeaponHolder falls under ReammoBox whereas most of Arma 3 crates are in ReammoBox_F.
Two interim workarounds to this issue:
systemChat str count (position player nearObjects ["GroundWeaponHolder",10000000]) doesnt seem to cost any more if the range value is lower. Perhaps, the function has to loop through the entire object space anyway to work out distance to the reference position. Still, its a cost to have to work out the distance.
player addEventHandler ["Put",{
private ["_container"];
_container = _this select 1;
if (_container isKindOf "GroundWeaponHolder") then {
serverRegisterGWH = _container; publicVariableServer "serverDespawnGWH";
};
}];
"serverDespawnGWH" addPublicVariableEventHandler {
[_this select 1] spawn {
private ["_obj"]; _obj = _this select 0; sleep 120; if (!isNull _obj) then { deleteVehicle _obj; };
};
};
Or you can use allMissionObjects "GroundWeaponHolder" which is fairly slow by might be better than nearObjects.
allMissionObjects is more elegant :)
Its a problem indeed, GroundWeaponHolder should be returned by entities command.
I too am getting this issue as of today. I can link my .rpt file if you would like but all it gets to is Item STR_CONTROLS_TOOLTIPS_IN_MAP listed twice
EDIT: everything STR_ is being listed as twice, I'll upload my rpt
Hello,
would it be possible to upload crashdupms the next time it crashes for you?
C:\Users\<Name>\AppData\Local\Arma 3\
Can you upload somewhere in winrar package please?
When package will be smaller than 5000k, you can attach it here. When package is bigger, please use some free sharing service and post link here.
How to find correct crashdump file:
Try to make the crash happen
Look into crashdump folder
Upload crashdump with latest date in name (crashdump is rpt + bidmp + mdmp file with same name)
Thank you.
They are different types so it is expected I guess.
I just finished validating the game files after deleting the add ons folder. It reached initializing add ons and then it gave me the game has stopped working message, I waited ten seconds, staring at my phone out of anger, and it did load.
I believe this has to do with the issue involving the fact that that animation is purely tied to altitude. If you spawned a house way up in the air (above 300m I believe) and placed a unit in it, it would be stuck in the HALO animation.
What we need is ejection seats...and then problem solved.
some valid points here ^^^
multiextension/multiuser I see it this way. Upon extension call, id is returned on submission. this id is then also passed back with result in _this array in extensionReady event handler.
This is related to #17943 - nearly duplicate except this issue deals with one very specific implementation suggestion without many of the pitfalls I mentioned in a note there.
Even with all of the below resolved, I'd like to point out the nature of this proposal:
It's about moving complexity away from the extension (worker threads) to sqf (continuations).
Away from where a few 'highly skilled wizards' (relatively speaking) have tools and languages that help deal with complexity,
to where the majority of users (sqf scripters often with no "real" programming experience) appear to be struggling with things like code structure as it is.
There are some deeper questions that need answering.
The latter would require that the functions are reentrant, and if the extension will "do something meaningful" it also has cross-call resources that need properly synchronized access.
In no case would it be appropriate to put all extensions in the same queue.
Analogous to putting them all in the same queue; you cannot suspend calls to one extension (e.g. acre) while waiting for another (a database call).
More importantly, how do you recognize which extension sent a return value back to you?
Two options OTOH:
addMissionEventHandler ["ExtensionReady_MyExtension", {hint _this}];
or making _this an array of ["extensionname","string"]
Imagine that when a player joins, you do a database check to get the data for that user.
Now two players joined at nearly the same time. You just got an answer back. Which object do you apply it to?
If we assume the queue above, you could track this manually in a sort of parallel queue, but it would be a chore and it would be error prone.
Another solution is to expand on the above: make _this ["extensionname",something,"output"] as a result of
"extensionname" callextensioncb [something,"input"];
At what times can the EH fire? I'm going to assume this will be checked at most once per frame.
Will a new thread be created for every request?
Will this be the game handling a "worker thread" for the extension instead of the extension writer?
Can be achieved in two ways. Overloading on right side being string vs array, or a new command like callextensioncb.
"Then create a sqf loop that would call extension until the result is ready to be collected."
Actually, you could do it all as
_ret = call compile ("ext" callextension "input")
and let the returned "reference" be the code for that loop, with the reference number embedded.
Again, moving the complexity about to where we have better tools for dealing with it.