Editing Tutorial: Beginners

ArmA editing, missions, modeling, textures, terrains

Moderators: Snake Man, Lone Wolf

Post Reply
Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Editing Tutorial: Beginners

Post by Snake Man » 2008-01-05, 05:02:52 PM

I have added Editing Tutorial: Beginners into our wiki. Feel free to post suggestions, questions or other feedback.
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

User avatar
Gnat
1st Lt
Posts: 120
Joined: 2004-01-07, 08:46:56 AM

Post by Gnat » 2008-01-05, 11:52:01 PM

Nice work SM.
5 second review.
- Need to add BinPBO to the tool list

sincov
Newbie
Posts: 5
Joined: 2007-06-16, 08:52:45 PM

Copy object

Post by sincov » 2008-01-31, 10:26:32 AM

I have a problem i dont remember on basic editor of Arma the command for copy a object or veichle. I remember shift + movement of mouse for rotation but copy not.
This commands are not on manual but i think old commands of FP and to be very useful for costruction of fortification lines.

Roberto Sincovich
Trieste Italy

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-02-01, 12:41:35 AM

Its the standard CTRL-C to copy and CTRL-V to paste.
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-04-26, 07:14:00 PM

I have such an uber-n00b question it is embarrassing.

Is there a certain directory structure I need to have to be able to skin a model?

I have a 3d rectangle. Eventually, it will be a hedgerow. It is in a folder \hedge\. I have a texture, in .pac format, which is in a subfolder, \data\. So, the path looks like (I used Z instead of P) Z:\models\hedge\data.

I can open the .p3d in O2PE. I can open the skin in TexView. But, when I try to load the skin in O2PE, it doesn't do anything, and when I start Buldozer, it says it can't find the texture.

I'm sure it is something extraordinarily silly I am doing, but I can't figure it out.

Thanks!
Sic Semper tyrannosauro.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-04-26, 09:21:45 PM

T_Rex wrote:Is there a certain directory structure I need to have to be able to skin a model?
No, not really.
when I try to load the skin in O2PE, it doesn't do anything, and when I start Buldozer, it says it can't find the texture.
Well can you walk us through the steps how did you try to apply the texture?
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-04-26, 11:49:21 PM

Sorry SM. I went out and mowed the yard and it came to me. :)

I was thinking that the paths were relative from the directory that had the model. The paths are relative from wherever the texture directory is set in the options. (Either that or the z: drive itself, not really sure.)

I went into the tools->mass renaming thing and put the full path to the textures from z: and it worked. :)

Instead of models\hedge\data I was using \data.

:thumbs:

Must be a language issue. All the instructions were in English, and I'm American. ;)
Sic Semper tyrannosauro.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-05-28, 01:18:35 PM

T_Rex wrote:I have a 3d rectangle. Eventually, it will be a hedgerow. It is in a folder \hedge\. I have a texture, in .pac format, which is in a subfolder, \data\. So, the path looks like (I used Z instead of P) Z:\models\hedge\data.
I have no tried to PBO pack the model. My config.cpp has the line:
model="\models\hedge\hedge01a";

The model name is "hedge01a.p3d".

I go into ArmA, in the editor, and it "sees" the config entry and I can place it, but then I get a "cannot open object models\hedge\hedge01a.p3d" error.

There's a thread at BI where a guy had the same issue, then he posts "Solved it!" but didn't say what the problem was! :D Also, it appears that the paths are relative to the "ca" folder?

TIA.

PS In typing this out, I will need to double check that the model name in the cpp is really identical to the real modelname, but without looking, I'm 99% sure it is the same. :)
Sic Semper tyrannosauro.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-05-28, 03:46:26 PM

Well that config assumes your pbo name is "models.pbo" and then there is subdirectory in the pbo called "hedge". I would take a wild quess that your addons pbo name is not "models.pbo" is it?

If its lets say rex.pbo then configure the model like this:

Code: Select all

model = "\rex\hedge\hedge01a.p3d";
And then it should find it.

Also there is the $PBOPREFIX$ file, but honestly I never used its benefits and cant recall how it actually worked now... its like some root path for the pbo, if your pbo name is "rex.pbo" then I believe $PBOPREFIX$ should just say "rex". But anyways, it should not matter if you configure the model like I just exampled above.
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-05-28, 04:07:22 PM

Wow - I think I see where I am totally confused.

