Scripting from within a mission now effectively useless in 1109

[VMFA117_Poko]

+1

[Speed]

Oo thats screws all my missions up then (haven't tested any of them since I am down to one hand after shoulder surgery).

 

Why, why,why would they remove trigger.setUserFlag() ?!!

Well, one has to hope that it's because they made an error. But to say it bluntly, if they were intending to preserve the functionality of triggered action scripts, while only locking out the dangerous stuff, they did a pretty poor job at it. Any of us working in scripting missions could have given them a list of vital functions/tables that needed to preserved in triggered scripts, and both print and trigger.setUserFlag would have been near the top of the list, but they didn't ask... and I guarantee that if it had been asked, they would have ended up catching a lot less flak from the community... probably would have been the opposite. But still, ED is the most open-to-the-community developers I have ever seen, I've got to give them kudos for that.

 

And it does irk me as well how they do changes like this without even so much as a peep on the patch notes. But that's the way it is- software devs never tell you the bad things in the patch notes, because then they would have to deal with preemptive bitching.

 

BUT- all that said, think of it on second thought- if they had been announcing to the whole community that "hey, there's this security flaw in our software you could drive a Mack-truck full of trojans through, so we need to close it up... we'd like your advice on what functions are vital..." YEA. How likely is THAT?!

 

So I guess I guess this change couldn't be mentioned anywhere public beforehand, Druid.

Edited July 28, 2011 by Speed

[Druid_]

Yep understand what you are saying there. However, mentioning only the positive in patch notes only is counterproductive imho. As for the bitching, whats the difference between bitching prior to release and post patch release? None as far as I can see other than maybe, just maybe some clever community member might pick up on a mistake or even offer an alternative or two resulting in less post release problems which can only be a good thing.

 

Somewhere between 50-80% of multiplayer missions (can't comment on SP but I know for one most of mine) are screwed by this patch, I would have been nice to have had a little more officially in the way of feedback as a result.

 

Having said all of the above of course, and after a whole week has gone by once again

1) It's a weekend.

2) It's a weekend.

3) It's a weekend.

 

And it's a weekend. ;)

 

 

Well its been a week and nothing new or official from ED on any of this, unless of course I missed it?

 

Just so its in black&white in this thread & until a Moderator starts a new forum topic (e.g. Community Development) for modders & Lua users ..

 

Can we have Print(), os.Time(), & trigger.setUserFlag() back along with all other non security problematic os/io functions please. A solution to long-term file handling in the new scripting environment would also be appreciated.

[GGTharos]

^^^^

 

Enough. We'll let you know when we know something. I understand that it's frustrating. You've already been told print will be returning in a future patch, and I've put in a bug report for the rest of this stuff a little while ago. It's in the system. As for a long-term solution, it'll be discussed. Again, we'll let you know when we know something.

 

Also waiting on Speed's post. Sooner might be better than later.

Edited July 29, 2011 by GGTharos

[Headspace]

In the meantime it might be useful for you guys (Speed, and others) who have depended on accessible objects in the mission/trigger environment to test other stuff you've used (ex: land.height) to see if it disappeared and make a list of what you might want back. I am personally really busy with other stuff right now and can't test all of this in the immediate future.

[Druid_]

ok, but Hotfix, likely or unlikey in your opinion? OR Wait for 1.1.10 and see?

^^^^

 

Enough. We'll let you know when we know something. I understand that it's frustrating. You've already been told print will be returning in a future patch, and I've put in a bug report for the rest of this stuff a little while ago. It's in the system. As for a long-term solution, it'll be discussed. Again, we'll let you know when we know something.

 

Also waiting on Speed's post. Sooner might be better than later.

[GGTharos]

Ah - for that, I would imagine waiting for the patch is the most likely scenario. I wouldn't expect to see a hotfix unfortunately.

 

The devs are very willing to work with mission builders on this, but do realize that they are very busy, so we take your requests to them and they implement as able.

 

This goes for a framework for keeping the LUA interface stable as well. This scripting capability is a relatively new thing, so expect another up and down or two.

 

It'll all come together, it'll just take a little time.

