derammo

Thanks for your response. We will make a nice clean TRK for this, if we can reproduce it. If it does not reproduce, then good anyway :)

Is the AI expected to engage all enemy clients in multiplayer missions? In a session yesterday, enemy B-29 tail gunners were shooting only at the plane of the server host. They were ignoring my plane entirely, when I was connected as a remote client. If I host this mission on my machine, then they do shoot at my plane. Note that I do not choose a different plane, or change any ROE or anything like that. The only difference is that I am the host in one case and a remote client in another case. Is this an expected limitation of the current code? Does anyone know how to work around this? Cheers, Dwarf Vader

Actually it is not a box. It is a T-80 tank, reduced down to a level of detail of 5 polygons. :) You can tell from the texture map it references. That also explains why there is no bottom, since it was made to be a ground unit. So yeah, at the very least it should use a "generic airplane" at distances over a few Km and maybe increase the size of that generic airplane at very large distances to make it easier to spot.

Clarification: when I had the connection interrupted problem, it was fixed 100% of the time by restarting the DCS multiplayer client. So I would not say what you are seeing is the same thing, since your problem survives restarts of the client. So the problem I am reporting is a bad state in the client and yours is not.

How to reproduce: running 1.2.12 on both sides my buddy starts his server, I start my client, connects, we play and everything is fine - my buddy takes down his server to make a change to map file I do NOT restart my client when I try to reconnect, it always says connection interrupted (immediately) if I restart my client, everything is fine We did this multiple times and it happened 100% of the time. For clarification, I am saying it acts like it is failing to reconnect to the server if the server was restarted since the client was loaded and connected to the master server. Maybe it is using some data from the master server that is stale, like an auth cookie or something? Just guessing here :) Cheers.

I am also having this problem since patching to 1.2.12. Never had a problem with the same mission file and the same settings before patching. I hit this crash three or four times after diving low to the ground/sea in a FW 190-D. Twice it happened after bombing or strafing a ship, once when I was bombing a ground unit with SC-500 and then pulling up.

I think you are describing something that would scrape a portion of your main display and send it to the iPad. Additionally, it would translate iPad touch input into mouse clicks on that main display, translating coordinates appropriately. This sounds like a general accessibility tool that could be created, and I have not searched to see if it exists. It has nothing to do with DCS or multi-monitor modes of course, but I don't see any reason why it could not be created. I suspect any naive implementation of something like that wouldn't work for DCS unless it was specifically targeting 3D graphics, like FRAPS does. In other words, if someone created something for handicapped use of an iPad as a screen+remote, then it may or may not support 3D applications, so you would have to look out for that.

You missed the part where I am suggesting that the newbie planes should be enabled by default in the missions being hosted (i.e. from any airfield that has fighters), to fill the skies with targets... errr... I mean with welcome new players who are being helped along ;) If the hard core people don't want them, they can turn off this option I suggested. Then we can see if everyone is of the mindset of "us versus those Battlefield kids" or if maybe we can play together and have more fun as a result. There will always be hard core people who are not into the gaming aspect as much as the realism, that's clear. I believe that right now, the new players are not succeeding with the 25T and the servers are as empty as ever. I doubt we will get better AI, so maybe it would be good to have more humans, even if they aren't all hard core. That was my point about already having DCS, don't you think the hard core group may be fished out (and aging out?) <==== SORRY forgot to mark that as troll bait :) Seriously though, I completely agree with you that the objective is to find those that find deep sims fun and just don't know it yet. I just want to stress that last part more, that they don't know it yet and therefore need to be given vaguely sexual strawberries.

Strawberries market themselves by their attractive color and the vaguely sexual shape. They have a very low barrier of entry and have no problems attracting new customers, who then grow to love strawberries and also buy cherries and raspberries.

I am attaching the patch (patch -p 1) that implements Peter's currently published modification without having to overwrite the macro with one from a different DCS release. Is there a diff/patch utility that DCS people agree on using? http://jungels.net/articles/diff-patch-ten-minutes.html UnchainRudderFromTrimKa50DCSWorld.patch.txt

Good point there, I missed that problem. Probably there is nobody left at Ubisoft to negotiate a deal to allow a demo version of the plane in DCS:World? If that is the case, perhaps they can get one of the other fighters. My point is not about the specific plane, but about the fact that newbies cannot be expected to do SEAD with a hard to use plane their first day. If they were already into study sims, they would already have DCS...