I want a hedge.pbo (for now - will likely be a bunch of structures).

So, I have the config in the models\hedge\ subdirectory - same place with the p3d.

Is that wrong? :)
Sic Semper tyrannosauro.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-05-28, 04:13:59 PM

Umm, no?

It doesnt matter if its in the f:\porn\warez\hack\mutilation\hedge\ dir if you just pbo pack the hedge\ dir.

My VTE files are in d:\armatools\armawork\ which are VTE_config, VTE_air and so on, I only pbo pack the VTE_config... and VTE_air etc, NOT the root dirs.

So if your p3d and cpp is in <blabla>\hedge\ directory, you just pack the hedge dir then. The whole point is what is the name of your addon pbo file, thats what decides where the cpp should be and p3d can be then in some subdirs (or even different pbos completely but thats for another topic).
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-05-28, 04:39:12 PM

T_Rex wrote:
T_Rex wrote:I have a 3d rectangle. Eventually, it will be a hedgerow. It is in a folder \hedge\. I have a texture, in .pac format, which is in a subfolder, \data\. So, the path looks like (I used Z instead of P) Z:\models\hedge\data.
I have no tried to PBO pack the model. My config.cpp has the line:
model="\models\hedge\hedge01a";

The model name is "hedge01a.p3d".

I go into ArmA, in the editor, and it "sees" the config entry and I can place it, but then I get a "cannot open object models\hedge\hedge01a.p3d" error.

There's a thread at BI where a guy had the same issue, then he posts "Solved it!" but didn't say what the problem was! :D Also, it appears that the paths are relative to the "ca" folder?

TIA.

PS In typing this out, I will need to double check that the model name in the cpp is really identical to the real modelname, but without looking, I'm 99% sure it is the same. :)
it's a little hard to deduce what maybe wrong with your config... could you post it...

also, a little background...

there is a game 'namespace' it has a namespace prefix of 'bin'.
by default the engine will look for a config.bin/cpp in the 'bin' namespace upon launch.

the above is the 'basic' game engine. but at this stage it is essentially 'nude'. it has no content so it goes looking for content in a folder called 'addons'.

all of the standard BIS content that lives in the 'addons' folder and is installed in a vanilla version of ArmA is what BIS call a 'mod'.
it's a 'mod' made by the same guys who make the engine... BIS.

the 'namespace' for the BIS mod is 'ca'... there is speculation that the 'ca' namespace prefix stands for 'combined arms'... but who knows...

so, along comes this guy called Snake Man and he wants to make a 'mod' too... so he sets up a namespace/prefix for his mod called say... 'vte'.

to setup this mod namespace you create a folder called 'vte' or 'trex' or whatever in the root folder of the virtual development folder called <ArmAWork>.
The BIS tools operate off of the <ArmAWork> folder and this virtual folder can point anywhere physically on a computer.

many addon makers & mod makers have registered a 'short' prefix code for themselves or for larger mod's at the ofpec website.
and they use this 'prefix' as the 'namspace' for there work.

for instance, the prefix or namespace i use is 'SYN' - now just to be a non-conformist. I actually use a prefix namespace of 'Synide'. And, again to be a non-conformist I prefix all may addons with 'syn'.

So, a proper setup should look something like...

P:\Synide
P:\Synide\synBodies
P:\Synide\synBuildings
P:\Synide\synWeapons

the above then replicates BIS's usage of the prefix/namespace system they have implemented as you can see...

P:\ca
P:\ca\characters
P:\ca\weapons
etc.

so, you are right when you say that BIS's content is relative to 'ca'... but no one else's content should encroah on thier 'namespace'.

you can of course also, just create a multitude of folders in the root folder of your P:\ drive... say...

P:\trxFences
P:\trxBuildings
P:\trxWeapons

but, this configuration deviates from BIS's intentions for usage as each of the 'folders' are essentially there own 'namespace', and, it's untidy...

Well, sorry about the long winded crap above but with it said you could probably better understand this...

The tools O2PE & V3PE look for config.cpp & model.cfg definitions starting in the current folder that the model you have open is located.
if it then iterates up the folder tree till they get to the root folder of the P:\ drive.

Also, when you 'build' your addon into a pbo whether binarizing or not... BinPBO & it's subordinates again look for information starting in the current folder and working there way up...

When the Game runs... it's a little different... it goes top-down, starting with the config in the bin.pbo then the config from core.pbo then it moves onto the addons folder and then mods...

the most common problems people are faced with are making sure everything inherits properly and using the BinPBO tool correctly to build there .pbo.
All it takes is one little thing to be out of place for the whole process not to work properly.

Post your config.cpp and screenshots of your BinPBO settings you are using to make your .pbo.
Also, check that the paths in the model are correct.
And, check each material.rvmat you make reference too in the model to make sure the paths to the textures inside them are pointing to the right place...

sorry about the brain explosion above... i felt like typing something...

cheers.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-05-28, 06:39:04 PM

Dude. Actually, that helps me envision the way it is supposed to be - which is VERY good. :thumbs:

But, it also is kinda how I'm doing it, so I'm kinda confused. :)

I'm going to go back through and look at all the basics, to make sure I have file/folder names that match up.

Also, I changed my <armaworkspace> to Z: instead of P: by going to the mapdisk.bat and changing that. That shouldn't interfere, right?

I have it set up thusly:

Z:\ModGroup
Z:\ModGroup\theaterA
Z:\ModGroup\theaterA\buildings
Z:\ModGroup\theaterA\structures
Z:\ModGroup\theaterA\vehicles
Z:\ModGroup\theaterB
Z:\ModGroup\theaterB\buildings
Z:\ModGroup\theaterB\structures
Z:\ModGroup\theaterB\vehicles

(There isn't really a name yet, but it'll probably have 3 letters when we come up with one.) ;)

Of course, nothing's finished yet, but that's the idea.

Each model has a config.cpp in the same folder as the p3d, right?

I guess the main thing for me now is, in the model= line, do I put the whole pathname, just without the Z: or do I make it relative to the .cpp - so no path name, since it is in the same folder?

Or, are those questions meaningless, since I still don't understand? :D

Edit: oh yeah, the config-

Code: Select all

class CfgPatches
{
  class ModGroupBuildings
  {
      units[] = {};
      weapons[] = {};
      requiredVersion = 0.10;
      requiredAddons[] = {};
  };
};

class CfgVehicleClasses
{
  class ModGroupObjects
  {
      displayName = "ModGroup Objects";
  };
};

class CfgVehicles
{
  class nonstrategic;
  class ModGroupBuildings: nonstrategic
  {
      model="\ModGroup\theaterA\structures\Hedge01\Hedge01a";
      vehicleclass="JTDObjects";
      armor=15000;
      scope=2;
      displayname="Hedge01";
  };
};
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-05-29, 12:41:35 AM

T_Rex wrote:Also, I changed my <armaworkspace> to Z: instead of P: by going to the mapdisk.bat and changing that. That shouldn't interfere, right?
Never had a problem myself... the only problem I ever had was with when I turned binarized .rvmats into there text equivalents. the CfgConvert.exe tool from BIS appends the drive letter to the front of the textures inside the .rvmat thereby causing problems further along...
T_Rex wrote:Each model has a config.cpp in the same folder as the p3d, right?
It's probably best for you to work to that rule of thumb... and a model.cfg file as well...
But, here's the skinny...

It appears above that you want to have a whole swag of different hedge models, right?
It's probably better for you to stick them all in the 'structures' folder instead of having a seperate subfolder of 'structures' for each model.
It sorta depends on what you are planning... If for instance, you are planning on say having a group of hedges, a group of fences, a group of whatevers... It might be better to have...

Code: Select all

\ModGroup\theaterA\structures\Hedges\Hedge01a.p3d
\ModGroup\theaterA\structures\Hedges\Hedge01b.p3d
\ModGroup\theaterA\structures\Hedges\Hedge02a.p3d
.....
\ModGroup\theaterA\structures\Hedges\Hedge07a.p3d

Code: Select all

\ModGroup\theaterA\structures\Fences\Fence01a.p3d
\ModGroup\theaterA\structures\Fences\Fence02a.p3d
\ModGroup\theaterA\structures\Fences\Fence03a.p3d
.....
\ModGroup\theaterA\structures\Fences\Fence05a.p3d
There are many senarios for do the config.cpp & model.cfg side of it but here is the setup I use...
the config.cpp and the model.cfg... it's not so much the actual name of the file but more the contents... a Fence05a.p3d absolutely needs the appropriate 'config.cpp' definitions, but does not require anything on the 'model.cfg' side unless it moves in some fashion.

