Just as a note, and may help others having the same issue, I tried changing a few settings from the options menu in the dash board and got ARMA to work.
What confuses me is I had to run the game in 32 bit mode and it works every time, when I run the game in 64 bit mode it crashes every time.
My system is 64 bit Windows 7 home.
I don't mind running in 32 bit because I can now carry on playing so that's a win for me and I hope for others too if their problem is the same.
I hope this helps you too Devs, I would appreciate if you could let me know why I need to run the game in 32 bit mode, what am I doing wrong?
Maybe I've missed something in my setup or overlooked an installation setting in steam?
Thanks Devs for an excellent game, keep up the great work!

Thank you. This change will also resolve T84595.

Ok makes sense, ropeAttachedObjects also removes null objects, lets see what we can do

I fail to see how my comment implies that variables referencing the deleted object should become nil.

By your logic the variable that contained object should become nil and not objNull when object is deleted. This is not how it works. You havent detached object so it is considered attached and returned in the array. detach object before you delete it, you are the designer

That is true, however, to me the name attachedObjects implies "return a list of currently attached objects to the given object". An object that doesn't "exist" anymore, can't be attached to the object (or anything).

Why is this unexpected? When you delete object the reference to it becomes objNull.

count (toArray (ctrlText _ctrl)) - text cursor at end

this will not work with non ASCII texts

Maybe

Das hab ich leider auch, aber noch keine Lösung gefunden.

It is not a fix, it is a won’t fix

Are you implying that for now we should share non-Workshop missions in an unpacked form, as a workaround?

When you are publishing to workshop you are providing a picture separately AFAIK so what exactly is wrong with showing picture you uploaded to the workshop together with description you have given on the workshop when your mission is appearing in the section of scenarios which explicitly says that they are steam workshop missions? How is that conspiracy against the humanity by evil BI devs?

In T147399#2001916, @BIS_fnc_KK wrote:

If you put mission folder in Missions, it shows fine

This is not a fix, but a workaround (for some cases).
I was trying to get the inventory from destroyed Vehicles into a variable.
In case Bugfixes are low prio, then its okay. Just want to help fixing things

Could it be true that BI delegated all overview data to the Steam system and removed the ability to make pbos with all overview data self-contained? Seems unlikely to me......

Great! I am so glad that it's a bug! The system is still reading data from the Steam workshop page, and at least some of that must be intentional.... Perhaps the system is meant to read data from Steam if no overview data is available in mission, and the bug is preventing the reading of mission data, thus resulting in data being read from Steam?

I tend to think that the decision to kill user-entered overviewText and overviewImage in description.ext/Eden Attributes and replace them with Steam data was a corporate one, and no further thinking went into it

And you are wrong, there is a bug that stops reading data from pbo in Missions. If you put mission folder in Missions, it shows fine

I tend to think that the decision to kill user-entered overviewText and overviewImage in description.ext/Eden Attributes and replace them with Steam data was a corporate one, and no further thinking went into it. If so, this is a real shame. The most obvious reason why it is a bad idea is that a mission's description on Steam workshop is meant for "marketing" and information purposes, to provide potential players with data like gameplay elements, links to forum threads, other web sites, etc., whereas overview data typically entered by mission makers are designed to get players psyched to play by putting them in the mood/headspace of the mission. I find it hard to believe that BI would stealthily do this without informing the community, even in the biki. Perhaps I missed it, though.

Do the user mission employ https://community.bistudio.com/wiki/markAsFinishedOnSteam command?

Should be fixed in the next dev

Should be fixed in next dev

It works on dedicated server but only if the playable unit got AI activated at mission start, if the playable unit got AI desactivated nothing will show up.
So its an issue for a mission where there many player who connect/disconnect from server cause there will be many empty playable unit over the map and they activate a large amount of AI.

same. dunno what to do

2019 And got the same problem. I do get the resume button but after a quick load I'm back at the scenario, window.

Tested mission and buildings are not moved at all now, they remain in their position and do not appear to be affected by the attachTo command.

Please provide your data in clear text not a zip file

A workaround for this issue would be ability to publish scenarios via Publisher tool, not Eden Editor. However, it's impossible for community content creators, as Publisher tool doesn't even have scenario tag option. Apparently it's not a problem for BIS developers, since Old Man is properly tagged as a scenario.

On further investigation this doesn't appear to have anything directly to do with Argo as stated above. It's possible this relates to a file lock or sharing violation. The only common factor is the error occurs when starting a Listen server. So far the only 'solution' is to reinstall Arma3 from scratch - hardly an acceptable solution.

any updates? :(