"Then I just tried individual lines. Load From Remote Resources seems to be all I needed to get this particular script to show up in a menu and run. The Supported Runtime line didn't help for this particular script."

"This change would be more global than unblocking each and every script."

That's great news, and was exactly what I was hoping to hear. The Load From Remote Resources line enables networked and downloaded files. The V2 compatibility line plus the affected Run-time version is supposed to relax .Net security policy. I'm looking forward to someone else who's having trouble giving this a try. And yes, you are correct. Instead of having to modify each individual script file, this is where the change should be made because it operates globally on all networked or downloaded files.

There is one other thing I ran across that may be of interest. I read that problems with the security streams that are attached to networked and downloaded files are only accessible and valid for NTFS file systems. Supposedly if you copy a downloaded file to a drive formatted for the FAT file system (like on a thumb drive), it will strip away the security and behave as if the file was UnBlocked.

Thanks.

Gary ...

Supposedly if you copy a downloaded file to a drive formatted for the FAT file system (like on a thumb drive), it will strip away the security and behave as if the file was UnBlocked.

I just tried copying a blocked dll to a thumb drive. You're right, the Blocked option is no longer there. Copied it back to the NTFS drive and the option is still gone. So, that'd be a quick and dirty way to unblock scripts and DLLs.

It's not elegant, though, and it seems to me that Vegasaur and TLT are installing just fine for me, so maybe this isn't exactly the problem for TLT?

Rob

Thank you for all the information on this topic. We have been working hard on reproducing and identifying root causes for scripting related failures using the information in this thread and are making good progress. We have identified multiple fixes and will release an update to address them as soon as possible.

Beta Testers who were with the VegasPro13 team earlier this year - it your time to come forward and reveal yourselves-- and
then confess and yes do so apologize to the rest of us who can see you did a really horrible job of beta!!!! OUCH !

+1 videoitguy.

doesn't any of you so called beta testers use scripts, plugins, extensions?

thankfully i now have my beloved event lenght extension working again, no thanks to you!

Supposedly if you copy a downloaded file to a drive formatted for the FAT file system (like on a thumb drive), it will strip away the security and behave as if the file was UnBlocked.

It is the Windows Attachment Manager that is handling the "Blocked" file attribute and this attribute is only supported on NTFS volumes. Most Web browsers, and email clients, use Attachment Manager to save files you download from the Web. This is how the Blocked attribute gets there.

videoITguy:Beta Testers who were with the VegasPro13 team earlier this year - it your time to come forward and reveal yourselves-- and then confess and yes do so apologize to the rest of us who can see you did a really horrible job of beta!!!! OUCH !

ushere +1 videoitguy. doesn't any of you so called beta testers use scripts, plugins, extensions? thankfully i now have my beloved event lenght extension working again, no thanks to you!
1/- BETA TESTING and NDAs: BETA Testing requires that those involved sign up with a NDA - that's a non disclosure agreement. Having done BETA testing for 3 of our Vegas Plug-In companies, I had to sign them and I know for a fact that one of the two gents complaining here about the value of the BETA testing on this "round", and the BETA personal involved with that program, that he would have signed one too. In which case this is most likely both galling and not a little upsetting to those VP13 BETA testers reading this. BETA testers would silenced by that NDA.

Which, both calmly and neatly, leads me onto my second point:

2/- No Knowledge is Bad Knowledge: How on Earth do either of you KNOW for a fact that this Scripting issue has not been raised at BETA level, by the same BETA Testers that you are accusing of NOT doing so? How? Have you been part of the BETA VP13 Program? Have you? No? In which you aren't privy to the reports made. And you certainly are not privy to the possible developments that SCS are making on your/my behalf.

Casting doubts, being critical, pushing for continuous improvement is one thing (actually that's 3 things!), but not appreciating the frustrations involved within that same NDA process needs cool heads and calm reactions. In the end we're all wanting the same thing - a better platform with which to go forward and be Creative! By keeping open as many lines of communication possible, e.g. ForumAdmin above and my invitation to Gary to be put/made contact with SCS is the only way I know to do this.

Now, if any of my analysis of the BETA and NDA is wrong, I'll correct it.

Cheers

Grazie

excellent points grazie, but both of us have beta tested for the same company, and i have beta tested for quite a few other companies over the past 3 decades.

i am willing to concede wholeheartedly that no amount of beta testing will catch all the bugs and that many will eventually slip through and cause mayhem amongst users expecting perfection, but some bugs are, or should be so obvious as to warrant investigation and / or rectification, and if nothing else, a note in the release notes that such and such a thing isn't working as expected.

if i had read of problems with scripts in the release notes i certainly wouldn't have thrown my little tantrum and simply waited for notification or explanation.

I'm not requesting you to concede that not ALL bugs are caught. What I politely requested you to consider was that how do you know that these SCRIPT issues were NOT raised by the VP13 BETA team. And that, right there, is all the point I am making. It is not about catching ALL bugs, and for me to even suggest such a thing would have been daft.

Cheers

Grazie

grazie i think we need an hour or so down the local... i'm sure after a couple of rounds (joints?) we can not only sort out this misunderstanding, but probably most of the worlds problems too....

The LAST thing I'd wish to do is talk BETA with you in a local. Now, Film making . . yes please!

g

i'll drink / toke to that ;-)

film making? are you being overtly influenced by the new icon? ;p)

@]videoITguy and @ushere

Really people? Name calling? Calling someone out just to beat them with a stick?

This calling out of beta testers, brings into doubt your motives, on this and other related subjects.

That said...

If I were a beta tester, I would not have found any script problems in Vegas 13. All extensions I use work just fine. That is a small list of extensions in my case.

Some people have problems running Timeline tools in 13. I tried that and it works for me.

The Event length extension that @ushere had problems with does have an issue but this is not a problem with Vegas at all.

The Blocked attribute is a valid windows file attribute. A security measure that requires user approval to let a DLL be loaded. That attribute is now being honored in Vegas 13, most likely via the change to .NET 4. SCS could probably bypass this security measure, but should they? Probably best to look for the attribute and post a dialog stating the extension is "Blocked".

One can take the view that it was wrong that Vegas12 and earlier let that Blocked DLL be loaded.

I've gotta say that I agree with Norman here. I didn't beta test this time but all of the scripts I had installed for VP12 worked with VP13. (Vegasaur was updated by the authors for VP13 so it's possible that it might have shown a problem during the beta).

So far, I haven't seen a problem with scripting and extensions that is actually a Vegas problem. Had SCS been communicating with beta testers (something I've not experienced) they might have said something to the effect of "Yes, thank you, we're notifying script developers of the problem" and that might be the end of it.

I deal with engineers at a very large electronics company. I can attest that they often focus on their specific task and that it often has much more to do with getting a product to the end of the assembly line than it does with customer experience. Sometimes the people who actually have responsibility over customer experience have no ability to make an engineer do anything about it, or even get them to understand the issue.

I suspect that the Vegas Pro 13 team just viewed third party scripts as "Someone Else's Problem" (Think Douglas Adams). From an OOBE perspective this was obviously a mistake and at the very least they should have warned that some scripts and extensions wouldn't work without updates for .Net 4.0.

Rob

"One can take the view that it was wrong that Vegas12 and earlier let that Blocked DLL be loaded."

I understand the technical reasoning behind this statement, but from a users perspective I have to disagree. For several days before I posted the link to the web site that discussed the Properties dialog UnBlock button, people who had just upgraded to SVP-13 were frantic that their favorite Scripts and Extensions had stopped working. They could care less about Windows, its file system, and ,Net 4.0 security policy. They just want their hard earned money to pay for a program that works as advertised.

Also, after I reviewed the contents of the Vegas application config file posted here, I could see that Sony had made an effort to alleviate the problem. They were just shy a single parameter that would have made the Script problem a non-issue. And another that I believe will fix the problem with running Extensions. They'll get this resolved in a new release that only needs to change the vegas130.exe.config file. Then this entire thread can be put to sleep.

> Reply by: videoITguy "Beta Testers who were with the VegasPro13 team earlier this year - it your time to come forward and reveal yourselves-- and then confess and yes do so apologize to the rest of us who can see you did a really horrible job of beta!!!! OUCH !"

You assume too much! What if the beta testers found many of these problems and reported them and Sony could not fix them in time for the launch? Anyone who has beta tested for any software company knows that not all of the bugs that are reported are fixed in time for launch date. I think it may be you that owes the beta testing community an apology for your rash judgement of their ability to find bugs and report them without considering Sony's capacity to fix them.

~jr

They'll get this resolved in a new release that only needs to change the vegas130.exe.config file.

Maybe. They may be working under a requirement to maintain the level of security in that config file. Don't count your chickens based on the eggs.

Rob

Actually Rob, they already had the parameter in the config file to revert to the .Net 2.0 Version 2 policy. They just didn't add the extra value setting to specify which .Net version would be affected.

GJ : They just didn't add the extra value setting to specify which .Net version would be affected.Maybe they WOULD have done if they had been made aware of the "need" to do it. But you, pointing it out here, has revealed it to us all.

Grazie

Grazie, there's no way I could have pointed out the need for the .config file mod to Sony because of two reasons. (1) I don't own a licensed copy of SVP-13, and (2) Nobody here has actually implemented my suggested change to verify if it works or not. What I'm relying on is information I've gleaned from the Internet from people who've run across similar problems with .Net v4.0 that have absolutely nothing to do with Sony Vegas. In each case the problem seemed to get resolved with the .config file policy change.

When Sony does get this problem fixed, and I'm sure they will, only then will we all know what corrective action it took. I'm retired now, but when I was employed as a Sr. Software Design Engineer, the companies I worked for paid big $$$ to Microsoft for Premium Customer Support. I'm pretty sure that Sony also pays for the same level of support. This lets them talk directly to Microsoft engineers to resolve issues with Windows, Software Development, and Microsoft programs. That's why I'm sure this will be fixed soon, because it appears to be more a Microsoft product issue ( .Net 4.0 ) than a Sony problem.

@Gary.

Making your suggested changes (using the exact code as listed by you above) to vegas130.exe.config does not solve the TT problem on my system - still the exact same error messages.

Willem.