[159th_Viper]

ok, but Hotfix, likely or unlikey in your opinion?

 

Hotfix for what?

 

Not an attempt at being obstructive, but we need to know exactly what it is you're asking for - short, conscise and wherever possible corroborated by reasonable argument.

 

We need to have a substantive request that we can forward to a developer for a 'yes' or a 'no' or whatever inbetween. I for one will not reference this particular thread in support of any request......It's all over the place and the Dev's do not have the time nor the patience to sift through the entire thread in order to sift the pertinent info from the rest. They have more than enough to keep them busy already.

 

Edit: GG's faster :P

[Druid_]

In the meantime it might be useful for you guys (Speed, and others) who have depended on accessible objects in the mission/trigger environment to test other stuff you've used (ex: land.height) to see if it disappeared and make a list of what you might want back. I am personally really busy with other stuff right now and can't test all of this in the immediate future.

Fortunately for me I didn't delve too deeply as I was worried by the numerous changes that took place with each patch. Once we are in a stable position with regard to development I will start delving. trigger.setUserFlag() was a big one for me along with some io handling (I worked on the ability to LOAD & SAVE a mission I built) which if they could restrict to a certain folder would be great. Others have delved a lot deeper and I cannot comment on any other functions I'm afraid but I'm sure they will be in touch.

[Druid_]

Ok GG thanks for the Honest answer, can't ask more than that.

[Speed]

Also waiting on Speed's post. Sooner might be better than later.

 

Well, how long should it be... I was thinking of going into full-request mode... like... listing ALL the things I need in a single post. That's why it was going to take a long time. If you want THAT up sooner rather than later, then perhaps you should proof read my thesis for me :D. But yea... trying to get my masters finished off at this moment, and it's crunch time, if you know what I mean.

 

So yea. That's why it will be later rather than sooner. I just don't have much of a choice- unless it's going to be a shorter post than I would really like.

 

What would the new topic be about, anyway? We all know what the problem is, but the problem can be solved in quite a number of ways... which leads to the topic being extremely long and complex.

 

Should each modder list all the functions that are currently being used by their mods, and functions they intend to use in the future? Should we just request new features on top of what we have now? Because just requesting features on top of what we have now opens us up for "Oops... I never knew any modders were using that!" kind of problems.

 

Or should the topic just be something we can get started now, and add to it slowly? Like, as I acquire the free time to do so, I add in the lists of the functions I am using, editing and updating a single post where this information is kept (probably under a "spoiler" window) and edit a separate post of mine where I keep a tab of features I would like to see added?

 

Or just a single post with each thing- lists of functions being used and list of functions being requested- both hidden under "spoilers".

 

But if this model were used for the post, then how would general Lua feature requests be handled?

 

Finally... we wouldn't want the devs to have to sort through a bunch of needless posts, or repeated requests, so it would need to be moderated to some degree, and importantly, clear rules in the topic would have to be established...

 

So yea... I've got some thinking to do about how a topic like that should work... what do YOU guys think?

 

Anyway, just to show you that I really am trying to take this action in the little freetime I have right now, I spent, I donno, 20 or 30 minutes the other day writing this as the introduction to the topic, but I felt it was a little too long-winded:

 

 

Preface:

The DCS modding community, particularly those interested in modifying the way the game works through the use of Lua, have been hampered by the rapid and sometimes seemingly arbitrary changes being introduced in the continuing updates of the DCS engine. What to the developers might be a very small change no one will care about, can sometimes completely break a mod someone in the community has spent hundreds of hours developing.

One recent example is Moa’s (from the 104th) stats mod. The mod was used by the multiplayer community to keep track of pilot stats on various public servers. The mod depended on the debrief.log file, where it read and tracked the events, in real-time, that occurred and did the best it could to keep accurate stats. Due to errors in information provided about such events, (such as erroneous “friendly fire” kills, *cough* buildings, etc) this mod required hundreds of hours of development time.

