Scripting from within a mission now effectively useless in 1109

[ivanwfr]

print has only been removed from whatever environment Lua scripts that are embedded into a unit's triggered actions exist in now. I do believe that print is still available in other Lua environments.

(...)

Ok, I can confirm that print has only been removed in the new Lua environment that ED has moved scripts embedded within missions to.

 

So far, all I'm seeing is that either socket don't do their job or, even more likely LoCreateCoroutineActivity() is not supported anymore as a result of some undocumented add-on support changes.

 

Even if I don't think we can get any good from nonconstructive augmentation, I can't refrain from saying that we can see that add-ons are not first class priorities to say the least.

 

Export.lua is a peace of history with it's copiright from 2006 and one of the major "advertised" function named LoGetMechInfo() missing since a few years and related forums questions about its disappearance still left unanswered.

 

Would Blizzard behave this way with World of Warcraft community, this could be their doom... If one thing is for sure, they won't! they are too smart for that.

 

And please note that what I'm saying here are simple facts that can be taken care of or neglected but also ignored.

 

And I'd rather vote for premium consideration concerning a documented DCS API. It would then be natural to have related changes well documented in release notes instead of being a matter of nightmares for some of us.... until they give up.

 

Ivan

[Speed]

I always said KISS right?

 

I'm sure we can get this fixed via a hotfix perhaps. As Viper has said, it has been addressed to the higher echelons.

 

Fairplay speed, now keep calm and await to hear.

 

A hotfix? I highly doubt that this registers high enough on ED's priority list for that, unless there are several other issues they need hotfixing. If ED does say that this will be fixed next patch or in some patch though, I can at least start work on the new mod (which could be done rather quickly). Before the patch is released, folks will be able to use the mod and insert the proper function calls into their missions by unzipping their mission files and manually inserting the necessary script. Definitely more complicated than it should be, but no more complicated than it has to be.

 

Ironically, if I do go the route of making a mission editor mod, then it may become simple to use by becoming a lot more complex (internally)... the functions would just become new trigger actions and conditions!

Edited July 24, 2011 by Speed

[mia389]

Hope this will get fixed to. All my mission use speeds script. All the time I have put into the editor makes them useless. Im talking about over 40 hours of work put into multiplayer missions for for the communty. Maybe its time to move onto a different editor until this issues is fixed. Maybe Rise of Flight for bit.

 

Thank you much Speed for your time and work into your scripts suite. I only hope some how it can modified in the future to be able to work once again.

[snwboardn]

Told you that you needed to be on DCS's pay roll ;)

[Speed]

Hope this will get fixed to. All my mission use speeds script. All the time I have put into the editor makes them useless. Im talking about over 40 hours of work put into multiplayer missions for for the communty. Maybe its time to move onto a different editor until this issues is fixed. Maybe Rise of Flight for bit.

 

Thank you much Speed for your time and work into your scripts suite. I only hope some how it can modified in the future to be able to work once again.

 

I just tested a work around that should work, but the final test is yet to come. And it's kind of a sloppy fix. Basically, instead of inserting scripts into your mission in the mission editor, you have to do it manually yourself. First what you do, is every where you want there to be a script, you put in a "message to all" trigger action. Type in a message, something distinctive, something you will remember, something that will remind you what script is supposed to go there.

 

When your mission is ready to build into a flyable version, exit DCS and find the mission on your hard drive. Extract the mission (a .miz is really a .zip) and open the file called "mission". Now, you need to replace the a_out_text_delay(<your message>) function with the Lua function you really want to run. This step is actually substantially easier than it sounds. I should be able to release a youtube guide on how to do it when it is appropriate. Anyway, after replacing the scripts this way, you will then need to select all the files that were extracted out of the .miz, rezip them up to a .zip, and change the file extension back to .miz

 

I just verified that I can use this method to access the print function via a trigger, so this work-around should indeed work.

 

But first, I need to hear back from ED as to why the print function was removed. If it was an oversight that will be corrected, I will then complete the print data passer mod I had begun work on several weeks ago to tie all the Lua environments together. If it was not an oversight, then print()'s days of working in the "mission" environment will likely be numbered, and I won't waste my time.

 

The new method though is going to have some obvious drawbacks:

1) Automatic installation is no longer possible. So in order to make the scripts run, the mission host will be required to manually install a mod. As it stands right now, the mod consists of two files that will need to be dropped into the Scripts/net/ folder. A Modman installation could be made available as an option as well.

 

2)Annoying to the mission creator. Obviously.

Edited July 24, 2011 by Speed

[Speed]

So far, all I'm seeing is that either socket don't do their job or, even more likely LoCreateCoroutineActivity() is not supported anymore as a result of some undocumented add-on support changes.

 