Disclaimer: I realize this could be construed as a comment on MARKETING, which I realize is both disgusting and not very applicable to anything DCS/ED related :music_whistling: That said, here is my proposal: 1) Change (or add) the free airplane that comes with DCS World to be the MIG-29A 2) Limit this to only "game mode" when FC3 is not installed 3) Adjust lethality of that specific aircraft in game mode in case it ends up overpowered 4) Create multiplayer option to allow this "gimped newbie fighter" in a server running only simulation mode otherwise, on by default 5) Have the plane warm start automatically even if the mission says cold start People who download the game (recently derisively and ignorantly called 'Steamers' by the veterans) could immediately jump into something they understand. The fact is new players DO go online and then they flail around not being able to start the 25T. Then they leave in frustration, which is hardly their fault. I am sure nobody would claim that plane is newbie-friendly. The intended effect is that our multiplayer servers would be filled with newbies in a fighter role who, en masse, would still constitute better air cover than our servers have now. And yes, our veterans would slaughter them, but only 4:1 or so :pilotfly: Then the newbies may decide it is time to go buy FC3 and get even. We get new players and ED makes a little money. Everybody wins.

Wow. This is one stable aircraft even without a canopy! It finally stopped flying up and down in altitude and settled like this for like 20 minutes. Finally ran out of fuel and crashed after 38 minutes and 19 seconds without a pilot.

I ejected from a 29S in level flight just above the tower for laughs and it flew away... it has been circling for more than 25 minutes now (no control input or auto pilot involved) and hasn't crashed yet. Is that a record :)?

I see our difficulty at communicating now :). This is definitely not pseudo code, it runs fine. I work on Linux in bash shell, and this is a bash script that contains and runs a LUA script. The bash script iterates all the .miz files and creates a directory for each MIZ into which it is unzipped. For each such directory, it iterates all the files that have no file extension (these are the tables, rather than the LUA scripts.) Then it calls a bash function for each such file. This function is declared in the same file. It simply calls the command line lua interpreter, feeding it a LUA script that is also embedded in the script. If anything goes wrong in reading the table, lua exits with an error and it does not get to rewrite the file. If it correctly formats pretty printed and sorted table output, then it overwrites the original table file with that. When its all done you have a directory for each .miz file in the current directory, containing canonical form tables, which can therefore be compared since all the fields are in the same order. Here's the code again with markup to follow along [edited to correct LUA script, previous version was not doing anything]: #!/bin/bash # this comment means linux automatically runs this script in bash if executed # a bash shell function function canonicalize { # run LUA command interpreter, taking script from standard input (-) and passing name of table # << EOF means replace standard input with contents of this file from here until # you see EOF again lua - $1 <<EOF -- beginning of LUA code -- load "serpent" LUA rock, which is a pretty printer local serpent = require("serpent") -- load the table or crash, returning to iteration of files in bash local text = assert(loadfile(arg[1]), "failed to read "..arg[1]) -- remove path to get name of table variable we expect in the file local value = string.gsub(arg[1], '.*/', '') -- disable ALL LUA functions setfenv(text, {}) -- invoke table code, which will just define that one table variable text() -- retrieve expected variable from sandbox environment local loaded = getfenv(text)[value] -- make sure we loaded something, so we don't serialize nil assert(loaded) -- serialize canonical LUA local formatted = assert(serpent.block(loaded, {comment = false})) -- comment print("rewriting "..arg[1].." in canonical form") -- since we didn't crash, replace the original file io.output(arg[1]) -- add the assignment back since this table file is supposed to create this table var io.write(value.." = ") -- write the pretty table io.write(formatted) -- end of code piped into LUA EOF # and now we are back in bash } # iterate all *.miz files for MISSION in *.miz ; do # get the name of the miz file without the extension BASE=${MISSION%.miz} # use this as a directory name mkdir -p "$BASE" # change to that directory, remembering where we come from pushd "$BASE" # unzip the MIZ unzip -o "../$MISSION" # for all files without a file extension for FILE in `find . -type f -not -name "*.*"` ; do # call canonicalize function to rewrite it, assuming it is a LUA table canonicalize $FILE ; done # return to directory we came from popd done

[edit] sorry Speed, I just realized that you replied to my first post, which didn't have the sandbox. I believe that we are on the same page.[/edit] I already do that in the code I presented above. I didn't pcall because I WANT to abort if anything errors in the untrusted code, so I don't overwrite the file in that case.

