on the rubble model; It could be a number of possibilaties. It may need to have the fullbrights removed or the skin isn't covering the entire surface. Also if any of the surface normals are facing the wrong directions it could appear to flicker while in movement. Any of those problems can be corrected with a basic Quake modeler like MDL. 

I have the rubble models in qME and I want to change the texture to match the wall that the exploding wall is in.

How can I overlay the city8_2 texture on the model? I have Adquedit, qME and I got Photoshop at work.

Does anybody know of helpful sites for these old programs? 

I did not understood the flicker problem at first time. I was looking at it with quad damage and it not flicker with normal looking. So OK now. Thank you for helping. 

In my rest time I used the company Photoshop and made new model skin.

I exported the new texture from TexMex in BMP
I exported the old skin from qME in BMP
I imported them two into Photoshop using layers
I changed the Mode to RGB and erased the old skin leaving the new texture to show through
I flattened the layers
I changed the Mode to Indexed
I saved it as BMP
I imported it into qME
I changed the old skin name to skin1
I changed the new skin to skin0
I saved the model into the program folder and run Quake and it works so now some of the rubble bits look like the wall that just exploded.

Now I get back to work and change the more rubble bits tonite. Is this the right way to change skins? 

Sounds like exactly the right way - good work. 

I am now using txture Rock1_2. When I import back into qME I see lots of black pixels that were not in Photoshop view.

When I convert back from Photoshop RGB to Indexed my selections are Palette: exact, Forced: none, Matte: none. Are some of the colors changing somehow in my converting and qME thinks they are not Quake colors so just gives those pixels black color?

I was happy hugging the trees and now I boot them. 

modes with Photoshop have always given me a lttile fuss as well. I would suggest exporting in RPG and using Wally or TexMex (which is the simplest of the two methods as it does the conversion automatically; I like touching things up in Wally though) to convert back to Quake 16 bit indexed.

The root problem could very well be that Photoshop is defaulting the RGB mode to 24 bit though, in which case, instead of my above suggestion, convert the 24 bit RGB to 16 bit RGB and then convert it to 16 bit Indexed. The translation should be smoother. 

This works all the time for rubble bits:

export skin from qME - this is automatic BMP file
open in Photoshop - this is automatic Index Mode
change Mode to RGB - this is automatic 8 bits
copy to new layer
delete Background layer
Magic Wand in black area - Tolerence 0, Anti-alias off
Inverse selection
press Delete - this is the mask
deselect
export rubble bits texture from TexMex - use BMP
open in Photoshop - this is automatic Index Mode
change Mode to RGB - this is automatic 8 bits
use Move tool to drag texture into mask window - this opens as a new layer
swap the layers around - this puts the texture under the mask
Flatten image
change Mode to Index - Palette: exact, Forced: none
save as BMP - File Format: Windows, Depth 8 bit
Import into TexMex
do nothing - maybe drink coffee
Export as BMP
Import into qME
Save model into Quake progs
Play Quake

Time to work this out and type this 25 minutes
Time to do it now I know is 4 minutes each rubble bit

Thank you HeadThump 

The exploding wall entity calls a function that starts a new entity (local entity new) that uses setmodel to define the rubble bits models (setmodel (new, "progs/rubble1.mdl");). I can set the skin of the exploding wall entity in the editor. I can read setting from inside the function but this is not the rubble bits so the rubble bits skin will not change yet.

How can I set the skin of that rubble model using the skin setting that I bring in from the exploding wall entity? I think like this - rubbleskin = self.skin and then set the rubble.mdl to use the skin rubbleskin. rubbleskin will be a number 1 to 4 being textured rock(1), wall(2), wood(3) and metal(4)

I try various self.skin = 1, new.skin = 1, to test the setting of the skin but get errors like - Error wall QC(17): expected;, found new.

new is the name of the entity that has been made to create the rubble bits and is the first part of the line after self.skin = 1

I hope you understand this Preach or HeadThump? 

...it just seems you forgot to terminate the line above with a semicolon; 

