Jump to content

Fortran

Member
  • Content Count

    199
  • Joined

  • Last visited

  • Medals

Everything posted by Fortran

  1. Thanks MarkJ112 Mini update. Fixed some texture problems, now using the new super shader. Fixed the proxies etc. Testing a camo pattern.
  2. Ahh fantastic Myke many thanks yet again man, by following your example and making some minor changes in my config that has actually fixed one of the errors I was getting when loading the A-10 unbinarized which was an error about "Default" not being in CfgModel or something. However I am at a bit of a loss with this. When the model.cfg is binarized and gets included into the p3D file all the animations work perfectly, however when I attempt to add the contents of the cfg into the cpp file and not binarize everything (due to the rvmat issue) only some of the animations will play. From what I notice these are the nonworking animations. Flaps Elevator Ailerons Rudder All cockpit readouts aside from the artificial horizon Every other animation seems to work correctly such as: Landing Gear Airbrakes Cockpit canopy Ladder Front wheel Engine Turbines Here is the full contents of the model.cfg (now inside the config.cpp instead) I don't know if you can spot any errors or obvious mistakes I have made which would result in the animations listed not working ? As I said before when binarized all the anims work perfectly. The full code is here on pastebin http://fortran-arma.pastebin.com/m9746e7 Or shown in the spoiler below. EDIT: Just check binarizing it again but this time binarized with the contents of the model.cfg in the config.cpp (so no separate model.cfg) and the animations all work perfectly again. I dont get this lol.
  3. Ahh thanks Synide, your right, BinPBO is obviously not understanding the new RVMAT, and yes I am using the new super shader in some of the files. I noticed even with the rvmat in the exclude list it is still binarizing them. Have copied my model.cfg entries into my config.cpp and most appears to be working correctly now. I must have some small errors in the cfg as without binarizing it only 90% of the anims work. Things like the elevators and rudder do not move whilst the airbrake, landing gear etc do work. I don't really understand why everything works when binarized and some anims dont when not binarized but I guess I have an error in my cfg somwhere. Anyway thanks for your help with this, def. seems that BinPBO cannot handle the new material types for now. ---------- Post added at 01:05 AM ---------- Previous post was at 12:24 AM ---------- Ahh which I have just found out is because the new skeleton class for ARMA2 A-10 is differently named. Cannot extract the CFG to find the new skeleton name so I am a bit scuppered right now.
  4. Hi Myke, thanks again mate, been seriously helpful with all these problems I have been having. Actually did try that before posting but it didn't seem to work for some reason. I don't really understand why because as you said it should skip rvmat types. For example I just tried it again, binarized the file, loaded it up in ARMA2 and no gloss/env/spec on the A-10 (this is with *.rvmat; in the exclude list). Quit, opened BinPBO again and packed with no binarize, loaded up again and the gloss/env/spec work but I get the following error the first time I load the A-10 in the editor: Might try restart my PC as I have just noticed BinPBO is coughing out 87MB log files and the PBO is only 27MB. This has only just started happening, usually the log file had a handfull of errors only mostly related to the model itself. Thanks again mate, will give this another go.
  5. Working on a small port of the BIS MLOD A-10 from A1 over to A2. This really began because I wanted to change the way the weapons were displayed on the pylons and without the A2 MLOD's this wasn't possible (issues shown in this post). Also wanted to load any missile/bomb loadout onto the jet and have it display properly on whichever pylons I wanted. Have converted the original MLOD A-10 over and edited the model to have only 2 FFAR pods and now 11 hardpoints (9 + the 2 FFAR). Will also be making it IAWS compatible so the weapon loadout can be changed on-the-fly in-game. Had loads of help from Myke so big thanks to him. Will be releasing this when completed for anybody who wants more flexibility in the A-10. Might also re-skin and make some other minor changes including maybe a new weapon for the center pylon such as a clusterbomb or something else. Is still WIP, proxies need repositioning etc.
  6. Fortran

    A-10 Pylons

    Ahh ok yeah you might be right, not entirely sure. Been thinking about having something a little different to fill that single central pylon and thought perhaps I might have a bash at making a clusterbomb for that. Maybe one of the following CBU-52/58/71/87/89/97. Not sure how complex it would be but after jumping in at the deepend with the engine I feel its something I could perhaps tackle now. Also made some more progress, fixed pretty much everything now (aside from the camera clipping when climbing the ladder). Sounds working, Glass fixed (although I would like a better material) Also would like to tweak the body material of the A-10 itself, this one looks decidedly dull compared to the gloss and shine on the new model. Finally need to fix the Proxies and implement the IAWS system, proxies are now sequenced correctly so it fills the hardpoints as you described in your IAWS thread.
  7. weapons "GAU8" "SidewinderLaucher_AH1Z" "MaverickLauncher" "BombLauncherA10" "FFARLauncher_14" magazines "1350Rnd_30mmAP_A10" "2Rnd_Sidewinder_AH1Z" "2Rnd_Maverick_A10" "4Rnd_GBU12" "14Rnd_FFAR"
  8. Fortran

    PilotView

    Hey Myke, thanks again mate, been a lifesaver with this. First issue is now fixed using the method you described and although the hand isnt quite centred on the stick anymore the view is now spot on. Been playing around with the pos driver and pos driver dir points. pos driver seems to be the distance from the jet that the player can choose to drive it and pos driver dir seems to be the one I wanted, however I can move it closer to the A10 and indeed the camera clips even further into the jet, but moving it away from the fuselage after a certain point doesn't seem to work unfortunately. I can move it a certain distance away and it still clips, but moving it even further than this seems to result in the player being turned 180 degrees to perform the animation which is odd. Will keep messing around with that anyway until I find the spot. Is just slow going moving it then loading ARMA2 checking it, repeat process. Anyway thanks again man, really appreciate all your help with all these issues.
  9. Fortran

    A-10 Pylons

    Had a good read through it, thanks mate! Is a fantastic concept, will most certainly be attempting to include that in this port. Will probably have to go back and edit the proxies now but it will be worth it. Have made some good progress tonight, managed to get the new A10-CAS model edited and running in the original game and have just quickly tested porting it over to ARMA2. All seems good, animations all work, model looks fine, just have some small issues with the glass textures (probably the rvmat needs work for the ARMA2) and also no sound as of yet, but I will have a good look at that tomorrow. Anyway here it is running in ARMA2 with the new single FFAR pods on the 2nd hardpoint in on the midwing. As you suggested will probably stick the Sidewinders on the outer points and fill up the central hardpoints with the Mavericks and possible one GBU12 on the centre most point. Will also need to add 2 more pylons + proxies left & right centre as the original ARMA model just has one pylon dead centre. This should give 11 hardpoint stations total. (9 missile pylons + the 2 FFAR pods), which from having a look around the net is the real-life amount. Am also now considering possibly modelling a couple of external fuel tanks or flare dispensers as well and making a couple of extra variants (or by utilizing the IAWS system you suggested).
  10. Fortran

    A-10 Pylons

    Brilliant, cheers Myke been a huge help. I just took a look at the MissileBox and it seems like its going to work out alot easier to use that, just swapped over the Maverick launcher + ammo from the MissileBox onto the new A10 model and its already fixed part of the issue (the jumping pylons). Will continue working at this and will def. be using it with the A10. Anyway big thanks again for your help. Will report back here as I make some more progress with this.
  11. Fortran

    A-10 Pylons

    Ah great stuff, might personally stick one GBU12 on the centre pylon if it will fit. Also will definitely take a look at your Missilebox, was actually having a look at it the other day, great work! As for the FFAR pod how would I go about removing them ? I just took a quick look in the original config for the ARMA1 A-10 and I see they don't seem to have a model path assigned to them (unlike the Mav's "\ca\a10\agm65"). Am not new to moding in general, have 10 years of experience with various engines but this is my first attempt at working with the ARMA engine and am a little unsure how to go about clearing the FFAR pods from those pylons. Anyway thanks again for you help, very much appreciated.
  12. Fortran

    A-10 Pylons

    Ah ok fantastic, thanks very much for your reply Myke, appreciate it. Do you have any links to any info on proxies I could read up on? As for the Maverick launchers, It doesn't quite work as expected as you pointed out. I have 6 missiles and they can all be fired, however as you noted they are in pairs due to the actual magazine layout for the Mavericks but they do fire off correctly, only other thing is they don't show up in the HUD correctly, I get...(as they fire off) 2/2 1/2 2/1 1/1 2 1 0 Anyway thanks again for the input, might have a crack at porting the original ARMA A10 as you suggested. (if thats legit?) EDIT: just looking at the original A-10 I see that it has 2xFFAR pods on each wing which is going to be a bit of a problem as there is only physically room for 4 mavs. I take it the FFAR pods are actually part of the model and not just additional geometry (like the missiles) ?
  13. Many thanks guys, works a treat. Appreciate your assistance!
  14. Hi guys, Just trying out a very simple CAS script to allow the player to call in an A-10, is all working fine but I need the A-10 to be indestructible to allow it to fullfil is duty to the player until it runs out of fuel (or time) and is removed from the gameworld. So far have this: _plane = [position spawnaten, 0, "A10", side player] call BIS_fnc_spawnVehicle _a10 = creategroup WEST; _plane join grpNull; _plane join group player; this addEventHandler ["HandleDamage", {false}]; However it is still getting shot down and destroyed when testing against some highly skilled AA guns. Have also tried this: _plane = [position spawnaten, 0, "A10", side player] call BIS_fnc_spawnVehicle _a10 = creategroup WEST; _plane join grpNull; _plane join group player; _plane addEventHandler ["HandleDamage", {false}]; But no joy, where am I going wrong with this? Any help would be greatly appreciated. Also is it possible to set the skill level of the A-10 in this script?
  15. Fortran

    3Dsmax ArmA2 modding toolset

    Fantastic work, this is exactly what the community is going to come to rely on for 3DS Max modelling/export toolset. Brilliant!
  16. Take a look here: http://forums.bistudio.com/showthread.php?t=78365, as suggested by slimSpencer it is basically down to the AI + your CPU, there is no "blocking" for the AI and no matter where on the map they are located it will still utilize your CPU to calculate them. The last image in that thread demonstrates this where I placed 150 AI soldiers spread out miles across the map, the result was the FPS became choked at 30fps. Makes no difference if they are close to you or you can see them the engine will still utilize your CPU to conduct their calculations resulting in a choke on the fps. This isn't really a bug as such as the ARMA gameworld is perpetual and the AI that populate it will act and patrol as instructed even if that is miles and miles away from your position. The only solution would be to utilize some kind of dynamic loading/unloading of the AI characters based on their relative proximity to the player.
  17. Hi guys, Just wanted to ask if anybody else is experiencing this, seen one or two people comment on it but no definitive answer. I can't get more than 30fps on the campaign mode of the game, however in the editor and the scenario missions the FPS seems to be un-capped. The reason I believe the FPS is capped in campaign mode is that even if I look at the ground or the sky the FPS will not go above 30. I would have taken a movie of this but I can't capture the FPS speed in fraps in a movie, only screenshots. Here are 3 side by side comparisons from the campaign and the same location in the editor. Obviously with no AI or other items on screen the FPS is no doubt improved in the editor shots but the difference between capped and uncapped is obvious and definitley not just to do with AI or props being on screen. Each shots is 1: straight ahead, 2: looking at the ground, 3: looking up in the air
  18. Fortran

    30 Fps cap in Campaign ?

    Hmm yes you seem to be correct, however I had to add 150 units in my immediate area to emulate the same effect, but yes it does seem to be some kind of CPU limit. Seems a shame a Q6600 @ 2.4 can't prevent this. I am guessing, due to the fact that in the campaign area I took the original shots from that the AI is loading the CPU wherever it appears in the entire gameworld as in the initial screenshots, aside from the camp props and the squad AI + a few extras there is no way near the same amount of pressure from AI as I have just given the game in the editor. I suppose with it being a perpetual game-world there is no way they could have really dynamically loaded and unloaded AI units within a given radius of the player. EDIT: Just to test this further I decided to spread the same amount of AI units (150) out far around the gameworld instead of all in my direct area and yes, its exactly the same kind of FPS result. I guess this is just unavoidable due to the reason I mentioned above. Anyway thanks SlimSpencer, seems to be the answer, thanks for clearing it up for me.
×