Fireball

Hello everyone! I just wanted to let you know that I've adopted Insurgency, kindly put to disposal by pogoman, as my project. Currently I have a project space set up at DevHeaven and will start taking feature requests and bug tickets there. Current version Arma 3: 0.90 A3 Current version Arma 2 OA: 1.50 Legacy version Arma 2: 1.00 - Fireball & Kol9yN -------- Project Details Mission available at http://dev-heaven.net/projects/insurgency/files (scroll to the bottom for A3 version) For improvements and fixes, please see the roadmap at: http://dev-heaven.net/projects/insurgency/roadmap Please feel free to post your suggestions here or, better even, file a ticket on DevHeaven in the project issue tracker. As you can see, it took me quite a while to get ahead, but with the major problems (in terms of code) fixed, I can move on to improve the overall mission and take upon feature requests. Next major step will aim at portability towards other maps. I will try to single out code, which applies to specific maps, so that the mission is easily ported. If anyone is a good banner designer: The project needs a catchy banner for the project home and for anyone to put into their signature who love Insurgency! Insurgency Project Home

I was trying to register a new unit tonight, and I think it wants me to log in on the site. But instead of the login dropdown I just get an empty dialog: https://i.imgur.com/Lprg5nH.png

Wow, I've really never seen that, this is awesome! :o :D Then I guess what I'm referring to with the sun warmth is more the colour tone of the sunlight during evening hours which is usually more red-ish due to atmosphere. For my comparison animated gif, I also used an evening time. I thought the original goes better with the evening tint, daylight tint with clear weather looks perfect *looks outside*.

Hi googlova et al, I revisited the topic of the "missing sun" or at least "missing sun warmth" of the visual upgrade and this is the best I came up with (bottom right you can see the watermark on the dev build one); and to say yet, the weather setting was completely "clear" on both shots - in fact I created the first pic on dev build the way i placed the player initially in 3DEN editor and then just reverted to stable build and only loaded the same scenario to take the second screenshot. EDIT: Btw., do you see what happens to some of the arid vegetation on the floor in front of the player? Some of the shrubs just disappear and the grass becomes a little juicier.

Sorry, I just had to chime in now; I saw those screenshots and downloaded dev immediately: versus new: And my first impression was: Who turned off the sun? Second thought was: This can't be the same weather condition! But yes, it is. :( So I checked now in dev build and really: The warmth of the sun is completely gone. There is no "warm summer day" mood anymore, it's all cold and gray, even though the weather is supposedly clear at a Mediterranean noon! This needs remediation before thinking about release.

You could host a Zeus mission! That would be awesome! Simply prepare a short story arc and take 10 min for initial setup and then proceed and improvise.

You've got a point there. Let's leave it here - it won't be supported anymore though.

You must know that Iceman is now full-time busy with the FT, but probably can only (if even) catch up with what was reported recently, which in turn shows that FT was left dwelling alone for too long, as Astaroth (back in time) was only doing it aside his main job in QA and was also only appointed, when the FT was already bursting with ticket. Then, what you missed within those xx% new tickets is probably that 80% of them are defacto unusuable due to reporter XYZ seen an issue and thus had a bad day and went on the FT to rant what should be improved in his opinion, instead of delivering a proper bug report. Also within those new tickets are probably many untreated dupes (if you see some, let me know). I've also seen that crash tickets are assigned (probably internally passed on to devs) and hardly ever closed, since noone can really confirm that that particular crash is resolved, as for end users one crash might look another. So we can also assume that many assigned crash tickets were already resolved without us/you knowing. Also, the cartoon in the beginning totally neglects that multi-core CPU support is in the game for a long time. Only because your cores don't all max out while you're playing, you can't say that there's no SMP support, but there's only so much you can divide among the cores without risking the game going fubar, so only expect small steps, but (hopefully) safe ones.

They're onto it: http://feedback.arma3.com/view.php?id=18733 But it's a bug that's apparently a bitch to reproduce. Can anyone check if 1.24 RC is affected?

Since that overhaul of the AI difficulty settings (removal of separate difficulty sliders and Super AI) the AI accuracy is still too high in all including the lowest preset. I currently have to teach DS admins on how to provision an .Arma3Profile using custom difficulty class definitions, so AI doesn't one-shot you the very instance they spot you, across 200+ meters. Accuracy as low as 0.2 make sense eventually as far my tests go; skill may be higher (such as 0.5). There is certainly something wrong...some hyperbolic attenuation of accuracy within the slider range.

It's more than a filter issue for me. I can filter correctly (or not filter at all), and my DS is not listed on Steam, but only on GS.

Please drop me a PM with links to solved tickets, so I can set them resolved or close them.

Can it be or is static weapon re-assembling (after it was disassembled and divided to two different players) broken again in 1.16 stable? Might have to use a DS in order to test it... EDIT: Nah, it was too long since I've done it before, so I/we did it wrong. It's kinda counter-intuitive, that you get two backpacks next to eachother when you disassemble them, but to assemble them you can't put both on the floor, you gotta keep one on.