Even if I don't think we can get any good from nonconstructive augmentation, I can't refrain from saying that we can see that add-ons are not first class priorities to say the least.

 

Export.lua is a peace of history with it's copiright from 2006 and one of the major "advertised" function named LoGetMechInfo() missing since a few years and related forums questions about its disappearance still left unanswered.

 

Would Blizzard behave this way with World of Warcraft community, this could be their doom... If one thing is for sure, they won't! they are too smart for that.

 

And please note that what I'm saying here are simple facts that can be taken care of or neglected but also ignored.

 

And I'd rather vote for premium consideration concerning a documented DCS API. It would then be natural to have related changes well documented in release notes instead of being a matter of nightmares for some of us.... until they give up.

 

Ivan

 

Yup, I would like to see a DCS API discussion thread started here shortly. Honestly, I was interested in getting started myself in the "export" environment, but based on your comments looks like that environment is faring no better than the others.

[snwboardn]

I don't know if you ever played the X series by egosoft... But perhaps a stand-alone "mod manager" would be helpful.

[159th_Viper]

..or in some patch though, I can at least start work on the new mod (which could be done rather quickly)....

 

It's confirmed that print() will most likely be restored in 1.1.0.10.

[Druid_]

After a few days off from PC I open up the forums, see 09s been released & this is the first thread I read. All I can say is ...

 

 

It's confirmed that print() will most likely be restored in 1.1.0.10.

 

take out the bold print and you have something Mission Designers can go on and move forward with. Unfortunately you aren't telling us anything constructive I'm afraid. Personally I shall wait until something concrete is said.

Edited July 24, 2011 by Druid_

[Speed]

It's confirmed that print() will most likely be restored in 1.1.0.10.

 

Thanks Viper! Like Druid though, I would like to see something a little more concrete, but this is better than nothing, at least.

 

I was able to find some more time to experiment on the new environment last night... I tried the function Unit.getByName, which is/was unique to the "server" environment where scripts lived previously. It didn't spit back an error when I tried to use it. So, ED may have actually been trying to throw us a bone here, and make us a environment that is both secure and capable, but they forgot to include print, so it's pretty much broken. That's one theory, at least.

Edited July 24, 2011 by Speed

[Ripcord]

It's confirmed that print() will most likely be restored in 1.1.0.10.

 

Hey guys, I think this is a pretty good response here from ED, considering this came within a 24 hour period on a weekend. The guy cannot guarantee it anyway, until it happens.

 

I am another that really wants this print() to be restored, because I think Speed is very much on the right track here and the more we are able to dump data from one mission, the closer we will be to referencing that in the next mission. I won't say DC word here, and risking throwing the whole thread OT, but it will be a huge step in that direction.

 

Viper, well done and thanks for elevating this. Cannot say enough about the contributions that Speed has made with the ME -- let's integrate them.

 

Ripcord

[159th_Viper]

Viper, well done and thanks for elevating this.

 

All credit goes to those behind the scenes that monitor and read the forums (relevant developers) but very rarely get involved directly due to obvious reasons, including but not limited to workload etc etc - In this particular instance I was merely a go-between.

 

That said, while their direct participation is limited, their indirect participation is not, reflected by the lengths they go to behind the scenes to accommodate user requests, questions and testers running off on tangents - they are always ready, willing and able to see any matter through to a conclusion, which is why it is always stated that constructive criticism is always welcomed and dealt with accordingly. Forum members might not always be aware of this, but trust me, it happens!

 

Conversely, one can imagine that rants, moans and heated diatribes would inevitably cause those that do monitor issues to adopt a 'less than helpful' attitude - a perfectly reasonable response to inferred provocation or ridicule, especially when one's work-product is the basis of the accusations.

 

In this instance we can see that the adoption of the former attitude in dealing with a specific issue leads to a satisfactory conclusion for all and my thanx to all for heeding the request at the outset of the thread - level-headedness prevailed.

 

One does indeed net the fattest fly with a pot of honey as opposed to a goblet of vinegar :)

[jeffyd123]

Is this why, when flying a mission from speed, when I drop a bomb my printer explodes?

[159th_Viper]

.....Unfortunately you aren't telling us anything constructive I'm afraid. Personally I shall wait until something concrete is said.

 

Aye - it's attitude like that that will make me think twice before even addressing issues in future............

 

I have relayed the exact sentiments (word for word) expressed by a developer in response to this issue - what more is there to say?

[Speed]

Thanks for the kind words, Ripcord.

 

Hey guys, I think this is a pretty good response here from ED, considering this came within a 24 hour period on a weekend. The guy cannot guarantee it anyway, until it happens.

 