Daribouca: Let me try to re-state my point then: I was trying to canonicalize the LUA tables, so that tables from two different miz files can be compared, regardless of the order of fields and escaping/quoting/formatting used originally. Sucking the whole thing into python dictionaries and then formatting back out in canonical form would presumably accomplish this. But you are then relying on your own implementation of any escaping that LUA might use. So yeah, you could do that. But I was asking about a more direct way in LUA, and whether the answer I gave for that (see the LUA code embedded in the bash script above?) is sane from a security perspective.

ok I got a pointer from somewhere else, so here is a new proposed script (simply removing ALL LUA functions from the calling environment): requirements: LUA 5.1 luarocks lua rock "serpent" bash unzip #!/bin/bash function canonicalize { lua - $1 <<EOF local serpent = require("serpent") local text = assert(loadfile(arg[1]), "failed to read "..arg[1]) local value = string.gsub(arg[1], '.*/', '') setfenv(text, {}) text() local formatted = assert(serpent.block(_G[value], {comment = false})) print("rewriting "..arg[1].." in canonical form") io.output(arg[1]) io.write(value.." = ") io.write(formatted) EOF } for MISSION in *.miz ; do BASE=${MISSION%.miz} mkdir -p "$BASE" pushd "$BASE" unzip -o "../$MISSION" for FILE in `find . -type f -not -name "*.*"` ; do canonicalize $FILE ; done popd done Do you think this is safe? It worked fine in a simple test but I am no LUA expert.

Great! Let me know if you need anything else from me.

Hi all. I am new to this platform and so I am soliciting ideas/experience. I was trying to diff two mission files to see what had gone wrong, breaking the product. My first approach was this: expand miz files convert each LUA table to a canonical form, meaning all fields are sorted and pretty printed the same way That looked something like this: #!/bin/bash function canonicalize { lua - $1 <<EOF local serpent = require("serpent") local text = assert(loadfile(arg[1]), "failed to read "..arg[1]) local value = string.gsub(arg[1], '.*/', '') text() local formatted = assert(serpent.block(_G[value], {comment = false})) print("rewriting "..arg[1].." in canonical form") io.output(arg[1]) io.write(value.." = ") io.write(formatted) EOF } for MISSION in *.miz ; do BASE=${MISSION%.miz} mkdir -p "$BASE" pushd "$BASE" unzip -o "../$MISSION" for FILE in `find . -type f -not -name "*.*"` ; do canonicalize $FILE ; done popd done Then I was able to recursively diff. Now here is my problem: normal LUA pretty printers (I used the LUA rock 'serpent') require the table you want to pretty print be in a table variable. So that means my script reads the tables from the files. This is equivalent to executing LUA on my machine that I didn't write myself. Note the invocation of text() to get the table file contents into a variable. Anyone could put anything they want in their mission file and I would end up running it on my machine. You see, in this scenario, the LUA is executed in an unrestricted LUA interpreter, not some embedded one in the game. How do people deal with this? Is there a non-LUA parser/formatter for LUA tables that doesn't require executing the source? I realize this is a direct result of using a script LANGUAGE to store DATA, and I am taking short cuts by just running it. But there must have been other projects that handled this. I have seen some LUA code that attempts to read a table without executing anything, is that what you use? Cheers and thanks for reading this long-@$$ post ;)

Ok, so how do I get someone from Eagle Dynamics to accept this as a bug? I would have expected there is some sort of tracking system like JIRA or something, but I haven't found any formal anything so far.

He he, you took the easier way out! Is it ok to blow away a resource and not update "resourceCounter" in the misson file? sorry I only started hacking mission files yesterday ;)

still bored... so I tried adding that section to the View configuration and it seems to fix it. try the attached mission. also: I have no idea why the editor sucks all these config files into the mission archive. It seems like terrible design. Operation Bermudes avec Hueys v2.miz

I was bored so I looked in your mission file. It does contain view configuration in Config/View/View.lua I found in a working mission of mine that it has a section for TrackIR gain multipliers. It looks like this: -- gain values for TrackIR , to unify responce on diffrent types of aircraft TrackIR_gain_x = -0.6 TrackIR_gain_y = 0.3 TrackIR_gain_z = -0.25 TrackIR_gain_roll = -90 Your mission doesn't have that section. Maybe the defaults have a different sign for the gain on roll so it rolls the other way? Just guessing here, but maybe helps someone find the root cause.

Yes, that's correct in the real world too. No, my approach was dramatically more fun and nerdy!