Also, although the new O2PE 'Model Config Editor' does not support the following... the BinPBO and the Game do...
When BinPBO builds your folder structure into a .pbo it first looks for a 'config.cpp' & a 'model.cfg' in the same folder as the .p3d it's building.
If it doesn't find either of those 2 filenames it then looks for files called by the name of the folder the current .p3d is sitting in.
If it can't find those then it moves up a level looking for .cpp's and .cfg's... it will only go up the folder tree to the point which you, the builder specifies with the 'Path to Project Folder' setting on the BinPBO 'options' page.
I've noticed all along a lot of people post in the BIS forums not being able to get there models working properly... this setting is one of the main culprits... it is often misunderstood and not set properly by the builder.
If BinPBO finds these .cfg & .cpp files (whether they are called config.cpp/model.cfg or <foldername>.cpp/<foldername>.cfg) it parses them. For the .cpp it creates class names - it does not care what those class name are and the name does not need to match the name of the model .p3d file. If you want the class to work though it needs to point to a valid .p3d model somewhere within the referenced namespace heirarchy.
Critically, if the model has moving parts then the definitions in the .cfg file must have the exact same name as the physical .p3d file.

If you are grouping a number of models together into a folder it's a little 'cleaner' to perhaps have the definitions for all models in the folder in just 2 defintion files. Either called, as previously mentioned... config.cpp or <foldername> and model.cfg <foldername>.

I prefer, and am using the <foldername>.cpp/.cfg naming convention.
1. Because when I do 'Find In Files' with UltraEdit, I can instantly recongnize when the particular text just searched for has been found in the namespace.
2. I don't like having the same named file repeated across the namespace... it can get confusing, and I have found over the years that one of the best ways to lessen troubleshooting tasks is to reduce the oppotunity for confusion.
3. The BIS build tools allow for the above usage senario. (NB: the new 'Model Config Editor' does not currently support a .cpp/.cfg that is called anything else but 'config.cpp' and 'model.cfg' - but I don't use it so I don't care.)

Following is a more illustrative view... bear in mind that the 'namespace' is called 'Synide'...

\Synide\Synide.cfg - defines CfgSkeletons & CfgModels definitions that are generic and available to the whole 'Synide' namespace. These defintions currently inherit from BIS standard defintions. And provide the basis for the inheritance structure in the 'Synide' namespace. In the long run they will not inherit from BIS defintions.

\Synide\Synide.cpp - defines 'config' entries generic for the 'Synide' namespace. The classes in this definition file may not necessarily point to actual models but instead are generic classes that are later referenced by other classes within the namespace. eg. synMan does not point to a working model. Later in the synBodies folder synSniper class inherits from synMan and points to a real model... 'Synide\synBodies\synSniper.p3d'.


\Synide\synAir\synAir.cfg - CfgSkeleton & CfgModel definitions generic for the synAir.pbo. And for convenience sake holds the actual definition for each model file. At this time it's easier to edit the one file.

\Synide\synAir\synAir.cpp - defines 'config' entries generic for the synAir.pbo. At this time also, for ease of management & editing contains the specific defintions for all the models within synAir.

