#13173 posted by ALLCAPS on 2013/08/30 01:08:38
Good to know. Thought it was my fault!
Tyrqbsp
#13174 posted by ijed on 2013/08/30 03:39:03
Has a newer version in testing at the moment with a lot of fixes and improvements.
Rebb�s Jury Rigged BJP Tools
#13175 posted by mfx on 2013/08/30 04:03:09
are youre choice at last...
Rotate Info
#13176 posted by mechtech on 2013/09/01 21:09:55
would something like this chart and an explanation be helpful?
The rotation stuff seems under used and understood.
http://www.mediafire.com/view/57cfzc2e615m5z9/testchart.jpg
Gameflow Study
#13177 posted by Qmaster on 2013/09/03 04:00:29
I'm getting charty with it!
I'm starting to do some data analysis tests for Quake gameplay. I've done a first run through of one of my old favorite maps (hip2m2 if your curious) to get an idea of some basic ideas.
https://www.dropbox.com/s/c6kcbe24129idf1/BlackCathedralStats.jpg
I'm attempting to create generalizations about the basic gameplay elements over time. This is only the results from one study, but I had to pause to write the data down every interval. Also, copying the output from the console is tedious if I were to try to improve the collection method by outputting the data every 30 or 60 secs to the conole. Is there an engine that supports exporting data in this manner? Maybe in the save file?
I can make some generalizations though (still this depends on play style and it would be nice to have others input their data for this study). Kills over time is almost perfectly linear at about 12 kills per minute or 5 seconds per kill. Shells and nails maintain the same average (44 for this particular map), but nails varies much more wildly than shells (okay so I use them more but who wouldn't). Rockets maintained a very low average hovering around 10-15.
The linear kills over time is to me the most useful tidbit so far that I've learned and gives me a good idea of this maps pace, although being able to see the balance of everything over time like this makes me giddy. :D I love charts!!
Is there a better way to automate this?
#13178 posted by ALLCAPS on 2013/09/03 07:10:50
You could record yourself playing/take demos, and gather the data later. Never peeked inside a demo file before, possible it's in there and could be plucked out.
Lights
#13179 posted by flesh420 on 2013/09/03 08:54:52
I've created a map and everything is sealed, but for some reason when I play the map it's bright though the worldspawn brightness is set to default, which should be at 0. Can anyone help and tell me what's causing this?
You Have To Place At Least One Light Entity
#13180 posted by spy on 2013/09/03 10:06:58
otherwise it would completely fullbright
and don't forget to run light.exe
Qmaster
#13181 posted by Spirit on 2013/09/03 11:00:21
Use QW and then cokeman's mvdparser. You can specify what information you want in the output with templates. Should be possible to get pickups etc. from it.
https://github.com/JoakimSoderberg/mvdparser
I used it for https://www.quaddicted.com/tools/frag_heat_maps_from_mvd_demos
There are also tools for protocol 15 demos but I haven't found a user-friendly one. Will probably be investigating them later this month. The SDA guys should have stuff. Maybe http://speeddemosarchive.com/quake/qdq/tools/demtool.html
@flesh
#13182 posted by ALLCAPS on 2013/09/03 16:11:21
Are you using the newest tyr tools for light and vis?
It's possible VIS broke somehow. In Quake turn "r_showtris 1" in console and just make sure that the whole level isn't being rendered at one time, which may indicate something doing wrong at compile time.
This is assuming you're running light.exe and have some lights thrown about in the map, which is what to check first.
Thanks
#13183 posted by flesh420 on 2013/09/03 18:33:49
Ok thanks. Yea something broke and I got the idea to try different compile tools and that fixed it.
VIS Has Nothing To Do With It
#13184 posted by negke on 2013/09/03 18:56:16
It's like spy said. Light.exe adds the lightmap information to the compiled bsp provided there are light entities in the map.
Collision On Moving (blocked) Bmodels
#13185 posted by negke on 2013/09/03 19:03:36
If a moving brush entity, e.g. a func_train, is being blocked by a player or a monster, does this affect the behavior of other entities riding it in any way? Technically, it's still in a "moving" state, right? Would that impact on any active/inactive monsters on it, specifically their movement/AI routines?
Never
#13186 posted by ijed on 2013/09/03 20:17:09
Seen anything like that, especially with trains. Typically they affect nothing and nothing affects them apart from a direct targeting and the obvious movement of creatures placed on top.
The only oddity I've seen there is with dead monsters, who'll sometimes slide on horizontally moving trains, and doors.
It's possible however that a mover is doing damage to a creature (even if it's 0 damage) which in theory could interrupt / reboot it's state.
Just conjecture / vague memory though.
@metlslime
#13187 posted by sock on 2013/09/04 01:38:17
I am trying to get my maps to work with Darkplaces and I have setup all my bmodels (doors, buttons) with skip on their hidden surfaces. I have been using your newskip.exe program to move the skip surfaces around inside of the bsp, but strange things are happening.
Projectiles often fall through the bmodels with skip surfaces and traceline functions cannot recognize the objects anymore. If I compile without the newskip.exe the bmodels are all fine. I checked that the objects have the correct bbox and min/max setup but I cannot see what is wrong.
What exactly does newskip.exe do? I want to be able to explain to LordHavoc so that I can log a bug with him about Darkplaces and hopefully get the situation fixed. I really want to keep the skip surface function but I need to get more details. Can you help?
Sock:
#13188 posted by metlslime on 2013/09/04 02:20:22
basically skip tool will re-arrange the faces in the leaf or bmodel so that the skip faces are at the end of the list, then it changes the "num faces" count to be lower.
so if you start with this:
NumFaces: 6
Faces: A B C D E F
And B and C are skip-textured, you get this at the end:
NumFaces: 4
Faces: A D E F B C
So B and C are still included in the list, but won't get drawn because the engine will stop after drawing the first 4 faces.
Also the source code is included in the newskip archive, so Lordhavoc should be able to look at it in more detail if he wants to.
@metlslime
#13189 posted by sock on 2013/09/04 02:34:06
thanks :)
So That's How SKIP Works!
#13190 posted by Qmaster on 2013/09/04 04:37:40
I thought it deleted the faces. That explains why newskipped bsps when loaded into another map as a .model still render all of their faces even when loaded by themselves they don't render. (Yeah I was playing around with the idea of instancing (you know like source engine!) multiple bsp's which works almost perfectly but would be absolutely horrid for performance in my case since skipping doesn't work. That and you get fireflies between mating surfaces of zero thickness (think tri-soup where two brushes only share an edge));
Wait...
#13191 posted by Qmaster on 2013/09/04 04:39:56
Wait how does the engine render entity .model's like for monsters and brush entities? Is there a way to have a skip utility that causes certain faces of a bsp to have the pink index color of transparency applied to them?
Skip
#13192 posted by Tyrann on 2013/09/04 06:12:14
The latest tyr-qbsp removes skip surfaces completely during compilation (instead of hiding them at the end of the surface list) in case that helps.
Qmaster...
#13193 posted by metlslime on 2013/09/04 07:33:41
Interesting, I didn't consider that use case when creating the tool. It should be possible to support it, though tyranns new absolute kind of makes my tool obsolete.
Correction:
#13194 posted by metlslime on 2013/09/04 07:35:20
"Absolute" should read "qbsp" -- cursed iPad autocorrect
Sock
#13195 posted by negke on 2013/09/04 09:23:13
Darkplaces doesn't treat skip surfaces as simply tranpsarent faces by default like normal engines. Instead, to DP it's pretty much like they aren't there, so shots pass through and they don't block visibility. Check the sv_gameplayfix_q1bsptraceline* cvars, they can revert this behavior.
#13196 posted by necros on 2013/09/04 14:56:02
i wish skip worked on external bsps. that would be radddddd
#13197 posted by Spirit on 2013/09/04 15:09:24
Sounds like tyr's does?
|