|
Posted by Kell on 2008/03/09 14:25:20 |
Finally. Quoth Part 2, the base-oriented update.
http://kell.quaddicted.com
Note: the mapping tutorial is only half done. We've decided to release anyway, because it's taking too long, plus there are maps already finished that use this content and surely some more will follow.
Map sources for all the Quoth maps, including the previous pak0 maps, are downloadable from the tutorial page.
Have at it.
[edit: fixed URL] |
|
|
Quoth2 Fgd
#92 posted by ijed on 2008/03/18 03:12:52
http://shub-hub.com/files/tools/quoth2fgd.7z
Its almost certainly incomplete, but the basic stuff should be there. If you update it then reupload it, but be warned, I ended up using c+p alot instead of the cascades system.
Thanks Ijed!
#93 posted by RickyT33 on 2008/03/18 11:02:28
Er.... It Says On Kells Site...
#94 posted by RickyT33 on 2008/03/18 17:50:49
...that there are forcefields. But there's no documentation to support this feature at all. Is it even used in any of the included maps?
How do you create a forcefield? :-)
Forcefields
#95 posted by spy on 2008/03/18 18:48:25
ricky, kellbase1 has a forcefield
Forcefields
#96 posted by Preach on 2008/03/18 19:22:13
Forcefields are func_togglewalls with a spawnflag set. The details aren't written up in the tutorial yet, but here's enough details to get you started:
Spawnflag 2 turns on the particle effect, making this into a forcefield. While the func_togglewall is solid, a particle effect will scroll across it. The "worldtype" key takes values from 0 to 5 specifying the direction the effect scrolls: up, down, east, west, north or south. The "colour" key should be a quake palette index specifying the colour of the particles. "speed" specifies the speed at which the wave should travel. "style" specifies the number of particle bursts that should be generated per second. Take care that style is not set too high, or the player will be flooded with particle messages, causing lag in network games.
The network warning is especially important if you want to run the map in coop, you might want to consider using the coop spawnflags to change the entity setup to something less demanding for coop mode.
Thanks For The Info !
#97 posted by RickyT33 on 2008/03/18 23:33:16
I Take It That Info_command_spawn
#98 posted by RickyT33 on 2008/03/19 16:32:17
will just act as if the command was in the worldspawn?
i.e.
"classname" "info_command_spawn"
"message" "r_wateralpha 0.4"
will just activate on the start of the level ?
Basically
#99 posted by Preach on 2008/03/19 16:52:02
Yeah, the info_command_spawn intended for that kind of command, but it has two subtle extra points. The first is that it is applied when a player spawns, rather than when the map starts. The only time this makes a difference is in coop, but using it means that each player is sure to get the command when they connect. It also gets sent again if they respawn, so if you have different fog levels in different sections of the map, setting the initial fog level with info_command_spawn ensures respawning players will have the right fog for that location.
The other thing that it does is sets the "environment variable" for the client to the command in the info_command_spawn. This means that when they load a saved game on this map, the command from the environment variable will be sent again. Otherwise it's possible that they could load another map or restart the engine, which would reset the wateralpha value. There are ways to update the environment variable for different regions of the map, but that's only needed if you're doing different fog levels/wateralpha levels around the place. If you have a global setting for the whole map, put it in info_command_spawn and it's all handled for you.
Two important additions on how to format commands though:
1) Make it "r_wateralpha 0.4\n", the extra \n on the end of the command makes it execute, otherwise players can encounter a problem where the engine misses them pressing/releasing buttons.
2) If you had fog as well as wateralpha, you shouldn't add two info_command_spawn entities as only one of them will work. Instead make one entity containing both commands separated by semicolons. Like:
"fog 0.2 0.3 0.2 0.5;r_wateralpha 0.4\n"
Sound Like I Need Me One Of Those!
#100 posted by RickyT33 on 2008/03/19 17:17:15
Nice one.
New Bad Guys.
#101 posted by mwh on 2008/03/19 21:16:44
It's strange, this having to learn new tactics thing :)
Pyros are cool, they definitely make you think again.
Edies are nasty.
Sentinels are pretty soft, they're easy to hit.
Eliminators are annoying.
My Quoth Fan-art Drawing
#102 posted by Jaromir83 on 2008/03/21 15:37:31
Hey
#103 posted by Kell on 2008/03/21 15:46:02
cool.
Ladder Issue Solved
#104 posted by Preach on 2008/03/21 21:56:07
I figured out why you can't get up the ladders in darkplaces, though I gotta tell you it was a bit of a stumper for a while. The problem is actually the size of the solid boxes around the metal grills, in darkplaces these are made too large. The size of them is calculated based on the dimension of the sprite reported by the engine.
Winquake(and presumably all other engines):
'-64 -64 -64' '64 64 64'
Darkplaces:
'-90.5 -90.5 -90.5' '90.5 90.5 90.5'
For reference, the sprite is 128x128 pixels - and one pixel to one quake unit is drawn in both engines. So why does darkplaces report such a strange value? Well, 90.5 is ~ sqrt( 64 * 64 + 64 * 64), which is the length of the diagonal line from the centre of the sprite to the corner. So I'm guessing that it's stored like that to create a corrected "bounding radius" for the sprite. This is to make sure you don't get into the situation where the corner of the sprite should be just on screen, but the engine thinks you can't see it any more.
My feeling on the matter is that this updated bounding radius should not be sent to the qc, and that darkplaces should just store it internally. I don't think this would be hugely problematic to fix, the fact is that nobody uses sprites in quake, so it's probably never been noticed before.
Sounds Missing...
#105 posted by distrans on 2008/03/27 04:39:03
I've got testers reporting missing quake.wav and quakeend.wav at level start. All are using -hipnotic -game quoth with Quoth and Quoth2 installed. I've double checked .map and the level doesn't call these sounds. Ideas?
Yeah, There Is Indeed Some Sound Missing,
#106 posted by Dooomer on 2008/03/27 05:00:18
the most noticeable one is when the game begins by playing demo1, and the explosion sound of ogre's grenade would be missing.
Yeah - Distrans - That Happened To Me!
#107 posted by RickyT33 on 2008/03/27 10:31:34
er, what was it, its coded in the info_screenshake to play those sounds. Re-assign the sounds to "misc/null.wav", for the keys "noise" and "noise1", in every info_screenshake in your map, and the warnings will disappear!
I think Preach answered me on the mapping help thread, #7180
:-)
Ta Ricky...
#108 posted by distrans on 2008/03/27 10:49:57
..I'll do that tonight. Mebbe there'll be another base map out this weekend :)
Sounds Missing
#109 posted by Preach on 2008/03/27 11:01:37
The earthquake sounds are available in mission pack 1, but not in the quoth packs. If you actually want them then send me an e-mail, but you can just silence them like Ricky says.
The missing explosion sounds in the start-up demo is in fact by design. Quake sends the explosion sound automatically whenever you tell it to create the explosion particles. In order to make it possible to have explosions with different sounds, the default explosion noise is replace by a silent .wav file and explosion noises are added "by hand". This can be seen with the bob. Of course, the noises are not added retroactively in demos that were already recorded.
So
#110 posted by negke on 2008/03/27 11:33:02
Will the Quoth2 pack be updated with these sounds?
Erm
#111 posted by than on 2008/03/27 12:29:53
Preach, sorry for not testing with my other map. That had the screenshake entity in it and I didn't notice the sounds were missing back then.
It would be cool if they could be added in an update. Maybe the current pak could be replaced? Anyone with the old pak would still get the warning, but it's not a big deal. Are there other complications that could arise from modifying an existing pak?
Should we just ship the sfx with our maps?
Yeah - Good Question!
#112 posted by RickyT33 on 2008/03/27 12:35:59
My map is in the latter stages of vis. I can do
txQbsp -onlyents
and
light
and then theres only newskip.exe to run, but after I do that, I cant change anything, cause changing the ents would require re-doing the lights (some lights toggle on-off), and light.exe has a fit after newskip is run... (takes deep breath)
In short, I'd like to know!
Er
#113 posted by RickyT33 on 2008/03/27 12:38:02
thats gonna confuse people.
I just mean I can get rid of the "noise" and "noise1" keys in my screenshakes, but only before I run newskip.
Unless theres another way. I'm too scared of loosing my vis data!
#114 posted by negke on 2008/03/27 13:02:01
light -onlyents then
I Dont Think That Works With Tyrlite
#115 posted by RickyT33 on 2008/03/27 13:10:54
:-(
Sounds And Ents
#116 posted by Preach on 2008/03/27 13:50:45
There's no plan at the moment to update with a patch. If we were, the plan would be to create a pak2.pak with the patch elements in it, to be overwritten when part 3 is released. We'd make that a separate download and patch the full file at the same time. But we'd really only use that option if a critical problem like a crash bug came up. So for now I guess the best thing is to distribute the sounds with your map. Otherwise it'll go from you telling us there's a bug to people playing your maps telling you there's a bug, even though it's not your fault, because they didn't get the patch.
And yeah Than, don't worry about not spotting it, I messed up too. I had a test map for the earthquakes, but I was specifying the sounds by hand, so the defaults were never tested.
Modifying entities:
There's at least one way of doing this when a map is fully compiled, without having to worry about which utility to use at which time. Get a copy of adquedit:
http://www.quaketerminus.com/tools/adquedit_v13.zip
Then open the bsp file with this program. You'll see a button to extract entities. This saves them to a text file, where you can edit them directly, add new fields, even add entirely new ents to the map. Then use adquedit to import them again. The text file is basically an ".ent" file, but the program bakes the entities into the map when you use the import function.
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|