Patch 1.1.0.8 arrived, and with it, came the new debriefing system. Under the new debriefing system, not only is debrief.log written differently (in the textual form of a Lua table), but instead of being written real-time to debrief.log, events are only written when the server closes- that is, if the server doesn’t CTD, in which case, all that data disappears forever. DCS is pretty stable, but on a on a high traffic, dedicated server that where a single mission can run for 3, 6, or even over 12 hours, it is not uncommon at all for a mission to be terminated with a CTD. Thus, Moa’s stats mod is became useless. Hundreds of hours of development time, and a mod that significant segment of the multiplayer community depended on, was lost.

Another example was the chatIOlibv1 mod I wrote, that allowed people in multipalyer- clients too- to interact with the world via entering chat messages, and which was capable of outputting chat messages that gave the positions of groups of units, in real time. This allowed, for the first time, accurate and continuously-updated coordinates of moving units to be displayed as text.

Unfortunately, chatIOlibv1 depended on the ability of scripts embedded within the triggered actions of units to be able to modify files on the computer. This was necessary in order to pass data from the server environment, where functions such as Unit.getPostion and Coords.LOtoMGRS exist, to the net environment, where functions such as net.send_chat exist. These same functions that were being used benefitually could be used by someone malicious to create a mission that would install viruses, steal data, delete the OS, etc. So naturally, they had to be removed from the environment where scripts were run.

I did have a backup plan in place something like this happened, however. At the time patch 1109 was released, and chatIOlibv1 became broken, I had a mod 70% completed that would instead use the print() function to move specific data from out of protected environments, and run that data safely in a full-capability environment such as net. It was sloppy solution, but at least it would work. However, to my surprise, patch 1109 not only moved triggered action scripts to a new environment, where libraries such as os, io, and debug did not exist, but the new environment doesn’t even have the print function! I now only have the statement, relayed by a forum moderator, that the print function will probably return in patch 1110. I don’t know whether it was removed by mistake or on purpose, so I don’t know if I should possibly expect print to be removed from other protected environments, too (like mission)- “probably will return” is inadequate because it doesn’t tell me why it will probably return.

What I’ve seen, combined with what other modders have told me, makes me believe that there is a disconnect between the developers of DCS and the modders of DCS. I think that the developers are just so busy that they don’t even know what the community is using or not using in community mods. After all, are they going to have the time to peruse thousands of forum posts, download community-created code, and make a list of “don’t touch” functions?

So that’s why this

 

 

 

Yea... too long winded. I'm trying with the little freetime I have... if you guys have suggestions as to how a Lua request topic should go, and how it should be run... please speak up. Personally, I like the concept I just had while typing this post- modders list stuff they use, and stuff they want, and hide it under "spoiler" windows. However, isn't there a character limit to posts? I think I've hit it on a number of occasions. So this "single post with info hidden under spoilers" approach wouldn't work unless it's possible to turn the character limit off for specific posts.

Edited July 29, 2011 by Speed

[Speed]

In the meantime it might be useful for you guys (Speed, and others) who have depended on accessible objects in the mission/trigger environment to test other stuff you've used (ex: land.height) to see if it disappeared and make a list of what you might want back. I am personally really busy with other stuff right now and can't test all of this in the immediate future.

 

Part of the problem is there were functions in there I was intending to use or try out, I had never used or tried out and I never knew what they did, but I wanted to experiment with them. There were functions I was experimenting with to try to figure out how they worked but I was at patch time still unsuccessful. The thing is, ED never produced scripting documentation. I was on the verge of doing so. I've provided the rough draft of the 30-odd page document I wrote about it to a few people here privately... privately because, well it was a draft, and the other reason I don't want to go into, but yes, it was going to become a public guide in .pdf for the community. But whatever, that's a separate topic. The point is... well, I don't even know all the functions I'd really like back, because I had only figured out maybe half the stuff. I might end up asking the ED devs back for functions that don't do anything at all, but which I think might. And there's probably stuff in there I could potentially use with great effect but I hadn't just figured out yet. There's close to 2000 functions in the server environment, IIRC. Most of them are useless... but some aren't. It's like digging for gold. In a 180,000 line text file.

 

