JOHNBELLO

bump, at least for the 3rd question.

Hello. First of all i posted this issue in /r/armadev already but to improve the chance of help i thought about posting it here aswell. http://www.reddit.com/r/armadev/comments/1rgbma/a3_setpos_and_maybe_jip_issues/ I'll try to explain this issue we have (the second one in the reddit thread) Our game is a persistent game that saves player's position and gear (like DayZ - i have no other comparable game/mod) and tries to set them again when a player reconnects to the game. Here is how we're doing it: We have a debug area where we placed 20 "playable" characters that serve as JIP spawn points. So far so good. On several events we save our player's informations in our database like his gear, position etc. - that seems to work since the coordinates we get were always correct. Now we use these informations to set our player up with his gear and then we setPos him to his position coordinates. Problem now is, it works like 70% fine but sometimes totally at random you either spawn a bit off of your saved coordinates (with a bit i mean 100 meters or more) - or even in the debug area, like you were not moved at all. We are not able to definitely reproduce this issue, only thing is that we "think" it might be caused by switching the player slot in the lobby. But we cannot be certain. So what we'd like to know is what might cause this issue, how to fix this and if we maybe are doing this whole "load gear and JIP" system totally wrong. How does DayZ achieve this feature? iirc the players were while they played also somehow in the debug area what would mean there is some kind of copy of the player at al times - but why and how? Anyone experienced enough and able to help us out here? If you need more informations we will deliver what you need to help us fix this problem.

So, it looks like we were able to fix the issue using a workaround like Johnson11B2P suggested. This is what we're doing: player setPos _position; // _position diag_log format["setting player's position to: %1", _position]; sleep 1; _real_player_pos = getPos player; diag_log format["position that has been set: %1", _real_player_pos]; _tries = 0; //sleep 1; while {abs(abs(_real_player_pos select 0) - abs(_position select 0)) > 10 or abs(abs(_real_player_pos select 1) - abs(_position select 1)) > 10} do { diag_log format["player pos is %1 which is not target pos %2. retrying...", _real_player_pos, _position]; hint format["position wasn't set correctly; trying again... %1", _tries]; sleep 1; _tries = _tries +1; player setPos _position; sleep 1; _real_player_pos = getPos player; diag_log format["player pos is %1 which is not target pos %2. retrying...", _real_player_pos, _position]; }; player setDir _facing; player setUnitPos _unitpos; if (_unitpos == "PRONE") then { player setUnitPos "DOWN"; }; if (_unitpos == "CROUCH") then { player setUnitPos "MIDDLE"; }; if (_unitpos == "STAND") then { player setUnitPos "UP"; }; The sleep's seem very necessary since removing them resulted in still spawning on the debug area and never actually firing the hint or diag_log's. Now, while we also figured out that maybe disabling the blackscreen while spawning (:rolleyes:) was a good idea, we found out that if the problem happens we get set onto land, warp back to the debug area - then our loop fires, and we get set again to the correct spot. We're using the abs to make sure that logging off on a rock or some weird place that the setPos cannot set you on does actually not end in an endless loop and sets you just a bit aside - while we did not change the setting for this issue it works anyways - we don't really know why but we're happy now that it does. So far it worked every time and since the loop loops until it's right i'd say we fixed it. Thanks for helping out. If there is anyone that has any other ideas or actually knows a real fix to this instead of a workaround, since workarounds are always kinda dirty, i'd like to test other options out.

Yeah we thought about that.. it seems as the only fix to this issue for now. weird problem indeed. Maybe someone else has encountered something similar and can share their experiences with this?

to get his position values (including stance and facing) _player_position = getPos _player; _player_facing = getDir _player; _player_unitpos = unitPos _player; then we save it into the db. so getPos - but saving the player's position seems not to be the issue since we checked and every time the coordinates were correct. on the spawning we load our values and set up the player like this: player setPos _position; sleep 1; // to give it some time player setDir _facing; player setUnitPos _unitpos; if (_unitpos == "PRONE") then { player setUnitPos "DOWN"; }; if (_unitpos == "CROUCH") then { player setUnitPos "MIDDLE"; }; if (_unitpos == "STAND") then { player setUnitPos "UP"; }; but we also tried setVehiclePos, setPosATL basically with the same results. And again, weird thing is that it works fine most of the time but just sometimes it bugs out and either fucks up the position or seems not to setPos at all. That's what made us think that it is some kind of timing issue... Like the code gets interrupted in a fraction of a second if that's even possible.. but even when we add sleep's between every line it still seems to bug out.

