pettka
-
Content Count
838 -
Joined
-
Last visited
-
Medals
-
Medals
-
Everything posted by pettka
-
This is consistent_ :icon_twisted: "This is War_" and such are all along Arma 3 :icon_twisted:
-
04-07-2014 Size: ~15 MB AddonBuilder Changed: Log is now stored in Arma 3 Tools\Logs\AddonBuilder.rpt Arma 3 Tools Launcher Added: Start-up parameter "-clearSettings" to reset all application settings Added: Support of Publisher (new tool) Improved: Support of external tools (TexView 2, FSM Editor, Mikero Tools & Poseidon) Changed: Now requires a common library Changed: Now uses a unique file to store log output (Arma 3 Tools\Logs\Arma3ToolsLauncher.rpt) Changed: stdout is now in rpt only (no more console) Fixed: Some dependencies were missing and others unused Fixed: Button to BankRev directory was not working Dev-P Changed: stdout is now stored in Arma 3 Tools\Logs\ ImageToPaa Added: Progress bar and information about progress (http://feedback.arma3.com/view.php?id=19346) Added: Options to show stdout and open log after conversion (saved in application settings) (http://feedback.arma3.com/view.php?id=19346) Added: Start-up parameter "-clearSettings" to reset all application settings Improved: Layout Improved: Starter rewritten Improved: Config Changed: Now uses a unique file to store log output (Arma 3 Tools\Logs\ImageToPAA.rpt) Fixed: it was needed to restart the UI when a non-existing path was used as source InstallScript Added: Node for Publisher Library (common.dll) <early experimental version> Added: Common functions mapDisk Changed: stdout is now stored in Arma 3 Tools\Logs\ mapFolder Changed: stdout is now stored in Arma 3 Tools\Logs\ Publisher Added: the first iteration of Publisher (no UI skin yet) Changed: Log is now stored in Arma 3 Tools\Logs\Publisher.rpt Samples_F Added: New lamp sample
-
Wait for it, it should work sooner than expected :icon_twisted:
-
Weapon sounds affected by suppressors change in 1.23
pettka replied to pettka's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
I am sorry to say that, but it affects both hand weapons and vehicle ones :icon_evil: On the other hand, the changes are rather easy to do, it just takes some time (took me about two hours to do all A3 weapons in one go) :icon_twisted: -
Weapon sounds affected by suppressors change in 1.23
pettka replied to pettka's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
As many as You like, as far as I know, there may be some limit for the numeric format, size of array or wazzit, but tens of indexes should be safe :icon_twisted: -
Project folder is empty after binarizing with Addon Builder
pettka replied to francis's topic in ARMA 3 - BI TOOLS - TROUBLESHOOTING
Thanks a lot for letting us know, there is a bug in copying the PBO into target directory that should be fixed with the next tools release (SoonTM). The PBOs are correctly packed in the temporary location, which is set in the options, you may find the output there in the meantime :icon_evil: -
Weapon sounds affected by suppressors change in 1.23
pettka replied to pettka's topic in ARMA 3 - ADDONS - CONFIGS & SCRIPTING
It just denotes that it's a float value, our programmers use it all the time to make us sure :icon_twsited: -
What would you like to see worked on next in ArmA 3?
pettka replied to Westonsammy's topic in ARMA 3 - GENERAL
Do You happen to know that the Terrain Builder, successor of Visitor, has been already released in the same version our map artists use for creating the maps (even Altis has been created using this tool)? :icon_twisted: -
Thanks for valuable input on behalf of managing the company, could You all, please, return to the topic? Feel free to continue with this discussion in another topic if You want to :icon_twisted:
-
Lite version is not an option. Period :icon_twisted: The reasons were stated in the blog, but to make it clear, if there was a lite version, there won't be any kind of development branch, especially not with the daily updates. Preparing data for publishing the lite version takes a day of work, which simply isn't compatible with daily updates for obvious reason :icon_twisted: It may seem strange, but our blog posts are sincere - when we say that lite approach has some issues data-wise and marketing-wise (game seen as a low quality one by people not knowing about Lite approach), it actually means that it does, not a bounce more, nothing less :bounce2:
-
Thank You for Your sig, I like it :icon_twisted: Please note that the inverse kinematics is used in game for pretty long time, take a look at the hands and weapon during recoil for example, or animation of hands on driving wheel / pilot stick. I just said: "Ermahgerd, Y U NO use diz for legs 2?" :icon_twisted:
-
This should explain everything, even the part about Expansion :icon_twisted:
-
Full body animations work fine, the only possible issue may be with facial animations as the skeleton of face differs :icon_twisted:
-
I would cool You down a bit, but WIP means it's not even configured at the moment, there is just an engine support for some parameter to be loaded. As You may see in the roadmap, we would like to address this for Bootcamp update, more details are inbounce soon :icon_twisted:
-
Is this enough to explain it or should I simply say yes, work in progress? :icon_twisted:
-
As it was stated in this week's SITREP, we are hard at work prototyping and it just happened that the exe didn't pass it's autotests at the same time. It just means there's going to be a bit bigger batch of engine changes today :icon_twisted:
-
Not only about Arma 3, but may be quite interesting to see development of it from another angle: http://www.eurogamer.net/articles/2014-04-29-bohemias-war-the-story-of-the-company-behind-arma-and-dayz :icon_twisted:
-
If I were to check the fire mode on the battlefield, I would probably take a look at the fire mode selector. And that's right what we have done in Arma 3 - the fire mode selectors on weapons are displaying current fire mode. No need of UI for that :icon_twisted:
-
Just to make it clear, we are working on the optimization and it is an ongoing task (as may be seen in the changelogs and all the BROREPs). I have just clearly stated that using resources depends on mission makers too, our missions are optimized even in this way. But throwing hundreds of AIs to some frenetic urban battle and expecting no performance hit would seem funny to every game developer :icon_twisted:
-
There is actually such possibility, but it is simplified into one countermeasure source in the basic game. You may even see aluminium strips (chaffs) effects around the flares. There are even advanced detection methods for vehicles to display warnings dependent on the type of lock. The possibility is available for modders to make game more complex if they want to and I know about some mods that use this :icon_twisted:
-
First of all, welcome to the forums :icon_twisted: I would dare to differ. Your point is mainly about AI being not optimized, which is caused by many different reasons, but there has been quite a lot of optimization in this way. The obvious issue is that Arma (all of them) isn't as player centric as various other games - it is possible in most cases that AI could finish/fail some mission on it's own even without player being involved, like it is in the real life. That means AI needs to be able to act independently, but that is a bit off topic here. The logical result is that AI is quite performance hungry as it does the same computations no matter if it is right in front of player or kilometres away :bounce2: It has been already mentioned here that one of the most taxing part of AI computation is pathfinding. Our AI is able to handle dynamic surrounding changes (structures being destroyed, paths blocked by wrecks or endangered by enemy and so on), this ability has been optimized over the years of development, but it may seem that it is still quite performance heavy during some bigger changes (eg. spawning 50 soldiers together or some battle in town). Our missions take that into concern and are quite well optimized, but it may not be a cause of all the missions. The question at hand is if we should allow to throw sand from our sandbox into delicate oiled machinery of engine and I dare say that we should enable the players to do what they want despite it may break the immersion for them if they do it wrong :icon_twisted: We provide them the sandbox to play with for hundreds of hours and they do, You do.
-
He clearly means @Endstar's Twitter where he specified that he cannot confirm nor deny :icon_twisted: I would dare say that it is a bit off topic here.
-
We are looking for more :icon_twisted: http://www.bistudio.com/careers
-
Prepare P:Drive not working, cannot find registry key or value error.
pettka replied to Juhansson's topic in ARMA 3 - BI TOOLS - TROUBLESHOOTING
It's not actually necessary, just convenient - most of the tools is prepared with P: drive in mind. You may set up the tools differently, but it would take some additional time. Our first thought while preparing tools for Arma 3 was that there is no need of such virtual drive. We actually use it for our work, but it's not needed (as I have learned by mistake while setting up my first workstation). There was a strong push for re-introducing the P: drive from community who was used to it and it's even easier for us to have some "standard" drive to refer to in our tools :icon_twisted: The first iteration of the tools (without P: drive) was more meant for expert users (as it didn't even get most of the tools yet) who should be able to set their own working drive according to their needs in all tools (and may name it even differently than P: drive). The addition of P: drive in cooperation with Tom_48_97 should set some defaults for easier addressing some common issues (eg. starting of Buldozer viewer in Object Builder) :icon_twisted: -
Stop being off-topic and see http://www.bistudio.com/english/company/careers :icon_twisted: