from the Vision.zip(DarinMcNeil) I need progs.dat only? cause he included many files.

that's all you need to play the map with the cutscene entities. but you will need the qcs (as well as the rest of the source - available from inside3d as linked by me above) if you want to modify the code any further. say, to add ambient sounds...


So now they work.. but useless! cause my goal is to have a looping ingame music constantly audible wherever player is !

..suggestions ?

modify the qc code ;)

if you open up misc.qc and bung the following in somewhere after the normal ambient entities...

void() ambientsound_start =
{
ambientsound (self.origin, self.noise, self.volume, self.distance);
};

void() fx_ambientsound =
{
if (self.noise == string_null)
objerror ("fx_ambientsound without noise!");

precache_sound (self.noise);

// Default volume to 1.0 if not specified
if(self.volume <= 0)
self.volume = 1.0;

// Default to ATTN_STATIC if out of range
if(self.distance < ATTN_NONE || self.distance > ATTN_STATIC)
self.distance = ATTN_STATIC;

if (self.targetname)
self.use = ambientsound_start;
else
{
self.nextthink = time + 0.1;
self.think = ambientsound_start;
}

/*
// start right away if not triggered
if(self.targetname == string_null) {
// Need to start on the second frame since that's when entities not called in world_spawn are created
self.nextthink = time + 0.1;
self.think = ambientsound_start;
}
else// wait for trigger
self.use = ambientsound_start;
*/
};


then paste this in your fgd:

@PointClass base(Sound)= fx_ambientsound : "Ambient Sound"
[
targetname(target_source) : "Name"
noise(string) : "Sound"
volume(string) : "Volume"
distance(choices) : "Attenuation" : 0 =
[
0 : "Play Globally"
1 : "Large Radius"
2 : "Medium Radius"
3 : "Normal Radius"
]
]

then you *should* have a new entity capable of playing the sound file of your choice at the volume of your choice, with distance set to 0 if you want it playing throughout the map. hopefully anyway...


So I copy entities code from Darin in my fgd and the new entities should appear in Worldcraft ?

well not exactly as FGD uses its own code/format as i'm sure you are aware. have a look in the fgd and figure it out; you should be able to add the entities yourself based on the information in cck.txt 

Ambient sounds in Quake are just used for that. Custom stuff is needed for ingame music.

Some mods, like Qouth, let you set attenuation -1 which means they're heard globally, but only while you're looking in their direction. That's where putting them at the cardinal points comes in. 

..Atlast I got them to work! But in order to be audible ingame I had to place these ambient sounds really close to the player!
My error was to place them at the 4 cardinal points(as in HalfLife) of my map.

Ah... yes, you mentioned this earlier but i think we assumed you meant you placed 4 in the same room as the player. Quake ambients are localized, you have to scatter them through out the rooms and hallways of your map.

NOTE: you only can have 116 of them if you are using a standard quake engine. And torches/flames count towards this total too. 

As for the soundtrack, the easiest solution would be to supply an mp3 which people can play in the background while playing the map. Or not, if they don't like it. 

Thank for all suggestions.. now my brain is melting..

As I stated I'm a not too bad mapper and musician.. but ignorant in qc code

I got my own songs ready but maps are not done yet.
------------------------------------
ps: I tried MikeWoodham "ThisOnion" it's really a nice work but soundtrack is the real winner! 

your own progs.dat will be so hard. People here have done similar to what you are talking about, if you try as much as you can and keep asking here you will succeed :) 

i'm no coder at all. but qc is pretty simple once you try and familiarise yourself with it, especially seeing as all you need to do is copy & paste the right bits in the right places. definitely worth looking at 

But save it for the next project. One step at a time :) 

1)Please somebody could upload a Quake progs.dat complete with cutscenes code and in-game music code ?
2)And the suitable *.fgd for Worldcraft/Qadapter ?

ehm.. I feel embarassed, but I really need those for my projects(I know nothing of qc!)

Bye 

1. Custents

http://www.quakewiki.net/quake-1/mods/custents-custom-entities

http://wartrench.telefragged.com/

This is a custom progs.dat called custents. In the download, there is a doc folder with an index.htm. Please look at that in a web browser and read the descriptions of the new entities.

There is a camera entity, an actor (npc), and sound playing entities that can be triggered.

It also comes with example maps.

2. Extras

http://quake.chaoticbox.com/downloads/extras_r4.zip

That is another custom progs.dat which also comes with a lot of documentation. I don't remember if this one has cameras. Has example maps as well.

3. Zerst�rer

http://www.quaketastic.com/upload/files/single_player/mods/zerdevkit_gbpackdit.zip

And this last one is the Zerst�rer progs.dat, source etc. Please read devkit.txt, it tells you which entities to use and how. You should be able to do the same kind of cutscenes that you see in the mod, Zerst�rer. I found this on my disk.

4. Quoth

Quoth has sound playing entities, but no cutscene stuff.

5. RMQ

I will create a webpage soon that explains how to use RMQ as a mapping toolkit. It has very nice cameras that can lerp from one to the other, rotate and be daisy chained etc.

I think we will release the code (and progs.dat) either with the next demo or at least around the same time, I hope it'll be before the end of this year.

There is an older progs.dat at the RMQ blog, but the cameras aren't so advanced. I advise against using that.