I would agree with you if engaging the turned out crewmen was a serious option (in the game), but in fact it isn't, specially while its moving. The AI turns in extremely quickly (maybe a tad too fast) and the attacking AI in the video from pappy.rabbit does not seem to realize this. There is certainly room for improvement.

That's actually mostly a mission/scripting issue, not the other way around. I mean of course when they do react.

Try this again, when you're alone, e.g. in the scouting missions.

With the campaign, I'm in serious trouble since the latest difficulty settings changes (i.e. patch 1.14). It seems like the precision is always very high. I tried going to "Custom" AI difficulty and set precision to something as low as 0.20 (skill 0.55) and they were still headshotting me at ludicrous distances, while standing and one eye bleeding. Created a FT ticket: http://feedback.arma3.com/view.php?id=18061 EDIT: As a workaround, if you lower skill to 0.40 with precision 0.20 it gets more "human-like", specially since they take many many rounds before they drop. It seems like precision is very dependent on the skill setting; as long skill is >0.5 it seems like they're unhumanly accurate, if you go below 0.5 it feels better; not sure if the precision setting has any part of it at all.

I simply wanted to point out that it still happens frequently, that walls or trees fall, when (AI) soldiers are killed next to them and fall towards aforementioned objects. http://feedback.arma3.com/view.php?id=7773

You don't need to setPos the playable units manually, specially not 50m in the air, they'll probably die in the background before the base has initialized. The contrary is the case; they'll not be recognized as "dead". Note these code lines: #define startLocation (if(isDead(MHQ))then{HQ}else{MHQ}) // return true when distance to spawnPos is less than 1000m unless the unit is flying (i.e. altitude higher than 50m) isDead = { (getPosATL _this select 2 < 50 && (_this distance spawnPos) < 500) }; #define isDead(X) (X call isDead) Note this definition in the map-specific defines.sqf (e.g. Takistan): spawnPos = [0,0,0]; This position is some place in the map, which is not normally reached by normal gameplay, e.g. some island at the edge of the map, or a place far off from the AO radius anyway, so players would never go there deliberately. As soon a base element or player "isDead" (i.e. within 500m and below 50m of the spawnPos), they'll spawn eventually with the base and later on, players will land in the spawn screen where they can choose to spawn with their mates too. So you simply have to make sure that the MHQ and the players (and other pre-placed elements) are within the spawnPos range of the map you're porting the mission to. Also, you'll have to make sure that the pre-placed elements don't blow up or roll away e.g. because it's too steep or the place is in the water. Go to the editor, make sure it's flat and secluded, copy off the location e.g. using a debug console and define spawnPos. Then go to the mission.sqf and edit the location of all playable units and base elements to be within the range or drag them in the editor.

Thing is, as many times in such discussions, both of you are right, to a certain extent. While you guys saying that the kinetic energy decreases over time/distance, you are absolutely right with that. When Ckrauslo says that slower projectiles usually do more devastating damage (to the unprotected body, that is!), he's also right. The explanation (or a good part of it) is here: http://en.wikipedia.org/wiki/Stopping_power#Energy_transfer To give an example on over-/underpenetration: A FMJ bullet at high speed may crush a ribcage with a clean hole, when it's passing through the body and leave a small exit wound, and as long it penetrates no vital organs it may not have a severe (immediately life-threatening) impact on the wounded. On the other hand, if a bullet with lower speed hits the ribcage or - let's say a rib - at a certain angle, it may detour into one or even multiple vital organs and wreak havoc on the target.

I'm writing this top of my head, but you need to make sure that you have the correct startPos and have the player and MHQ units moved (adjust positons of them within the mission.sqm) within the "isDead" range of it, which is, about 500m (or maybe more, depends on the map, check the macro/function).

Ok, I also searched that "clinic" you cited, and it was completely empty, but I didn't go back in there AFTER picking up what I needed - is it that what you're saying I have to do? :confused: It would be OK if there were the supplies I was looking for, but it was completely empty, so why can I complete the task only in there? UPDATE: Looks like the trigger didn't activate again, back in time when I was there first. I didn't take enough of the supplies when I was within the range of the trigger the first time. I restarted the mission, revisited the location, killed the AI and as soon I stepped over their bodies (i.e. within 25m of the clinic) it triggered as I had already enough supplies from last time in inventory and the task was done.

Ok, maybe it's just me, but - I searched the whole village, every house twice, for the friggin medical supplies and found nothing I read your comment here and:

Yeah, but I thought: "first things first, let's go to the waypoint" which magically skips you to the next morning without any hint of doing so whatsoever and thanks to Deadfast I got a heads-up that I probably should do the side tasks before attending the briefing or - me too - would have missed half the fun. Constructive criticism on mission design: The dialog with James at night should indicate that - the briefing is in the morning and that the time will fast forward when using the action - any other tasks in the camp should be completed before daybreak EDIT: In any case just stumbling onto the table should not start the briefing which effectively cancels out all the other tasks; the night mission. It also makes no sense for you to stand 10 hours next to the table until daybreak. A total immersion AND mission breaker.

And post the ticket URL here again, please