yeah you got a bunch of "nans" on some texcoords for some reason - grab a fixed file here (i've just zeroed the nans, so you have to redo the texcoords on the affected brushes)

https://drive.google.com/open?id=0B74rZcw0hvZpa3U4dTEwLXk1WkE 

I'm pretty sure SleepwalkR would be grateful if you reported it as an issue on the TrenchBroom github page: https://github.com/kduske/TrenchBroom/issues

By the way, were you using Valve format (I can't tell from the map file you uploaded)? I ran into an issue with "nan" unexpectedly appearing in my texture coordinates; sounds like it may be the same issue:
https://github.com/kduske/TrenchBroom/issues/1069 

Ok, I get try to do it with careful.
In my case I using kurok, The files for the Progs.scr Needs to be in the same directory? Adding for example duck.qc to qc directory. 

Thank you! SleepwalkR also provided me with a clean file. The problems seem to have occurred when I duplicated some brushes. I'll have to do some experiments to see why it did that. 

The simplest way would be to add things like objects before the misc.qc and monsters after the ogre.qc. That's for the compiler you're using. Not had much trouble with it as long as the objects you're placing are standalone.

As soon as they become related to eachother, let's say the monster needs a weapon.qc tribute that isn't there you have to add it seperately.

I'm placing trees so I add a tree.qc just before the misc.qc and make sure ther's a tree.qc with the message for the corresponding tree.mdl.
Then it goes fine. 

But I edit the misc and weapons qc's for seperately? Or it creates the defintion in weapons.qc by default? 

I lost some ammo, I just need to study about qc? 

I add hipscor.qc and wrath.qc to a same progs.scr.

While doing that there are defs in both qc files that won't fit with eachother.

org duplicate definition ignored
Here you have a def of two shotgun types that can't go along with eachother so you have to hussle wich one does fit.
You can click on the green definition to show you where both definition misargue.

In this case you'll need to define new arguments for the TE_Explosion, ammu_shells1 rockets cells.

It's rather kinky stuff because as soon as you find the string another one starts calling.
I spend months to seek the head type the gremlin uses for the weapon change trick.
Couldn't find it as it is integrated throughout whole the code. 

which mod is wrath.qc from? 

 

thanks 

ok 

in side of defs.qc or the side of items, world, misc.qc? 

carefull. 

Is not in progs.scr, so not... 

you downlaoded the hipnotic zip,
you unzip the qc.zip,
you'll find the package with the progs.scr
if you read it with an editor it ends up with the hipnotics.qc entities.

That is if you have the hipnotics.zip 

My progs.scr looks like this, but is not finished yet

../progs.dat

defs.qc
hipdefs.qc

frikbot/bot.qc
frikbot/bot_way.qc
frikbot/bot_fight.qc
frikbot/bot_ai.qc
frikbot/bot_misc.qc
frikbot/bot_phys.qc
frikbot/bot_move.qc
frikbot/bot_ed.qc

subs.qc
fight.qc
ai.qc
combat.qc
items.qc
hipitems.qc
weapons.qc
world.qc
client.qc
player.qc
monsters.qc
doors.qc
buttons.qc
triggers.qc
plats.qc
misc.qc
hipmisc.qc

ogre.qc
demon.qc
shambler.qc
knight.qc
soldier.qc
wizard.qc
dog.qc
zombie.qc
boss.qc
hipgrem.qc
hipscrge.qc


tarbaby.qc // registered
hknight.qc // registered
fish.qc // registered
shalrath.qc // registered
enforcer.qc // registered
oldone.qc // registered2


Where I put the hipmodels.qc? 

Be aware that the progs.scr is only the script that the compiler reads before starting compiling.

What I see is that you made a sommon of the qc files before knowing if they even will compare.

If you ask me where to put the hipmodels.qc you're already going with the hipgrem,hipscrge,hipsmisc,hipitems.

As you're not common with the qc files I would suggest first to compile the SoA progs.dat to see if the outcome goes well.
From there you can add new qc files to see what will happen. 

How do I do that?

What trigger type the button has to be, and what type the wall/door brush has to be. Door acts like platform/elevator but it lowers only ones and stays there (wait -1). I haven't figured it out yet. Hopefully someone is more experience with this subject? 

The best option is to use a func_button, because it lets you use the button textures which change when the button is shot. func_button is quite simple to set up, you just need to set "target" with the same value as the "targetname" on the destination entity.

You got it right using a func_door for the moving wall. If you want it to move back up when you shoot the button again, Try applying the TOGGLE spawnflag to the func_door, and see if that helps. If you want it to close automatically after some time then set "wait" to a positive value. 

And for the button to be shootable it needs to have "health" set to some amount. Setting it to 1 is usually good unless you want the player to have to use a lot of ammo to "kill" it. 

Tragedy!

I sealed my map to test vis times and so on, and suddenly my light tool started to crash!
I'm using ericw's tyrutils v0.15.5, I tested with the original tyrutils and there was no crash.

Here's some evidence, if it helps anyone:
http://puu.sh/pXDTr/40c285c6ce.zip
http://pastebin.com/L7Vtx2m7

The zip file includes two versions of my .map, one which is unsealed and doesn't crash, and one which is, and does crash. There are also pictures showing what I changed.

The pastebin is an example of my console output when running qbsp.exe and then light.exe. When it reaches the "2." point, light.exe crashes, as shown in that log.

Does anyone have any advice on how to fix this? I've tried sealing the map in various different ways around there, which has lead me to believe it is not that specific spot that causes the crash, but rather some issue with the sealed bsp as a whole. 

... we have found a lost soul.. So repent sinner, repent !! And read the Holy Quake Mapping Bible...

http://web.comhem.se/bjp/tooltips.txt

Hoped it helped :) 

I don't think that covers a complete crash of the light.exe