Hi - As a side note, the code imports the values from the map in the entity's KeyValue function. Be sure that any of the variables that can be set by the mapmaker are handled here.
The exception to this is the spawnflags. Each of the spawnflags (1, 2, 4, 8, 16, etc) are the corresponding bit in "pev->spawnflags". Flag 1 is the farthest right bit, Flag 2 is the 2nd from the right, Flag 4 is the third, etc. They are useful for "Yes/No" information. Check the code on some other map entities for the specifics. Barret ----- Original Message ----- From: "Pat Magnan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 26, 2002 3:12 AM Subject: Re: [hlcoders] FGD's and coding > Well, a couple things. If you've removed every halflife entity, and are > going to code all your own from scratch, then NOT starting with a stock > Halflife one is a good idea. ;) > > Otherwise, start there. Learn a bit about mapping (the use of entities), > and you'll start to connect the dots as far as the things that are in the > FGD relate to what Hammer's UI shows the mapper. I think to code entities > for Halflife, you HAVE to be able to build a boxy room and make a couple > entities work. Otherwise, your entities will be too hard to use for most > mappers, as you won't be conforming to standard idioms of entity use possibly. > > An FGD is simply a way of customizing entity properties in Hammer's UI, and > linking between your entity's code (Look at the KeyValue function to see > how the code deals with the properties), and the compiled .bsp. > > Otherwise, an FGD is pretty much a C++ object's data members, or, depending > on your COM experience, it's like an IDL file -- not C++, but ways to > document what a C++ class exposes as methods and data types (in this case > more like a struct), it's an intermediate language. > > The data types are pretty simple (number or string), why everyone says > start with Halflife's is that it will become self documenting once you > spend enough time reading it (yes, that's the hard part.. cause it looks > like gibberish the first go). @SolidClass or @PointClass just means 'is it > a brush based or point entity'. That is, does the mapper drop in a brush, > and convert it to an entity, or do they pick a point. Again, a basic level > of mapping will help here. > > The rest is just a bunch of data stuff. If you can write a C++ struct, you > can pretty much write a description of your entity in the FGD file, by > looking at other entities for the 'data types' and/or UI features you want > to expose. > > For example: > > @SolidClass base(SomeBaseClass) = MyEntityName : "Mappers Pretty Name" > [ > myvalue (choices) : "Mappers Pretty Name" : <defaultvalue> = > [ > 0 : "choice 0" > 1 : "choice 1" > ] > ] > > Things that the names may not make obvious: > (choices) - gives the mapper a dropdown (or combo box), the value is an int > in code > 0 - the int value when mapper picks this > : "choice 0" - what mapper sees > > MyEntityName - You'll use this in code in the LINK_ENTITY_TO_CLASS macro > > In general, if it's quoted, then the mapper will see that value (there's > probably an exception I'm forgetting). > > Copying and pasting is like inheritance is to C++ in my opinion. Wisely > used, it saves work and brain power for more important logic problems. > Poorly used, it's just a bloody mess. > > That's about all I can think of that wasn't clear to me after mucking about > with it a bit.. and I don't know of any documentation per se. > http://www.planethalflife.com/hlsdk2 has something on creating an entity, > and he may go into the FGD there? > > At 01:45 AM 11/24/2002 -0800, you wrote: > >Howdy, I'm really interested in how FGD's work and such, I want to know the > >real deal, is their some design documents, or > >tutorials that are written on them, because I know everyone always says its > >not hard just look at other peoples stuff, > >but that just means cut and paste a stock halflife fgd if you aint got an > >idea wth your doing, I have no idea how to > >associate this stuff codewise, things like, > >--stock fgd-- > >@SolidClass base(Door) = momentary_door : "Momentary/Continuous door" > >--end of stock fgd-- > >means bloody nothing to me, how am i suppost to read this and just figure it > >out ? see where im getting at ? > >anyways it would be of so much help if theirs some sort of tutorials or > >guides on writing fgd's (i.e. keys, syntax, > >usage, etc) and hopefully, writing the code required portions and > >everything, because i honestly don't feel right in > > giving out my mapmakers something i truly don't understand, which i want to > >udnerstand myself. > > > >Thanks ahead of time, > >Paul > > > > > >_______________________________________________ > >To unsubscribe, edit your list preferences, or view the list archives, > >please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > Pat 'sluggo' Magnan > Tour of Duty mod > http://www.tourofdutymod.com > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
