madrussian

My guess is Rockstar moves forward with PC release once some financial condition is met. They lock their actuaries together in a room and make them come up with some arcane formula. If I were to bet, we'll see an announcement for RDR on PC, as ultimately its another revenue stream for Rockstar. But not until the point they can squeeze it for all the money they can get! :D

Well, OK if you guys have really looked into this and proven that gravity is actually inconsistent across different game assets, then yeah that should be addressed. Of course terminal velocity should factor as applicable. Although bombs are heavy, they do sport a pretty good surface area that must be taken into account. Regarding floating over hills while driving, and things feeling "weightless", etc, yeah imho BIS needs to implement a new physics engine badly. I would personally love to see PhysX (with optional HW acceleration). But keep it all true to real life, without monkeying with the new physics engine's standard overall gravity value, or standard time step, etc. In other words, never speed anything up beyond real life values. You can tell when other games do it, and it really cheapens the experience. Anyhow regarding the status quo, keep in mind that things could always be a lot worse! ;)

Haven't read through the entire thread, but for those who think that ArmA2 gravity is off, have you considered: Gravity vs. Terminal Velocity My guess is bombs hit their terminal velocity well before the equivalent "free-fall in a vacuum" comparison. Anyway, ArmA2 gravity feels right to me. A lot of other games speed up the physics, hence another reason BIS games are superior. Other than being ancient and not processing collisions very well, Open Dynamics Engine (ODE) will model gravity just fine as long as you don't go tweaking it (i.e. speeding it up).

@HateDread Oh, I see what you saying now. :) And once I settle on something time-accel-wise, I'll report back here, in case it might help you or someone out. btw- How is your mission progressing? What's the brief scoop of what it's all about? I'm interested! @AZCoder Your method may very well be the way to go. Will definately check it out. Right now I've moved over to other mission facets, like how to have criminals that hold up the player and/or AI civs at gunpoint, rob them, and then shoot if they don't comply. I've made some pretty big leaps in that area lately. Eventually I'll have to revisit this time accel thing, as it's part and parcel to the mission.

I've got a survival-style mission in mind where the player must survive X number of days (while gathering food, weapons, ammo, etc) and then at some point make it to safely. Even though the mission spans multiple days, I'd like to condense the gameplay to a couple hours time max and thus need to accelerate time. And allow the player to "sleep", etc. So, I've been playing around with skipTime and setDate, but unfortunately I'm getting some quite undesirable results. Both of these commands result in a noticeable lag, each time they are called. I don't recall seeing this lag with these commands in OFP and perhaps ArmA1, but it is indeed significant in ArmA2. After some investigation (using Chernarus), I've confirmed these lags have an firm association with the graphics that are being rendered, in terms of the ViewDistance and level of Fog. With a clear day and ViewDistance set to 2500, there is noticeable and signifigant lag (couple seconds maybe) using these commands. However, with fog maxed out -or- ViewDistance at 500, the lag disappears. [Also, please be advised my computer is up to snuff (i7-920 w/ GTX-275), so that shouldn't be a contributing factor.] Ideally, I'd like to just do a simple accelerate on daytime and leave it at that. But I don't want to force the player to play in Fog or with crappy ViewDistance. The only workaround I can think of right now is to have four distinct phases of the day (morning, afternoon, evening, night), and force a transition between them by temporarily pulling in the VeiwDistance or Fog in prep for accelerating time to the next daytime phase, actually doing the time accel, and then pushing ViewDistance or Fog back out afterwards. Anyone have better luck with these two time acceleration commands (skipTime and setDate) or have any other ideas on how to accomplish this? Thanks again as always. :)

Isn't the watch an inventory item? If so, just remove it if you like, then no more watch. :) Hey good luck with your mission. I may post a WIP thread on mine eventually in the User Missions subforum, if I get enough together to where I'm pretty sure I'll finish it. Mine is a massively ambitious undertaking, but I'm pretty motivated right now. We'll see. ;)

If you want to switch terrains inside a single mission, check out the playScriptedMission command. Now, I could never get this to work, but I suspect there is a way. And it definitely appears to advertize switching terrains mid-mission. Good luck. :)

