sergeant rock

Without learning to script/code and employing ArmA Scripting commands, what you are asking for is not going to be possible.

Thank you ceeeb! I've tested and it works perfectly. I knew someone could solve this with math and good code. This will make a great placeholder until such a time as the createSimpleObject command goes stable build. Wish I could buy you a beer mate, but the best I can offer is to give your credit in the mission briefing. ;)

damgerousdiz_ thanks so much for the try but I'm still getting vertical textures employing your method, I think the best course of action right now is to wait for createSimpleObject, that killzone_kid suggests, to hit the release build as it seems a very straightforward way to get done what I'm trying to do. Thanks to all.

johnnyboy thanks for the response but unfortunately the same result. The attachTo just attaches the texture to the photo in its normal orientation which as we know is perpendicular to the photo. Same thing goes for capturing the vector of the photo and then applying it. The vector of the photo sitting flat is the same as the texture sitting upright. The math is here somewhere just need someone smarter than me to point it out. :) As for the texture I'm using, its just a texture I downloaded from an old Duke Nuke'em forum and photoshopped it a bit before converting it to .paa format. You can grab it here. Here is how it looks when flat (flattened by manipulating with rotation widget in 3den editor): And when its placed or created in default orientration: Anyone have any other suggestions?

Sorry to resurrect this older thread but I am doing a similar mission where the players are tracking a wounded unit. I'm using "UserTexture1m_F" and applying a blood drip texture to it. Using setVectorDirAndUp I can get the normally vertical object to sit on flat ground just fine and the blood drips at a random interval as the unit attempts to evade the players. The problem is when the escaping unit heads down/up a slope. I've been unable to get the texture to sit flat on sloped ground. I've tried multiple methods with no luck and am looking for some help. Does anyone have any ideas or script examples showing how to get "UserTexture1m_F" to sit flat, even on various slopes? This is just example of the base code that works fine for flat ground: _blood = createVehicle ["UserTexture1m_F",[getPosATL player select 0,getPosATL player select 1,(getPosATL player select 2) + 0.01],[],0,"CAN_COLLIDE"]; _blood setObjectTexture [0,"blood.paa"]; _blood setVectorDirAndUp [[0,0,-1],[0,1,0]]; If the user texture object were just flat like "Land_Photos_V1_F" it would be very easy.

I'm 44 and have been playing this series since the OFP Demo. I formed our gaming group, Rock's Raiders, in 2001. Many of the original gang still play, though we are more limited in time with families, careers, etc.. Glad to see some older gentlemen enjoying the game. Cheers.

ArmA3Sync had been working fine (this is the server running the repository) until today. Now I get this error: Running the debug I see: ArmA3Sync Installed version = 1.4.63 DevMode = false JRE installed version = 1.7.0_79 java.net.SocketException: Network is unreachable: connect at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:895) at org.apache.commons.net.ftp.FTPClient._retrieveFile(FTPClient.java:1855) at org.apache.commons.net.ftp.FTPClient.retrieveFile(FTPClient.java:1846) at fr.soe.a3s.dao.FtpDAO.downloadFile(FtpDAO.java:111) at fr.soe.a3s.dao.FtpDAO.downloadSync(FtpDAO.java:126) at fr.soe.a3s.service.FtpService.checkRepository(FtpService.java:90) at fr.soe.a3s.ui.mainEditor.MainPanel$25.run(MainPanel.java:985) at java.lang.Thread.run(Unknown Source) Connection updates repository Success ArmA3Sync Available update version = 1.4.63 The network is fine. Everything else on the server works without issue. Any ideas?

I think you should remove the dependency. Requiring the download of a ~400MB mod to use a ~8MB mod is a bit much, especially if you have no use for anything in the EvW mod.

Not an error with performance or dynamics, but I get this error on screen (I have "Show script errors" enabled): And repeatedly in my ArmA rpt log when using the Apache: Anyone else getting this? Doesn't happen when I load the Viper or Chinook.

It appears the error is being caused by the East vs. West addon, not yours Drongo. The config.bin of sud_gw_wpn.pbo contains a reference to sud_np_wpn\sud_strela_rocket.p3d on line 28: and to sud_np_wpn\sud_strela_loaded.p3d on line 37: That path and p3d file does not exist in this release of East vs. West. Not sure why others are not seeing this issue.

