conback.lmp and used to have a limit of about 64k in size, but some paks use larger and might cause some engines/tools to fail (or even crash) to load it. Carved in Flesh is such a pak. 

I found a tool called Adquedit and was able to extract it. So I'll have to keep it under 64k then? The original file is 55.9 KB. 

to avoid weird behaviour or even crashes in standard engines, you should keep it beneath 64k. There are also similar restrictions on skins and other texes (at least in GL-engines), but the limit is higher then.

In my next engine versions, I've added warnings when exceeding normal limits. 

I wonder if anyone can point me in the right direction...

I remember seeing a mod where Chthon had been shrunk somewhat and could be killed with ordinary weapons. I am not sure if it was part of a larger map or was just an example map showing the mod.

I remember that there were two of these in little lava pools each side of a very small room and you could duck in and out of the room (it may have had a doorway at each end of the room) and lob grenades at them. The room was probably 1024 x 512, or at least that kind of proportion

I've Googled, Copernicked and even Asked Jeeves but only get referred to Chthon10 or Chthon! neither of which are what I am after.

Ring any bells with anyone? 

The mini-chthons in little lava tanks appeared in Mish Pak 2: DoE iirc 

Bugger me Kell, bit quicker next time please:-)

Thanks. However... I never bought DOE, so if that was it, it must have been released to the public OR someone used it in a map.

I have a lot of lava in my current map and thought that it could be a useful extra monster type? 

You can get the DoE QC source here: http://ftp.sunet.se/pub/pc/games/idgames2/more_idstuff .

And the DoE map Kell refers to is probably Elemental Fury II (r2m3). 

Hello, It's my first post here... :)
I'm looking for the pak (zip) with all Ogro's textures but I can't find anymore. :(

the file on his site is down and I still don't had lucky.

can someone help me?

thanks,
Freddy 

Hope these are what you are looking for?

Try here

http://www.fileplanet.com/dl.aspx?pandemonium/ogropak.zip

tip
If you find files on PQ/fileplanet that seem to be missing/404. just add the following before the filename path,

fileplanet.com/dl.aspx?

for eg, the following link

http://www.planetquake.com/dl/dl.asp?q2cc/q2ccv102.zip

would become

http://www.fileplanet.com/dl.aspx?pandemonium/ogropak.zip

(func_msgboard will screw up the above example, but you should get the idea, hope so any way}

Not guaranteed to work on all occassions, but will for a lot. 

hover over the links to see what vorelord is talking about, though. 

I don't know how I came to use 2 totally unrelated links in my example above, but I did, it of course should be,

tip
If you find files on PQ/fileplanet that seem to be missing/404. just add the following before the filename path,

fileplanet.com/dl.aspx?

for eg, the following link

http://www.planetquake.com/dl/dl.asp?pandemonium/ogropak.zip

would become

http://www.fileplanet.com/dl.aspx?pandemonium/ogropak.zip


// I'm going to go and have a lie down now 

I'm not yet really used with antilight use, so I would like to have a little bit informations.

I just would like to have confirmation that antilights are only lights with a negative value, or if there is something more in their description (additional field, etc...)

I also noticed that antilights didn't have effects on worldspawn minlight value, i.e it is impossible to have a zero light (like full dark) area around antilights... or do I missed something ?

Thanks in advance... 

antilight have the same keys as usual light, i.e. wait, etc (if u use aguirres light). and if i remember right it affects minlight turning everything to pitch black. 

Well, so it seems I set antilight fields correctly (i.e negative value, wait, delay, etc...) Maybe I need further tries to find the good use with the good effect..
Thank you Von' 

the only good use is to black out abysses like in numb nimbus level by czg. 

I would not like to be so "radical" ;) 

Antilights works basically like normal lights with all extra keys. But it can only affect light with the same style, e.g. you can't darken a flickering light with normal light (style 0). Also, you can't use antilight as ambient light, e.g. minlight.

In TyrLite (which I think you use) there are some other possibilities, e.g. you must add the option -nominlimit to make antilight force levels beneath ambient minlight.

Check readmes for more details. 

Thanks for the information, I will try it this evening: I now suppose this option was missing in my light process.. ;) 