Yea, I agree, it is a pretty good response in such a short time period, on the weekend too. Russian workers have weekends too, right? But as far as a more concrete word on it, I would think that they should be able to provide that at some point here. Looking through the forums, you can find lots of examples where ED devs have said "this will be fixed" or even, "this is already fixed in the next patch", or, "we will fix this". When the issue is pretty simple, as this one probably is, they are usually able to provide promises that are a lot more concrete than just "will probably be fixed". It's usually only the big questions like "integration with Black Shark" or "next DCS module" or "when will the patch be released" where there are so many unknowns that ED doesn't give us solid promises. So anyway, we can hope that they will get the time to look at this one in more detail soon, and provide us with a more concrete answer.

[Druid_]

Aye - it's attitude like that that will make me think twice before even addressing issues in future............

 

I have relayed the exact sentiments (word for word) expressed by a developer in response to this issue - what more is there to say?

Not at all, & it wasn't a go at you. But lets be honest here, the Devs are really not giving us anything to go on.

 

Something like "we have examined the Print() function and removing it was an oversight, it will be restored in the next patch" however is.

 

I have no time for politician type replies, sorry.

Edited July 24, 2011 by Druid_

[159th_Viper]

the Devs are really not giving us anything to go on.....

 

The danger of selective interpretation ;)

 

The 'most likely' as you selectively bold-quoted refers to the time-frame as opposed to the reinstatement of the Print() function.

[EtherealN]

Something like "we have examined the Print() function and removing it was an oversight, it will be restored in the next patch" however is.

 

1) It's a weekend.

2) It's a weekend.

3) It's a weekend.

 

And it's a weekend. ;)

 

Seriously, you've been informed that a dev is aware and considers it likely that print() will be reinstated with the next patch. What more do you expect on a weekend? An extra meeting of the board of directors to discuss the issue? :P

 

You have gained information. It may not be a definitive promise, but you still gained information. Be a bit more appreciative that someone actually took time off on his weekend to look at things. Thanks. :)

[ivanwfr]

No need to wait for a restored print function, here it is:

local logFolder   = os.getenv("DCS_LOG_FOLDER") or ".";
local logFileName = logFolder .."/".."Export.log"
local logFile     = io.open(logFileName,"wb");
print('Export: print redefined to write into ['..logFileName..']');
function [b]_G.[color="Red"]print[/color][/b](s)
   if logFile then logFile:write(s.."\n"); end
end

 

But here are some long time supported Export functions that are now gone where print currently is:

local getArgVal = [color="Red"]GetDevice[/color](0).get_argument_value
local getAltRad = [color="red"]LoGetAltitudeAboveGroundLevel[/color]
... and probably more

[Speed]

No need to wait for a restored print function, here it is:

local logFolder   = os.getenv("DCS_LOG_FOLDER") or ".";
local logFileName = logFolder .."/".."Export.log"
local logFile     = io.open(logFileName,"wb");
print('Export: print redefined to write into ['..logFileName..']');
function [b]_G.[color="Red"]print[/color][/b](s)
   if logFile then logFile:write(s.."\n"); end
end

 

But here are some long time supported Export functions that are now gone where print currently is:

local getArgVal = [color="Red"]GetDevice[/color](0).get_argument_value
local getAltRad = [color="red"]LoGetAltitudeAboveGroundLevel[/color]
... and probably more

 

ivan,

We're talking about multiple different Lua environments here. You probably know what that means, but for those who don't, a Lua environment is kinda like a universe. So when you have multiple different Lua environments, it's like having parallel universes. Each universe just knows about what's going on in its own universe, but there is no or very limited communication between two different universes as to what is going on in the other. Same thing with Lua environments. There are now six that I know of:

 

"server" - the object data base, the most capable of the environments in terms of data getting. Where scripts embedded in missions used to reside. It has full Lua capability.

 

"export" - the environment for data exporting and the like. The one you are talking about.

 

"net" - the network environment. This is where things like Servman exist, and the "home base" environment where the new mod I am working on operates out of.

 

"mission"- the environment where things like a_out_text_delay reside. This is the environment where your mission triggers are run. It is a secure environment that does not include the io or os tables, for example. You can do things like send those white-text trigger messages, view the contents of a mission, play sounds, etc, in this environment

 

"config" - some kind of configuration setting environment, not really sure yet how this would be useful to modders.

 

New Scripting Environment - the new environment apparently created by the patch, where mission scripts now run. I think it's sort of a lobotomized "server" environment :D

 

 

So yea, the code you just posted, does not work to restore the print function, because both the io and os tables do not exist in the New Scripting Environment. To be specific, this is what it says:

 

