Synide

I suppose so... dunno what the channel name is though...

Ofcourse... He may be a of the underarmmous-bowlerous species but he's not slow off the mark... ArmA2P - :).

Have a look in animals2.pbo... there's already 'scared' fsm's (like reactDanger.fsm, reactFire.fsm) and functionality enabled through the config. See the execFSM and related scripting commands for altering the various fsm's variables as needed. You'll note in the Sheep's config it inherits from 'CAAnimalBase' which already has a 'firedNear' eventHandler in-place for instance that runs 'ca\animals2\data\scripts\reactfire.fsm'. FSM's are a whole little sub-culture in RV... quite cool & interesting really.

It's usually a good idea to uninstall, reinstall... although it's not an absolute requirement the main reason is that during the install of the tools when it comes to asking which drive letter you'd like your build environment mapped too if you already have the p:\ drive mapped it'll not let you select this letter again. There are ways around that but it's just easier to uninstall then reinstall. Either way you'll loose user specific settings for things like O2/V3/BinPBO etc.

Are you sureabout that? Have you installed the 2.5.1 Tools?

Hi, The link that Aplion posted is pretty much correct. Also, you'll want 'class=house' as a property in your Geo LoD. Best to make the poly's etc. about 10cm above the roadway surface. You can have quad's in Path LoD's but it's best to stick with triangles for the most part anyway. Yes it can do. The leader of a group knows about all 'pos#' position points so having too many can overload the leader's options. How many do you have?

Hey mate, Yeah... just change your 'tex1' in that .rvmat to 'tex'. tex=UVSet0 in a p3dm, tex1=UVSet1 etc., etc.

This will be because the .rvmat you have it pointing at is one that requires 2 UV sets. At a guess you're perhaps using an .rvmat that specifies multi or super shader. If you post your .rvmat we'll go from there eh? Cheers, Sy.

Not now... it doesn't work. I know it worked in A1 tools but only recently tried to use it with A2 Tools and found it broken as well. Yeah' date=' as the others have said...'File>Import Templates'. Yes you can... through v3script. A common senario is you may want to import templates from several sources and modify all those templates properties (scale, angle, orientation etc.) in a uniform manner. One method is to output all the templates from their respective .pew's and collate them into one file, use MS Excel (or a text editor) to adjust all the properties to your liking and import these into your current project with v3script. While technically doable when your talking 'templates' it's easier to just use 'File>Import Templates' or v3script as usually the amount of templates involved is relatively small in comparison to say the number of 'Object Instances' of 'templates' for instance. Injecting 'Object Instances' into a .pew where you already have the templates defined is often a very good idea as it's 100's of times faster than using v3script to create the instances based on a source text file. This is especially true when you start getting over a million instances.

Obviously English isn't his first language. It's quite plain isn't it that he meant he tried to use the p3dm & the odol version of the example model and both his attempts crashed. @ghost123... Are these the only errors you get in your build log file? If you goto www.pastbin.com (or similar website) and add your entire log file there we'll be able to get a better idea what going wrong with your build attempt. Also, pasting your model.cfg & config.cpp would be helpful. @[APS]Gnat... Dunno what english language you learn't but example & sample are synonyms. Perhaps if he'd used the term 'non-binarized' in his first post it might have been little easier.

Hi, Try something like... in your CfgModels definition. class Animations { class missile_damage_hide { type="hide"; source="damage"; selection="missile_hide"; }; class missile_fired_hide { type="hide"; source="direct"; selection="missile_hide"; }; }; You should then be able to initiatiate the anim 'missile_fired_hide' from any script (eg. your 'fired.sqf') with something like... this animate ["missile_fired_hide",1]; I'd suggest making yourself a generic setHideFired.sqf though where you pass the 'anim name' & 'phase' to the script and have a 'call compile' construct... but that's up to you. You don't need to setup a specific AnimationSources subclass in your config for this particular 'missile_fired_hide' anim. Cheers, Sy. PS. In the above code snippets I've not specified things like 'hideValue', 'min/maxValue' or 'min/maxPhase' etc. because in this instance you shouldn't need too specify them. The default values based on the AnimType & SourceType should be sufficient.