When you build synAir folder (and it's subordinate folders into a .pbo) you would set BinPBO so that the 'Path to Project Folder' was 'P:\Synide' and you would make sure that the 'prefix' that was going to be used inside the .pbo ended up being 'Synide\synAir'.
You can double check this by extracting the built synAir.pbo and checking the 'prefix/namespace' defined in the resultant $pboprefix$ file.
Or, you can look at the build.log that you create at build time...

Try this....

Code: Select all

class CfgPatches {
  class mgBuildings  {
      units[] = {"trxHedge01a"};
      weapons[] = {};
      requiredVersion = 0.10;
      requiredAddons[] = {"CABuildings"};
  };
};

class CfgVehicleClasses {
  class mgObjects {displayName = "ModGroup Objects";};
};

class CfgVehicles {
  class nonstrategic;
  class mgBuildingsBase: nonstrategic {
      vehicleclass="mgObjects";
      armor=15000;
      scope=2;
  };
  class trxHedge01a : mgBuildingsBase {
      model="\ModGroup\theaterA\structures\Hedges\Hedge01a.p3d";
      displayname="Hedge01a";
  };
};
1. make a folder called 'Hedges' under 'structures' and move the Hedge01a.p3d and it's associated files into this folder. Make sure all mappings in the model are correctly re-pathed.

2. Also, I would suggest you have the following structure...

Code: Select all

P:\ModGroup\mgBuildings\structures\Headges
And, place the above 'config.cpp' in the P:\ModGroup\mgBuildings folder.

2. class 'trxHedge01a' is the new classname it inherits from 'ModGroupBuildings' which inturn inherits from 'nonstrategic' - I haven't checked to see if this should be the proper class for your 'hedge' to inherit from - I'm presuming it is...

you should be able to understand the rest... i'm tired of typing sorry...

clear as mud???!

cheers

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-05-29, 02:20:35 AM

Digesting... but this kind of explanation is invaluable. I don't know if I just haven't seen it or haven't seen it presented like this.

I'm at the kind of false-dawn moment. I can see the light coming, I'm just not in it yet. :D

Edit:

Ok, first the config.cpp

Code: Select all


class CfgPatches
{
  class JTDBuildings
  {
      units[] = {"jtdHedge01a"};
      weapons[] = {};
      requiredVersion = 0.10;
      requiredAddons[] = {"CABuildings"};
  };
};

class CfgVehicleClasses
{
  class JTDObjects
  {
      displayName = "JTD Objects";
  };
};

class CfgVehicles
{
  class nonstrategic;
  class JTDBuildings: nonstrategic
  {
      vehicleclass="JTDObjects";
      armor=15000;
      scope=2;
   };
  class jtdHedge01a : jtdBuildings
  {
  
      model="\jtd\balkan\structures\hedges\jtdHedge01a";
      displayname="Hedge01a";
   };
};
A pic of the directory:
Image

A pic of BinPBO:
Image

And a pic of the error:
Image

Also, I noticed that if I try again after getting the error, I don't get the error, but I also don't get a model. :(

Something else, this is an unskinned model at this point. That make a difference? I also noticed that, by adding the additional class, I now have in the editor for "building" (in addition to Hedge01a), but I get a similar error but it is for data3d\bmp.p3d (whatever that is).

Thank you SO much for your patience in this. :D
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-05-29, 05:42:18 AM

lol... no worries...

1. Although it is quite ok to have a deep folder structure to models so as to facilitate keeping things in logical groups for easier management. There should also be a desire to have as shallow a structure as possible too. I'm not criticizing your judgement in any way... simply that your desire to have 'structural' stuff relating to 'balkan' in it's own subfolder is a bit awkward for me... but, that's just me... you might find it entirely logical... that's ok too.

I've put together a small example... JTD.rar 90 Kilobytes. (NB: Link not 24/7)
Place the JTD.rar in the root folder of your <ArmAWork> drive... in your case Z:\.
If you have a folder currently called JTD, then rename it temporarily to something else...
Right-click on it and select 'Extract Here' from the WinRar context menu.
It will create a subfolder called JTD.
This 'JTD' folder is the source for the enclosed jtdBalkanBuildings.pbo. Which you could place in your AddOns folder (or one of the mod folders) and boot up ArmA to see a 'JTD Buildings' and 'Hedge01a' under the Empty objects type.
Also, there are 2 screen shots of the BinPBO settings I used for your example.

I put you a bit wrong with the naming convention for the .cpp files... currently BinPBO doesn't process .cpp's that are not called config.cpp.
But, it does process jtdBalkanBuildings.cfg if it existed in the folder.

Good luck...

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-05-29, 01:12:28 PM

No joy on the link, but if you want to email it: thanks for sending it!

In terms of structure, I'm open to learning from other people's experiences. ;) Plus, logically, there is little difference between naming \jtd\balkans\buildings and \jtd\balkanbuildings\ so if the latter is better for ArmA purposes, I'm cool with that. :)

How do you do your model development, though. It almost seems like I need a different folder to do the iterative stuff on models, then have a consistent name for the cpp. So I do hedge1a, make changes, save as hedge1b, want to see what that looks like in game, copy it to the folder to make the pbo and change the name to hedge1 (which will be what is in the cpp) and build the pbo from there. So, I decide to try something else, go to the dev folder make hedge1c and even 1d, then copy to cpp folder, change the name to hedge1, build pbo and see it ingame.

That kind of workflow?

Edit:
Also, I noticed in the .log of BinPO it says it can't find some Lucida fonts, even though they are in the main fonts folder.... is that important? :)

Edit2:
Can't f'n wait to try this out!
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-05-29, 01:52:20 PM

T_Rex wrote:No joy on the link, but if you want to email it: tdperkins2000 at gmail dot com.

In terms of structure, I'm open to learning from other people's experiences. ;) Plus, logically, there is little difference between naming \jtd\balkans\buildings and \jtd\balkanbuildings\ so if the latter is better for ArmA purposes, I'm cool with that. :)
sent... you are right ofcourse... I was just pointing out that your above setup was starting to get a bit long... your hedge01a.p3d was in...
Z:\jtd\balkans\buildings\structures\hedges\hedge01a.p3d... starting to dig to china... there is no 'best' way... there are just 'ways'...