Now... I guess I could list all the ones that I ever used and figured out. I do know, as just another example, that view.getCamObject disappeared in 1109 too. Obviously, no one is going to be able to attack your computer with view.getCamObject.

Edited July 29, 2011 by Speed

[GGTharos]

I could probably read your thesis, but I'm not sure I could correct much in it for you ;) Depends on what it's on.

 

In any case, no, nothing that long-winded. Give me a list of 5-10 things you need.

 

A suggestion: Sandboxed luasocket and os.write might be an idea, ie. luasocket restricted to the localhost for example, and os.write restricted to the player's warthog temp folder.

[Speed]

In the meantime it might be useful for you guys (Speed, and others) who have depended on accessible objects in the mission/trigger environment to test other stuff you've used (ex: land.height) to see if it disappeared and make a list of what you might want back. I am personally really busy with other stuff right now and can't test all of this in the immediate future.

 

On second thought headspace... should be fine I guess... but there might come a time a several months after the first request that I find out I need some other "new" old function back.

 

Gonna be a pain in the @## testing them all though to figure out what's gone adn what't not. It's not like I can do a _G dump to a text file any more, or even, a _G dump to dcs.log via print.

[ivanwfr]

I +1 for localhosted LuaSocket for USB devices script/driver comm... and maybe missing print workaround.

[Speed]

I could probably read your thesis, but I'm not sure I could correct much in it for you ;) Depends on what it's on.

 

In any case, no, nothing that long-winded. Give me a list of 5-10 things you need.

 

A suggestion: Sandboxed luasocket and os.write might be an idea, ie. luasocket restricted to the localhost for example, and os.write restricted to the player's warthog temp folder.

 

So unorganized except for perhaps moderators removing non-relevant posts or something? Like, the only organization is that all posts have to be either "I'm using this feature" kinds of reports, or "I need this feature" kind of reports? Or maybe, only the "here's my mod, and here's the features I need preserved" kinds of posts could be spoiler-hidden, and feature requests could be open... but as far as posting within the topic... it would invariably get into discussions over various things, or how to ask best for various things, or "well, we already have that feature with this" kinds of discussions. Then you'd just have another post like this one where feature requests are diluted, and the devs would have to sort and sift through it.

 

Here's the thing though. As far as how to pass data between environments and computers- I've never written anything in Lua to do this. I know folks like Headspace, Moa, Yoda, have. Heck, I've never needed to write anything like that in any language. But at the same time... you guys don't seem to understand the environments as well as I think I do. So I'm not really qualified to ask for Luasocket as I've never taken the time to figure out how to work it, and perhaps you guys aren't qualified to ask for it because you don't really know how the environments are set up?

 

Of the two, understanding the different environments is probably vastly easier so perhaps I could just explain to someone who understands Luasocket real well what the environments are, what they contain, which are secured, etc, and then that Luasocket expert would know what to say. Because I don't. But I can tell you what is needed. What is needed is some kind of safe passage out of secured environments, through memory. For scripts specific to missions, how there could ever be a way around that requirement I just stated? you tell me. So it's going to have what- is this the right word- a "wrapped" function? Like send_data('net', 'blah blah blah'), and you get the string 'blah blah blah' written to a table called PASSED_DATA in the net environment at the next available nil entry in PASSED_DATA.... that's obviously simplified a description, but the point would be, it would force you to pass data to only a very specific variable name.

 

Or can you guys think of a better way to do this? As far as I understand it, you've got to make sure that a mission designer can pass data in such a way that it can get into a unsecured environment, and yet, can never overwrite anything... so it's gotta go to a specific variable. And then the mod maker has to be very, very careful that he never just does a simple dostring on that passed data.

If there is a better way, let me know!

 

Anyway... I gotta go... I'll check back later... maybe put up a topic if I can figure out what needs to be said.

Edited July 29, 2011 by Speed

[GGTharos]

Speed, don't worry about internal implementation right now.

 

Just say:

 

I need a secure send_data_socket in the server/mission/whatever environment. It takes these parameters.

It's purpose is to do x.

 

This isn't the time for setting up a larger overhead framework for this stuff. Just ask for what you need and we'll present it, and the devs will comment and offer compromises is necessary/appropriate.

[Святой]

In 1.1.0.9 patch Lua environment for mission scripting was separated from main simulator Lua environment that drives build-in systems (radio communication GUI, radio message building procedures, debriefing GUI and others) and used debugging too.

 

There was the two reasons:

 

1. Using main simulator Lua environment for mission scripting is unsafe because here are multiple unsafe modules and functions (binary module loading, input-output, file system management, process running).

 

2. Mission scripting does not need functions those not related to game world. Game world is a couple of game objects: time, terrain, atmosphere, units, groups, weapons e.t.c. Lua environment for mission scripting must not have functions to control graphic and sound system, main loop, GUI and other application systems. By definition.

 

The Lua environment is made not for mod making. This made for mission making. The Lua environment allow mission designer to write sophisticated logic to control AI-controlled groups and untis that cannot be implemented with ME GUI or may be implemented easer with programming than using ME GUI.

 

Main simulator Lua environment may be used mod making, but on modders own risk.

 

But even in 1.1.0.9 this environment still not officially exist because not all works done. There is still no final version of documentation. I have started working on this document at the beginning of last week and will publish it when it will done.

[ivanwfr]

It's good to read some objective considerations at this stage and, even if it this is no solution for our problems yet, this is what modders need to know. Only someone involved in technical design can have a grasp on what is relevant to security in addons scope.

 

Modders don't need any access other than what the sim is ready to communicate about in and out. And, once more, I think that socket can provide means to settle some API based on simple commands+args semantic as well as separate module responsibilities completely.

 

LUA sockets is nothing more than any other implementation of socket layer... open, connect, read-write, close... Socket Hello-world are nearly one-liners and no one should be allowed to say I don't know how to use them more than once per lifetime ;)

[Speed]

In 1.1.0.9 patch Lua environment for mission scripting was separated from main simulator Lua environment that drives build-in systems (radio communication GUI, radio message building procedures, debriefing GUI and others) and used debugging too.

 

There was the two reasons:

 

1. Using main simulator Lua environment for mission scripting is unsafe because here are multiple unsafe modules and functions (binary module loading, input-output, file system management, process running).

 

2. Mission scripting does not need functions those not related to game world. Game world is a couple of game objects: time, terrain, atmosphere, units, groups, weapons e.t.c. Lua environment for mission scripting must not have functions to control graphic and sound system, main loop, GUI and other application systems. By definition.

 

The Lua environment is made not for mod making. This made for mission making. The Lua environment allow mission designer to write sophisticated logic to control AI-controlled groups and untis that cannot be implemented with ME GUI or may be implemented easer with programming than using ME GUI.

 

Main simulator Lua environment may be used mod making, but on modders own risk.

 

But even in 1.1.0.9 this environment still not officially exist because not all works done. There is still no final version of documentation. I have started working on this document at the beginning of last week and will publish it when it will done.

 

Thanks for the response Святой. I'm glad to see we appear to be on the same page. I think everyone, even here in the modding community, agrees that the mission scripting environment needs to be limited to only being able to effect the game world, and that modding needs to not be done there. Yes, I know that previously, the mission scripting environment was used to install a mod (my mod). No one here is asking for that capability back. I only used it in my mod as a matter of convenience. I can get by just fine without that ability.

 

But us modders want to create new ways in which mission scripting can effect the game world. Such as, for a basic example, a function that when called in mission scripting, outputs current coordinates of a unit to the screen. Or a new mission scripting function that will set a flag when a specific map object is destroyed. Or functions that take user chat input to set flags or set tasks for friendly aircraft. The problem is, while those things are highly desired (by mission makers) and do not effect anything outside the game world, the mission scripting environment is entirely unable to do them. So what it needs some limited way to communicate with a mod that exists in another environment, where the mod takes that requested action.

 

So I believe that the mission scripting environment needs some way of safely outputting data in real time, where it can be picked up by a mod, so that the mod knows what the mission is doing. It would be great to have this one day. I will most likely put up a post tonight as a sort of wishlist thread for Lua modding, and a secure and limited method for sending data out of a the mission scripting environment will be one of the primary requests. Perhaps, such a data-sending function might, for example, only be able to modify the contents of a table in each Lua environment called "PASSED_DATA" or something.

 

