 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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'. 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. 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. 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. 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. 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. 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 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 the style is global, no matter what lights are targeted, if the style is being changed, all lights with that style are being changed...
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? Therefore it appears entity related
Hmmm that's bad, it seems like it's not simply edicts overload. Hello,
I would like to place a invicibily artefact above a well (to force the player to catch it and then falling down into the hole...) but, while testing the map, the artefact seems to "slip" down to the weel ground (gravity effect ???) Is it possible to preserve the artefact position without this fucking "gravity" effect ?? Thanks ...there's probably a tute somewhere, but basically:
1. Fill the well with a func_wall 2. Give the func_wall a name 3. Place a trigger_once at the player_start 4. Have the trigger "kill target" the func_wall by name 5. Place the PP on the func_wall The effect is that the player arrives in the level, causes the trigger to function thus removing the func_wall but leaving the PP floating. PS: that must be one very big well if the player can't jump over it? No, the well is not really big, the basic idea is that if player doesn't take the invicibility artefact, he die into lava at the ouput of the well... sorry for him...
Perhaps placing the artefact lower into the well will be more efficient to avoid "little sly" to take the item without falling down into the well... hmmm I think it will be better like this... Thanks for the advice... Bye.. ... because you didn't try swimming into lava... it cannot be done without pain... don't you know ??
Is this the same map you've been working on for a while now? I'm looking forward to see what you come up with. Good Luck
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |