|
Vis Crash, Or Just My Imagination?
#5350 posted by Orl on 2006/09/23 15:39:40
Has anyone ever has vis crash while it was working? I ask this because, I have been full vising this one map for... 3 weeks now and it is still working on the same portal, for 3 weeks! I dont know if it crashed, or if its still working. And, would loading a map that has vis working on it disrupt vis, or make it crash or something? This is just getting ridiculous. I am using aguiRes latest utilites.
Orl
#5351 posted by Tyrann on 2006/09/23 19:43:46
If the map is complex enough, it is definitely plausable to be stuck on a single portal that long.
Orl
#5352 posted by aguirRe on 2006/09/24 03:10:08
Make sure vis is still running at full speed, check with Task Manager. Some OSs may pause the running application if you use the keyboard or mouse on the open console window.
It *is* unusual to be stuck in one portal for three weeks though, the longest time I've had was a few days. But so far it has always come through (at least on level 4).
How many leafs/portals do you have and how far has vis come?
AguiRe
#5353 posted by Orl on 2006/09/24 11:35:04
From what I see in the task manager, vis appears to be running. It's taking up 50% of my CPU, and every once in awhile its mem usage goes up by a few K. Sorry, I do not know how many leafs/portals I have in my map, how may I go about checking? But I will tell you, vis is at 61.61% done so far. And, is vis saving its progress while its working on this portal, or only in between portals?
Hmm
#5354 posted by aguirRe on 2006/09/24 12:14:02
Why only 50%, normally it should be almost 100, do you have a dual CPU?
#leafs/portals is printed at the first lines of the console/log file and you can also see it in the .prt file (just a text file).
Unfortunately, vis is not saving while working on a portal, only in between them. You can see the last save time on the file date/time stamp of the .vis file.
Also, there's a rough progress bar for slow portals, has it moved lately?
Yeah
#5355 posted by Orl on 2006/09/24 13:51:40
I do have a dual CPU, which is a good because I can do other things while vis is running. According to the log, I have 4500 portalleafs and 15354 numportals.
And that rough progress bar you mentioned, it started at "--". It has not moved since.
OK
#5356 posted by aguirRe on 2006/09/24 15:27:41
Then there doesn't seem to be anything obviously wrong, you just have an extremely unfortunate map from a vis perspective.
Either you'll have to sweat it out, or abort and try to find out what's causing this problem. You might want to try to add -v (verbose) and run again, vis will restart that portal.
My latest vis version will print out the coordinates for each portal *before* it starts processing it and you can then use this to find the portal.
The coordinates are taken from one of the vertices of the portal and should hopefully help you locate it. Just note that a portal can be very small or big, so it might be difficult to pinpoint it.
50%
#5357 posted by metlslime on 2006/09/24 22:14:46
Why only 50%, normally it should be almost 100, do you have a dual CPU?
I heard somewhere that CPUs with "hyperthreading" technology can't give more than 50% of the CPU time to any one process. At least I think that's what I heard; it's been a while.
Correction
#5358 posted by aguirRe on 2006/09/26 14:47:00
My latest vis doesn't print the coordinates for the current portal in verbose mode; it prints the portal number. You can then use that to find the corresponding coordinates from the prt file (see also readme).
All the vertices of the portal are visible on the prt file line for that portal.
You can even do this check while vis continues to run. Just copy the bsp/prt/vis files to another directory and start a new vis session from there with the -v option and abort when you see the portal number.
Metl
#5359 posted by aguirRe on 2006/09/27 04:15:21
I think that's just an indication issue; I read an article that also noticed this and they checked processing times and they were OK. Otherwise the hyperthreading tech is more stupid than it has any right to be ...
Invisible Faces
#5360 posted by negke on 2006/09/27 04:55:37
like this: http://negative.net.tc/images/fitz0004.jpg
how to get rid of them again? already tried changing the brushes, splitting them up, but to no avail. any universial remedy?
From The Shot
#5361 posted by aguirRe on 2006/09/27 05:53:01
it looks like either a brush problem (if it's like this before vis) or a portal problem. The cause is similar; bad brush junctions.
Zoom in close to see if they're on grid and also check neighbour brushes, sometimes a brush can "poke a hole" in another brush.
If you still can't find the culprit, try deleting neighbour brushes until the issue goes away. One or more of the deleted brushes are then the likely cause.
See also my ToolTips, Portal Problems.
If all else fails, send me the zipped map+wad and I'll take a look at it.
Shadow
#5362 posted by madfox on 2006/09/27 11:44:27
After another session of my Q1map I see the light.exe produce a strange effect of dark and black shadows on my textures.
I didn't move one light, and before they were all smoothly lightened.
If You're Using
#5363 posted by aguirRe on 2006/09/27 12:22:24
my Light together with QuArK and its ETP map format, you could try adding the -etp option.
Yes
#5364 posted by madfox on 2006/09/27 23:14:36
That helped a lot, I keep learning tnese compile optoins. Think I squashed the map by loading it in an older Quark version.
I have made a VoreBabe and a Vore-egg.
I've been changing the shalrat.qc so it throws vore-eggs. I also made a working VoreBabe model.
But I can't figure out how to make these two in a shalrat.qc The VoreBabe I made startgo with the Spellmaster.qc
So I pasted the Ogre_Grenade_Explode into the void() ShalMissileTouch;
and it worked, the Shalrat started to throw eggs. But I wanted the VoreBabes get out of them, and that is just to high for my qc.
When I give the eggs a lifetime of 4 seconds, for let's say 2 Vorebabes, the Shalrat throws much too often. If I ever get so far spawning them out of the egg.
Looks like a Shalrarebit...
http://members.home.nl/gimli/shalrat.jpg
Custom Animated Sprite
#5365 posted by . on 2006/09/28 21:43:20
Realising Quake 1 supports animated (.SPR) sprites, and knowing you can place a light entity that appears as a sprite... I need to make a few steam sprites to put by broken pipes.
Making the sprite itself should be easy (and I see FrikaC has some tool that supports SPR, but I haven't tried it yet to see if it's capable of making a .SPR)...
But my main concern is, how can I make it an entity to place in the map? If anyone has anything ready-made that I can easily modify art-wise (I'm no coder, so I won't touch QC), that'd be great!
Yeah, I Do
#5366 posted by Preach on 2006/09/29 01:59:49
I'm basically going to rip this code from mapgen, http://qexpo.quakedev.com/uploaded/32/mapgen.zip
If you need a placeholder sprite and sound to use with this code, that's where to look. Drop all of this into the bottom of misc.qc.
//PREACH start func_steam code
void() steamp2 = [1 , steamp3]{};
void() steamp3 = [2 , SUB_Remove]{self.nextthink = time + 0.7;};
void() func_steam_think =
{
local entity steamp;
local vector r;
steamp = spawn();
setmodel (steamp, "progs/steam.spr");
setorigin (steamp, self.origin);
r = '0 6 0' * (random() - 0.5);
makevectors(self.mangle + r);
steamp.movetype = MOVETYPE_NOCLIP;
steamp.velocity = v_forward * self.speed;
steamp.nextthink = time + 0.1;
steamp.think = steamp2;
steamp.avelocity = '20 20 0';
self.nextthink = time + self.wait;
}
void() func_steam
{
precache_sound ("ambience/steam.wav");
precache_model( "progs/steam.spr");
if(self.targetname)
self.use = func_steam_think;
else
{
self.think = func_steam_think;
self.nextthink = time + 1;//no need to start straight off
}
if(!self.speed)
self.speed = 90;
if(!self.wait)
self.wait = 0.15;
ambientsound (self.origin, "ambience/steam.wav", 0.8, ATTN_STATIC);
};
//PREACH end func_steam code
Then create a point entity func_steam. The fields to set are
mangle: sets the direction the steam fires
targetname: if set, must be triggered
wait: sets frequency of steampuffs, the default setting of 0.15 works well
speed: changes how fast the particles move. The default makes for a nice continuous stream of particles and a medium length.
Lines you might want to change:
void() steamp3 = [2 , SUB_Remove]{self.nextthink = time + 0.7;};
Change the 0.7 to change the lifetime of the sprite and so the length of the steam spray.
r = '0 6 0' * (random() - 0.5);
Controls how random the spray is, change the 6 to alter it.
The original mapgen code had a chunk of .alpha stuff which made the steam fade out, but I've omitted that as it's not the kind of thing mappers usually go for. If you want it, just ask and I'll write that back in.
[deleted Spam]
#5367 posted by Vallentino on 2006/09/29 09:52:40
[deleted spam]
[deleted Spam]
#5368 posted by Vallentino on 2006/09/29 09:53:38
[deleted spam]
[deleted Spam]
#5369 posted by Vallentino on 2006/09/29 09:55:12
[deleted spam]
[deleted Spam]
#5370 posted by Vallentino on 2006/09/29 09:57:03
[deleted spam]
[deleted Spam]
#5371 posted by Vallentino on 2006/09/29 09:57:51
[deleted spam]
AguirRe
#5372 posted by negke on 2006/09/29 11:57:37
thanks, i could get rid of it. there were no brush misalignments involved though.
Silly Question
#5373 posted by madfox on 2006/09/30 12:10:32
how do you write in white?
my cheap htm knowings won't help.
Check The Faq
#5374 posted by negke on 2006/09/30 12:32:44
< q > blah < /q >
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|