How do you do your model development, though.....That kind of workflow?
pretty much... it's an absolute arse most of the time...

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-05-29, 02:22:36 PM

Synide wrote:there is no 'best' way... there are just 'ways'...
Yeah, but your way works. My way doesn't. ;) :D

Will let you know when I get a chance to try this out.

:thumbs:
Sic Semper tyrannosauro.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-03, 02:25:21 AM

w00t!!!

Image

THANKS so much for the starting point! :D

Am still going through figuring out what goes where, but this is an EXCEPTIONAL head start.

:bow: :notworthy: :smiley-that-conveys-intense-gratitude:

:D
Sic Semper tyrannosauro.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-06-03, 10:49:00 AM

How about we convert all the thanks to the beginners editing tutorial in the wiki. What do I need to change there to merge this newly learned information?
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-03, 01:01:38 PM

Yeah, I'm still working that out. I think there will be an overlap with Synide's development example.

Here are some observations, though:
First - binPBO settings. These pics showed that, while probably not fatal, I did have these set up incorrectly (or at least not ideally).

Image
Image

Keep in mind the folder structure (more or less) recommended by Sy:

drive:\devname\devnameAddonName\

Then 2 folders under that: hpp and tx.

Second - the config class setups.
#include "hpp\basicdefines.hpp"

class CfgPatches {
class devnameAddonName
{
units[] = {"devnameModel"};
weapons[] = {};
requiredVersion = 0.10;
requiredAddons[] = {"CAData","CABuildings"};
};
};

class CfgVehicleClasses
{
class devnameMetaClass
{
displayName = "JTD Objects";
};
};

class CfgVehicles {
class NonStrategic;
class devnameSubClass: NonStrategic
{
scope=protected;
access=ReadAndCreate;
side=TCivilian;
vehicleclass="devnameMetaClass";
armor=15000;
};
class devnameModel : devnameSubClass
{
scope=public;
displayname="devnameModel";
model="pathtomodel.p3d";
};
};
And here's the example config Sy sent, so you can kinda see how it fits together:

Code: Select all

#include "hpp\basicdefines.hpp"

class CfgPatches { 
  class jtdBalkanBuildings {
      units[] = {"jtdHedge01a"};
      weapons[] = {};
      requiredVersion = 0.10;
      requiredAddons[] = {"CAData","CABuildings"};
  };
};

class CfgVehicleClasses {class jtdObjects {displayName = "JTD Objects";};}; 

class CfgVehicles {
class NonStrategic;
class jtdBuildings: NonStrategic {
      scope=protected;
      access=ReadAndCreate;
      side=TCivilian;
      vehicleclass="jtdObjects";
      armor=15000;
   };
  class jtdHedge01a : jtdBuildings {
      scope=public;
    displayname="Hedge01a";
    model="\JTD\jtdBalkanBuildings\jtdHedge01a.p3d";
   };
};
Sic Semper tyrannosauro.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-03, 06:53:57 PM

Heya Sy-

In your basic defines.hpp, you have the following entry 2x:

Code: Select all

#define LockNo		0
#define LockCadet	1
#define LockYes		2
Any particular reason? :)

Edit:
Another question about the rvmat. I Linker Split's pdf for normal/specular mapping. He has 3 stages in his rvmat, one for normal mapping, one for (what appears to be) the regular UV map, and one for specular. He also has some config entries (CfgMaterial, etc.) that I do not see in the config you included. There may not be any easy answer to this, but I'll ask anyway. :D

Is there a "right" way to do it?

Thanks again!
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-06-04, 12:57:35 AM

Those 'basic defines' are just what came with the BIS Example P3DM mlod models. That is BIS supplied additional example models in a recent release (I wonder why?) and importantly included the model.cfg (skeleton & bone & static anim) files and the config.cpp for each of the 'groups' of models.
I noted after posting the above example that the 'basic defines' include add a double-up on those defines. Just delete them.

The 'new' world of Materials in the 'Real Virtuality' BIS engine is slowly becoming better understood by the ArmA community.

Essentially it's like this...

A 'Shader' is a lump of compiled code that has been created by the BIS developers. There are 2 types of shaders, Pixel Shaders & Vertex Shaders. (And, in DirectX 10 for use on newer computer setups there is additionally the new Geometry Shaders). If you want to know more about shaders try reading The Cg Tutorial at Nvidia...

The combination of Vertex & Pixel shader that you use with your material will have specific requirements as to the no. of stages & what each of those stages do/are for the shader combo. to work effectively.

BIS have supplied some 'templates' for material files which would have been installed into the 'root' folder on your <ArmAWork> drive.
Also, there is a list of Shaders on the biki (Here).

Although, BIS have neglected to go that one step further and properly describe to us what each Shader's functionality is aimed at producing & what each shaders prerequisite or required input parameters are... unfortunate, but that's the way it is...
So, one has to look at 'material' .rvmat files that BIS's content makers have used with there models etc. AND look at the material templates provided with the tools AND look at the biki .rvmat pages to work out the story.

The easiest way is to find a comparable type of 'object' already defined by a BIS model and copy that rvmat over to your models and amend the contents where necessary.
Then further along, you can start tweaking & altering the materials and even trying different combinations of shaders etc.

As far as the no. and contents for stages... it's entirely dependent on the Pixel/Vertex Shader combo. used.

Eg. a fairly commonly used...

PixelShaderID="NormalMapSpecularDIMap";
VertexShaderID="NormalMap";

requires 2 stages...
stage 1 points to 'High Quality Normal Map'
stage 2 points to the 'An Optimized Specular Map'

I haven't looked at LS's normalmap/specularmap tutorial so I can't comment...
Also, different Vertex/Pixel Shaders are aimed at achieving different effects in the game...
This, is where BIS should be updating the Biki to detail each Vertex/Pixel Shaders intended usage...

It is important to utilze BIS's suffix naming convention. But WHY?? you ask?
Because it helps the TexView2/Pal2PACE decide when creating the .paa's (or .pac's) to decide on how best to process the incomming image and compress it into .paa format.
It's definetly not a set in stone requirement, but it's certainly optimal.


CfgMaterials & CfgTextureToMaterial are still used within ArmA just not as much as was in OFP.
They're usage in ArmA by BIS at least tends towards defining generalized fallback material definitions for basic environment effects, predominately.

Also, they were a means by which the community could define new materials for stuff during the period when the game was released and the first BIS tools came out.

For just about all circumstances it's better to define your materials using the .rvmat technique. There are of course situations when this is not the best way... It's all trial and error, I'm afraid - always has been always will be...

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-04, 02:20:04 AM

Excellent response! :D
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-06-04, 11:04:52 AM

As promised here is a .pdf on how to setup your Development Environment...

For novice's and budding Addon makers it might provide some guidance... dunno.

Cheers, Sy.

ArmABuildEnvironment.pdf 698 Kilobytes (Link not 24/7)

ArmABuildEnvironment.pdf 698 Kilobytes (from RKSL)


Some additional info...

A method to copy the 'original' config.bin files from P:\ca\..\.. to P:\<YourNamespace>\ca\..\..

1. open the msdos window and navigate to P:\ca

2. type the following command and press enter.

Code: Select all

xcopy *.bin P:\<YourNamespace>\ca\ /S /Y
3. you should have previously placed any model.cfg files you acquired from the BIS supplied example models to there respective places within your P:\ca\..\.. folder structure.
If you haven't then you should probably do this right now otherwise you can't do step 4....

4. type the following command and press enter.

Code: Select all

xcopy model.cfg P:\<YourNamespace>\ca\ /S /Y
Result should be you now have a folder structure under your P:\<YourNamespace>\ca\ folder that matches the P:\ca reference folder structure and there should be only the config.bin files and model.cfg's.

good luck.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-04, 01:49:55 PM

Great stuff!

I've done a little (VERY LITTLE) programming, so I'm familiar with the idea of namespace. I just want to make sure I understand the practical side of it in the ArmA context. :D This is focused on your illustration at the end.