00036.641 ERROR Lua::Config: Lua error [string "local logFolder = os.getenv("DCS_LOG_FOLD..."]:1: attempt to index global 'os' (a nil value) in "local logFolder = os.getenv("DCS_LOG_FOLDER") or ".";"

 

As you can see, it clearly states that "os" is nil.

Edited July 24, 2011 by Speed

[ivanwfr]

Thanks for the insight!

 

Those layered contexts are indeed to be considered separately and yes, my point was only referring to the one where Export.lua operates where print has been banned as well. But there, os and io were not. Kind of closing a door and leaving the key in the lock.

 

Well no luck then for your print. But my print was not what I was the most worried about. Export.lua does not export anymore to my UDP listening TARGET scripts and that's what bothers me right now and I'm trying to make an opinion on how reliable is ED modding support, or lack of.

 

We are going to know more in the coming days, should devs say something or keep silent, in both cases we'll have our answers.

Edited July 24, 2011 by ivanwfr

[159th_Viper]

.....and I'm trying to make an opinion on how reliable is ED modding support, or lack of.

 

We are going to know more in the coming days, should devs say something or keep silent, in both cases we'll have our answers.

 

 

Support for what?

 

Speed's print function? Been dealt with - it's coming back.

 

 

 

Devs' say something/keep silent about what?

 

Is there a list/post/thread that details modders' wishes/requests that we can put to the relevant developers? I am assuming from your post and 'expectation of answers, or lack thereof, in the coming days' as confirmation that there is indeed such a thread/list/post.

 

Apologies for missing it, but could you link it for me please?

[ivanwfr]

Support for what?

I agree, there should be a place where to put what has been disrupted by the last patch. But I'm not sure how that should happen and who has to do that in the first place. Before those undocumented disruptive changes introduced by 1109 patch, Export.lua functions like the one I've pointed in

my previous#44 post

used to work nicely. They don't anymore. What else needs to be said? And I'm pretty sure there are others still to be discovered as not working anymore.

That's a what.

 

Devs' say something/keep silent about what? (...) could you link it for me please?

Shall we get something a bit fresher that those outdated Export.lua comment lines about how to use those functions in Lock On version 1.2?

-- Data export script for Lock On version 1.2.
-- Copyright (C) 2006, Eagle Dynamics.
(...)

That's another answer to what? And the current

online related page

is the exact replica of Export.lua comment lines.

 

Eventually, I'll have the comprehensive list of what does not work as it used to before the patch. But it takes time just to add code to assert what is gone from ED Export.lua interface. And if devs don't have time to check those themselves, that by itself will be a part of the answers I'm looking for.

That's a link.

[EtherealN]

Simple solution:

 

Those modders that have issues with existing modscripts, or specific wishes with scripts they want to implement, talk to each other about them. There appears to be a couple of you. Start a thread and discuss.

 

This will allow a couple things:

 

1) A central location where developers, testers and other interested parties can find your thought.

2) A central location for you to learn from each other about any workarounds that may exist.

3) A central location that testers can peruse towards assembling a shortlist to bring up with the developers.

 

Right now the devs have no way at all to really know what you guys use, how you use it, and why. There's no way for them to make an informed decision. This change was brought about due to the exposure of a serious security vulnerability, but there was very little in the way of resources for the developers to learn how to plug the hole yet still keep things in good shape for modders. They have a job to do which is mostly spent hunkered down over an SDK writing code. They don't have time to read scores of threads spread over many forum sections. Moderators do, but we may not have the time to really think about how each thread ties into another, and it's only one of us that has a really solid grasp of LUA.

 

So please, help us help you. Collect all your thoughts in one place. I'd recommend starting a relevant thread in the wish list section, discuss it well (and try to help us out through including some layman-friendly explanations of what things you suggest would do) and we might be able to make things happen for you.

 

But in the present chaos, it'll be extremely difficult.

[ivanwfr]

I see no chaos from where I'm reading but rather a bunch of facts causing some trouble for people that are exactly as passionate about the subject as you moderators and devs are!

 

With time (only 2 days till now), patience and some deep breathes, I'm pretty sure the outcome will be constructive and the experience be seen as a step forward.

 

My single Export.lua had no chance to be one of devs priorities but this one and other tools can't be collateral damage unnoticed with modders kept waiting silently.

 

Should it look like there is some emotion involved in the process, well, I think we are fortunate it is so!

 

All these posts are about getting a sign for some amount of attention coming their way.

 

Praise for ED devs work is a constant in these forums. And I'm one of those who knows how well deserved they are. But, I'm sure devs are also ready to pay attention to more than correcting bugs or getting the most from the technology.

 

A community is an asset, and Apple knows what I'm talking about. As you said, we can help each other to help each other.

 

BTW, I try to shave off bad words that comes out under my fingers before I hit the submit button but please don't ban me right away if I miss one.