Know what i would like to see?

[Baker]

Ranger is saying Half-Life development is so easily even complete newbies can do it with the greatest of ease and with more creative freedom than the Quake palette and does not involve conversion plug-ins that don't always work or are somewhat non-newbie friendly to setup.

A super nooblerized NetRadiant or QER that was knobster easy to setup with Quake BSP 2.0 support (more colors, extra hulls, the stuff that Spirit would like, ...)

Still that misses the model thing. Admittedly I've never used Blender and leileilol's tutorial combined (but in my limited time playing with modelling, I wasn't immediately comfortable with Blender ... probably takes doing a few tutorials to warm up to it). Even then Q1 format is 256 color locked. IQM may have steep requirements incompatible with some engine goals. Etc. Etc.

[Spike]

Also, if IIRC the PHS from Quake 2 was also added, which alone implies a good ammount of rewrite in the sound subsystem. And let's not forget the 4th collision hull, which to be fair can be quite easy to add.

The PHS in halflife is likely more derived from QuakeWorld rather than Quake2 (Quake2 stores PHS inside the bsp itself, unlike halflife, which does not change the bsp format for it). The sound system is as good as identical between Quake and QuakeWorld. Its only the server parts that change to support phs.

The only actual format difference between quake and halflife bsps are the textures and lighting colours.
Any other changes are due to entity fields (transparency), specifically named textures ('fences'), and content types.
The first is basically a specific alternative form of DP_ENT_ALPHA, the second is just a glEnable(GL_ALPHA_MASK), the third is usable in quake with just a pointcontents and needs no engine support at all (except for ent physics). Okay, sure, rendering for fences and colours requires a lot of changes in a software renderer, and they had a d3d renderer too (for that extra latency). So yes, they likely rewrote some large chunks of the software renderer, but for the most part, all they needed to do was to change how it generates colours, and nothing more, the rest of the logic is the same, just cleaned up a bit/lot (no mere mortal can read abrash's code!).

To put things in context, hexen2 has transparency also. Again only on non-world entities, and hexen2 still claims to be version 29 (the only differences in the format itself is 8 hulls, and arguably palette).

[Ranger366]

Ranger is saying Half-Life development is so easily even complete newbies can do it with the greatest of ease and with more creative freedom than the Quake palette and does not involve conversion plug-ins that don't always work or are somewhat non-newbie friendly to setup.

Well, mapping and modelling is easier, but important for me is the quality of the model format, smaller in size, better texture quality, skeletal animations. The maps are colored and such etc. but the compiling times are way too long.

Im not a newbie of course, but Quake modding should be like half-life modding, except for the gamecode.

We have full controll over Quake, who is against a method to make modding easier AND prettier?
IQM is good HL MDL alternative of course.

[Rich]

I guess we are deviating a bit from the real point of the discussion. I never said it was impossible to support HL BSP in Quake; it's already done (in a partial way) by Baker and others in a number of engines. The point here is: a) it's a partial support, and doing a full implementation is not that trivial (But I concede that "not that trivial" is a very subjective concept; what requires a lot of work and thought to me can be trivial to you or other experienced engine coders) and b) what Ranger366 and others really want is full support to all Half Life features (not only BSP files, but models and everything else, kitchen sink included - in other words, they want the Half Life engine, not Quake) into a PSP port, and they want this arguing that "Half Life is based on Quake, so this must be easy to do", which is a completely WRONG reasoning. And that's why I suggested to him in another similar thread that instead insisting in this approach, they should start a movement to press Valve in order to release their now 12 year-old Half Life engine under an OSS license so someone can at least try to achieve what they want from the right start point. Personally, I'd love to have a chance to study how they implemented a lot of things in a legal way.

And about your scatological analogy: at least to me, crap over a chocolate cake always turns the whole into crap, regardless if it's only a tiny piece of crap. But hey, there's always people who are less demanding...

Alright, so I guess you were just using a questionable choice of wording to argue against the supposed "ease" with which Half-Life data can be fully supported in a Quake engine. We can probably both agree that HL is based on Quake, but that supporting every single thing HL does in Quake is a decent bit of code and involves a good bit of "clogging the plumbing". It's also absolutely not worth doing, because we already have better content paths available to us.

I know that not all Q1 engines support these things, but speaking based on my knowledge of DP features (and I generally only have this knowledge from conversing with LordHavoc), you already have q3bsp, Q3 materials, and IQM. These formats offer collectively far more than HL formats can give you, and I'm not sure what kind of twisted goals an engine might have if it can permit HL MDL but not IQM.

So with that established, I think the better angle on this situation to take is, how can the tools be improved? The HL MDL path is no easier than the IQM path, certainly. You can go directly from SMD to IQM, or COLLADA to IQM, or...well, anything Noesis supports to IQM. And you've got yourself a nice skeletally animated model to shove into any Quake engine that supports IQM. So if we ignore the fact that most engines don't currently support IQM, I think the "ease in content creation" issue comes more from Worldcraft vs. QER. Or "Hammer" vs. QER.

Having used both WC and QER myself, I actually find QER to be preferable in pretty much every way. However, WC was re-branded as Hammer, and I haven't even used this newer incarnation. So I'd be curious why/how people think Hammer is a generally better map-making tool than, say, the latest version of GTKRadiant.

It wouldn't be surprising if the issues brought up turn out to be completely easy to fix, and making better tools is certainly a better idea than implementing HL formats in Quake engines.

On the other hand, this situation changes a bit for PSP engines. In that realm, I doubt anyone really wants to fully support a Q3 shader system and/or q3bsp. In that case, HL BSP support might be the fastest/easiest path to less-shitty content types and (non-palettized, edit: er, well, non-GLOBALLY-palettized) textures for a lot of PSP engines. However, HL MDL is also a piss-poor model format to use on the PSP. IQM is a better one in that it offers a wide variety of data types, and Noesis even has advanced commands which would allow you to segment and batch the output IQM for hardware skinning. Although IQM is still far from ideal, and would require you to generate bone reference lists on load.

So I'd have to say, there ought to be a streamlined "IQM"-like standard for PSP Quake engines. Then people can convert whatever the hell they want to that format. IQM also lacks a per-surface scale and bias for geometry, which makes using limited-precision data types with it a bad idea. (this strikes me as a bit of an oversight) This could be implemented as an "extension" to the format, but I think that would be a messy solution.

You'd be surprised at what you can get away with when you are using a per-surface scale and bias. I bet most people would never guess that Final Fantasy 13 model vertex positions are stored as 16-bit fixed point values. But getting back on topic a bit, yeah, PSP Quake engines really need a new format. Something like GMO would be best, except GMO is far too complicated and allows far too many data types. (being a platform-wide standard) I think that spending your time implementing HL MDL directly would be a bad idea, though.

If I were to design an open spec and example implementation for an extremely-optimized-for-PSP-hardware model format, would any PSP Quake engine coders actually have interest in implementing it? I think this would be a good use of my time, but I would not want to put forth the effort and end up with another IQM situation.

[jim]

I can comment on the Hammer vs Radiant as I've used both. Simply it's like this: Hammer got default controls similar to pretty much every other program you've used, but Hammer is a lot of press enter key to do this and that, etc. Radiant got default controls pretty weird and different from other programs, so people might think it's hard to use.. if you learn the default controls or change them, you'll find out that Radiant is much faster to use than Hammer and you can create and shape new brushes as fast as you can fire the nailgun

Also it's probably not so good idea to get HL MDL into Quake, at least if it's the HL1 version.. that only had vertices that could be affected by only one bone.

I've been using DPM and it seems pretty easy to get them compiled. Export model to SMD, write some scale, rotate, etc parameters to a text file, reference the SMD files in the text file and run the text file with dpmodel.exe and you get both DPM and MD3 versions of the model.

[horrorporn]

this is slightly offtopic, but can you use attachments on iqm? and if so what does the qc look like and how do I go about constructing them in blender?

[Boss429]

this is slightly offtopic, but can you use attachments on iqm? and if so what does the qc look like and how do I go about constructing them in blender?

with skeletal formats in DP you use bones as attachment points.

[Electro]

What Rich said.

Except GTKradiant 1.4 is the best version. It takes less presses than was horribly added to the 1.5 workflow.

There really is basically NOTHING that hlbsp does that q3bsp can't... is there? The HL mdl format is rubbish and old, go for IQM.

[Tomaz]

I never said it was impossible to support HL BSP in Quake; it's already done (in a partial way) by Baker and others in a number of engines. The point here is: a) it's a partial support

HL BSP support was added to TQ, DP and probably others... lets see... 9 years ago?

What about the existing HL BSP support is partial? What is missing?

[ceriux]

this is slightly offtopic, but can you use attachments on iqm? and if so what does the qc look like and how do I go about constructing them in blender?

with skeletal formats in DP you use bones as attachment points.

what if you didnt want to use a bone? and wanted to use a model group? like lets say you wanted to change the entire body as a group? instead of having to change each and every piece of the model by each bone?

[Spike]

That's not how attachments work.
Its gluing other models onto a parent model, attached to a specific _parent_ bone (aka: tag).

[frag.machine]

I never said it was impossible to support HL BSP in Quake; it's already done (in a partial way) by Baker and others in a number of engines. The point here is: a) it's a partial support

HL BSP support was added to TQ, DP and probably others... lets see... 9 years ago?

What about the existing HL BSP support is partial? What is missing?

From the top of my mind (probably there are more): a) 4 collision hulls (I think this is the easiest to add but I really don't know how many engines do support it); b) all the CONTENT_* types supported by HL BSP; c) correctly load and show HL WAD textures used in such maps; d) stippled textures in worldmodel. Do you know any Quake engine that features all of this ?

[Tomaz]

I never said it was impossible to support HL BSP in Quake; it's already done (in a partial way) by Baker and others in a number of engines. The point here is: a) it's a partial support

HL BSP support was added to TQ, DP and probably others... lets see... 9 years ago?

What about the existing HL BSP support is partial? What is missing?

From the top of my mind (probably there are more): a) 4 collision hulls (I think this is the easiest to add but I really don't know how many engines do support it); b) all the CONTENT_* types supported by HL BSP; c) correctly load and show HL WAD textures used in such maps; d) stippled textures in worldmodel. Do you know any Quake engine that features all of this ?

This is just going from memory so I might not be 100% correct.
a) TomazQuake and DarkPlaces both supported all 4 hulls ( I remember doing crouching to TomazMod but I'm not sure if that's still in there )
b) What CONTENT_* types were new? I only remember CONTENT_LAVA being gone?
c) TQ and DP both load WAD textures ( TQ being tested to succesfully load 90% of all the maps I tested, HL, CS, DMC and some other mod )
d) Stippled textures? If you mean aplha blended fences and stuff then yes, those also work in both DP and TQ

All this was added 9 years ago to both engines, and probably to several others that I don't remember, and many others since have had this added.

I also think FTE supports all this as well AND HL models, if my memory is correct you can play the entire single player HL in FTE. I know Spike worked on it but I don't remember if he ever finished it.

[Spike]

There is some contention over the actual hull sizes. If you use the hull sizes suggested by halflife, you end up with floating players. If you offset the hull size, then many quake mods 'just work', even though the offset is not compatible with halflife mods, which can get messy. you still need mods to use it properly, and it still needs tracebox.
from memory, halflife 'only adds' contents (removed=unused=reserved), and they're just fluid movement directions. gamecode can query that using pointcontents with no other engine modifications. I think.
FTE does load texture wads. From memory, DP only loads them if they're within a different subdirectory from halflife (which may be an issue for mapping tools), or I might be confusing that with ezquake.

[ceriux]

personally i think external wad support can be done with out. cause the texture can be compiled directly into the map.