Hi all, how do I make a func_door that does not get blocked by a player/monster? (i.e. just keeps crushing without going back) 

http://celephais.net/board/view_thread.php?id=4&start=17910&end=17914 

i dont understand this.

why cant i compile?

http://imgur.com/a/9UTvn 

Impossible to tell. Check the compiler .log files; presumably QBSP failed for some reason.

By the way, you run VIS with either -fast or -level 4, not both in the same command line. Fast is for testing, level 4 is precise one for release. 

Thanks! 

i dont have any 

compiling is very difficult... 

compailing is very difficult 

i had to reboot into windowa so i can compile 

Since there are many new mappers here - I recommend doing some research on basics of compiling a map.
This may be a starting point. BJP's Q1Tooltips and his Vis readme contain some useful information for troubleshooting and general knowledge, too.

I'm posting this, because in recent releases I noticed some levels were leaking and/or unvised or only fastvised, and that may have been due to a lack of understanding and possibly the uncritical use of compiling GUIs or in-editor scripts. Maybe run each of the tools in a command prompt window at least once to see what happens, or look for log files in the corresponding directories, e.g. qbsp.log. I'm critical of GUIs and script for reason that there's a risk of them swallowing important warnings and error messages which then go unnoticed for the unaware user.

On leaks/VIS: the basic idea is that a map must be air-tight, completely sealed off to the "outside", otherwise QBSP will report a leak. Another way to recognize a leak is by noclipping outside of the level, and if you can't see the interior but instead the backsides of the outer walls, you know something's wrong.
In this case, QBSP will generate a .pts file. When placed alongside the .bsp in the maps directory, you can use the pointfile console command to display a dotted line leading from towards the leaking spot. Some editors can load the .pts file as well. When located, it can be plugged; usually it's obvious and straightforward, though occasionally it can be quite obscure. More often than not a map has several leaks, so you may have to repeat the process.

Once the map is properly sealed, and only then, QBSP will generate a .prt file. It contains information on the vis portals the level is made up of, so to speak. This file is required for VIS to calculate the visibility of the world ('what is visible from where', so the game doesn't have to render the whole map at once)- without it, VIS cannot run.
There are two command line switches for VIS that matter here: -fast which does a quick but sloppy calculation used for testing purposes, and -level 4 which runs a slow and precise calculation = the one you must use for the final release. Depending on the size and structure of the level, this can take a while (although with multithreading tools and detail brushes, it's not much of a problem these days). A fullvis is important. Don't listen to people saying it's not because modern systems can handle it and so on!

To get an idea about how it works, you can check in game: using Fitzquake or Quakespasm, load one of the original maps and type r_showtris 1 in the console, then walk around and see how stuff appears and disappears if it's sufficiently blocked by other geometry.

By the way, the .vis file is just an autosave of the current state of the VIS process (because you can stop and resume it if necessary). After the job is done, the file is useless. Don't include it in your release. 

by Bengt Jardrup, v0.19 Jan 12 2007

Almost 10 years! 

I know I know... don't shoot me.

VIS's only function is to make a map play "fast"/smooth right? Meaning, have the best frames possible. But with PC's today, even my old rig here, all levels typically play fast.

One night at Gotshun's we were looking through some of the large levels and were surprised to see quite a few had no VIS at all. Or at least "showtris 1" didn't show that anything was being removed/hidden from view.

This is why I ask this question. Is there some other benefit?

OFC, there's no ambient sky and water without at least running -fast(true?). 

Ignoring world polys for a minute, I think only having to deal with the entities that are in the PVS has a big benefit - a coder should be able to explain better. 

Don't be ridiculous. With proper mapping and use of func_detail, full vis will take seconds on a map that would have otherwise taken months.

Nowadays light is an exponentially bigger bottleneck in compiling than vis. 

http://celephais.net/board/view_thread.php?id=61178&start=68 

DarkPlaces doesn't support per entity alpha unless the progs supports the field

Here are pictures of the map petes1, which I believe you are familiar with ... and these pictures show the lack of translucency ...

DarkPlaces October 2016 build | DarkPlaces January 2017

Possibilities:

You have something in your Quake folder you don't realize. DarkPlaces reads every single pak and pk3 in your Quake folder regardless of the name, and will load any free floating file sitting around.

Plus there is an extra Windows directory under "Users" where something could have downloaded and it'll read from there too. 

I thought the last dp build was from 2014? where can I find these later builds? 

Here's my test DP's Quake and id1 directories:

http://imgur.com/a/1bVeR

pak2 is simply the watervissed maps and pak3 is mine which is simply a different console background.

I have no clue why it works for me, strange. Sorry if I've misled anyone. 

https://icculus.org/twilight/darkplaces/download.html
The links under "Latest development autobuild release (updated every 6 hours)" 

I checked the size of my pak0.pak(17.8 MB | 18,689,235 bytes), it matches what is in the QuakeWiki(1996-10-01 14:25:58 18689235). 

thanks, hidden in plain sight :P 

Don't know. Being the master of your own Quake folder is something everyone personally has to bring to the party. ;-)

Keep in mind Bloughsburgh asked why DarkPlaces doesn't support entity alpha for stock id1.

Why would he make that up?

/If you see what I mean there, haha ;-) 

That being said, I did some more tests and there is some sort of X factor going on here.

Perhaps something not well known about DarkPlaces.

I did a rough test with an external .ent file and it worked. But petes1.bsp doesn't?

So something strange or not well known is happening? 

Baker:Keep in mind Bloughsburgh asked why DarkPlaces doesn't support entity alpha for stock id1.

Why would he make that up?


Bloughsburgh:damage_inc: Ah there we have it...my issue is happening with func_illusionaries...I actually do not have any func walls using alpha.


He wasn't making it up.

IIRC, petes1 works as intended in QS but the brush settings are to subtle then for DP's. I to thought it didn't work, as well as someone on here, I forget the name of the person... but it does.

I'm not trying to be argumentative and hope it doesn't come off that way. I just want to know ;) 

I did some more tests using external .ent files.

And entity alpha does seem to work in DarkPlaces?

Yet petes1.bsp doesn't? Not even when using Quoth.

So ... perhaps you are correct or there is something missing piece of information that would explain this?

I do know that historically DarkPlaces required an alpha field in the progs.dat to support alpha, which is one reason mods like Quoth have that field.

But apparently this has changed, and I get that because that's just the nature of engines adapting.

But I don't understand why it isn't being consistent.

+1 mysteries of the universe.

Looks like damage isn't insane and is in fact correct.

Baker's example may be correct and should show entity alpha, but doesn't but perhaps for different reason than the current topic.

Then again we still have Bloughburgh's example?

Conclusion: Hell if I know!!!