Dohhhh. I am the dopie one.

It now works as I wanted. No tree hugging now as my girlfrend has suspisions.

Thank you czg. 

Can you explain why these are two separate functions and not all in one? Is it needed because there are more than one ogres in a level?

void() monster_ogre =

void() monster_ogre_set =

And what is void() monster_ogre_marksman =

please? 

Normally in quake the two functions monster_ogre and monster_ogre_set are just one function. They are seperated out for the purpose of the teleport code. This way, when the server starts, the monster_ogre function is called, and decides if the ogre needs to be spawned now or later. It does the precaches now, because everything has to be precached at the start of the server.

Monster_ogre_set is called either straight after monster_ogre for a non teleporter, or when the monster teleports in. This part of the code is seperated out so the monster is non solid and invisible when it hasn't teleported in. If the monster isn't a teleport monster, the code behaves exactly the same as if the two functions were one.

Monster_ogre_marksman is a monster that ID was originally going to make different to regular ogres, but then decided to make all the ogres the same. Rather than replace all the monster_ogre_marksman entites with monster_ogre in the maps they'd made so far, they just made it so both of them do the same thing, spawn a regular ogre. So basically it does nothing. 

Ogres will infight if they are marksman/not marksman. 

using different classnames like you describe will break the monster obituary code (unless you fix that, too.) 

How do I first of all get the texture wads to work for qeradiant 1.5 for q1? The new radiant should "support" q1. Is there someone who uses this? There's very little documents in the net. :(

Or do I have to do _everything_ q3-style (meaning all the scripts and tga's and whatnot) and just compile the resulting intermediate files to q1 bsp's with aguirre's tools? 

All of your wads have to be in Quake/id1/

Easy as that. 

bambus, I suppose you're talking about gtkradiant 1.5? Make sure you go in under options and point your filepath to your quake directory. 

I'm mapping for Enemy Territory Fortress (www.etfgame.com), which is a mod for Enemy Territory, which uses the Quake 3 engine. I've got a target_speaker that I want to have on and looping at the start of the map, turn off while a particular info_notnull is active, and turn back on when the info_notnull becomes inactive after 30 seconds.

My understanding of target_speakers is that they can only be "triggered" which toggles their state from what appears to be "play" and "don't play", except just triggering the target_speaker using activetarget and inactivetarget from the info_notnull does not work correctly for some reason. The sound starts at map start, then shuts off when the info_notnull is active, but then it never comes back on again.

I've tried implicitly setting the target_speaker to ~active/~inactive, ~active/~disabled, ~inactive/~invisible, and pretty much any other combination that seemed to make sense, but either the sound plays at the exact opposite of when it is supposed to, or it works for the first activation and then never again.

Anyone have a breakdown of how to implicitly control the states of target_speakers? 

what it was,
AllocBlok:full

argh.... 

I'm not sure, but I know someone who might know, so hold tight, and check back in about 6-12 hours :D 

Thanks Blitz, it helped. But I'm sorry, I still have problems. Now I can texture fine in the editor, but the resulting .map file has no references to the used wad file (I checked it with a text editor) and thus the compile fails to put textures in the bsp (although it seems to work otherwise).

The settings menus are really spartan and there's very little documentation about q1 mapping.

I guess I could add the wad references by hand but it's a hack.
How are you doing all this? 

a better way of doing this in Radiant, but using my compilers, you can have a wad with the same name as the map file in the same dir (so called default wad). The compiler will use that wad if no wad key exists or the referenced wads can't be found.

You can also use wild card specifications in the wad key (e.g. "mywad.wad;*.wad"). 

Does anyone have a (preferrably small) Q1 demo file that is corrupt or otherwise unplayable in standard engines (e.g. FitzQuake)? I'd like some test material for a new demo conversion/validation tool. 

Add the wad information to your map's worldspawn with the following key/value:

"wad"
"c:/blah/textures.wad"

Unless you already did this and it still isn't working, in which case I'm not sure what's up :/


Also: the line length limit on this forum is a fucking joke.