Jump to content

Make Love Not War

Member
  • Content Count

    155
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Make Love Not War


  1. I'm totaly agree with that, a guy from my group create the "Armageddon " mod for Muliplayer contest, he spent much 1000 hours to make the script work well for the tornado and other stuff, depending of optimisation for other player, he got 224 supporter, he was promoted, is mod was downloaded more than 40 000 time and he don't have a place for the final?

    I have to jump in here and remind you that there was two of us working on Armageddon! Still, your words of support here mean a great deal to me (and super-truite as well, I'm sure). Thank you! And, yes, the mod required overcoming numerous technical challenges on both our parts and it was very gratifying to see the enthusiastic reception from the player community upon release.


  2. Anyone played it until the end in localhost SP mode? How about the balance?

    The balance is such that you'll probably die a lot, but with the current system of unlimited respawns it shouldn't be impossible. :) The one big, game breaking issue with playing the mission in localhost on your own, however, is that, at thi moment, you are pretty much forced to take a repair specialist. Any other character class is unable to use the tool kit to repair vehicles. We'll probably "fix" this by creating a special, universal Tool Kit item that is available for all classes to use. In fact, at some point in the not to distant future, we're hoping to improve and expand upon the entire vehicle repair process similar to what AGM does.

    Howdy Super-Truite, wanted to let you know that I've been spending the past few days making some tweaks to ArmAGeddon. They may be things you've already done or are working on. When I'm done, I'll send you the mission file I've modified where you'll be able to use any part of it you'd like. Thanks for the wonderful mod! We're having a great time with it. Can't wait to see the volcanoes. ;)

    Looking forward to seeing your changes! I hate to say this because everybody is very excited for the volcanoes, but it seems unlikely that we'll be able to get working volcanoes into existing maps - such as Altis - due to performance and engine limitations. It would be possible, however, to create a new terrain just for ArmAGeddon with working volcanoes already built-in - that's an option we are considering.

    Pssst, hey super-truite, I'm still waiting for that SP version you talked about some time ago! ;D

    Yeah, that's actually my job really. A proper SP version shouldn't be too much work; we're looking to release an (somewhat larger) update by the end of the month which will hopefully include the SP.


  3. ...it still means that there is one more step to take to get your hands on the data. And if it would remain only in the underground. that be good...

    Keeping the data out of the criminals' hands is the stated purpose behind your idea, and yet here you admit that not only would the underground continue to maintain access, but, in fact, they would become the ONLY people with access. You want to punish legit users in order to create a minor inconvenience for the outlaws.


  4. Ebos would create greater damage to the modding community than the problem they are attempting to solve (piracy). Without the ability to learn and build upon the work of others the Arma modding community will largely cease to exist in short order as the barrier of entry for potential newcomers will become far too daunting.


  5. First off, thanks for all the praise and the feedback, guys!

    @super-truite

    but there problemy FPS sags and lags when playing in a pair.

    poorly optimized.

    disabled only earthquake.

    Konaba, can you be a bit more specfic as to what is happening when you experience fps lag spikes? Are there any obvious patterns as to when these occur? So, if I understand corrrectly, you disabled just the earthquakes and all the other special effects are active and you're seeing lag spikes?


  6. Many thanks for the rpt log, IHUNTERI. Yeah, we ran into this once or twice during our playtesting, but it was so intermittent that we were unable to replicate the issue properly. Good news is that I know exactly where this is occuring - it's the empty vehicles spawn/caching script - so hopefully we'll be able to track it down soon. Also, for the record, I too consider myself one of the "old grumblers" (although I prefer "miltard" or "milsperg" personally :D), but we thought since this mod was for the contest it was the perfect time to fool around and try something a little different. My future mod plans are a lot more "hardcore", BTW, but not before ArmAGeddon (possibly) gets a lot more crazy in the not to distant future. :SpiningDemon: In any case, great to hear that our fellow "grumblers" are also enjoying the mission!


  7. Lachesis580, thanks for taking the time to try it out on dev build. Yeah, I had a feeling it might be working on stable and not dev. It might very well be an issue they are aware of, but we should probably let BI know that ctrlText is no longer working with HUD elements in dev build before it is migrated over and becomes a pernament fixture within stable. At a glance, I don't see it reported anywhere. Seeing as you are much more familiar with the issue than me, would it be possible for you to create a feedback ticket or post something in this thread? If you do post a ticket let us know back here so we can go and vote (already voted on your original currentGrenade ticket, BTW).


  8. Hey,

    OK, addon is running and function is there, but it produces following errors:

    13:39:52 Error in expression <idx = 0;
    _curstr = [];
    while {_curidx < _countstr} do {
    _char = _strar select _c>
    13:39:52   Error position: <_countstr} do {
    _char = _strar select _c>
    13:39:52   Error Undefined variable in expression: _countstr
    13:39:52 File x\cba\addons\strings\fnc_split.sqf, line 26
    13:39:52 Error in expression <_fnc_defaultParam;     ;
    
    _strar = toArray _string;
    _separ = toArray _separator;
    _c>
    13:39:52   Error position: <_string;
    _separ = toArray _separator;
    _c>
    13:39:52   Error Undefined variable in expression: _string
    13:39:52 File x\cba\addons\strings\fnc_split.sqf, line 13
    13:39:52 Error in expression < _replacement = (_this) select 2; ;
    
    
    [[_string, _pattern] call CBA_fnc_split, _>
    13:39:52   Error position: <_string, _pattern] call CBA_fnc_split, _>
    13:39:52   Error Undefined variable in expression: _string
    13:39:52 File x\cba\addons\strings\fnc_replace.sqf, line 12
    13:39:52 Error in expression <') displayCtrl 151);
    
    _ggtyp = ctrlText _distyp;
    _ggcountRaw = ctrlText _discoun>
    13:39:52   Error position: <_distyp;
    _ggcountRaw = ctrlText _discoun>
    13:39:52   Error Undefined variable in expression: _distyp
    13:39:52 File CurrentGrenade\580Addons\CurrentGrenade\CurrentGrenade.sqf, line 6
    

    And the SCW_fnc_currentGrenade function itself is returning:

    [string,""]

    I'm on dev build 1.35.128059 and loaded only @CurrentGrenade and latest @CBA (1.0.9.140907 RC4) as addons into SP.


  9. We are playing this a lot. I prefer it when we are started in the far east of Altis as it becomes a dash to get over the middle of the map before stuff gets cut off. Starting in the west lessons that sense of time ticking and danger.

    Just had a peek at the code, and currently the whole central isthmus and airport area is generally no higher than 15m which means it gets flooded in 25 minutes at current rates. Starting in the far east, players would almost never make it. We could certainly play with increasing that time to, for instance, 45 minutes, but then that would mean for anybody who did make it to western highlands they could easily forget worrying about the water for another hour or more. Still, there are perhaps other, much more dastardly, solutions to this pacing problem... :D We will certainly have another look into these things!

    I would like to see some sort of revive system used instead of re-spawn

    That's not a bad idea. We couldn't use any of the 3rd party revive systems for the contest and certainly didn't have time to write our own, but now it could be something to look into.

    and maybe another couple of player slots.

    Could be done, although 10 men is the max number that fit into a Ghosthawk (which is what got the players to Altis followed by a prompt crash upon arrival), so adding slots might be a bit of a credibility stretch. Again, there are probably creative ways around such limitations. ;)

    Keep up the amazing work.

    Thanks! And thanks for the feedback. :)


  10. Sounds like everybody is enjoying the mission, and, even better from my perspective, there have as of yet been no real reports of bugs! :D Yes, as BadLucky1776 discovered, the addon has to be turned off when not playing the mission or it will flood the island in any other mission you attmept to play. Perhaps BIS will provide us with a setWaterLevel scripting command some day, but for now we create the flood by modifying the maxTide value within the island's config file.

    Having a great time with the mission. Is there an actual goal or way to succeed? We got a helo and flew around for a half hour but couldn't figure out what to do.

    Yes! The idea is to grab a helicopter - either find one and fix it up or hijack one from the AI - and escape the island before time runs out and it is completely flooded. So, if you guys were exploring around in a helicopter you had pretty much already won. :) The only thing left to do is fly off past the edge of the map. Although there is a help hint that pops up briefly at the start (just after the intro video snippet plays) that explains the situation and the mission goal, we should probably make things more clear. Perhaps a further explanation within the briefing screen? Or some more help hints popping up when a player enters their first chopper? A title text in the centre of the screen at the beginning screaming: "Get to da choppa!"? Yeah, probably not the latter idea. ;)

    Also, while we're talking about escaping the island, there are currently plans to introduce boats as another method of egress. The idea being similar to the AI helicopters flying in to extract their teams, there would also be AI boat pickups. But, there's a number of pretty serious technical issues to sort out before this can happen. I will write more about those and other technical aspects and challenges (past, present and future) in an upcoming post.

    Excellent.

    Downloaded both mod & mission and played it through on local until water level was up, about 1hr 45.

    I only saw one server running the mission (French) is that yours?

    Most probably. If it's the Armadeus server then that is indeed super-truite's.

    Be sure to continue with the SP mission, I'm certain it will be a great success.

    Thanks, have some :icon14:

    Many thanks! We'll make sure to release an SP version. It really shouldn't be too much of a problem; most of our pain in the making of this mission came from dealing with MP hijinks, so back-porting to SP will hopefully be child's play for us (famous last words ;)).

    Thanks for the feedback, guys. Don't be shy about reporting bugs and making feature requests. Work on version 1.2 has already started with new fixes, improvements and goodies coming down the pipe soon. But, again, I'll leave that discussion for an upcoming post. ;)


  11. Lol, we should rename this HADES now ;).

    We are now two to work on this project. So please make a standing ovation for my collegue: MAKE-ARMA-NOT-WAR!

    Howdy, I do believe super-truite is refering to myself. Admittedly, all these "make this, not that", "do this, don't do that" names can get a little confusing. ;) Currently, super-truite is working on the special effects and other goodies, while I am trying to sort out the underlying scripting framework dealing with spawning, objectives, AI, game logic update, etc.. Right now, my primary goals are:

    • Replayability - ie., a fair bit of randomized and procedurally generated gameplay, such as new starting locations and objectives on every playthrough.
    • Performance - writing various scripts and systems within SQF isn't terribly hard, but writing them so things run fast and smoothly is quite the "challenge" (read: involves a lot of swearing, alcohol and despair).
    • AI - ideally, we want the AI to react to and navigate around the rising water and other hazards, but, as one can imagine, this will be no easy task to script without eating up server resources.

    Lol, we should rename this HADES now ;).

    Gotta admit, HADES does have a nice ring to it. :)


  12. ...I'd prefer they seriously downsized maps to OFP size or smaller...

    No, sorry, I must respectfully disagree. You seem to be thinking strictly from an infantry perspective, while I think Arma should be a combined arms simulator. Vehicles - especially aircraft - need room to manuever, so, provided details aren't sacrificed, the bigger the better as far as map size is concerned. Although Chernarus++ sounds sexy, I find the suggestion of a mid to late 20th century historical setting for A4 the most intriguing. Korea or Vietnam perhaps? More than anything, however, I think we need to see more improvements to the base simulation engine. A historical setting may help with that task as the variety and complexity of technologies is reduced the further back one goes in time which in turn should alllow the devs to concentrate more of their efforts upon core functionalities and features.


  13. That's an interesting find, Gnat. Probably some sort of material property setting within the .p3d itself? I recall reports from months ago regarding the helicopters sticking to all surfaces in an unrealistic manner as if super-glued, so I'm thinking heli wheels and skids are simply given some silly high friction co-efficient. Has anyone looked within the model configs? Didn't have any time for Arma this past week, BTW, so no further progress on any of this was made from my end, but I'll be back at it shortly.

    Ed: Just looked inside one of the helicopter model configs and nothing about friction or physx.


  14. Indeed, it's the holidays and the devs deserve a break. Either way, first I want to take a day or two to investigate this idea of using a proxy vehicle. If that fails, I'm thinking the wisest course of action will be to release a working version of the script implemented to the maximum of my abilities, evaluate the specific engine changes needed to allow the script complete functionality and then present all of this to the devs as one package. I think making requests of them to re-write portions of the game code whilst demonstrating an almost fully functional script solution will make for a much more powerful statement than going at them in a more ad-hoc manner. Another quick thought: although A3 is problematic ATM, I'm pretty confident that a version of this script could be adapted to work in A2 with relative ease. Any interest in such an attempt?

    Ed: Also, thanks for stopping by, Krem. Yeah, this is pretty exciting. :)


  15. cant you attachto perframe , meaning use key press on WASD then use Switchmove to play the WalkForward left etc and match the releveant location ?

    sounds easy in the above but i have done something similar in the past and BIS now include some good trig and other funcs in default to helpout .

    I appreciate its all abit convoluted but im sure if a way is needed that would be the way .

    the only other thing i can think of is a vehicle that is simply made of a Proxy and the Vehicle setposed whilst the player whilst inside the vehicle would assume the stance of the Driver or Cargo anim , this anim again could be changed if required and thus negate all this halo stuff.

    Problem with switchMove is that it switches to the start of the anim passed to the command. There does not appear to be a method to switchMove to a specified frame of an animation, so calling it per frame simply locks the character into the first frame of the passed animation. One has to use playMoveNow instead, but the freefall anim overrides that command. SwitchMove also locks the character's upper torso and prevents both aiming animations and freelook. AttachTo has pretty similar effects in that again it locks the character along with preventing freelook and weapon aiming. The is a problem introduced with Arma 3, as Dsylexci succesfully used AttachTo for his LittleBird addon in A2.

    Yes, once the unit is attached to the vehicle object by either using attachTo in A2 or setPos'ing to match the vehicle's movement in A3, the next step is to use the keyDown and keyUp display eventhandlers to read keyboard inputs to displace and animate the character accordingly. Most of the trigonometry is trivial; you just have to add up a few vectors. This is how the truck part of the script works; it just fails with aircraft because we lose script control over the animations at altitude.

    Yeah, the invisible proxy vehicle idea I have also thought of and played around with a bit, but it might be worth another shot. It might be possible to create an invisible proxy vehicle which allows the character to use the full spectrum of his usual animations while inside of it. From there one simply attaches the proxy vehicle to the vehicle being ridden and then steers the proxy around while playing corresponding character animations. I suggested pretty much this idea in a post somewhere on these forums more than a few months back.


  16. Ok, just tested the roadway LOD idea and I don't think it can be applied to this case. If the unit begins by standing on a roadway which is then moved upwards above the 100m ATL mark, then everything functions as normal with the unit able to walk around on the surface and so forth. So far, so good. If the unit becomes detached from the roadway in the slightest, however, he immediately goes into the freefall anim and becomes subsequently stuck there. More crucially from the standpoint of this script, all attempts to use any of the setPos commands on the unit while he is standing on the roadway and > 100m ATL immediately throw him into the freefall anim again. Seeing as all variations of this script are built around the ability to setPos the unit onEachFrame, this line of inquiry appears to be a bit of a dead end.


  17. Maybe you can sent a PM to one of the developers to see if they can help you with that..

    It's always an option, but we can't depend on it. I'm hoping the community might have some suggestions or ideas that I overlooked.

    Dan;2588256']I am extremely excited with what you have managed to achieve. I could live with what we had so far to be honest' date=' but hopefully BIS can get you over that last hurdle.[/quote']

    Thanks for the perspective, but ideally I'd love to make this solution as universal as possible.

    Maybe the very thing that hindered progress in A2 will help in A3 in this situation , A roadway Lod would return a Height of 0 no matter how high you were , so maybe set //attach a roadway Lod under the unit and test , i suspect the small clutter cutters should have a roadway lod if you want addon less test .

    Thanks Sealife! If roadway LODs really do return height 0 then that would probably be the fix I need. I actually played around with this idea yesterday, but it didn't seem to work. As I was trying out a variety of solutions, however, I ended up rushing through this one and it's quite likely I set things up wrong. I will most definitely investigate this further and report back. Thanks again.

    Edit:

    Don't worry about that showstopper for a first release.

    Screw showstoppers, the show must go on! ;) Don't worry, I'll definitely release everything that I was able to get working and semi-working, so that even if the script isn't fully functional right now future generations might be able to make use of the knowledge gained. I mean, aircraft do work pretty much as expected provided they stay below 100m ATL.... just a wee limitation is all. :)


  18. Aircraft

    Regretfully, moving or shooting while onboard aircraft does not appear possible in A3 using the same or similar techniques that I applied to ground vehicles and ships. Using the script with aircraft works as expected without significant problems except for one complete showstopper of a bug. Namely, the game is hardcoded so that any unit which is above 100m ATL and not seated inside of a vehicle (as a proxy) is automatically forced into the freefall animation on every frame. Until I find a way to override this animation the script cannot proceed (in regards to aircraft). Any help and/or suggestions will be very much appreciated.


  19. Excellent rundown, Bad Benson.

    This engine is very capable. it just needs some love in the details. BI needs to stop and breath and do the right things for once. a solid frame will make the future amazing.

    Sums up my feelings perfectly. Considering BI's current cash flow - primarily thanks to DayZ - there's no better time than the present for a serious house cleaning.

    EDIT: event handlers. we need more eventhandlers so we can make more efficient scripts. there's none for reload. the hitpart one is pretty messed up and many more i can't think of now.

    More than anything, we need native stackable EHs. Functions such as BIS_fnc_addStackedEventhandler are a step in the right direction, but incomplete and should be considered a stop-gap measure at best.


  20. @Gnat: Good observation; always much appreciated whenever people let me know that they see something weird or otherwise "fishy". Good news regarding the reloads, however. I just tested it and the reloads work without a hitch. Seems like ProGamer just hit reload and started moving backwards during the animation

    . See anything else that looks strange or unexpected?

    @Sealife: Leaning - the 'Q' and 'E' keys - is in and works flawlessly. Should have showed that off, huh? :) Stance adjusts, prone and weapon switching are some of the big ones that are not in yet, however. It's mostly a question of sitting down and going through all the animations and adding them to the code, although there will still be a few extra technical issues to sort out such as re-working the collision detection for the prone animations.

    The other big thing left to implement here is mount and dismount code. I'll release somethig for everybody to play with in a week or two, but there's still so much missing right now that there's no point in wider scale testing yet. Nevertheless, things are looking really good again (inb4 I come back tomorrow with more rage posts crying about why SQF won't let me do this or that :mad:). Thanks for the feedback, guys!


  21. Development Update

    ProGamer just kindly posted a short video of a little showcase he put together demo'ing the latest version of the script being used to move around and shoot from the back of a HEMTT truck. Yeah, I managed to sort out those animation issues I was having last week and created a method for being able to move/shoot around while riding vehicles that don't have a roadway LOD in the model p3d (ie., BIS vanilla vehicles). Seems to work pretty well, although there's a lot more work that needs to be done before this is ready for any sort of wider release.

    A few more notes: there's still some annoying jitter present which is particularly visible when the truck goes up slopes, but I'm fairly sure that can be fixed. Also, after the success of this test, I'm now confident that - by hook or by crook - it should be possible to script shooting from the interior of vehicles. The biggest obstacle to a solid implementation are animations. I imagine that shooting a rifle from the inside of a car is somewhat of an awkward proposition at best IRL. Trying to replicate that in-game so that it's functional yet still looks and feels realistic is going to be a difficult task, particularly animation-wise.

    Anyway, don't want to get too bogged down into the details just yet, so for now I'm going to leave the HEMTT and other ground vehicles and move onto testing an implementation for aircraft. Think I'll start with seeing what can be donw with Littlebirds. :)

×