When you unpack all the ca stuff into your work folder, it is basically "parallel" with the mod namespace. So, when you build the pbo, it recognizes the ca as a different namespace, and doesn't actually pack all those models/data into the pbo, but it does include the references. So, when you put it into the addons folder (or use an @mod\addons folder) it preserves the references to \ca\ also.

In other words, by specifying the path to project correctly, it will only pack the mod, and not the "base" stuff that you've also put into your work directory for reference?

Sorry if that question doesn't make any sense. :D
Sic Semper tyrannosauro.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-06-04, 02:18:18 PM

Guys, I think the discussion has gone way beyond "beginners" here now...

What sort of tutorial would be the next level after beginners... is it straight to advanced or hmm how would we proceed with the next tutorial so it would be most helpful?

Would it be best to do like direct examples, like "how to make HD config addon" and "how to retexture a soldier" or something like this?
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-04, 02:54:36 PM

Perhaps use some of this stuff has hyperlinked "deeper levels" from the beginners wiki entry?
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-06-04, 02:55:59 PM

Snake Man wrote:Guys, I think the discussion has gone way beyond "beginners" here now...
Maybe, although I don't think it's gone 'way' beyond what a beginner needs to know... At the very first stage they need to know how to setup their build environment... Otherwise they won't get far with any sort of editing... don't you think?
Although, as you say this discussion is starting to push to the next level...

I feel being able to have a good'ish setup on your build side of things forms the basis... I'm not sure what a beginner needs to know next?
I guess it's entirely dependant on what they want to do? dunno...

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-04, 03:10:28 PM

Hey Snake,

As I do this hedge, I'll try to generate a tutorial about it. I plan on getting into the normal/specular mapping stuff, too.

:thumbs:

Do you want me to start a new thread on the namespace question, or just email Sy? :)
Sic Semper tyrannosauro.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Post by Snake Man » 2008-06-05, 11:25:08 AM

Yeah feel free to open a new topic, lets just keep each topic... "ontopic" so when people click a topic they can read the subject at hand.

I'm still bit lost what part of the conversation here should be added to the beginners tutorial.
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

T_Rex
FreeFalcon
Posts: 848
Joined: 2001-03-04, 11:01:01 PM
Location: here

Post by T_Rex » 2008-06-05, 01:05:01 PM

Personally, I think the biggest help for the beginner is going to be the basic config.cpp. Using the red hilight parts to kinda explain what to change.

When you first get something into the game, it is the kind of excitement that keeps you motivated. :D

I feel like people who are even interested in doing it already know how to model, at least a little bit. :thumbs:
Sic Semper tyrannosauro.

Synide
2nd Lt
Posts: 76
Joined: 2003-11-18, 07:14:51 PM
Location: Wgtn, New Zealand

Post by Synide » 2008-06-06, 07:08:34 AM

see this post of yours a month ago on your house config problem?

I could pretty much guanrantee that it'd be solved by setting up your build environment as above. Without, you having to modify lod's and stuff in the model... that error you mentioned in that post is 'casue your model hasn't been able to find what it should be inheriting from... if you follow my setup guide and then make sure your config for the model in question is sound you shouldn't have any problems... i don't.

The very 2nd thing a budding addon maker should do before they start modding is follow the steps I discussed above in the .pdf.

Snake Man
Commander-In-Chief
Posts: 8556
Joined: 2000-07-31, 10:01:01 PM
Gaming Interests: ArmA, ArmA 2, Falcon 4.0 and OFP.
Editing Interests: All, I (try) to edit everything.
Location: PMC

Re:

Post by Snake Man » 2009-03-17, 07:14:50 AM

Synide wrote:As promised here is a .pdf on how to setup your Development Environment...
For novice's and budding Addon makers it might provide some guidance... dunno.
Cheers, Sy.
ArmABuildEnvironment.pdf 698 Kilobytes (Link not 24/7)
ArmABuildEnvironment.pdf 698 Kilobytes (from RKSL)
I finally got around to add it to our wiki; PMC Editing Wiki: ArmA Build Environment.
PMC since 1984

Editing knowledge, visit PMC Editing Wiki
Addon manuals, visit PMC addons/mods online manuals
View our videos in PMC Youtube channel.

PMC Tactical forum Advanced Search is power.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests