The project wont die (ie source lost in the rift of time forever). Plus what Ijed was hinting at....

Hmmm. I think Baker has a valid point though.
There's no harm in covering their backs, so to speak.... 

and not exactly "alive". 

how many people actually intend doing something with the source code?

/me raises his hand weakly, having more or less stopped giving a shit at this point 

could be the way to pursue it? 

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...