Drongo, Firstly, thank you for your work on this. It really fills a niche for much needed middle eastern units. Bravo. Secondly, I get this error when launching a mission with @MEC units in the editor: Error in log: Warning Message: Cannot open object sud_np_wpn\sud_strela_rocket.p3d I have the East vs. West addon installed, but the download does not contain a sud_np_wpn.pbo Lastly, Would it ever be possible to decouple this from East vs. West and make it standalone? Too much effort?

That fixed it, thanks armatech.

Same here. Otherwise a brilliant addon!

Excellent tool Tom, thanks for taking the time to develop it. 2 quick questions: 1. Is it possible to highlight the active tab better? In the "bis default" color scheme its very hard to see which tab is active at a glance. Perhaps change the tab color or the text color to something that contrasts more against the others? 2. Highlighting text within the script is also very difficult to see. The color variation is very subtle against the gray background. I apologize for my middle-age eyes. They aren't what they used to be. ;)

Sorry to resurrect an old thread, but I have been experiencing this same issue and am unable to find a resolution. I have created an array of editor objects (actually they are what I call building "profiles" which contain quite a bit of useful information about the buildings such as the number of positions inside, classname, number of doorways, number of windows, coordinates of all entries and exists, etc) which I then plan to call random elements from and perform some random operations specific to the mission. For arguments sake, lets say this: aoHouses = [1081388,1081509,1080931,1081274]; The problem is that these editor objects are 7 digits, 1 digit longer than what is allowed and therefore results in a float being returned when you select an element from the array. For example: hint format ["The selected building ID is %1",aoHouses select 0]; Will return: The selected building ID is 1.08139e+006 I've tried some workarounds with strings and parseNumber, but with the same result. I also tried to modify a similar issue as described by KillzoneKid here but without any luck. For a simple example, let's say I want to name a building: House1 = (getpos player nearestObject (aoHouses select 0); Does anyone have any ideas on how I can select these elements and pass the proper numeric representation to a script?

Same here.

Assuming 6.0.6.4 is the current version, I experienced the following error in the log when using the "NOWAIT" parameter: The offending line of code is line 160 of UPSMON_MainLoop.sqf: _pause = if ("NOWAIT" in _UCthis) then {_pause = "NOWAIT"} else {"WAIT"}; It should be: _pause = if ("NOWAIT" in _UCthis) then {"NOWAIT"} else {"WAIT"}; I'm sure this is just a copy/paste mistake. :) Thanks Azroul for keeping UPSMON going.

Would love to see a civilian Cessna Citation or similar class of jets. Well done.

My squad has enjoyed playing these quite a bit. You have created some great missions with a nice sense of balance, mood, and context. Thank you very much.

Kronzky, Can you comment on the issue many have experienced where the enemy AI are in an instant state of agitation (combat behavior) even if they do not know and cannot possibly know that an enemy unit is on the map? It very easy to reproduce. In a previous version of your script, I was able to stop the behavior by commenting out a specific line, but I can't tell you which one right now because I don't have access to the script from where I'm at. Please advise if you can.

I'm not sure that's the issue. I've tried that for a fix with the same result...the OPFOR enter "alert" mode without any apparent knowledge of BLUFOR. If you take the test mission that comes with the UPS script and modify it slightly you can see the behavior exhibited. Take that mission and move the BLUFOR unit to an area as far away as possible. Now replace the "player" with an OPFOR unit so you can observe them as they patrol. In less than a minute the OPFOR will become agitated though there is no possible way they could know about the BLUFOR on the other side of the map. Now go back in the editor, delete the BLUFOR unit and observe again. You will see they remain "CARELESS" and just meander around the town. To make it easy to test: ups_test.Stratis.zip

I'm happy to release my first mission for ArmA3 Beta. This is my first complete mission since back in the OFP days and it took me a bit of time to get reacquainted with the syntax and the idiosyncrasies of the engine. This is a simple, quick into the action mission for a small group of players. Though the mission is short in scope relatively speaking, it is fully realized in content, context, and completion. Mission Name: Operation Candlestick Mission Type: COOP # of Players: 1-4 Time Of Day: Night (Changeable in Parameters) AddOns Required: None Support: Limited UAV assistance Revive: None Background: The economy of the small island nation of Stratis had been in deep recession for years. As unemployment and inflation continued to rise, the locals on Stratis began blaming foreign investors and imported labor for their ongoing problems and hardships. As the economy continued to spiral out of control, the blame also shifted to the government, seen as an American puppet, and peaceful protest gave way to rioting and conflict. Out of this conflict arose the SDL. Mostly young, mostly unemployed and disenchanted, but certainly all angry, the membership of the SDL continued to swell. Their methods turned more confrontational and violent as the radical elements of the group, lead by Col. Firouz, seized control of the leadership and its message. What started as disorganized marches and civil disobedience devolved into rock throwing, bombings of government buildings, and more recently organized, armed attacks and kidnappings. The central government, known as the People’s Democratic Republic of Stratis (PDRS), has not only been severely weakened by the bad economy, but more recently by the defection of many military members to the SDL. With its grasp on power weakening and the people on the edge of revolt, the PDRS has reached out to America for economic aid and military assistance in fighting the SDL. The Americans, not eager to publicly get involved in yet another conflict, have instead assisted with intelligence and logistical support. However, every once in a while, small Special Operations Forces are called upon for highly critical missions. None have seen more action than the secretive and elite D.A.R.S team. SDL: The Stratis Defense League (SDL) is paramilitary group who has its origins in a highly nationalistic hate group whose main goal is the cleansing of all foreigners, through intimidation and violence if necessary, from the island of Stratis. In recent time, and with the emergence of the mysterious Col. Firouz, their goals have expanded to complete governmental overthrow. DARS: D.A.R.S. is the acronym for the elite Special Forces teams that specializes in Destroy, Assault, Rescue, and Sabotage operations. They normally operate in fire team size elements and are highly trained and specialized, able to operate in any combat environment. More of a scalpel than a sledge hammer, these small teams bring asymmetric warfare and tactics to an increasingly asymmetric enemy. Briefing: Recent intel was uncovered showing that a dangerous sale of a shoulder-fired AA missile launcher was underway between members of the SDL and a known arms dealer who goes by the name of Massoud. Unfortunately we deciphered the intel too late to capture both Massoud and the weapon he was selling, but you still have time to destroy the AA launcher if you hurry. Your D.A.R.S. team is located on the USS America, an amphibious assault ship located about a kilometer outside of Tsoukala Bay on the southeastern coast of Stratis. This America-class ship is a 45,000 ton fighting machine. Carrying over 1,500 Marines, support teams, and a wide array of weaponry and vehicles, including both helicopter and fixed-wing assets, the USS America is capable of projecting extreme force wherever and whenever necessary. Mission: Your mission is to insert via SDV to the insertion point indicated on the map. From there you will depart and swim, undetected, to the shoreline. Once on shore, coordinate an assault on the objective. The objective is a small fishing village on Tsoukala Bay consisting of 5 ramshackle buildings. Find and destroy the AA missile launcher that Massoud has just sold to the SDL. Download Mission: Operation Candlestick v.1.8.8 BETA Armaholic Mirror: - Operation Candlestick Co-04 [bETA] Since ArmA3 is BETA I will keep the BETA tag on my mission as changes made by BIS may break the mission. I also reserve the right to delve back into this mission and add some additional tweaks or content based on feedback. Constructive feedback is appreciated. Even though this mission has been tested in an MP\Dedicated Server environment over and over again, sometimes things in ArmA just don't work right, whether it be bad latency or some other uncontrollable reason, or intentionally finding ways to break the mission. I've tried to account for everything I can think of, but I'm sure folks out there can think of plenty more. Lastly I'd like to thank the many scripters. mission makers, and others whose work has got me through this mission. A special thanks to Kronzky for his UPS script and Engima for his Dynamic Weather script.

We noticed that bug during testing and were never able to pin it down exactly, but we believe the cause is UPS. Other editors have reported a bug that caused the OPFOR to be agitated if a BLUFOR unit existed anywhere on the map, even if they exist on the complete other side of the map. Since Kronzky has no intention of updating his UPS script until the final release of ArmA3, I'll hold off on updating this mission until then. Hopefully that will fix it. If anyone else has any ideas, I'm all ears.

Task Modules work fine in MP, its all in how you implement them. I hate to keep whoring out my mission, but it implements tasks that work properly, in order, and in MP. It seems there has been a lot of questions in their regard lately and I just want to help. Download and DePBO my mission here and good luck!

I just pointed someone else having task trouble to my recent mission. I used modules to create and assign the tasks and fought with it for quite a while before I got it working properly. One of the most annoying things was getting the task order right without it being random. I did this by synchronizing the tasks with each player individually, and in the order I wanted them assigned. DePBO my mission here to see how I set it up. Good luck!