Are you saying to remove the watch so it won't break the immersion if the player looks at it and see's the time flying by? I suppose it's worth thinking about, but the player is going to know it's a time accelerated mission after all. Thanks, that may come in handy. :) Yeah now that I've got skipTime to not lag, I need to do some more experimentation on just how much time can be sped through while maintaining a completely lag-free experience. I am thinking though that most of my lag issues happened when I switched over to setDate. I want to use setDate (so no clouds a ripping across the sky), but it will be interesting to do some quantitative analysis on how the lag issues stack up exactly with regard to setDate vs skipTime.

Interesting. I wonder how many of these bis_fnc's there are? I just discovered them today reading up on implementing ALICE. :) So I just tried a series of single instances of skipTime commands are various durations (on a clear day, no fog, VD=2500, on the ground with lots of Chernarus horizon visible) My results: skipTime 0.1 results in huge lag (the good part of a full second, at least). skipTime 0.01 results in bit of lag. skipTime 0.005 results in perhaps(?) unnoticeable lag. 0.005 hours = 18 seconds. Yeah, you're going to need a whole lot of those to get anywhere, and how fast can you even call it? Not sure, I'd have to do more experimenting. My main issue with skipTime is that you see the clouds ripping across the sky. SetDate avoids this problem, but if it has the same limits on small duration as skipTime, well that's a real shame. (Again more experimenting required.)

Not sure, but that would be pretty easy to test, right? Well even if I only call either of those commands ONE TIME, I get that huge hit of lag. That's pretty close to the basic idea I've got for sleeping at night. When it gets late enough, the player gets an action or radio entry to sleep (which is optional). Then as you mention we can fade out, skip the time, and then fade back in without issue. (i.e. You won't see the lag.) But for this mission idea to work, I've really got to force time to move forward to explain why the player is hungry, and all the apocalyptic ambient events I have in mind. Wouldn't make sense to just have it all take place over the course of a couple real-time hours of time. Anyhow, I'm starting to lean toward dividing the day into quarters (and have the length of each segment chooseable at the start of the mission, default 5 min per quarter). Have the time advance over a 10-20 second period to next quarter. Maybe play some music while the time advances. Pulling in the fog to eliminate the lag while time advances and then pushing it back out may actually add to the ambiance of the mission and remind the player he's gonna starve if he doesn't keep moving. Depending on how you think about it, it's really kind of a neat mission dynamic. ;) Thanks for the comments and suggestions guys. :) So anyone else get big per-call lag on these two commands (skipTime and setDate)?

So it's possible to level a whole town in terms of buildings with a few lines of script: _things = ((position player) nearObjects 500) - [player]; { _x setDamage 1; } foreach _things; However, all the fences remain standing. Anyone know how to knock down fences too (via script)? Any help greatly appreciated as always. :) DOUBLE EDIT (SOLVED): Turns out that nearObjects does not return fence segments. So they were not in my _things list after all. Thus they could not be destoryed. Using nearestObjects instead seems to detect everything and works like a charm: _things = nearestObjects [player, [], 500];

Cool! Will check that function out mate. :)

Simply amazing island IceBreakr. It's a wonder BIS hasn't hired you yet. :) Thanks again to all involved.

Agreed. If this report file method was viable and worked without any drawbacks, that would be ideal. However... Good thing folks are working on these external tools, because unless there’s another way to skin this cat, there’s really no way around using them anyhow. :)

