User Details
- User Since
- Mar 6 2013, 12:40 PM (605 w, 2 d)
May 16 2021
May 12 2021
Jan 9 2021
May 31 2016
In the mean time this can be of help: https://forums.bistudio.com/topic/191167-what-can-we-do-with-arma-2-maps-now/#entry3032652
May 24 2016
It is definitly the right direction and will spare us some calling SQF from SQS lines of code.
May 10 2016
Not sure, but can you interact with objects (through action menu) when on a ladder? This would be mandatory for this to work.
Okay, here are our findings from our "Tartan Bug Taskforce". Most stuff by Miro:
- The Tartan Bug is not a Terrain Builder problem, as terrains created with Visitor3 for ArmA2 suffer from it too (but look as expected in ArmA2 and OA).
These are some of community terrains that show the bug: Fallujah, Podagorsk, Aliabad, Thirsk / Thirsk Winter, Afghan Village,Celle, Hazar-Kot Valley, Reshmaan Province, MBG_Nam. Also BIS terrains like Porto and Proving Grounds show the bug too when directly loaded in A3.
- The tartan bug is a mipmap problem in the sat texture. You don't see the bug on the sat texture when zoomed in the A3 2D map/editor or at the distance where detail texture is blended into sat texture (in A3 and buldozer). You see the tartan bug only if zoomed out in the 2D map or in the distance ingame and in buldozer (for example when flying or looking down from a hilltop).
- The bug is an engine problem as the mipmaps in the paas generated by TB are correct.
- High resolution sat textures suffer more from this bug than low resolution sat textures. When using very low resolution (10m/px) nobody has encountered the tartan bug yet, where using high resolution sat images (1m/px) often show the tartan bug.
With this info I suspect a simple error in the mipmap selection in the engine itself. Maybe something simple like an variable overflow or faulty rounding of numbers when the textures/layers are large?
On the image uro posted, it looks like two different mipmap resolutions are loaded for the same image and stitched together.
On further investiagation: Looks like the only password that does not work, is the password we used before the update. Caching issue?
I attached a fresh rpt (with a failed #login attempt) and the corresponding server config and server log.
I also noticed that the word "password" and a 7-letter password only containing the characters a,b,c,1,2,3,4 also works. So it may not only be a problem with the length, but also the characters in a password.
And BTW: The server is a Win2008 dedicated server. Just saying because Joris wrote in the Spotrep that they know about the password issue with linux servers.
Ours has 7 letters. Will try with 5 later today.
Edit: 5 letter password works
- We had Battleye disabled while testing (passworded server).
- It's definitly not a problem with one single client as multiple people (different IP) tried to log in and everyone got refused.
- My IP and the whole tracert changed since yesterday ;)
And the IP the server shows for the player with the wrong password is indeed the local home network IP if the players adapter.
Maybe I have some additional information regarding this ticket. I was building a 3D preview for my Map Builder editor put people complained about random crashes. Looks like some models, like the (shiny) fuelstation crashes ArmA3. Also some people reported, that they have random crashes with previewing objects that worked before. So I conclude that invoking ctrlsetmodel often with different models can crash A3 too.
So ctrlsetmodel has probably two problems: Some objects crash A3 and switching often crash A3.
Anyone can reproduce this error by installing Map Builder 0.7 and quickly go through the objects library or directly go to fs_pump (or other fs_*** objects).
Maybe ArmA3 itself could get a command itself to return an objects pitch, bank and roll corresponding to the TB import format.
The normalmap/6th maskcolor channel could be used for this watermap if they are unused.
I think this ticket can be closed. TB/BD has now a smooth function.
https://community.bistudio.com/wiki/Buldozer
Please stay on topic in this ticket. If you want to discuss buldozer, create a post in the forums. Thanks.
We are talking about Buldozer, the real time terrain editor. Terrain vertices are streamed between TB and Buldozer.
Merging two polylines works now (1.40) when snapping is enabled but "Continue Polyline" is not possible yet.
Buldozer is a tool/Modelviewer by BIS. Thus no spelling error.
No more crashes since a week here.
Definitly not fixed. Also it's not related to clicking the continue button (Since the ArmA2 bug where the gear menu is not working, when somebody clicked "Continue", we don't use this button anymore). Thus clients also crash, when only admin clicked continue to start the game.
I did have a friend crash once under the same circumstances on the latest patch but otherwise it was fine. If it's not fixed it has at least been reduced
We had a little LAN party last weekend and tested the patch immediatley with three players. Doln, you are right: We also noticed the crashes seems to occure less often. I also think this CTD happens more often on a dedicated environment, than client hosted games (but on client hosted games the host CTD more than other connected clients).
This ticket definitly needs a higher priority and severity! A reproduceable CTD for all players in MP with a high probability should be fixed ASAP.
We tested this issue and it seems to be related to empty slots (slots without player and AI). If all slots are full with either players and/or AI, we haven't encountered a CTD.
I am also interested in this command. At the moment I have to script mit own "lifestates" with setvariable.
It would also be great to change lifestate to return an array of states. A unit can be unconscious AND injured. Or alive AND unconscious (but obviously not dead andhealty :D).
I am not able to reproduce this crash with the stabil 0.5 version of client and server. The stable seems stable regarding grenadethrowing.
How else can I help?
Attached three crashdumps and RPTs from windows server 2008 rc2 64bit.
Jep, I just looked Ingame and version misaligment and frametitles are fixed. I think this ticket can be marked as resolved.
Heyho, I made a little addon to temporary fix this issue (it's very annoying if you are looking for a patched server).
You can find the Addon in this thread: http://forums.bistudio.com/showthread.php?149687-AT-UI-Fixing-quot-Require-quot-field-in-serverbrowser
And here some further infos on this UI bug:
There is an unused RscText for "time left" at horizontal position y = "20.8 * ..."
Both CA_ServerDetailVersion and CA_ServerDetailVersionRequired are on the same height of y = "21.5 * ...
Setting one of them to y = "20.8 * ..." fixes first problem.
The headlines of the players and expansion frame are not aligned like the left frame (left frame at 16.3, other at 16.2).
Setting CA_ServerDetailExpansion and CA_ServerDetailPlayers at
y = "16.3 * ..." solves the overlapping headlines
May 9 2016
I would like to see Zeppelin32 (ArmA2 font) back for editor and continuous text.
I can confirm this and uploaded a pic of the main menu.
My FOV Settings:
fovTop=0.75;
fovLeft=4;
tripleHead=1;
And Resolution:
fullScreenWidth=5760;
fullScreenHeight=1080;
This settings works great with NVidia Sourround in ArmA2:OA. In A3 those will mess up the UI as seen in the picture.
Turning deadzones off is not a solution. The problem persists: TrackIR with deadzone combination is broken.
Also: With small aiming-deadzones the issue appears less often. With max. deadzone is the player instant moves his head up or down.