|
Necros
#1551 posted by aguirRe on 2004/04/01 04:50:21
try TextPad http://www.textpad.com , it's excellent.
Necros
#1552 posted by Kell on 2004/04/01 10:48:46
I've been using Metapad for years; 'tis good. No filesize limit, find/find+replace, line # etc. etc.
http://www.liquidninja.com/metapad
Thanks!
#1553 posted by necros on 2004/04/01 12:29:18
they both work great and the map works now. :P
Headthump: it's not so much the brushes as it is the entities... there are a lot of lights in there ;)
Awwww...
#1554 posted by necros on 2004/04/01 16:57:54
CALL1 465(precache_model)precache_model()
items.qc : item_health
(NO FUNCTION)
PF_precache_model: overflow
Host_Error: Program error
on startup of map.
this sounds familiar but i don't remember what it means. can someone tell me?
Some Excerpts From
#1555 posted by aguirRe on 2004/04/01 17:16:04
old QMap thread 2001, GlassMan posts:
too many precached models. Only 255 allowed including brush models. Remember each individual func_movewall, func_illusionary etc etc will count towards that maximum. Use mcache to list them. The items marked *1,*2, etc are your brush models.
it will include all the weapon models, health etc etc..use mcache & you will have them listed. 195 is a _lot_ of brush models.
Also Includes trigger_* brushes
The limit is not 256 'bmodels'. Its 256 models of all kinds. That includes sprites, each type of monster, monsters heads, the bsp of the map itself, weapon models, the rocket model, the nail, gibs the lot. I doubt you would have enough space left for all these models if you have 200 'bmodels'.
I would guess you've gone over the top with the triggers for the teleporting in. Theres only so much of that you can do. With your coding skills maybe you could write some kind of monster spawn function to use instead of the triggers. I think custents has something like that.
*sigh*
#1556 posted by necros on 2004/04/01 18:45:26
man, i really hate that! :P looks like i'll have to trim some door and triggers out... thanks for pulling that up for me. you rock!
Quake C
#1557 posted by Mike Woodham on 2004/04/02 14:54:07
Does anyone know of a Windows based Quake C Editor. I have downloaded various Dos based programs but I really want a nice easy interface - you know the kind of thing, drop the file in the window and hey presto, it all opens up in the editor. Click a button and whizo, it compiles etc,etc.
The nearest I have got is FrikQCC, which seems to have a Windows GUI but no help file to tell me what to do next. (old dog, new tricks)
Frikqcc
frikqcc windows gui thing should allow you to associate progs.src files to it so that double clicking on one (in your quakec working source directory for example) should automatically launch frikqcc and compile it (iirc, may have changed).
if you mean an IDE for quake-c editing, i dont know. i know there are some hacks and tricks you can do to get MS visual studio to associate with .qc files and run qcc, however ive never used them. i think they were on friks site or something. i think most people just use some notepad-esque program (editpad, ultraedit, whatever)
Mike,
#1559 posted by HeadThump on 2004/04/02 15:43:41
Masm as an editor is very maleable; I haven't used it for QC but you should be able to run .qc files from it by changing the .bat files in the editor settings to ones associated with frikqcc. Might be worth a shot.
Of Course,
#1560 posted by HeadThump on 2004/04/02 15:48:36
I mean Qeditor which comes with the package I'm an old fan of Abrash that's why I still have it on my system. In a few weeks I'm going to be switching gears from finishing up mapping for a modders project to programming a progs.dat for a project of my own, so I would definitely be interested in what you might find useful.
Quake -C Editor
#1561 posted by quaketree on 2004/04/02 23:35:26
From Blues News (Googled)
"QCAPE is an integrated developmental environment (IDE) for managing QuakeC projects with pak editor, project manager, compiler, decompiler, and QuakeC manual all in one."
Don't know if its still on the net though. I still have a copy if you want me to e-mail it to you. Size 2.42mb.
Note: Did not like to run in XP home so if thats what you use then I dunno'.
Fat Controllers...
#1562 posted by quaketree on 2004/04/02 23:37:51
Metlslime
#1563 posted by aguirRe on 2004/04/06 09:35:23
Thanks for getting the board online again.
I'm trying to straighten out a few quirks in the Light tool regarding switchable lights. Do you know what's required from the engine to make them work correctly?
Specifically regarding the sharing of the same "style" key both in source and target entities. When there are multiple targets, the current logic is entity order dependant.
I even managed to create severe HOM effects in the engine just by manually inserting a "style" key in a bad place. Same behaviour in FQ and TyrQuake, so I assume this is an old problem.
Aquirre:
#1564 posted by metlslime on 2004/04/06 14:02:30
I know a fair amount about how it works in the engine. The logic you describe is all handled in QuakeC. Without the source in front of me, i believe the reason only the first entity gets the target is that the lightstyle message that is sent to the client will affect all lightmaps of a certain style. So this avoids redundant messages.
I can't imagine offhand why you would get those HOM effects, though. Please email me the bsp that demonstrates the problem, and i'll see if i can track it down specifically.
Quaketree
#1565 posted by Mike Woodham on 2004/04/06 14:20:05
Regarding Qcape - I have the same problem with XP, which is a shame because Qcape sounds good. I wonder if anybody has managed to find a workaround?
However, aguirRe pointed me towards TextPad4 and it has quite a lot going for it e.g. syntax highlighting and compiling directly from the editor.
If anyone's interested I can pass on aguirRe's very helpful e-mail.
Ooops!
#1566 posted by Mike Woodham on 2004/04/06 14:21:21
Provided aguirRe doesn't mind?
Clip Brush In Bmodel Problem: Update
#1567 posted by metlslime on 2004/04/06 14:28:52
Okay, well i did a lot of testing and code diving, and i found out exactly what the bug is, and what is causing it.
The bug occurs any time a clip brush in a bmodel extends past the bounding box of the visible portion of the model in any of the six axial directions (north, south, east, west, up, down.) If this happens, you can pass through the part(s) of the clip brush(es) that extend. The reason for this is that physics code uses the bounding box of the visible model (hull0) for culling -- if the player is outside of that box, quake doesn't bother doing collision calculations (which would use hull1) for it.
I haven't quite decided the best way to fix this in code. I also am not sure if the fix should be engine-side or compiler-side. However, if you are a mapper and encounter this problem, the solution/workaround you should use is to add extra visible brushes to the bmodel to extend the bbox as far in each axial direction as any of the clip brushes extend.
Metlslime
#1568 posted by aguirRe on 2004/04/06 14:56:46
I'll email you a small map+wad so you can see the HOM effect. This problem isn't very likely to happen, but it's quite an interesting effect. If anyone had showed me that symptom before and asked me why it happened, I doubt I would've found the cause.
Mike: Of course I don't mind, just pass it along to who ever that might find it useful.
Mmmm
#1569 posted by PuLSaR on 2004/04/06 16:50:08
My map likes to crash. At first I thought it happened because of edicts, but it crashes even in deathmatch mode (with no monsters). I'm completely disappointed.
But it still runs fine in Tyr-quake (software), but crashes in glquake, winquake and telejano. At least I tested it only in these four engines.
aguirRe, can I bother you once again and e-mail it to you?
btw my comp has been down for two weeks, I wanted to ask it before, but couldn't
PuLSaR
#1570 posted by aguirRe on 2004/04/06 17:22:00
Sure, just send me the zipped map+wad (no bsps please, I'll rebuild it myself).
Great
#1571 posted by PuLSaR on 2004/04/06 17:31:53
that's the same map, you already have that wad.
Aguire, Light...
#1572 posted by necros on 2004/04/06 18:53:19
i'm not sure if this is usefull or not, but:
in nesp06, i made a little fading light thing... for that i would manually assign one of the 'style' that are highup which is usually reserved for the light util... then, to change the style, all you do is change the intensity via (in qc):
lightstyle(#of style, " *letter of intensity* ");
the way normal light works is the compiler assigns a "style" to the light then the qc code does:
lightstyle(self.style, " *letter of intensity, so m for on and a for off and swaps between the two when triggered* ");
um... i don't know if that's helpful at all, or even what you were looking for... i'm tired. :P
Er, Also...
#1573 posted by necros on 2004/04/06 18:54:13
the style is global, no matter what lights are targeted, if the style is being changed, all lights with that style are being changed...
OK, I've Got The Map
#1574 posted by aguirRe on 2004/04/06 19:04:07
I'll have to check more tomorrow, but first impression is that I think it's entity related. After a normal build (no vis/light) it crashes FQ 0.75 immediately, TyrQuake can handle it but with entity flicker.
After a fast vis it still crashes FQ after a few rooms as you said.
After adding compiler options -solid -noents, FQ seems to be fine even without any vis. Therefore it appears entity related (noents removes all entities except world and players). I'm not so good at tracking down entity problems though.
Metl: FQ crashes at 0x41aac5 (access violation) every time, can you see in the FQ map file where that is?
Um...
#1575 posted by necros on 2004/04/06 19:15:06
what are you trying to accomplish, aguire? i seem to have forgotten...
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|