Take a good look at custents and extras, please. If you still have problems after doing that, contact me and we might be able to solve them. 

i have a feeling your advice is kinda wasted on this guy... 

good times.... ^_^

looking back... man, i had like no idea what i was doing. it was also the least quakey of all my maps. :P

hm... i believe nostalgia mode has been activated... 

Making mistakes is a required step of the learning process. Let this guy make his. 

don't know the exact terminology for this, but essentially, bmodels are attached to vis areas to determine whether they are visible or not. if the player can't see any of the vis areas that the bmodel it attached to, the bmodel isn't drawn.

essentially what happens is that the rotate_object is somehow linked to the vis area at the origin and not with the vis area that the bmodel is actually located in.

so you get a rotate_object that flickers in and out of existence (or just plain isn't there if the '0 0 0' vis area is never visible).

i've learned a little more since the last time this happened to me and i know that using setorigin() on an entity 'links' it back into the world visibility or some-such.

so i open up the code and add a new line to the rotate_object function:
setorigin(self, self.origin);
this should link it in.

didn't work.

the other thing that plays a part in visibility is the bbox of an entity. so i put in:
setsize( self, '-512 -512 -512', '512 512 512' );
an arbitrary, very large, bbox.

ok, so it works now. yay!

but WHY?

rotate_object already sets it's size to self.mins and self.maxs. this works for 99% of rotate_objects that are made. why is it that occasionally i need to reset the bbox to some other value to get it to work?

is this a qbsp problem maybe? how does the engine first load up things like mins/maxs? it it precomputed or does the engine figure it out the first time? 

about coding, but could this bigger setsize not be the total of the start and end position? 

Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior. 

Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior. 

I would suppose that in order for the object to be visible one of the two must be true:

A) The bounding box must be large enough to fit the object at every point in its rotation.
B) The original bounding box is visible from every place that you can see the rotating object

B is what happens most of the time - although what might be termed a bug in the code is present, it doesn't manifest itself. In B I'm using visible in the sense of 'being in the engine's PVS', but 'see' in the sense of it being rendered for the observer.

For example, if you create an hour hand pointing to 1:30 in it's rest pose, the bounding box might be a square running from 12 o'clock to 3 o'clock. Then imagine you load it in game and move the hand to 7 o'clock. The bounding box does not rotate, so the hand is now completely outside the box, in the opposite quadrant. However it is still likely that in most places where you can see the 7 o'clock mark of the clock face, some part of the original bounding box is in the 'potentially visible set' that the engine gets from VIS.

I'm sure that in any case where the visible object can leave the original bounding box entirely, you can construct a point on the map where you can experience the bug. However, in most circumstances the rotating object is almost off-screen itself, and so it isn't apparent. Objects where their info_rotate lies some way outside their bounding box are much more susceptible to this. It's also worth noting that rotating your viewpoint can change what the engine deems visible.

So B is basically the usual situation, the bug is there all the time but by-and-large we get away with it. Setting the bounding box to some very large size moves us into category A - the rotating object never leaves its bounding box so no rendering bug can occur. We might ask how small can we make the bounding box and avoid the bug, both to keep overdraw down and to ensure that we do catch the entire size.

If we calculate the maximum of vlen(self.maxs) and vlen(self.mins) and call that x, then set the size of the bounding box to be '-x -x -x' to 'x x x'. This is sufficient and necessary, since we've found the furthest point from the rotation origin our object could be, and then created the smallest cube which contains a sphere of that radius.

Of course, this is only as optimal as a static bounding box can get. If the engine were to recalculate bounding boxes based on rotation then we would be home free. Since the engine doesn't bother, I wouldn't want to begin considering doing it in QC... 

Can someone please explain to me how that works - I'm getting a little frustrated here. I have a shootable button in a recess on the upper part of a wall small room. Shooting rockets at walls and floor doesn't affect it. However, there's a monster in front of it which somehow transfers the rocket's splash damage to the button. Or at least doesn't block it. What do I have to consider here? 

> Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior.

I think this is it. I'm pretty sure that was fixed in RMQ, probably DirectQ, Proquake etc. a while ago, I remember it being called the flicker fix or flickering bmodels fix. 

What do I have to consider here?

Splash damage against BSP objects is meted out based strictly on a traceline between {the midpoint of the entity's mins and maxs} and {the origin of the blast}. Monsters (strictly things with FL_MONSTER) are ignored by the traceline. If the trace_fraction equals 1 or the trace_ent is the BSP object in question then damage is inflicted.

I'm guessing that normally the centre of mass of the button can't be traced to, but that when hitting a monster the explosion gets a clean line of sight at it (ignoring the monster itself which doesn't count for these traces). 

Makes sense. Moving the button further into the wall fixed it. Maybe I just expected too much of Quake's physics. 

Oh why, oh little cuboid light fitting, oh why do you taunt me so? How can there be 300 more vertexes when you are a func_illusionary, oh why? 

Could be it has a huge bbox and touches too many vis leafs, this plagues large func_walls also. This problem has not been fixed in fitzquake yet as I don't know which numbers control that behavior.

i can confirm this has a high likely hood of being the problem as i just ran a quick test with the rmq engine that was release a few days ago and the problem isn't present.

thanks for helping clear this up for me. :)
the actual bbox dimensions that the engine was generating for the bmodel must have been even larger than 512^3. 

ditto for DirectQ.