Ok, it's been long sought after, even promised by a few people. But on Friday I got a snow day, and decided to do something productive with it. So I've made a fgd file which contains essentially all the Quoth entities. Try it now, for free, from:

http://www.btinternet.com/~chapterhonour/quoth2.fgd

This is beta quality, it's not been extensively tested (or spellchecked), and there are probably omissions. If you spot what you think is a glitch or mistake, let me know in this thread, and I'll try to revise it.

The enticing selling points:
* All the quoth monsters, with coopflags and teleport flags added.
* Full listings of the available textures in mapobject_grill and func_breakable rubble objects.
* Hints in the rotating object fields to remind you how to set them up
* Undocumented features???

I also read that GTK Radiant 1.5 supports loading fgd files, so those people aren't entirely left out in the cold. Which is probably best given the weather... 

Woot woot! Thanks Preach! Maybe I'll make ToeTag able to read FGD files as well as DEFs then... 

light_tubelight
light_postlight
light_globe
light_marsh
Cause errors with tyrelight. The color key if not set to zero causes the error (no light emitted). For tube and post lights I've found changing "color" to "skin" in the FGD works. For globe and marsh "skin" does not work no luck with "frame" either. Any ideas?? 

Well, we have a classic conflict here, that both the light tool and the mod claim rights to the field "color". The convention which is meant to be obeyed is that light tools use entity fields which begin with an underscore, and the later versions of tyrlight do just this. The same problem was found in the original quoth thread:
http://www.celephais.net/board/view_thread.php?id=40281&start=150
So if you can track down that newer version of tyrlight then you should be ok.

In a future version of Quoth, I will try to make sure that leaving color unset will enable you to set the frame directly. For now as a workaround, you could use a second light entity in the same place to cast the light. Alternatively, you can build the map without color set, light it, and then reset the color and recompile with -onlyents.

This post was brought to by the american spelling of colour, but grudgingly 

 

Have you guys thought about adding a new entity class that would allow the properties of an entity to be changed? I'm thinking of an entity that, when triggered, would perform a particular operation on a given field of its target entity ("operation" could be set, add, multiply, etc.)

This could enable a mapper to, say, dynamically change an ent's alpha value, or move it, or add health, take away ammo, etc...

Something like this:

{
"classname" "func_<whatever>"
"target" "scrag1"
"targetfield" "alpha"
"op" "1" /* --> add following argument to scrag1's .alpha */
"arg" "0.1"
}

or

{
"classname" "func_<whatever>"
"target" "tele1"
"targetfield" "target"
"op" "0" /* --> set value of tele1's .target to following argument */
"arg" "teledest2"
}

It seems to me [someone who doesn't map, and has a very minimal understanding of QC ;-) ] that it could be useful 

I like the idea! 

there's an official FGD, that means someone can now make a .def!!!!!!1 

WHEN 

I think c_shot2.mdl is a bit gimpy? I noticed it while playing sm149_drew - there's a yellow strip at each side of the base of the barrel.

I opened the model in QME (Lite v3.1), and the tri at that spot seems to be in the wrong place on the skin. It's the most evident in frame 4.

See:
http://www.quaketastic.com/upload/files/screen_shots/c_shot2.png 

Yeah, good catch! I'll have to fix that for future releases. 

That must mean that the entire pack must be quarantined and eliminated immediately! Shame on you Kell, Necros and Preach! SHAME!!!


I'm kidding. 

The skin in the shot I posted is how it appeared in QME that day. Today, there are almost twice as many tris. Weird.

Is there a more stable modeling app out there? What do you use?

Zwiffle: It's shocking, I know. Almost like these guys are mortal or something. ;) 

My personal approach is to do as little in QMe as possible. So I use gmax to make my model, animate and skin it. Then I export it to MD3 format, and convert it from MD3 to MDL. There are two paths I know of to make that final conversion. Either you can use quark, if you can set it up correctly, but that is a bit of a pain. The alternative is a command line program which I wrote for the purpose.

Once you go down the path of creating your models in MD3 format and converting them to MDL, a lot of options open up because MD3 is a much more popular format. Most major 3d modelling packages have an export to it (3dmax, maya, blender to name 3). The only difficulty is knowing what you can't do in MDL but can do in MD3 - eg MD3 supports multiple skins but MDL doesn't. 

http://www.icculus.org/qshed/qwalk/ 

There is a typo in the official Quoth 2 FGD that causes tubelights not to load.

@PointClass size(-8 -8 -8, 8 8 8) base(Light, Target, Targetname, Static) = light_tubelight : "Tube light"
[
spawnflags(Flags) = [ 1 : "Initially dark" : 0 ]
color(choices) : "Colour of light object" : 0 =
[
0 : "Yellow-white"
1 : "Blue-white"
2 : "Red"
]
]

Also, I am having no luck with the other color options. I get yellow-white every time. (Same for postlights.) The greying out works, however. 

Sorry for the typo, will go fix it on my copy.

As for the color issue, you aren't having the same problem as
http://www.celephais.net/board/view_thread.php?id=60173&start=344
are you? 

I changed "color" to "skin" in the FGD for light_postlight and light_tubelight, and all was good.

Thanks! :) 

of all the threads the bot could have posted on... 

I'm hoping it's pertinent because Quoth Part 3 is about to be released ... ? 

The JPEG artifacts in the otherwise great "stars" skybox were bugging me, so here is a fixed version where I filtered them out using GIMP:

http://www.quaketastic.com/upload/files/misc/stars2.zip