Hello. On our mod project we have every player in the game as a custom civilian. They play against each other since it is possible to join several different groups due to ur own custom group system. However now the problem is, that uniforms have these weird restrictions, that make sense in a game where bulfor fights opfor fights independant, but for our game this is kind of an issue. So, is there any way to remove the part that restricts a uniform to one faction? Is there a flag to set for the player, or is it in the uniforms itself? Also, kind of weird because a while ago i am pretty sure we were able to use all uniforms - but i cannot remember if we used a civilian as player character - so might some class be able to use them all? (independant maybe?)

Thank you very much. Also i found out that i seem to be retarded since i used a standard blufor unit to enable the preview, what made the game use that character for my testing - ofcourse it could not work then. Already wondered why i had a civilian not being able to use civilian clothing :D Thanks again, helped me out a lot!

I'd like to know if there is a problem with the new attachments? Because i was not able to attach the new sniper scope to anything, also just the greyish reddot handgun attachment was attachable somehow.. this seemed weird. Is this a known issue?

So, simple question - is it possible to access the 3D editor right now through the game itself since it has left beta state, or is it still the old method? Or how do you people edit your maps and add new buildings and stuff? Also, does it only happen to me or is it "normal" that everything i place seems to stand way off ingame? Is there a fix for this?

Hello. I'd like to know if there is a way to create a right-click activated context menu? I mean, i can only think of one example right now, and hope the arma veterans won't hang me for it, but in dayz (arma2) you have on some "items" the ability to do a right-click and it will open a little menu that allows to interact with the object. (like, "use bandage") Is there a function in arma2 to achieve this tthat does not exist in arma3 anymore? Or is it, and this might be obvious to some people if it is true but to me it is not, just a dialog that opens at that position? How to control that - or how does the game know what item i am hovering to open what dialog in that case? Would be nice if someone is able to help me out on this one. Thanks!

yeah, sorry that i don't really see a point in plowing through 500 sites and over 5k posts in order find my answer. thank anyways for clearifying.

just quoting myself in hope to get an answer.. is there any information about this?

Are there any informations yet about if and if yes, when altis is coming to the dev branch? we're kind of stuck at the moment until we'll get our hands on altis, so that would be nice to know :D

Hello. I haven't found anything posted about this issue yet so i decided to open this thread while hoping to find out if it is an ArmA3 issue or something related to our mod. Since a very long time we have weird issues with NV goggles in multiplayer testing sessions of our mod and we'd like to figure out why or what exactly is causing these issues. So, we spawn NV goggles into a crate (as additem, globally ofcourse, already tried addweapon and others but that did change nothing) and the player that hosts the game has no problems whatsoever - looking into the crate, picking them up, wearing them - everything perfectly fine. A client player however can't do anything with them - as soon as he opens the crate he gest an missing picture error for the nv goggles, they exist in the crate but without an icon, he can't pick them up or wear them, unless he puts them from the crate on the ground tab, and then inhis inventory - he then is able to activate them, but they are not shown visually on his body. Weird thing, what makes me rule out that i spawn them some kind of wrong, is that even if we add NPC's and they have NVGoggles (standard NPC's, nothing changed on their gear) it is the same issue. This issue relates only to the NV goggles - Rangefinders that are spawned the same work perfectly fine for client and server. So, what is the problem here? Is this a known issue that has not beend documented in some way yet or something? Does anyone know a workaround to actually be able to use them in MP games? Thanks.

Hm, i am not sure if luck is the right thing to call it. If that feature is broken, then it should be broken for us aswell - either we are talking of different things or it just isn't broken? I don't know, but i don't think that we just have "luck" and it just works for us. This is weird. Very weird indeed. Well.. edit: Okay so, i guess we were talking of different things and there was an issue with our script.. We spawned boxes for debug purposes, containing vests, backpacks, weapons - basically everything. What we failed to see was that we spawned them on the client and not on the server. So we were able to loot everything (except the broken NV goggles) because we "owned" these crates. This is like the vehicle loot issue, that prevents you from looting primary weapons out of vehicles uless your got into it once. So we changed our script to spawn the boxes on the server, and then we had the same issue as you said, we were not able to pick up uniforms, vests and headgear (backpacks worked fine btw!) Like i said, not being able to loot these items is the fault of the box not being owned by us, the player. Thats why we created a script (like for our vehicles) that assigns the ownership to the closest player - and voila, it works now after creating these boxes server side. BUT - and here comes the main reason for this thread into play again, the NVgoggles are still broken! This issue has nothing to do with the point that players are not able to loot out of a box they don't own. As soon as a player opens that crate, a message pops up giving some kind of error, and the NV goggles are in there but have no icon (just the text) - you can't take them (even if the crate is yours) and while drag & dropping them the binocular spot lights white, not the NV goggles spot like it should be! You can't equip them unless you drop them on the floor once, but then from the ground you can pick them up (into the binocular slot) and use them - but they won't be shown on your head like they should be ingame. So there seems to be a serious issue with the NVgoggles.

Uhm, that can't be it.. So far we have no issues whatsoever with uniforms, vests or backpacks. They work perfectly fine (what btw. questions the reported issue i guess) It's not exactly that it isn't lootable, the whole item is kind of broken. It is basically the only one htat, as soon as you open the crate, gives an "missing icon" error and then is not usable. Everything else works just fine.

Bump! Noone that has the samei ssue or knows what might cause this for us?

Just use the addItemCargo or addItemCargoGlobal depending on your usage for vests and uniforms. small example: _weapon_holder = createVehicle ["groundWeaponHolder", _pos, [], 0, "can_collide"]; _weapon_holder addItemCargoGlobal ["V_TacVest_oli", 1]; // adds 1 vest of classname "V_TacVest_oli" _weapon_holder addItemCargoGlobal ["U_O_Officer_uniform", 1]; // adds 1 uniform of classname "U_O_Officer_uniform" headgear and attachments are addItemCargoGlobal aswell, backpacks are addBackpackCargoGlobal. (using global here for mp functionality)

So, little update on the issue - we just finished our very own script based group system. Now we don't need any unit to hold the group open, or some kind of leader but are still able to do all kinds of things like player icons etc. If there is interest we will release it to the public in some days. Maybe someone else will benefit from it aswell. Thanks to everyone that tried to help on this issue!

Well sorry, just totally misread the thread.

nevermind*

Well, the point of being in a group is forming a team ingame without being forced to join a faction in the lobby. We basically have only one faction that serves as a free for all faction, and then we want to give the players the choice to either join public group A, public group B or create their own custom group. Custom groups are easy because these can have their group leader, but a public group where players join into because they have no mates to play with or something like that simply can't have an player as leader due to the radio spamming and the orders that someone would be able to give that have impact on the game (like dismount) That's simply not enough because that would just disable the messages to these orders but not prevent the orders itself. Rearm, attack, dismount - all these still happen, what is the real problem of this issue. The chat is basically irrellevant. Besides that we tried this one already and it seemed to be broken because it did nothing.

Have not tried that one yet. Will do tomorrow. I now tried creating an game logic - at least as far as i am able to due to finding code scraps on google. That seemed to work for the ordering part, until i tried to look or get into an vehicle, because well - i wasn't able to do anything except opening doors. I tried using resitance but still creaking the "unit" that will be the leader as "logic" but that immediatly gave me back some orders again to rearm and all that nonsense. I don't know if i might have used that logic feature wrong.. anyone experienced in this able to post the lines that would actually create a group for an game logic with an leader that well, is only the game logic part? Any other ideas to fix our problem would be nice aswell... isn't there an way to contact the BI dev's to ask such a question? I mean, they have to know, right?

We tried the first one, like i said we have all the "disableAI" parameters for these group leaders, but they still keep ordering stuff. The second one we did not try, and probably might work for some things but i guess the order to rearm and the order to dismount will still be there and these are the big issue (at least the dismount)

use eliteness to extract them, that will work. get the latest one (and the necessary depbo) from here: https://dev-heaven.net/projects/mikero-pbodll/files