 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
for these apologizes to Kell. I'm sure one of those who consume in waiting for the Base Pack release and I was in full agreement with your way to push it. I think it's great you finally got an answer to your e-mails. All the best for an updated Quoth version then. Quake quality first! - Don't blame yourself to much for your so called lack of patience. It showed more like enthusiam to me...
Are we still planning for the end of this month, or are in in hiatus until Kell and/or Necros can be available with the updated Quoth? I'm pretty sure I can get my map ready by the end of the month, and could scale back the baddies for only the original Quoth stuff if needed -- but honestly, the extra time would only help the project. Just to let you guys know I'm officially on the fence, here...
I got your message; I'm gonna be on the road for a few days, but when I get back in I'll give the start map a good look over and tell you what I think, also, I'll give you the source to the cute little dome thing of mine I showed a screen shot to, if you would like to integrate it for my map selection area.
.. Now, the thing is Kell seems to be quite alone on the project, as necros has other interest (with Doom3 maps).. so necros is almost out of Quoth project I guess (can I say that?
Concerning the delivery by the end of the month, I think we have to deal with Kell's inputs about Quoth update progress... If it goes fast, we would be able to deliver this month, if not, I think we need his feedback, and then decide what to do... But as he is still on the scene, we can hope for a delivery (soon ?)... Wait and see... If Kell is still up for working on Quoth once he is ready then I think we should definitely wait until that time comes. Hopefully Necros will also respond sometime and either continue to work on Quoth himself or allow someone else to finish it off.
The extra time will also allow those who haven't finished their maps to get them done to a satisfactory standard and presumably not have to decide between their map and real life commitments. Personally, I was getting sick of my base map and also feeling under pressure to either rush it and get it finished or just drop out of this project and release it separately. I'd really like time to maybe work on one of my other near complete maps and finish it off before hopefully returning to my pack map invigorated from releasing a map. Worked for a starmap this night. I think it has to be simple, because of the compatibility to other adjustments of the mappers.
I will try to make my own part in it, and send this map to at least everyone who like(d) to collaborate. As far as now I have 7 entries and a skill setting. Except nightmare. As I have no qc of the Quoth pak I can't be usefull to it. I only have the earthquake.qc and before the Quoth.qc isn't updated it is of less importance. I tried the newvermis in my map, but it didn't appear. the Quoth pak download is on Necros site: http://necros.planetquake.gamespy.com/quoth/index.html I still didn't started my part, I'm sorry but my current projetc has some complex issues that I need to solve.... I'll send you the stuff when ready, don't worry, I didn't forget you ;P
BTW Kell, any news on your side ? Or does somebody know how things are progressing on Quoth front ? necros and I are in communication, have started working on the beta pak1 content to finish it off. Can't really say more than that atm.
Great to hear you guys are working on Quoth again. I don't really want to throw a load of crap your way, but I figure that this stuff is worth mentioning anyway...
Is there any chance that the ammo boxes could be changed to require less precaches? At the moment it looks like they use 8 altogether, one for each type of ammo and size :/ It's only of importance to my non-basepack quoth map, which is very large, but it is possible that it could help other mappers who want to make large maps with Quoth in the future. I suppose the problem with changing bsp models to mdls is that the lighting changes. Is there no way around that? If there are any other optimisations on this front that could be done that would be fairly trivial and not make a big impact, such as the voreling using less precaches (currently 4?), do you think you might have a look at doing those too? You might remember that I mentioned something about bounding box triggers before. If it is possible to implement an additional trigger type that uses a user specified bounding box (min/max keys) instead of a bmodel, then it would be incredible. It would sure solve a lot of my precache model problems anyway Also, I don't know if I mentioned this before, but some enemies have a few fullbright pixels on their skin in places where it looks as if there shouldn't be fullbrights. The drole is the first example that pops to mind, but I think that maybe the death_lord and edie have some very minor problems too. Finally, I'd be interested in seeing Necros' Doom 3 stuff. Has anything been released yet? There is currently nothing on his PQ site. I'm pretty sure Mindcrime added pure entity based triggers to Nehahra, where you specify bounding box size instead of using a brush (was to be able to modify maps without actually having to completely recompile them), so that's definitely possible.
Good news: I'm glad to see you back on the Quake scene ! I am waiting patiently for the Quoth update :P
Dammit Than, you pre-empted both my ideas there. Here's a bunch of mdl replica of the id ammo crates:
http://people.pwf.cam.ac.uk/~ajd70/ammomdls.zip They are lit according to the light levels in the map, so you'd have to place them in well lit areas. Some of the skins have fullbright lights on them, ala doom 3. But since fullbrights don't work in some engines you have to be careful. Also at the moment there is one replacement for each model, none of them are combined, but with a bit of care you could get four or more models combined. For point entity based triggers, there's a neat 4 line change that will give you every type of trigger at once: Find the line setmodel (self, self.model);// set size and link into world and replace it with this chunk of code if(self.model) setmodel (self, self.model); // set size and link into world else setsize(self, self.pos1 - self.origin, self.pos2 - self.origin ); Then simply add a point entity with the correct classname(eg trigger_multiple). Set pos1 to the absolute coordinates of the minimum point of the trigger, and pos2 to the absolute coordinates of the maximum point. Doing things so quickly, without making any new entity classes, does have one downside. In worldcraft if a classname is already defined as being a brush entity, it can cause problems making point entities with the same classname. Adding some extra classnames like void() trigger_multiplep = { trigger_multiple(); } can help with this, as now you can make trigger_multiplep a point class. This has the advantage that if you need to make changes to trigger_multiple then you only change the code in one place and both classnames are affected. Other model optimisations: * Combine all the generic gibs into one gib with three frames, perhaps even combine the zombie gib while you're at it. * To take it a step further, you could have an optional global flag for maps to disable head gib models(to be replaced by a generic lump of flesh). A saving of one model per monster it pretty good by my reckoning, even if it's a bit of a loss in visual terms. * Combine the silver/gold keys into a single model with two skins. Only saves you one but it's a total waste right now. * Combine the flames into one model with multiple sequences - Start with the flaming torch and shrink down/hide all the wooden bits for the other flame. Only a saving if you use both of them in your map, but gets you an extra model if so. This was better when I thought the large flame had a different model to the small one, but that optimisation is already present. * Combining all the sprites into one large sprite could save you a few models if you're willing to do the work... There's also a very desperate way to optimise bsp models if you have models that don't overlap in skill settings/coop. For example, you have a wall that appears only in coop, and a totally different brush entity that appears only in non-coop, so that the two are never loaded on the same map. I think I'm right in saying all of the brush entities in a map have their models loaded, even if the actual entity that uses that model is removed because of spawnflags. If you find an entity for which it's worth strictly checking it's in the map before precaching its model, then there is a way: Compile the model as a seperate bsp file, in the way that the original ammo boxes are bsp models. Then have the spawn function for the entity precache the external model. This last tip is quite fiddly and it's most likely that it's not helpful for any given map. On the other hand, there might be some maps where it makes quite a difference, if the map is very different for coop than single player for instance. So it's worth a mention. Thanks for the info.
AFAIK, Kell and Necros have already made a lot of optimisations to Quake's use of mdls. The gold and silver keys, for instance, are already combined. This is basically why I mentioned the other stuff - I thought it might be easy for them to do and wanted to know if there was a reason that they hadn't for instance, optimised the ammo boxes - I'm guessing it's mainly because of the lighting thing. BTW, there is no spawnflag to set something to COOP only - only DM. Aye, we already did the key trick cos it was easy.
The other stuff...not so much. Combining different models - e.g. the gibs - into one is very very fiddly. Changing the ammo boxes from bmodels to pmodels is something I've contemplated, but not for Quoth. I've always thought it would be a case of 'messing with fundamentals'. However, those replacement models are absolutely top, Preach - nice work! I think we shold test them out in a map to see how objectionable the lack of lightmaps on them really is. I'd like to hear what other mappers feel about this - do you guys hate the idea of changing the way you have to think about placement and lighting of ammo and health? Or might it actually look better? Will players reject the change? Of course, unless those models are combined in some way they aren't going to use any fewer precaches are they? The option to globally disable gib head models sounds fine to me, though I doubt I'd ever use it as a mapper myself. Likewise, the use of a point entity to define mins/maxs of trigger volumes raises no objections with me, that's really a necros decision. The sort of model optimisations you're suggesting are feasible, but as I say: very very fiddly and time consuming and prone to irritating errors. And in the end, it might free up, what... a couple of dozen precache slots? Not ultimately efficient enough imo. Rather than asking necros and I to go through all the model optimisation for the sake of two-dozen model slots, it'd be much simpler to ask metlslime to bump FitzQuake's precache limit by two-dozen :P Re: skin fullbrights. Ack >_< I know, the little bastards always slip through. It seems to be the second line of fullbrights, the flame orange colors, that are the culprits. The only blanket method is to load them into TexMex to clear them of FBs, but the remove fullbright feature is imperfect I think. BTW, there is no spawnflag to set something to COOP only - only DM. A "coop only" spawnflag is something I asked necros about waaay back. We wanted to develop some coop specific features for Quoth. It's on the cards, but right now down at the bottom of the deck. Finally, I'd be interested in seeing Necros' Doom 3 stuff. Has anything been released yet? There is currently nothing on his PQ site. I'd better let necros answer that himself :/ If you wanted to keep the ammo boxes bsp model, you could at least double up the large and small shells/nails by renaming the textures cleverly. If you had a small box with shells textures +0smside, +0smtop and nails textures +asmside, +asmtop you could toggle the "skins" like the textures on a buttons are switched. You could also do that with medpacks. The rest of the ammo is all different sizes so you'd only save three models, but it's better than nothing.
On the other hand, the fact that you'd have to light every place you put an ammo crate isn't that bad in practice. As long as you made it an optional optimisation you can turn on with a worldspawn key then it'd be fine. Regular maps would have bsp lit models, and ones that want the extra model slots would opt in and be more careful with where they put health packs. I'm pretty sure you can put 11 skins into one model, so I might give that a go. The skins themselves would need some of the textures stretched, since you'd need to apply the same skinmap to each one, but I think it should be possible. The large rockets are awkward though, since they have an irregular shape. Might have to settle for 10... QME has a pretty good means of removing fullbrights on the skin. Open the model, go to view -> skin palette map editor, then you can uncheck the two bottom rows of the palette. It then remaps to the nearest colour in a range that is checked. Initially only rows that have already been used somewhere are checked, but you can improve the effect sometimes by checking all the other rows first. You can revert the changes, so you can make multiple attempts and see what looks best.
Also you can swap all the pixels of one colour with another one by double clicking the colour you want to replace, and then selecting the target colour from the palette that pops up. Neither of these methods consider the neighbouring pixels, but generally they'll get rid of fullbright speckles well. Bright red tends to cause a problem, but if your skin has patches of bright red it's best to make them dull/dark before you convert. force fields
ladders entity based triggers will be in. can probably convert all ammo box lighting will be better than it is with bsps, because, afaik, quake uses the lighting that was calculated when the ammo box maps were compiled. using mdls for ammo boxes mean the engine will light them appropriatly. if done correctly, players won't notice any difference at all. coop only flags is something i'd like to put in. busy atm, but i hope to get that in there. the thing with spawnflags is that, it appears that the ones in quake already actually control if an entity is spawned before it gets precached at all. this is really good. a coop flag would be done progs-side, and so would first be loaded by the engine, then removed by the progs. this is less good, but still ok. just not as nice as true engine spawnflags. as for d3 stuff, i haven't uploaded anything yet. currently, off and on working on a map with those sandstone bricks mixed with tech. kinda like some strange hydroelectric plant. also have a more 'traditional' white brick gothic map in the works.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors. |