Sniperwolf572

Nice find, that seems to be the issue. Modulo seems to have changed the way it operates since that function was written. I suggest making a ticket on the FT for this. Seems a bit severe. The correct line should be after the change to the way modulo works: _ret = _ret - (360 * (floor (_ret / 360)));

Well, if you turn them to face west instead of north, they'll both return negative values. I think something is either broken or inconsistent with BIS_fnc_relativeDirTo math, but I can't look into it now. :(

Ok. Just tried it in editor. Relative dir returns a negative value for some objects. For this car, the range is -180 to 180. For this arrow, it's 0 to 360.

Just a note that none of these conditions will trigger if you are at exactly 0, 90, 180, 270 or 359 degrees. You need to either use higher-or-equal-to operator (>=) on the left side or lower-or-equal-to operator (<=) on the right side (but not both!) so it includes those degrees as well. If you are having problems, I suggest hinting the value of _relDir as well, so you know what _relDir is and why it isn't matching any conditions. hint format ["_relDir is %1", _relDir]; I also suggest moving the sleeps into a single slee outside the if conditions, on the same level as _relDir, but after the conditions, so you don't have to write it 4 times, but instead only once.

Yes, you are right, I forgot about the BI licenses given with this data. Standalone HQ replacement packs certainly make more sense in that regard than forcing the BI license.

I remember that, it probably is one of the reasons, but I believe it just requires the island reload to bring the objects back as they were instead of the full game reset. Either way, it appears really inefficient way to do things. If you think about it, in addition to spawning yet another instance, there's also a need to track which ruin belongs to which object in case the damage was reversed at some point, which kinda means they are already dynamically creating and removing a lot of ruins. I suspect object deleting/recreating wouldn't be necessary if all you were doing is swapping the model for the entity. For certain objects, textures already get swapped depending on the damage level. I see no reason why a saner solution wouldn't be to implement damage tied model swaps too.

From what I can tell, yes. Simple way to observe this is to: Load up Stratis Enter in one of the watch fields "cursorTarget" Point your cursor at a destructible building in Agia Marina, then Execute "bld = cursorTarget; cursorTarget setDamage 1;" Enter in another one of the watch fields "bld" When the descruction is done, point your cursor at the ruin and notice that the bld and cursorTarget are not the same entitiy Execute "ruin = cursorTarget" while still pointing at the ruin Enter in another one of the watch fields "ruin" Execute "bld setDamage 0", unpause. Observe that the "ruin" reference is lost Execute "bld setDamage 1", point cursor at the ruin again when the dust settles Pause and notice that ruin is not defined, bld is still the healthy building, and cursorTarget is yet another new entity

Yes, you can disallow damage to any object with the "allowDamage" command. An addon could always be made to prevent building damage, but that would break missions that require certain map buildings to be destroyed. If the method of doing building damage is changed, I believe that the data transfer/processing could be significantly reduced. Currently, when a building is destroyed, you are not transferring data/processing only one object, but two instead. If the way it's done changed, so that the model is actually changed in the original instance of the object instead of spawning a new one, you are still transferring only the state of one object over the network, instead of two as it currently stands and this becomes a non-issue. In the end, disallowing the damage on the buildings is a workaround. It doesn't focus on solving the problem but instead just sweeps the issue under the rug. We already have enough of that I think.

Arma supports the "Addon mission format" since Arma 1 I believe. It's how BI missions and campaigns are distributed, since you'll notice there are no missions in the "Missions", "Campaigns" or "MP Missions" folders. Basically you're creating an addon that contains the mission, therefore you can add more stuff than with the pure mission format. You can find more about it here. What I think Ivan is saying, is that as long as you stick to that single .pbo, you can add new units or whatever with it. Multiple PBO's for missions seem to be disallowed. (Distributing your mission.pbo and an additional unit.pbo) At least that's how I'm interpreting that "no extra addon installation" bit.

Well, the only way to compare would be to litter an area with around 200 healthy houses, measure, then do the same but with ruins not generated by destruction. It certainly is a factor, but I'm not sure it's causing the whole of 20 FPS loss on my machine. I think we haven't noticed this problem before as the buildings used to be less complex, less densely populated and on islands with smaller surface area. Usually large cities are avoided as they are performance hogs even when you do not damage them. Zagrabad was one of the larger cities, and I believe PMC wrecked it to an extent in it's campaign. The BI function to destroy cities, that is currently in ArmA (and might have been used to destroy Zagrabad in PMC and the villages in Eagle Wing) has a very small chance of actually flat out destroying the building, instead, the most common case is a building damaged to the point where it just changes the texture to the damaged one. On one hand this is due to a "realistic" portrayal of a damaged city (not a lot of buildings are actually destroyed fully) and on the other, it might be so that some performance level is still maintained even if the buildings look heavily damaged.

If the ruins are deleteable, then it probably means they incur the same penalty as the editor placed objects. We've known for at least a decade now that littering the map with them is brings down performance more than the visitor placed ones.

It's probably coming from the civilian randomization script that BI has in the init event handler for C_man_1. You have to override the init event handler in the config of your unit.

Nope, haven't found any. It's a fairly straightforward test. Leveling Kavala and waiting for the dust and FPS to settle is ~22 FPS loss compared to the intact Kavala. Before and after. Click the image itself, not the little yellow stripe for a larger image.

You shouldn't need to do it manually. If you place the Empty > Wrecks > Blackfoot wreck, it will start sparking on it's own.

If an object is on a slope, taking the surfaceNormal on it's position (what you are currently doing) means that the vector you get back will be pointing in the direction the surface is pointing towards. What you need to actually do is ignore the terrain and just set it's up vector to point upwards, like so: _obj setVectorUp [0,0,1] To illustrate: Edit: Ninja'd, but I'll leave it as it might help you understand the difference between a surfaces normal vector, and a fixed vector of [0,0,1]

Well yes and no. While this might not be the root of all evil, it appears very inefficient. A destroyed town will always have twice the objects in the scene, so let's say, Agia Marina has 50 houses, when they become ruins, there will be 100 objects present. For example, if we take that X is the current "healthy model" entity and that Y is the ruin model entity, when X is destroyed: New object entity Y is created, with the ruin model and placed on the position of object X Object X is sunk into the terrain Objects X and Y persist for the entirety of the mission (Unless X is made healthy again, at which point Y is removed and X is put back where it used to be) To me it seems much more efficient to do: Entity X is altered to be the ruin model New entity Y is created with the "healthy model" and then sunk into the ground When Y stops sinking, delete the Y entity as it was only used for visual effect and it's no longer needed Only X persists for the entirety of the mission (In case it's made healthy again, just swap the model again) The potential issues with the current approach: Memory/processing power needed to keep 2 entities for each destroyed object might get significant as the "object kill count" rises Retrieving object position is not always correct (as shown by DasAttorney) Terrain might not block the rendering of the "sunk" objects With more objects present, serialized save files are probably much larger than necessary

I don't think so. They are probably left there so that any scripts referencing them can still find them. The ruins that get created in their place get new references. Maybe some other engine reason as well. Setting the damage on the original building to 0 will put it back in it's original place and remove the ruin and it's reference.

You certainly have a strange definition of same. Considering it means identical, exact with no changes. And both of those things you say are not like that, as you say so yourself. I see no point in you correcting him, considering that Kaxii is more correct in saying what he did since "based off of" means the exact same thing as your second sentence there.

I can replicate that you cannot reload magazines from the backpack, but not the disappearing part. If I transfer a magazine to my vest or uniform, I can reload it fine and nothing disappears. I'm hoping that this might mean that BI is attempting to implement this.

False. That's a screenshot from Arma 2 as vanilla as it gets.

Seconded. This was really frustrating. Also, I don't remember the main menu doing the sub-item animating. While it looks really neat, in some cases you're just forced to wait after a click. Like if you open up the configure menu, then want to go into a sub item of play, it animates the Configure closing then Play opening. If I might suggest altering the mechanic so that the open still animates, but close is instant or that the close happens at the same time as the open. I slapped together a demo of what I'm trying to say.

The purpose and circumstances are fairly different. And it's pretty much the same conclusion again, nobody is forcing you to participate.

Just so it doesn't get lost in the Make Arma Not War discussion. Now we all know how that competition came to be. :p

No, but look at the question in the end of that post that's using your logic that there will only be 2 entries, a campaign and a mission by different authors and that BI will judge according to logic that a campaign beats mission.