Anyway, thanks for your time.

Edited July 30, 2011 by Speed

[Святой]

I see no problem here.

Main simulator lua environment has ALL functions those available in mission scripting environment and also has many other functions used by simulator system, including unsafe functions. Mod makers may use this.

It is possible to create mod that manipulates objects of game world and maintains data exchange with file system or network.

 

The script that initializes main simulator lua environment is ./Scripts/autoexec.lua. Mod makers may insert their code here.

 

In 1.1.0.9 it is possible to create deleterious mod, but it is no more possible to create such mission. Installing of mod is always risky, but playing missions must always be safe.

[Ripcord]

Svyatoi...

 

In this context, does deleterious = harmful? I had to look up that word in Lingvo :smartass:

 

Thanks for all your help here, and your willingness to communicate and coordinate with the community.

 

Ripcord

[Speed]

Svyatoi...

 

In this context, does deleterious = harmful? I had to look up that word in Lingvo :smartass:

 

Thanks for all your help here, and your willingness to communicate and coordinate with the community.

 

Ripcord

 

Yea. It's one of those words I've read a million times, but I couldn't pronounce it. It means harmful.

 

So I guess I did have one of my principle questions answered: why did this happen? It looks like print was removed because they are just now getting around to working on the mission scripting environment. Back in Beta, they basically said they had never really started work on mission scripting... and from Beta 1 through 1108, very little changed.

 

So it appears that having mission scripting run in the "main" or "server" environment was just a place-holder till they could build the dedicated, mission scripting environment, I guess.

 

So it looks like we could expect a slow growth in mission scripting capabilities over the long term. That's good.

[159th_Viper]

'Harm caused/capable of being caused in a subtle or unexpected way'

 

Thought the choice of word was quite ingenious :)

[Speed]

Got a "beta" version of my mod working... you can install it and fly mia/Smokey's "Operation Saturn". Gonna release the "official" first beta version when I integrate most of chatIOlibv2 functionality. Very shortly after that, or perhaps before I "officially release" it, I will be doing some guides.

 

I just tried to hack into my mod, from the mission environment, and access functions I wasn't supposed to in the net environment. The security method I used stopped me cold in my tracks :)

 

It's really pretty cool watching the daemon and print passing data into net... here's a snippet if anyone is curious:

 

 

 

00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[1][1]command_check_start_loop_net
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[1][2][string]spawn f15s
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[1][3][number]1
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[1][4][number]1
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[1][5]END_OF_CMD
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[2][1]command_check_start_loop_net
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[2][2][string]show task
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[2][3][number]2
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[2][4][number]1
00143.379 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[2][5]END_OF_CMD
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][1]chatmsg_groupMGRS_net
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][2][string]Enemy tanks are now at: 
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][3][table][string]tank1[string]tank2[string]tank3[string]tank4[string]tank5[string]tank6[string]tank7[string]tank8[string]tank9[string]tank10[string]tank11[string]tank12
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][4][number]6
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][5][number]8
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][6][number]5
00157.383 DEBUG   dDispatcher::InitLow: slmod_pre_cmd_mission[3][7]END_OF_CMD
00159.511 DEBUG   WinMain: slmod_pre_cmd_server[1][1]chatmsg_groupMGRS_out
00159.511 DEBUG   WinMain: slmod_pre_cmd_server[1][2][table][string]Enemy tanks are now at: [string]37T[string]GG[string]248[string]938[string]10[number]8[number]5
00159.511 DEBUG   WinMain: slmod_pre_cmd_server[1][3]END_OF_CMD

 

 

 

Some of this communication could be reduced by implementing Luasocket in unprotected environments, but a good deal of the communication will be from a protected environment to an unprotected environment.... just because the only environments that a mission maker can access, or can be accessed via a trigger, are protected environments.

But gonna definitely need that print function next patch to make it easier for folks to use this.

Edited August 3, 2011 by Speed