RickyT23 let�s go private baby!!! 

 

I already have 2 daughters: no way to try again for a new baby! I'm very reluctant to have another girl at home (I'm also unlucky I think...), it is already enough complicated as it is :P 

JPL my boys need womens... keep the good work :) 

We don't need Trinca/JPL hybrids! No one at func should be replicating, period! 

they'd only be 1/4 trinca and 1/4 jpl... 

.. yeah, but it is also impossible, I would not let my daughters with Trinca's sons... if hissons are as pervert as he is... 

hehe :)

latins are all pervert they dont have many choises...

only if they find some faget in another not latin country :p 

My ex wife was Creek, and I have been with women of every race, even some of them without having to pay up front! So I don't know where that is coming from. 

Key representative of Gonzo mapping 

I meant Headhunter S.
Illiteracy ftw. 

 

what was the native american wedding like?

Also, quoth2: open source is good for the future. Perhaps a working compromise could be this: when the team (Necros and Kell and Preach) feels that "it's ready", whether that means that they are too tired to make new additions or that it really is complete, they can release the source to make sure it stays alive.

On the qw side of things there was the ktpro mod (closed source AFAIK) but it died and now everything is done with the open KTX. And it gets updated quite often, together with MVDSV, the server executable. In fact, the coders would like more developers to help them.

Also, there were some 64bit vista issues with the mod (the progs). So it's not as if mods can't give problems.

Just if you want to make sure your work lives on, make it open source after a while. 

with only seven other people in attendance. Her decision, not mine. 

I am having a tough time setting this up in WC. So far, I have something like this in the FGD:

@PointClass size(-8 -8 -8, 8 8 8) color (128 128 128) = mapobject_mesh : "Custom Mesh"
[
mangle(string) : "Angle (x y z)"
frame(integer) : "Frame"
model(string) : "Sprite"
spawnflags(flags) =
[
1 : "Static" : 0
2 : "Solid" : 0
]
]

But Quake gives me an error:

No spawn function for:
Edict 9:
Origin '208.0 -352.0 -512.0'
Classname mapobject_mesh
Model progs/grill64.spr
Frame 1.0
Spawnflags 1.0

Any ideas? 

And I was so sure we eliminated all references to the old classname. It was renamed mapobject_grill when the sprite started including other textures than wire meshes. I guess that change didn't make it to the docs though...

(btw, that fgd looks really thorough, would love to see the full thing once it's done) 

Works like a charm, now :-)

I will upload the FGD after I get the rest of the kinks out... 

As long as we're on the subject, are there radiant .def files for quoth anywhere? I have seen one mentioned but can't find it.

I considered making one myself, but it's a non-trivial amount of work, and certain things aren't obvious from the mapping tutorial, like which entities are point and which are solid. 

We tried to make the entity classnames instant indicators of what is and is not a brush-based entity. Anything with func_ at the beginning is a brush-based entity with the following exceptions:


func_rotate_entity
func_rotate_door
func_rotate_train (to conform with the hipnotic naming of these confusing things)

func_hordespawn (this name is depreciated though, for the reason that it is a point entity, use info_multispawn instead: http://www.celephais.net/board/view_thread.php?id=60173&start=257&end=257 )

func_something_point (these are obviously meant to be point entity versions of the func, for ease of use in hammer)


Similarly anything with a name beginning trigger_, other than trigger_something_point, is brush-based.


I think I'm right in saying that any other entity is point based(unless you're doing some diabolical entity hacks of course). 

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