While watching your original thread unfold the other week I felt you should be doing this for buldozer instead too. And, like you I wasn't sure that scripting etc. would be supported well while running in buldozer mode. So, a few weeks back I did a couple of limited tests. Well, I sorta only did 1 & half tests. In Buldozer when you hit F1 you get the plain unadourned game 'Options' menu. I modified the Rsc in the P:\bin folder to have an additional button that launched Gaia's debug console. This worked fine. The debug console was entirely functional. I could run scripting commands like 'createVehicle' for instance. So...Yes, you can run .sqf & do a customized user interface for buldozer. But, of course you won't be able to 'play' a character model for instance. And, scripting commands that are simulation centric would be problematic. Oh, and I'm not sure about 'mouse' related scripting in the context of buldozer-mode. You'll have to test that yourself. If you're inclined to go down this route that is. I'm not much up on the UI side of modding. But, if you can get your scripts to 'fire' keypresses on the buldozer controls for moving the terrain up and down then those alterations will instantly feed back into visitor3. Of course the roads you 'paint' (like when your in mission-mode in your current effort) will only exist for the duration of running buldozer and will not feed back into visitor3. However, you should be able to run Jaynus' ArmA2Lib tool with buldozer and save/load persistent data to disk while you're in buldozer. Then shut buldozer and flip back to V3 and import that text file - instant V3 road and/or placed building/tree etc.... :) Food for thought eh?

Copy the camera MemLoD point from 'BISoldier.p3d' or 'BISkeleton.p3d' from the 'BIModels.zip' example A1 models into your MemLoD of your head model. Rebuild and give it a go in game. Yes, that's correct. PS. Post your build.log after building this too if ya can. helps deduce problems. PS2. Oh, And again (as per previous thread) what is the character model you are using this head with? Reason I ask is... does it have a 'replaceable head' proxy for bysta?

@ZoneKiller... During mission runtime you cannot #include upwards out of the missions folder. You can #include files within the missions' folder or files that are in subfolders of the missions' folder. You can #include files that are stored in .pbo's that have been (or will be) loaded by the game runtime environment. During the development of your mission while you are still creating it and have yet to .pbo it up you can do what PvPscene said and create symbolic links or junctions into your missions' folder of other directories on your machine. I'd not recommend this method as it's very easy for you to stuff this up or forget to remove these junctions/links prior to releasing your mission. The preferred method is to place your commonly used resources, whether they be scripts, textures, whatever... in .pbo's. You can then reference these in any mission you create. See Back to the $PBOPREFIX$ root(s) for a related discussion on this. Still? I thought you got the gist of the runtime use of #include the other day.

