Ijed
#16689 posted by mjb on 2016/07/23 02:09:54
I use Nvidia Shadowplay to capture game screens. I would probably use Bandicam, OBS, or the like if I used ATI.
Fraps always works but I find it to be so resource heavy.
Qc Details
#16690 posted by spy on 2016/07/23 07:32:41
you have to define/declare other.items2
there is no hipdefs.qc on your progs.src screens
or just put this
// have to use a new items flag because we ran out of bits in the original
.float items2;
inside your defs.qc (to the very bottom of the file)
Textures In-The-Raw
#16691 posted by Qmaster on 2016/07/23 17:01:18
Much as I love a good google search, my efforts are proving fruitless for what I am hunting for. Does anyone know of a place to download all quake textures in a raw portable format such as png, jpg, tga, etc.
TexMex Can Export To Jpg And Tga
#16692 posted by czg on 2016/07/23 17:26:58
Just open wad, select all textures, then file -> export
Ah, Great
#16693 posted by Qmaster on 2016/07/23 17:28:29
Easy sneezy
#16690
oops, I removed that hipdefs.qc
Digs
#16695 posted by madfox on 2016/07/25 05:25:06
A small search for how to create ent files for quake ended here.
Why Enemies Didn't Get Hurt By Gas/poison/fire, If They're Not Angry?
#16696 posted by NewHouse on 2016/07/25 19:23:23
I use Arcade Dimension mod, using quakespasm engine. I made gas trap and placed the enemy near to it, let assume it is fixing it or something. I use button to activate it, trap starts shooting its gas/poison/fire but enemy doesn't get hurt, how to deal in this situation? I also used button that can be fired by shooting it, enemy reacts to a noise and turns around and dies to that trap.
Big Problem
#16697 posted by komagame on 2016/07/25 20:22:34
I've found that MHColouredLight(light.exe) does NOT work under win98se ! @#gulp#@
error: light.exe requires newer Windows version
Other light.exe(with colour) ?
thank
#16698 posted by Baker on 2016/07/26 01:49:34
Really you are gonna post that?
And if your only computer is a Windows 98 computer ... don't you think you have more pressing problems than whether or not MHColorLight will run on it.
Sv_touchlinks: Next != L-Next
#16699 posted by Rick on 2016/07/26 02:55:26
What?
Fitzquake only problem?
Hmm..
#16700 posted by Rick on 2016/07/26 07:19:48
Sv_touchlinks: Next != L-Next
Well, I had to go back five revisions before I found a copy of the map where that odd message doesn't pop up.
It looks like it started when a specific door was added or the direction it opened was changed. What's really strange is that the message appears when I touch the trigger for a completely different door which has been in the map and working fine for years.
Another funny thing is that it doesn't happen every time. I can reload the map and go through the exact the same way and about half the time there's no message.
I'm pretty sure I've never run across this before. If it actually is just a Fitzquake bug, I wonder if I should just ignore it.
Sv_touchlinks
#16701 posted by ericw on 2016/07/26 08:31:38
I think it's an engine bug; there are some details here (sounds like you can trigger it in vanilla quake):
http://forums.insideqc.com/viewtopic.php?f=3&t=4920&p=45279&hilit=SV_TouchLinks#p45279
Hmm
#16702 posted by Qmaster on 2016/07/26 13:53:44
If I recall, that error occurs whenever you have two touching doors with one checked to "Don't link" and the other not.
#16703 posted by Rick on 2016/07/26 15:23:33
After more checking it looks like it was changing the direction the new door moved that caused the sv_touchlinks message. I can live with that door moving up/down instead of sideways if necessary. It isn't really needed at all, it was only added to make an encounter a bit more interesting.
If I recall, that error occurs whenever you have two touching doors with one checked to "Don't link" and the other not.
I'll go back and look at this. The door that was added does indeed touch the pre-existing door which now causes the message when triggered. I normally check "door don't link" without thinking, but maybe I left one unchecked. The new door needs to move, but the older one just needs to go away. It could easily be a func_wall that gets killed.
#16704 posted by metlslime on 2016/07/26 16:59:43
Btw this might be a Fitzquake 0.85 only bug, or at least you might get a different message in other engines. I would at least check quakespasm to compare
#16705 posted by metlslime on 2016/07/26 17:00:26
Though a question: aside from the message do you get any broken behavior?
#16706 posted by Rick on 2016/07/26 17:04:02
Okay, I was wrong. Changed the older door to a func wall and gave it a new name and brand new trigger_once killtarget. Now neither of those doors have a connection to the trigger that's generating the sv_touchlinks message. And the message is still appearing.
About Win98
#16707 posted by komagame on 2016/07/26 17:33:43
<BAKER> Obviously I have a "modern" pc too but I usually map on my Pentium2 at least for Quake.
So I really don't understand why mh-light.exe does not run on win98.. some ideas ?
Are there any colored-light.exe that could work ?
#16708 posted by Baker on 2016/07/26 21:10:39
It probably has a trivial dependency on the Windows API that wasn't available in Windows 98 or requires a .dll that isn't available/can't be available on Windows 98.
It is really hard to compile something to ensure it works on an old platform that isn't used by an appreciable number of people.
I don't know when mh-light was compiled, probably in 2010 or 2011, but even 10 years ago Windows 98 was pretty scarce.
It is almost impossible to compile an executable today that would work on Windows 98 unless someone used tools of that era (i.e. Visual Studio 6) and tested it specifically on Windows 98 and almost no developer is going to have a such an old machine.
Sv_touchlinks
#16709 posted by Rick on 2016/07/27 02:27:26
I'm pretty certain I've found the problem.
This:
// entity 2025
{
"classname" "info_notnull"
"targetname" "NoMoreDoors"
"target" "SewerGate"
"use" "trigger_once"
// brush 0
...
}
Since it wasn't either of the doors, I looked at the other things fired by the trigger that was causing the message. The one above was added about the same time as the doors.
It's one of those "triggerable triggers" made from an info_notnull brush. I have no idea why it causes the problem. I have three more of those that have been in the map for years and they never did it.
I deleted it and was then able to start and restart Fitzquake and the map and reload the map multiple times and could not get the trigger to give that message.
Now I just have to figure out some other way of doing what the info_notnull trigger was doing.
#16710 posted by metlslime on 2016/07/27 03:07:21
That makes sense now. FYI, the engine keeps a list of touchable entities. The bug you're seeing comes when the list is changed at an unexpected time. Creating a new trigger (using trigger_once spawn function) probably causes it to be added to the list. Not sure if there's a better or different way to do what you're trying to do.
#16711 posted by Rick on 2016/07/27 03:55:49
Well, I haven't totally given up on it, but I'll leave it out for now. After all, there are three other "triggerable triggers" made from info_notnulls in the map that don't fire that message.
I was using it to open a door. The door is accessible very early, but not openable. After the player travels a long path around the map they would eventually pass the door again, at which time the trigger would fire and the door would open.
I can probably do something similar with a spikeshooter logic gate or a hidden button that's revealed just before the player arrives from their trip around the map.
#16712 posted by Rick on 2016/07/28 00:06:50
I got the door working just the way I wanted using a simple logic gate. I was able to use an existing func_wall as the blocker, so all I had to add was the shooter and a button.
That leaves 2 models I could add before Fitzquake will complain that 256 models exceeds the standard limit of 256 (lol).
Off By 1
#16713 posted by Preach on 2016/07/28 08:52:56
That leaves 2 models I could add before Fitzquake will complain that 256 models exceeds the standard limit of 256 (lol).
That's an off-by-one error, but the incorrect part is the standard limit, which should be 255 models. A single byte can store 256 values, but the value 0 represents "no model", so one less slot for actual models.
It's also important to remember that the world itself occupies a model slot, so you're down to 254 useful model precaches. If you want to see some tricks on how to reduce the number of models you use, drop me an e-mail and we can work something out.
|