After sitting and thinking long and hard I have formulated a 100% clean means of getting external data in and out of ArmA2. That is to say without the use of the clipboard or any external programs like ArmaLib or anything similar. First off, such a system would have many obvious uses. What I've personally got in mind is a dynamic campaign where the results carry over from mission to mission. There is a decent chance of this data system ending up as an Addon so I posted this here in the Addon Discussion area. If you're interested hear me out! :D Getting External Data into ArmA2 This part is easy. Simply utilizing the loadFile command and parsing the data with CBA string functions. Getting ArmA2 data out This part's harder, but I finally figured out how to make it happen! It all has to do with the "report file". Here's some info on it: http://community.bistudio.com/wiki/Crash_Files Turns out the diag_log command will write to this report file. So we can reliably pass data out of ArmA2 into the report file. Good so far! Trouble is, the report file is located out in the AppData folder, which as far as I know currently, ArmA2 cannot get to via the loadFile command. As far as I'm aware (and please correct me if I'm wrong) , in terms of scripting ArmA2 can only access folders and subfolders within: 1. The main ArmA2 folder - example: _text = loadFile "\userconfig\MRU\MRU_DD_Config.hpp"; 2. A mission folder - example: _text = loadFile "Library\MRU_Distance2D.sqf"; Note the difference being the lack of the leading back-slash. As far as I can discern, you can't go UP and thus outside these two specific types of areas, like this: _text = loadFile "\..\..\TestFile.txt"; Nor can you simply go anywhere specific, like this: _text = loadFile "c:\Temp\TestFile2.txt"; Please someone tell me I'm mistaken about this and you can get to the AppData folder somehow and then we've got it! -OTHERWISE- Fortunately (although a less ideal solution), you can temporarily relocate the report file location to where ever you want, via the -profiles tag in the ArmA2 startup parameters: http://community.bistudio.com/wiki/Arma2:_Startup_Parameters#Profile_Options Now, there are some advantages and disadvantages to relocating the report file. Disadvantage first: ArmA2 expects your profile info (key setup, etc) in the new location as well. Not a huge deal though, you can just make a quick copy. Advantage: Because "-profiles" is a startup tag, you only load that way when necessary. (i.e. if the mission requires, etc) So in theory we should be able to: 1. Relocate the Report File to somewhere ArmA2 can access (hopefully not necessary if someone knows how to access files outside two aforementioned key areas) 2. Pass Data from ArmA2 to the report file via diag_log 3. (optional step) Extract the data from a report file via an external app 4. Pass Data from external file to ArmA2 (either directly from the report file or from a processed txt file the external app created) Awesome!!! The only trouble I'm having right now in trying this out, is with the "-profiles" tag. My startup line looks like this: Unfortunately, because I have a space between "Arma" and "2", it's not working. Placing quotes around the path does not work (i.e. it seems to expect no quotes): When I try the next line as a test, the report file ends up in the right place (but of course I need it somewhere down past the main ArmA2 dir): Anyone know any way of making this "-profiles" tag work given the space in the path? Also, back to the idea of getting the loadFile command to see outside the main ArmA2 folder and individual mission folders... this is the ideal way to do it (because you wouldn't have to move the report file at all in this case). Anyone know if there is a way? So close!!! :)

Yes it's a pretty big file. And I do have questions regarding performance when reading the data back out of it. But I wouldn't call the behavior "undefined". Should work like a charm, if we could only get it open. Now, having said that, it appears the report file is of fixed length. So if you had a repeating error (say from a faulty addon script) that went on and on and on being written to it, that could theoretically push out the data you wrote in. Easy solution in that case though: Fix the thing causing the report file to blow up. Anyhow, the reason I'm so fixated on the report file is that it's the only way I can think of to get data out and back in using no external apps. Sadly, it sure seems this particular method isn't viable after all. Very interesting. Plus in the thread he mentioned the source was posted.

That occurred to me later on. I probably jumped the gun a bit. Yeah, look at me going all conspiracy theorist, and calling out BIS as involved in a intricate and cunning scheme to thwart budding mod creators. :alien: I can hear the white coats transmitting inside my head as I write this. :D My bad BIS, I recant my prior allegations pending any truly irrefutable evidence. So yes, in all likelihood you're probably right, but do we really understand the mechanics of why this isn't working? I mean, it's not like loadFile should be attempting to open the file with write access... it should just be reading it, right? I recall Fwatch from long ago, that handy little app. Is there something else for ArmA2? If you are reading Sickboy, does CBA provide anything like this? (If so, guess I've just missed it til now.)

Regarding that bullet point about "abandoned wasteland style military weapons test range environment", anyone see anything that confirms we'll get a bunch of derelict and ruined buildings in this DLC? If so, that will be a great asset for map-makers to create believable post-apocalypse terrains. :D

Anyone try 3.0 yet and see if, as an AI, it opens up fire any better than before?

UPDATE: So, ready to have a crack at this thing, I relocated my report file to "C:\Games\ArmA 2\Profiles\arma2.RPT" via the profiles tag. I start out by trying to read in the report file via loadFile: _txt = loadFile "\Profiles\arma2.RPT"; Not working.... Getting a message that it can't find the file. So after some experimentation, I rename the report file and try again: _txt = loadFile "\Profiles\arma2_DEVIOUS_BASTARDS.RPT"; Now that one works like a charm. Contents of the renamed report file read in and display just fine in all their glory (and a new impenetrable report file is generated). Just to be sure, I repeated this phenomenon multiple times and the results are clear. Apparently BIS specifically blocks read access to the report file via loadFile. Foiled!!! BIS are simply devious bastards. And I say that with all due respect. They actually thought ahead that someone would cook up this scheme and actually try this. Gotta love em. In any event, I hereby admit defeat. [btw- I hope if nothing else I got a good laugh out of a BIS dev or two. Thanks again for making the best games on the market, and I mean that. :) ]

Pretty nifty. :)

Good idea Defunkt. Found some info on "symbolic links" and it's looks like that will work with Win 7. Symbolic Links in Windows Will try out Hard Links and Soft Links soon and report back. :)

The basic idea I've got is to achieve the functionality of saveVar (and subsequent retrieval of that data), but only be able to do it outside of "campaign space", and do so without any external app (like ArmaLib, etc) or the clipboard being required. So the bare basic functionality is this: 1. You call a function to save data, which gets written to the report file via diag_log. 2. In a subsequent mission, you call another function to retrieve the saved data, which gets read in directly from the report file via loadFile. This ability in and of itself would be extremely useful. If this can be achieved (which now it seems almost certain it can), that opens the door to something like what you're talking about, where you can interface easily with an external app if desired. I see that as kind of a bonus. External app can monitor the report file and feed info into a file that ArmA2 reads in exactly as you mention. In terms of feeding data back into ArmA2' date=' you can put the file anywhere inside main ArmA2 directory or an individual mission file, so if you had an external app feeding the data back in I suppose it wouldn't really need to know which mission is running. For instance you could just feed the external data back to ArmA2 in the "ArmA2\FeedIn\FeedIn.txt" file. In any event, it would be really nice (though not necessary by any means) to be able to break free from that requirement of ArmA2 only having access to main ArmA2 folder and individual mission folders via loadFile, if anyone knows how to do it. So hopefully I can get a mockup of this thing running sometime relatively soon.

Those look like they might indeed work for my intended purpose. Very nice. :) But it appears they only work for "campaign space". I'll have to run some tests in an individual mission and see if anything carries over between sessions. In the end, it may turn out that using the report file is the only clean way to pass data in and out of ArmA2 when doing anything outside the confines of an individual campaign. But if anyone can crack this nut in a different way (and in a more elegant way perhaps), by all means let's discuss it here! ---------- Post added at 07:28 PM ---------- Previous post was at 06:22 PM ---------- EDIT: Regarding saveVar, saveStatus and saveIdentity: I just tested saveVar and it works as advertised for campaigns while playing in single player (bridging the data from mission to mission). However, surprisingly, saveVar does NOT bridge data from mission to mission in campaigns while playing in multiplayer. Why not? Certainly I think this should work. :eek: Unfortunately I have a dynamic coop multiplayer campaign in mind. Anyhow, back to attempting to pass data via the report file.

Kick ass Sickboy! That worked! :) How about getting loadFile to see outside main ArmA2 folder and mission folders? Anyone accomplished this feat?