That's an arbitrary limit I think. @Delta Hawk... BinPBO pushes a default value of 56 (from memory) through to the binarize.exe commandline parameter '-targetBonesInterval'. I've regularly just called binarize.exe directly bypassing BinPBO to build various things but I've never bothered testing upping the '-targetBonesInterval' value higher than the default. (Which is 55 if you're calling binarize.exe from the commandline. And, 56 if called through BinPBO) I'd guess you possibly can have those sorts of figures you're asking about... but you'll have to use a dos batch file to call binarize.exe rather than using BinPBO. I haven't pushed it towards the sorts of values you're talking. You'll have to give it a whirl yourself. Let us know how you get on. To call binarize.exe directly you'll want to use a batch file similar to the following. m:\rv\a2tools\binmake\binarize\binarize.exe -binpath="m:\rv\a2tools\binmake\binarize" -textures="m:\rv_temp" -targetBonesInterval=56 -addon="p:\ca\wheeled_e" -addon="p:\ca\wheeled2" "p:\sy\vehicles\trucks" "m:\rv_temp\sy\vehicles\trucks" mtvr.p3d pause m:\rv\a2tools\binmake\binarize\binarize.exe This is the path to binarize.exe in your build environment. -binpath="m:\rv\a2tools\binmake\binarize" This is the path where binarize goes looking for a folder called '\bin' and consequently the main reference config, stringtable.xml etc. On my machine I have the latest AllInOne.cpp etc. sitting in the '\bin' folder of binarize.exe but most people have there's sitting in the root folder of their P:\ drive. -textures="m:\rv_temp" This is the path to your build environments temp scratch area where all textures are copied. -targetBonesInterval=56 This is the number of allowed in one section when processing a .p3d. -addon="p:\ca\wheeled_e" -addon="p:\ca\wheeled2" You can specify multiple folders in your Build Environment where binarize.exe goes looking for reference information when processing your config/models etc. "p:\sy\vehicles\trucks" The <source> folder you are binarizing. "m:\rv_temp\sy\vehicles\trucks" The <destination> folder for outputting your binarized content. mtvr.p3d One or more models (.p3d) using wildcards a or .wrp you are processing. Cheers, Sy. PS. There are other binarize.exe commandline parameters you can specify as well. To see the complete list open a dos command prompt into the folder where binarize.exe lives and just run it without any params. It'll give you a list of the parameters.

Ok, perhaps you could send (or post) your build.log for your island. Binarize.exe needs to collate lots of info regarding island placed models. So, perhaps it's not finding what it needs when your doing your build.

Heads have skeletons. I'd like to see these heads you made that didn't have skeleton's and worked fine. You should be building your custom bysta.p3d with a model.cfg included. Build your custom head model with a model.cfg that has the same skeleton as the body your trying to attach it too. What's the body.p3d you are trying to attach the head too?

This road texture... how'd you map it into the bridge model? Did you select the poly's in the bridge model and then remove the bridge texture and replace it with the BIS road texture? At the same time did you point them at an .rvmat? Or, did you duplicate (or create) new poly's into the bridge model at the same location as (or very close too) the current bridge poly's and map these to the BIS road texture/rvmat? If perhaps you have done the 2nd method that's not a good method. For 2 reasons... you'll quite often get visual 'popping' and the engine often gets confused about the what 'character' it should use from CfgSurfaces/CfgSurfaceCharacters etc. Also, a number of the BIS road .rvmat's use transforms in the stages to stretch one or more of the stage textures to the appropriate sizes the .rvmat was created to work with in the first place. If perhaps you are using an unaltered BIS road .rvmat but pointing it at textures that it was not originally pointing at and they are of a different dimension you may experience undesired stretching effects. Stretching only comes from 2 places... diproportionate UV's in the main model or the UV transform in an .rvmat.

Hi IceBreaker, Had a quick look at the model. Been a long time since I've seen that OFP model. Memory is a bit gray... was it always that size? Did you add some cubic meters of poly's to it? Perhaps it was that size originally... dunno. Of the stuff you sent... In your config you have... ladders[]={{"Start1","End1"}}; In the main models MemLoD you have... ladder_start ladder_end ... as the point names. Altering these to match did not get it to work. But nevertheless they should match. Was this model always that big? S'Been a long time since I've seen that OFP Airport. And, did it always have that many proxy's? Or, did you add a whole lot more? Personally, I've always made it a rule to not proxy in user-interation model portions. As a quick test... I re-integrated your ladder proxy into your main model, correctly sync'd up the ladder start/end point names with the config. Re-built... result = Ladder didn't work. Then I sliced your main model in two deleting the portion that didn't include the ladder. The intention being to 1. reduce the linear dimensions to under 50m and 2. to reduce the number of proxied objects present in the main model. Re-built... result = Ladder worked. So, I'd suggest that you split the 'ibr_terminal.p3d' into 2 portions. And, don't proxy in your ladders. Cheers, Sy. PS. Oh, btw I'd go through all those proxy models and fix up all the point/face properties & user values. They should all be 'Normal' and Uservalue 0 in all LoD's.

