IDs were discontinued. They are unreliable, because when terrain is updated, they often change and can break missions.

I recommend to use https://community.bistudio.com/wiki/nearObjects

Duplicate of #25744

Duplicate of #0015268

Editing Loadouts via Arsenal and crates/vehicles as with Zeus would be perfectly fine.

Agree!
Right click on unit/object (vehicle, infantry, crate, any weaponHolder in fact);
Allow arsenal (adapted to the holder if possible).
Arsenal could have minor change in its display (keep Eden view instead of zooming on face of the unit);
Adapt also for loading turrets of vehicles!
Permit saving for loadout by type of vehicle.

For Christmas please ;-)

NVG sound removed. It made sense in Zeus, where a mission takes place in the background and other sounds are present, but I understand it was quite annoying in otherwise silent Eden Editor.

Should be gone in the next dev build update.

It is implemented to prevent you getting addicted to the editor and spending too much time with it. ;-)

14 years too late for that. ;D

This is intended behaviour and not a bug. It is implemented to prevent you getting addicted to the editor and spending too much time with it. ;-)

Normal vision: http://puu.sh/koTvg/f238c0fe15.png
FLIR: http://puu.sh/koTvN/0b2fc53173.png

New Info:

Assets/Objects with class=House in GeoLOD and incorrect config.cpp entry I.E. not defined as a land_ class can cause Binarize to crash which results in Terrain PBO created without WRP inside.

Grabbed from PboPro window, using latest mikero pro tools(09/11/2015) and binarize(dev branch, 1.53.133.12):

"
<Bis Binarise...>
Binarise crashed with error status -1073741819.
Depending on the number of goats you sacrificed,
this may, or may not matter.
</Bis binarise>
"

Any building that has animation - ladders / doors / ruins+destruction class / hitpoints / etc, requires class=House in GeoLOD and class Land_ config.cpp entry, else Binarize crashes out-putting the error above ^.

Hope this aids you in adding error reporting to Binarize &/or some sort of included document that references these errors + how-to fix would be useful instead of searching for the illustious needle in haystack ;)

We backtracked via our git and found the issue manually and fixed it, so unfortunately we cannot repro this using the latest binarize as we fixed it manually via reverting commits.

But better binarize error logging would have saved us a weeks worth of sifting through data and a possible terrain revert to last working full build. Which would mean 1 months of collaborative work could have been wiped, and we would have had to manually check/re-check everything added from that point to ensure the error wasnt replicated elsewhere.

If it happens again I will report any updates to this issue, along with relevant data and create a clone of our repo at that point for testing binarize.

:)

They're quite annoying to work with when using the NV view as well.

TBH annoying to work with all together so hopefully that hide action comes in soonish..

http://feedback.arma3.com/view.php?id=25829

is related to this issue.

Hi, I see you're using pretty old version of binarize. Could you please try it with current version to see if the issue is still there?

Attached screenshots, binarize.RPT, bidmp & mdmp from binarize.exe

Nice suggestion.

The developers should give us more comfort functions like that. No more use of scripts for simple things like that.

Alright I gave it another shot (after saving) and it didn't crash this time. I guess it was just a really unlucky first click.

Oh, the irony

Fixed in the current Steam dev version.

Can confirm.

I do not have any problems with my GTX580 and the latest drivers. Maybe you tell us and the developers, what kind of graphics card you use.

So i found an issue and it is fixed now ;) you can check it out in tuesday DEV update :)
Have a nice day...

Hello! :)
Thank you for your report. I'am going to take a look on it right now ;)

This same thing kinda extends to the group attributes as well regarding the formations:
The units don't start in the formation you set them in; as in they do have the formation set correctly but they move to it from the default formation after mission start which looks kinda dumb.

Imagine let's say a large combat element of several groups starting somewhere to move forwards and all the vehicles and infantry drive and run around like headless chickens for a while to get to their format position if the format is set to something else than wedge..

But I guess this is getting to be an issue of it's own already...

Yes, that's what happens with AI, you can hear the AI commanding the group to the formation etc given in the WP, they don't start with the WP set attributes like in the 2D editor.

This is I guess a bit of a non-issue, although wouldn't mind if this worked like it used to. Completely fine if devs don't wanna to waste time on this, probably way more widely useful stuff to add/fix..

Oh, I think I noticed what you mean. Can you confirm we're talking about the same thing?

For example, when you attach the first waypoint to the unit in the 2D editor, the unit respects the speed mode from the instant the mission starts. The unit never starts runnin.

While doing the same in 3DEN, it takes a few seconds for it to take effect and the unit is running for a second or two.

Fully aware of the group attributes (which a very nice addition, just wish the init box on it wasn't greyed out.. ;) ), I use a _lot_ of scripted crap in my missions and while checking out how the importing etc works noticed that the group related attributes weren't 'fed' into the group like before.

Wasn't using the WP's to do that, this just caught my peripheral vision..

Admittedly I worded this quite badly; what I meant is that if you attach the group's first waypoint to the group _itself_ (as in create the first waypoint on the group leader, for whatever reason) the waypoint attributes should apply to the group.

Obviously did not mean they should apply to any enemy units etc, come on.. :P
Surely you can make the distinction between the waypoint being attached to it's owner and not an enemy or any other object.

Not sure if you missed this, but 3DEN has the concept of a "group entity" that 2D editor didn't have (it only had group links, but you couldn't edit the groups properties). Which means you can edit the group itself, and even set things like the groups callsign via Attributes without ever writing a line of code.

Editing the groups properties (double click the group icon in the viewport / right click the group on left hand menu then go attributes) allows you to do set their initial behavior, formation, speed mode, etc. without any waypoints. Attaching the waypoint to the group is kinda redundant in the 3D editor for these things, no?

Screenshot: http://i.imgur.com/z0uXIWv.png

I understand old habits are hard to get rid of. :)

No, it shouldn't.
For example when I give BLUFOR group a waypoint and attach it to an OPFOR vehicle, and set the waypoint to Stealth and Forced Hold Fire, I want these values to apply only for the BLUFOR group, not the enemy vehicle. Attaching means the waypoint will move with the target, nothing more.

Will be fixed in the next dev branch update.

"Move to Formation" option in entity context menu will now also respect the formation you chose.

It's time that gaming comes into the 21st century when it comes to networking. IPv6 is happening now. New IPv4 addressing is no longer available, and soon games will have to make the jump.

Using VPS to host. Have more IPV6 than IPV4. Could really use compatability

I'am glad to hear that! :) so i will close this issue and wish you many hours of fun mission making ;)

Good day Sadovsf, can't seem to repro the crash now with the new version 1.53.132600, but was able to at least twice prior with 1.53.132552.

Gave it a few attempts just now and it seems to be happy now. So I can upload my backup of the mission along with the windbg dump if you like, but its looking like it already got fixed =-)

Hello there :)
to resolve such type of the issue i will need to have ideally SQM that is causing crash or at least minidump. Can you please upload it?

Already mentioned in #25744

Duplicate of http://feedback.arma3.com/view.php?id=25750 which will be resolved in a future build.