Hatchet_AS

Firstly, you can work with the PhysX stuff just fine with the current O2. It does require entering some LOD ID's correctly, and you can not bin with the old tools. If you are planning on running things under PhysX, I highly recommend playing around with things. Big differences in how things behave between the simulation classes. Anyway, regarding the non-moving boat in the OP, assuming you have the correct LODs in place (PhysX GEO = 2e+013, PhysX Buoyancy = 4e+013), do you have mass assigned in the GEO LOD? And how much? Another kind of important part of this is having the effect points placed and configured properly. An image for illustration purposes. Relative config entries: (excuse the less than logical naming) memoryPointsLeftWaterEffect = "engineeffectl"; memoryPointsRightWaterEffect = "engineeffectr"; Hope it helps.

Gentlemen, I need some assistance in getting some of these working fully. Right now everything works as expected, except when utilizing teamSwitch which is 'very randomly' causing CTDs. The only way I have been to eliminate the CTDs (95% sure, see 'very random'), is by removing the tex/mats. As illustrated in this image, every time I add a tex/mat to any of the models in O2, this error presents itself for every model (utilizing makePBO -U -G), seemingly indicating an external reference being broken. My hope is that perhaps I've just stared at it too much the last couple days, or perhaps I'm just forgetting/missing something simple. I believe the geometry to be good, although I could reduce a little detail.. (bah!) it produces no errors. Only LODS in play are: res0, viewPilot, shadowVol (which is less than 1k, not that it matters I don't think). Here is copy of the current .rvmat, switched it around last night in hopes of something mystical. Believe it's functional enough. And this is the current config setup which utilizes ASDG_JointRails, config/assets separated for internal purposes. Much is of it commented out while I'm trying to sort the current issue. ASDG_Attachments_C (Config): ASDG_Attachments (Assets): Any thoughts, help with obvious oversight or the like is very much appreciated. As the current issue is the only thing preventing these and other things from arriving on the scene. *edit* Someone pointed out the '*.rvmats' listing in binpbo. This has been corrected, but does not change the scenario. What I have noticed is that the CTD is almost instant when assigning tex/mats to the second model (the secured version in testing locally). With only tex/mats applied to the deployed model, I still receive the makePBO error for the deployed models .rvmat, but thus far been able to teamSwitch 20-30 times without issue. Although, that is not a first, it has done this then failed during another testing session. What am I missing here guys?

Could of sworn I was going crazy for 3-4 days there. Would still like to understand why loading one model that has a GEO LOD, prevents those that do not from crashing the game. Again the only link I can think of would be the .rvmat ... although I don't understand how that would interface with something like the GEO LOD. Absolutely reproducible though. Ah well, sanity found momentarily. :)

Roger that, many thanks for the update. Really looking forward to the sharing bit! Will get to trying out compatibleItems things right now.

Well, for starters ... none of the imagery is accessible in your post. If you can fix that, it will certainly make trying to assist you easier. ;)

You can certainly do it using the method shown by Yonose. The issue as noted already, is that these objects are not visible to the editor. To which there might be some future mods (that might not require, 'requiring' the mod). There might actually be one already, I'd check http://www.armaholic.com for A3 Editor Updates. If I find the time (not likely soon) I might finish mine for A3. Until then, you can search for the relative 'classnames' for the objects (whatever it might be, chances are if you can see it game, you can get into a mission.), in the BIS .pbos and the config.cpp files contained within. There are many ways to do this, but is a separate topic all together, and has been covered in many places. Basic process though, copy out .pbo (eg.. rocks_f.pbo), and unpack it utilizing something like extractPBO which can be found here with all kinds of other goodies. Find relevant classname, utilize as shown above by Yonose.

Bad news indeed! But life, is what it is. Best wishes in finishing up the education! Oh wait, that never ends. But still, good luck and many thanks for all that you have done. Still used daily. We might be interested in taking a look at things, will have to get with Robalo and see if it's something we can fit into our doings. Was going to release an optional/updated TMR_autorest.pbo here shortly that works with some bipods. Came looking to see what's up, but here we are. Anyway, will catch up with you elsewhere.

Just thought I'd add some info based on my experiences with lots of proxies/walkable surfaces and things related to player/ai movement being tested currently. Firstly, things are for sure better in general with these things in A3 vs. A2, although getting everything right in the 'building' models is an art itself. Many things need to be done properly is a more accurate way of saying that. When it comes to proxies (needed for objects larger than 50m (safe number)), while players will generally do pretty well with things, the AI can be interesting. Most notably when pathing between proxies. This can be hit or miss currently, again though much better than before. Sometimes they just don't sort it out. Limiting the number of linked (proxies) surfaces/pathways, and having regular entrance/exit points out of the pathing nets seems to help. Not sure that the AI will walk across non proxied objects. That was historically always fail for me. Granted players are more capable in this regard. Although they don't cross gaps in roadway lods well at all. ;) When I think about adding the additional challenge of objects over terrain and the relative alignment issues ... my initial thought is to run away. But now that I think about it, if you're planning to proxy large sections together (hundreds of meters at a time at least (i know 300m can work)), the terrain below the proxied parts is fairly irrelevant. The position of the main model, and the piece of terrain it sits on it what's important. So in theory, you should really only have to worry about 'those' pieces of terrain that the main objects sit on. Everything in between could be whatever makes one happy. Never tried hooking up anything bigger than the VLCC I'm working on. Curious if anything breaks at some particular point in hooking things together. Best of luck with things, seems like a great project! :)

For what it's worth the .tga references are not typical of my flow on these. I actually manually converted these (trivial process). This was an attempt to sort things, .paa would be normal for me. But I'm pretty sure using .tga is legit as mentioned. @DaMonkey There is nothing. There are dump files and whatnot, nothing useful though outside of that (maybe those are useful?). *edit* I actually removed those. Was under the impression they weren't need. But I can't recall why I have that impression. Will check that now. ---------- Post added at 16:56 ---------- Previous post was at 15:47 ---------- Ok ... after some testing (and probably a little more needed to be confident), it would appear having the GEO LOD is indeed important. Why this is the case, I'm not sure. Here are the results of my testing with the two models defined above, the deployed model being the only one where I added the GEO LOD back in. With the Deployed model (w/geo), I can load mission take attachment, place on weapon and teamSwitch seemingly forever (i can switch dozens of times rapidly). Add it to more units and continue switching without fault. When loading the Secured model (wo/geo) first*, it crashes instantly, seemingly without fail, every time. This being a half dozen or more restarts. What is interesting to me, and what I'd like to understand is this: * = If I load the Deployed model first in-game, and then add the Secured model to other units ... there are no issues seemingly. Again switching around dozens of times. All in all, it seems the geometry lod is needed, but what is the relation to what I assume has to be the .rvmat, as it's the only common thing between the two. :confused: ---------- Post added at 17:12 ---------- Previous post was at 16:56 ---------- Think you got it right Monkey. :cool: Added the GEO LOD back to the secured model, open it first in-game, no crashing. After a half dozen restarts, I'm leaning very much towards this being resolved. Releasing it's probably a sure way to find out I suppose. :rolleyes:

For whatever it's worth, having the ability to quickly see what attachments are compatible (presumably under JointRails), I think will be beneficial going forward. Just based on what I know I'm intending to release along those lines, and everything else currently going that direction. Seems wise/useful. Very much like the current additions in the image above. Very cool. One thing I was curious about the other day when playing, would it be possible to make 'double-clicking' on a loadout in the 'load preset' dialog, just load the preset and take you back to the default dialog page? Hope that makes sense. Trivial in the scheme of things though.

All pro. Really looking forward to this guys!

Sorry to hear you're busted up Tonic, although very happy to hear you're still here and doing. Looking forward to the update. :D

All Pro. Things like this are needed, many thanks to all you who got it sorted, and are getting it done. Job well done indeed.

If you want just house cover (building entry), then the best way to do that is by script at the mission level. I believe there are a couple on Armaholic currently. UPS(MON) I think currently works, and is great for setting up missions with AI to do all kinds of things. If that's not your thing though, and you're looking specifically for a mod to do these things for you, here is a link to the A2 version of ASR_AI. A3 version coming in the not so distant future, with some new features you'll find fitting. A fair amount of people will tell you it's a pretty decent setup. So hang tight I suppose, or perhaps someone knows about something I haven't seen and will chime in. :)

Well, without getting into all the details ... to accomplish what you say you're after in a more firefight'ish type way would be to increase the aimingShake. The one thing I'll mention is that the array is very intertwined in how they can each affect one another. The default AI skill settings, can have a profound effect on things in general. The higher the base skill levels, the more capable the AI become (eg.. movement/tactics). This is also more resource intensive. But anyway, play with the aimingShake and speed some. Should get you where you want to be. This coming from many years of testing/running the ASR_AI package. Which is coming to A3 soon. Where there are easy methods for you to change these things within a fairly complex system (also has some notes in there). Plus is does a bunch more stuff that is relative and for sure changes how the game is played. Can also be a great resource to learn from. ;)

Guess it's not too early to mention ASR_AI will be returning shortly to the mainstream. And it covers many aspects of how the AI perform. But there are also other mods out there that address some of these things. Armaholic is your friend. All in all though, the reality is the AI in ArmA is not particularly crap. Actually quite capable when compared to many other games. ;)

Just a quick teaser of one of the many items coming to the community under the ASDG Attachments project (thread coming soon). ASDG_Atlis_Bipod We hope we can sort setting up new attachment slots via stealing one of the 3 current slots and creating definitions and proxies for additional slots. This will work for systems like this early on WIP image. The goal being to add lasers/lights or whatever to the new rail systems models. Of course a better system in general would be excellent. But we'll keep working with what we have and adapt as those changes come. :)

Finally got the rig back in working order. In a rush to get some attachment mods out, but almost done with that. Then I can finish where I left off last week the ships here, and put a proper example together. I wasn't having issues with aircraft a couple days ago, hopefully that's not really borked again.

I know I looked at the first model of the LCS 2, think I downloaded a new version today. Will be checking it out again for sure. Although (without being obtuse), my initial thought was something a little more directed would be worthwhile in addressing things properly. To the best of my knowledge from testing before deciding to tackle the VLCC (late A2 days), was that there is indeed a requirement (issue perhaps) with the GEO lod, and I would fully agree that 50m is the safe working limit. Anything beyond has/can cause issues. Although you can do much better in the vertical axis if I recall correctly. Not sure what that limit was/is. These limits really are not an issue when things are modeled and proxied correctly with the static classes though. Which leads to other thoughts. I'm still very curious how exactly the man class interacts with the physx system and other vehicle classes in general. If at all regarding collision/walking on things. In my brief testing before my pc was effectively submerged, I was leaning towards the interaction being non-existent. As I was finding myself submerged in all but one particular case (which involved sorcery). In previous testing in A2, I was left wondering if perhaps there is some disconnect between the way models are setup and what the engine actually utilizes per class (e.g. does the roadway lod even actually work with other non static classes?). As this is what is required for walking about on things under the static classes (unless somethings changed?). My understanding is that the other classes utilize the GEO lod for collision. And thus in my mind, the first big difference between things. Obviously materials play a role to some degree. Although I've not had time to fiddle with them much. It seemed somewhat limited in the brief time I spent collecting config settings, and sorting their functions. Again though, if the interaction with between the classes, models and/or systems is disconnected somehow, this would be a somewhat mute point (and explain things) regarding the man class currently. The fact that there is evidence that things are working between other vehicle classes (and improving); helps maintain the faith here.

Ah roger, I was curious who did that. For whatever reason I did not equate JumpDog to JDog. I forget about the other thread also, so thanks for that. Consolidation of information is something many topics on these forums could benefit from, or rather people could benefit from. I'll return with my wares tomorrow hopefully.

Joint Ops was ahead of its time in so many ways. Which is not to say, other games weren't doing/capable of the same at the time. Few if any though that I recall. I'm very interested in this topic and hopefully we can get some things working, or answered definitively if nothing else. I'm awaiting next day parts from newegg unfortunately, but hopefully be back together by this evening. Then I can get a couple working examples together. Best I can contribute on the subject matter. If someone else wants to bring things to the table, that is beneficial for all. At this point in the conversation I'd say the direction of travel should be towards what we do know works (with an example), and what we know does not work (with an example). That being said, if anyone with actual knowledge, could share information regarding the reality of how things are configured in the game currently (e.g. whats different between the classes that we can see in the configs. (DEV branch)). Or anyone who has extensive modeling knowledge that can define rather specifically the limitations we know to exist, it would be helpful, again for all. Hopefully we can put everything together and have something useful that makes looking at this easier for BIS. If nothing else, so that those of us with true interest in the subject at hand, can sort things better for ourselves. Honestly the rest of the chatter about who's done what, opinions and the like ... isn't particularly useful in achieving the fairly specific goal of this thread. :D

Really prefer BIS remove all bipods from weapons. Any attachments for that matter. I'd be happy to model different bipods for the MG's/Sniper rifles or whatever. But really would like to get the nonfunctional stuff out of the way. Or give us some clever way of hiding proxies or something. And I'll not get into the whole attachment system in general, just yet.

This is again good news. Just don't come back tomorrow with your crashes at every 12hrs. :D That is interesting to a degree also. I know a couple guys who park cores intentionally with success. Have not heard about it the other way around until now. Not that I frequent these troubleshooting forums all that much. Thanks for the followup and sharing of information.

There is this one also. Believe it supports Patricks FreeTrack from within. A few others also. Is fairly modular in design so might have other useful things.