|
It's A Cheat
#12313 posted by ijed on 2013/01/03 13:55:23
But why not add the blood trail flag to the gibs it fires? It won't bleed when hit but will splat when destroyed.
Loading Quoth After Loading Engine
#12314 posted by than on 2013/01/04 04:17:10
I know you can run a mod using another mod as a base using e.g. fitzquake.exe -quoth +game warpspasm, but is there a way to do that from the console?
#12315 posted by Spirit on 2013/01/04 09:36:05
No.
Strange Marksurfaces Problem
#12316 posted by RaverX on 2013/01/06 18:10:27
I'm working on a map, the problem is that I've exceeded marksurfaces limit, the map will run, but I want to make the map "standard" (it's an experiment, I want to use default Quake textures, respect standard limits, etc).
I've deleted some details, so I managed yo get from 32.893 to 32.237, but I need to go lower because I need to add some areas to connect some parts of the map with other parts.
So I started to delete small rooms and I had a huge unpleasant surprise. I deleted a small room behind a wall, it's a very simple room, but still... it has 4 walls, floor and ceiling, plus the entrance to the room is a digger made in the wall, that should take quite a few marksurfaces.
I was hoping in a nice drop, but marksurface went from 32.237 to 32.275. Jow is that possible? That room is completly isolated, the only area that connected the room to the map is a wall...
I work with Quark.
Any suggestions?
From Experience...
#12317 posted by Fern on 2013/01/06 18:18:22
are all (most) of the vertexes on the grid and none (few) of the brushes penetrating each other at weird angles?
I had similar problems with dom3m1 (deleting simple architecture that wasn't even touching anything and having it destroy the entire map) and it really all came down to being lazy and not respecting the grid.
As negke could tell you. :P
Off The Grid
#12318 posted by RaverX on 2013/01/06 18:26:04
Yes, thanks for the very fast response. Unfortunately I started the map back in 98, I even finished the map (but it was a simple DM map and it was quite ugly). Almost everything in that map was off the grid and instead of starting again I continued that map.
But I still cannot understand, it's beyond logic how deleting a room behind a wall will increase the marksurfaces number.
I understand that the compiler will "break" the "walls" into smaller "chunks", but it's only a simple wall that has a digger cut into it (deleting only that digger should decrease the marksurfaces greatly). And then there's the entire room behind the wall.
Weird, very, very weird :(
Basically...
#12319 posted by Fern on 2013/01/06 18:35:24
The more floating vertices and odd intersections your map has, the more desperate measures qbsp needs to take to make it presentable. In every case, you're basically giving the compiler a rubik's cube and saying "solve this" and your .bsp file will always be the programs saying "I did the best I could!"
While on the subject, you should be happy a weird marksurface count is all you have to deal with. I had to delete two torch-holders THAT WEREN'T EVEN TOUCHING ANYTHING because somehow having them float there in the middle of the room made compile time jump up 5 hours, outleafs drop to 0, and the map unloadable
Incidentally have you tried lighting the map yet? Because I think I'm still the only mapper to build something with such horrible brushwork that running tyrlite on it literally broke the hull.
Lights
#12320 posted by RaverX on 2013/01/06 18:44:36
Lights are there (except a few tunnels that are still "pitch black").
I think I understand what you are trying to say, but it's still very frustrating for me.
I just tried something else, I've deleted the "entrance" to the room by deleting the digger, the room is still there, the compiler didn't elimiated it because it has a light and a weapon inside, marksurfaces dropped from 32.237 to 32.228.
But if I delete now the cubic room (4 walls, floor and ceiling) will make the marksurfaces go up to 32.275.
If anyone has any other suggestions or ideas, please let me know.
Thanks.
I Call Them "Mocksurfaces"
#12321 posted by negke on 2013/01/06 19:01:50
Because to me it seems like the compiler randomly changes the number to make fun of me.
Optimizing a map to get under the limit can be a real bitch - especially since the behavior doesn't seem to follow logical patterns.
You saw it yourself, removing or simplifying stuff sounds like it should lower the count, but in reality sometimes it actually makes it rise. In my current map, for example, I had the strangest actions affect the mocksurfaces: moving a door one unit made the count jump up by 100, when moving it by two units it remained the same as before; or even better, at one point I could influence the count by, I don't know, maybe up to 300 points simply by moving the monster teleporter room up and down by a couple of units. Weird shit. The position of the brushes in the map list (old vs new) also affects the outcome.
In consequence, I don't really have a definite suggestion on how to effectively lower the count. Try the usual measures first - turn details into funcs etc, simplify walls (e.g. make new textures that have wall+trim) etc.
#12322 posted by necros on 2013/01/06 19:05:02
marksurfaces are a different thing than just vertices or faces so deleting stuff does not always reduce them. I don't really know much more than that though.
Stock engines can run a map with slightly higher than max marksurfaces, iirc.
#12323 posted by negke on 2013/01/06 19:05:20
The room you just deleted, see what happens if you copy/paste it to the top of the .map in a text editor. Long shot, but it's really a matter of clutching at straws for a good part...
#12324 posted by negke on 2013/01/06 19:10:19
Also check if there are walls made up of multiple brushes (in the same plane) with the same texture but different offsets, e.g. from copying or moving with texture lock. Often barely visible, but QBSP treats them as individual surfaces instead of a single one.
Hulls
#12325 posted by RaverX on 2013/01/06 19:16:19
Thanks negke, I feel a little better now. Fern said something about hulls, I must admit I don't know what are those, but checking the Quark log I assume that my map is split somehow in 2 hulls
------ GrowRegions ------
Processing hull 1...
----+----+
----+----+
Processing hull 2...
----+----+
----+----+
Looking at the map I see that it seems to be split in 16 zones, check the screenshot here:
http://www.abload.de/img/mapogyqh.png
So I thought to move all the map to the left to have the map in only 8 zones. If I cut a little from a long tunnel I could get it much better, only to one "zone".
Anyway, the first step was to move it only to the left a little (selecting everything and pressing left arrow a lot of times, keeping everything to grid).
But the map didn't compiled at all after that, I get
SubdivideFace: Didn't split the polygon near (-1920 1536 488), tech14_1
I encountered that error in the past when making long thin polygons, I only needed to scale the texture to get rid of the error.
Now I see the error after I "move" the map in editor...
Anyway, back to the question: what is a "hull"?
I noticed one time in the past that if I use noclip and I continue to move forward I end up soon in the "back", like I woul be teleported somehow. Does that has anything to do with the "hull" concept?
#12326 posted by negke on 2013/01/06 19:28:59
The engine uses the three hulls for collision. See here for a short explanation.
This is largely unrelated to your marksurfaces problem.
The zones are only a visual addition in the editor, the map doesn't need to stay within a zone for better results. Having said that, with all the weirdness surrounding the marksurface mystery, moving the entire map could potentially affect the count, for better or worse. The SubdivideFace error could be related to the texture lock messing up some offset perhaps.
On the editor shot, the level doesn't look very large, so I'm a little surprised you hit the limit already. Or does it only seem that way from that persective?
#12327 posted by negke on 2013/01/06 19:33:50
As for suddenly ending up on the other side when noclipping in one direction, this is because the standard bsp format only allows a maximum world area of 8192^3 units (+4096 to -4096 on every axis).
Map Size
#12328 posted by RaverX on 2013/01/06 19:36:32
Well, the map is not large at all, but it's made from many, many slim walls, it has a lot of "bars" and it's not optimised at all.
If I had to compare the map with another map (only regarding the size - "volume cubic meters :)), I'd say that it's about twice the size of E1M1, but it's much more cramped, there's a lot of little rooms and tunnels.
Because...
#12329 posted by Fern on 2013/01/08 08:48:38
<Perse|Fr3n> is there in Q1 a way to make messages print in the corner instead of the center?
<Perse|Fr3n> i.e.you got the nails, you got the silver keycard, you got the comandant's severed head
I know I can kill the object, trigger a sound, and use info_command "bf" to emulate picking up an "object" but I was wondering if, short of messing around in .qc, it were possible to also emulate the confirmation text one normally gets when picking stuff up.
ASDF
#12330 posted by Fern on 2013/01/08 08:50:38
forgot there was an echo command. problem solved. nevermind.
One of the reasons I dislike Fitz is by default it puts text messages over the crosshair rather than above it which is really annoying if you're fighting (also annoying are engines that don't print such messages into the console so if you miss it because you were busy/it was too long you can't reread it).
I dunno if it's changeable cause I just use different engines :P
#12332 posted by sock on 2013/01/08 12:56:53
One of the reasons I dislike Fitz is by default it puts text messages over the crosshair rather than above it
Just add a couple of '\n' to the front of your centerprint messages and they will appear below the crosshair and not be so intrusive to game play.
#12333 posted by Spirit on 2013/01/08 15:09:38
Don't they then end up in front of the crosshair of other engines?
Preach
#12334 posted by negke on 2013/01/08 20:08:15
And what is it with those missing door sounds ir_start.wav and ir_stop.wav (as well as er_) in Quoth?
Region Locked
#12335 posted by Preach on 2013/01/08 21:48:53
There's actually a fascinating history behind those sounds. They were only ever made available in the Japanese version of Quoth called ワタリガラス話す、殺された妻 (lit: speaking raven, slain wife). The Asian region release came with the construction kit along with arcade mode and a completely different model for the gaunt
http://tomeofpreach.files.wordpress.com/2012/12/horror.jpg
Sadly these files never made it into the European version, although for save-game-compatibility reasons the progs has to look for them...Or I screwed up and never noticed because they were sitting in the dev sounds directory outside the pak. Will you hurry up and ask for your copy of the 2.2 beta negke, you'd clearly be a huge asset to the testing!
Since Func_ Isn't Japanese Compatible Either
#12336 posted by Preach on 2013/01/08 21:54:36
Them Japanese Always Get The Better Releases....
#12337 posted by negke on 2013/01/09 19:47:45
Ok, why not (lots of reasons). Let me test the beta so I can play through all of those terrible unbalanced Quoth maps again!
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|