Oh dear... hmmm... would you like to send me your model, config, model.cfg, last build.log. synide at rocketmail dot com

Hmmm, while inheritance is often an issue with people's config's in your particular case it may not be. It depends whether or not you are defining ladders[] = ....; in your buildings' config class or not. If you are defining it in your class then any previous inheritance value for ladders[] will be irrelevant to the engine irrespective of whether you actually had your buildings' inheritance setup correctly or not. On the other hand if you are not defining ladders[] in your buildings' class then it's inherited value will be of importance. For the purposes of your problem we only need to be interested in where you have ladders[] defined (or not defined as the case may be). Seeing your config.cpp would help. Although you've checked, perhaps you have a name-mismatch 'tween the ladder names start/end points in the config & the MemLoD... Have you triple checked it? Sometimes when working on stuff one often is staring directly at some blatant error and missing it... I'd suggest firing the lot of to a mate for a look... they might see what you're missing. Also, where in relation to the ladder you have modelled in the ResLoD's is your start/end points in your MemLoD - Just out of curioisity. Often I've seen peoples buildings with ladders and they've just slapped a start/end point 'somewhere near the ladder' and when you use it in-game the characters climbing anim means his hands are hitting every gap between the ladder rungs or his forearms are sticking into the wall etc. Looks at bit yuck. Oh, and also... if your buildings' class inherits from class House; you only need to forward reference this class... not class HouseBase as well. In inheriting you only need to forward reference the class your inheriting from. Eg. If somewhere else in the system is defined... class HappyFeet { NoOfWidgets = "30"; class InstantNoodles { HasLargeShoes = true; }; }; ... and in your config you wanted your class to inherit from 'HappyFeet' and override the NoOfWidgets value only then you'd have... class HappyFeet; class MyFeet : HappyFeet { NoOfWidgets = "17"; }; If however, you wanted to override 'HasLargeShoes' in HappyFeet's subclass 'InstantNoodles' you have to forward reference it as well... class HappyFeet { class InstantNoodles; }; class MyFeet : HappyFeet { NoOfWidgets = "17"; class InstantNoodles : InstantNoodles { HasLargeShoes = false; }; };

Hmmm, well don't remove class=house from the GeoLoD 'cause it'll definetly never work if it's not there. Let's tick this off eh? 1. You have a Land_####### class in CfgVehicles with the ladders[]={ {"start1","end1"} }; 2. You have points in your MemLoD in your model called 'start1' and 'end1'. 3. Your GeoLoD has the LoDProp 'class=house'. 4. Your GeoLoD has had 'Structure>Topology>Find Components' run on it. 5. Your GeoLoD has had 'Structure>Convexity>Find Non-Convexity' run on it. 6. Your GeoLoD has Mass. Btw, Your MemLoD start/end point names can be anything you like just as long as they match with what you have in the config.cpp. At the absolute bare minimum you need a MemLoD, GeoLoD & Roadway. The Roadway LoD is so when the character gets off the ladder at the top they have something to walk on. Techinically you don't need Res LoD's for the ladder to work but it'll look strange if the character is climbing an invisible ladder. You don't need poly's in the GeoLoD for the actual ladder just the main structure of the building. Oh, and what's your building inheriting from in your config? That's of course if you have it inheriting from anything...

Oh, if you're a bit particular about things I can try and dredge up some old measurements for ladder rungs, ladder length's & start/end point placements so the character ladder climbing anim sorta matches the ladder. They weren't perfect but a bit better than most I've seen.

Do you have 'class=house' LoD property in your GeoLoD? Btw, the cause of 'backwards operating' ladders is due to a dodgy GeoLoD if you happen to be suffering from that at all when you actually do get your ladder working. The GeoLoD must be 'convex', be 'componentized', 'closed' and have that LoDProp + your other stuff you've already stated you've sorted so you should be good-to-go.

Ah, yeah... we're talking an OFP building eh... true... sorry, you meant 'kind of hard for an OFP building to have bones defined'. Misunderstood your post.