/*QUAKED misc_fireball (0 .5 .8) (-8 -8 -8) (8 8 8)

Am I right in thinking that the second and third group in the above are the dimensional off-set from the origin of the entity based on the size of the model and that the bounding-box is therefore 16x16x16?

If not, what are they?
If my assumption is correct, is this how the entities origin is determined i.e. I could redifine the entities origin by altering the parameters to (say) (-8 -8 -12) (8 8 4) to have my origin higher up the model but still within a 16x16x16 bounding-box.

What is the first group relating to?

I have Googled but cannot find a decent definition of this anywhere (14000 entries offered, a couple of dozen checked, and then I thought that I would use my favourite search engine:-) 

These are all just fields to tell the QuakEd editor about the entity.
First group specifies it's color, the two following specifies the minimum and maximum bounds of the entity relative to it's origin.
This is just for the editor though, it won't have any effect on the actual in-game entity.
If you change the bounds, the box in the editor will appear to change, but the origin will still be in the same place. (Unless you move the entity, obviously, to acommodate for the change in the box.) 

Thanks. A couple more questions:

How does the Colour Group work - what are the three values telling the editor?

Also, if the other groups are there to tell the editor about the entity, how/where/why is the origin of an entity determined? I can see that the editor 'knows' the origin and passes this detail to the compile routines via the .map file, but this is only calculated from the *Quaked definition. So, is the origin only determined by the entry in the *Quaked definition and can I therefore change the origin simply by changing that definition?

I haven't a clue why I would want to do that but i am trying to understand the relationships between the editor and .map files, the .bsp file, the progs.dat and the engine. 

if you change the Mins and Maxs in qc, it would affect the collision of the entity against other entities, but not the model positioning (which is always centered on the origin, rather than centered in the bounding box. Back to the collision thing, it will affect its collision against other entities, but the collision against the world will always use one of three hard-coded sizes: zero-sized (0 0 0)(0 0 0), player-sized (-16 -16 --24)(16 16 32), or shambler-sized (-32 -32 -24)(32 32 64). 

Thanks for the explanation.

Is the world collision detection routine run three times, one for each of the hard-coded sizes, or does each entity have one of those fixed sizes 'allocated' to it somehow? (Of course, I don't actually know how collision detection is carried out as the game progresses - is it only after (or perhaps just before) each individual entity movement, or cyclical on every entity all the time or ???)

These questions have come to the fore because I have a model but no *Quaked definition. By trial and error I have created a bounding box and can fit it the map OK but do not know how to decide the origin for the entity: should I just use player-size or shambler-size according to the size of the model or is it a bit more complex than that? It is only a static model at present but if I ever get the hang of animation, it could become a 'monster'.

I notice that the Bounds dimensions shown for standard Quake models in QME 3.1 never match the *Quaked definitions - what am I missing?

Metlslime, do you map or do you just stick to programming?

Mmmm, a lot of questions again. Hopefully there are others who are as novice as I am and will learn from the answers as well. 

I can't answer you're more technical questions, but I can shed some light.

should I just use player-size or shambler-size according to the size of the model or is it a bit more complex than that?

In my earlier reply about the narrow beam, I was not entirely accurate when describing the player bbox. In fact, the player and monsters don't have a bounding box, they're just point entities that collide with the 'expanded into the map' hulls 1 or 2, which creates the illusion that they are in fact boxes.
This mechanism vastly simplifies the amount of information calculated for collision. The ( acceptable ) trade off is slightly longer compile times and larger file size of finished maps.

The other limitation however is that you can only have moving entities ( i.e. players and monsters ) that are the size associated with the collision hulls. In Q1 there are only two sizes: player and shambler. ( HL1 had more collision hulls afaik, allowing for a greater variety of monster sizes )

From my experience working with necros on monster creation, I believe that it's possible to specify the weapon collision box for a monster, which needn't be the same as the architectural hull1/2 box size. In the case of the vermis for example, because it doesn't move from it's location it only has one very wide and very tall box for calculating weapon hits, but no box specified for either hull 1 or 2.

For a regular monster that moves about and will bump into walls and stuff, you got player/knight/scrag size and ogre/fiend/shambler size. That's it.

I notice that the Bounds dimensions shown for standard Quake models in QME 3.1 never match the *Quaked definitions - what am I missing?

The information shown for model entity properties is not for collision, it's simply the maximum and minimum extents that the verts of the model occupy in any given frame and also over the course of all frames throughout its animations.
This is relevant because of the way the Q1 .mdl format saves the location of verts. Unfortunately, it is ( as Kinn helped me to crudely understand ) sort of a case of mdl being, like the Quake color palette, limited to 256. That is to say, the farthest distance apart the verts reach in any single animation frame is used to define the 'grid' into which all the other verts in all the other frames will be fitted. The max/min extents are divided into 256.
So for example, a monster with an insecty proboscis that it can shoot out of its mouth at the player a long way is going to have its front to back 'grid' stretched out because of the distance of the verts in that one animation frame. As a result, the rest of the verts will have to be fitted into the nearest grid locations along that length, giving rise to visible innaccuracies. In-game, this makes the verts wobble about a bit - it's called 'vert dancing' or the 'jello effect' for obvious and rather regrettable reasons.

Generally, the exact numbers are not of interest when modelling in .mdl format. Just try to keep the verts of your monster within a fairly defined space - don't have it reaching out to far in any direction in any frame. The more detailed the model - the finer the grain of the verts you've placed - the more of a problem vert dancing will become.

Metlslime, do you map or do you just stick to programming?

Metl has for some time been one of our community's illustrious professional devs. He used to map for Q1 and Q2. His first map was The Crawling Chaos, a nice bit of stygian horror. His most memorable map for Q1 was Rubicon, for which he also created a competition winning (?) texture set, still used for Q1 maps. One of the best base texture wads evar.
Rumours of Rubicon 2 are not baseless, but apocryphal or at least wildy innacurate.
He is a supremely talented bloke in all areas of game design, though he also suffers from an inexplicable aversion to bees.

HTH 

Yeah i map, but i have a lot less time for it at home now that i do it as a profession. Since my homepage has been taken down temporarily, the only place to see screenshots and stuff is my portfolio, here:

http://www.celephais.net/cv/portfolio.htm

Um and to answer your question, the choice of which of the three sizes to use for world collision (point-size, player-size, shambler-size) is based on the bounding box you specify in quakec. I don't know for sure if it rounds down, rounds up, or picks the closest of the three sizes.