"FitzQuake Plus": An Easy Engine To Compile

[Baker]

And the relevance of this thread is about to make a comeback ...

It isn't that it wasn't relevant before (it has been since X 4 ... MH's dynamic light speedup, Jukki, mystery man from nowhwere uses this to produce 6DOF FitzQuake which filters into FTE as a new MOVETYPE and unnamed not-me person using this to supplant some project).

More that it is now time to raises the stakes just a little. Nothing bleeding edge, more a "rising tide lifts all boats" and quite anti-dramatic --- from an advanced developer perspective.

From a user perspective? Perhaps will feel differently. Users feel mainstream changes more than some feature they hear about and don't see in practice.

(Why'd I bump the thread? I keep looking for it and can't find it! I don't "need it" but I need to do documentation ... often it isn't whether or not X or Y or Z has a feature but whether or not W, U, V *can* have it. I'm getting tired of certain constraints (I get sick of read about them and they make me mad that I have to read about them in the year 2012) ... so I want to make them easy to circumvent ...)

[qbism]

Maybe a slightly evil question... ProQuake+ already has FitzQuake protocol. What is the advantage of FQ+ as a separate engine?

[Spike]

What is the advantage of FQ+ as a separate engine?

What is the advantage of ANY engine as a separate engine from $FAVOURITEENGINE?
Working on a clean slate, different code bases, etc, can help with people's sanity, I find.
Besides, there's always the fact that different people associate different engines with different objectives. FQ+ is thus more appealing to mappers than a PQ+ even if they are otherwise identical.

[qbism]

What is the advantage of ANY engine as a separate engine from $FAVOURITEENGINE?

That question is more general (and more evile ) than the case of two well-developed engine mods from the same author. Looking from a development standpoint rather than "is X better than Y", a clean slate for testing makes sense. Other possible scenarios:
A. Engine Y is a lightweight subset of X.
B. Engine Y and X are divergent projects.
Besides the fact that both PQ+ and FQ+ are from Baker, another commonality is that both "root" engines are well-commented and easily diffed against glquake.

The trend seems toward more similarities between engines (in a good way, like shared bug-fixes) even though new engines continue to appear. Although certain standardization issues continue to be gnarly.

[mh]

The trend seems toward more similarities between engines...

Wait till you see what I've got coming... (just try diffing it with anything else...!)

But I do agree with your point in principle. Similarities and convergence of features (and of the way edge cases relating to these features are handled) is 100% a Good Thing.

[revelator]

Wait till you see what I've got coming... (just try diffing it with anything else...!)

mh on the prowl warning hehe looking forward to what you got cooked up.

[Baker]

Maybe a slightly evil question... ProQuake+ already has FitzQuake protocol. What is the advantage of FQ+ as a separate engine?

Rising tide lifts all boats.

Spike really answered the question better than me. I have a large slate of stuff and porting it to FitzQuake helps me make it digestible (for others to acquire for their engines) and able to be standardized. FitzQuake in many ways represents the "best" baseline classic Quake.

[drm_wayne]

Is it just me or does FitzQuake plus ignore the Quake entities on HLBSP maps?
The map loads, but enemys, items and weapons doesnt show on the floor -.-

[Baker]

Is it just me or does FitzQuake plus ignore the Quake entities on HLBSP maps?
The map loads, but enemys, items and weapons doesnt show on the floor -.-

Sounds like your progs.dat doesn't support your map entities. That is my guess. Does your circumstance above work ok in, say, DarkPlaces or FTEQW? If so, maybe there is something I need to look at, but double-checking versus another engine first helps tell if a problem is user-error or an engine bug.

[drm_wayne]

Works in Q1BSP and on HLBSP in Darkplaces, and i think i will stick with Darkplaces for now.

[Spike]

only reason I can think of is hull sizes? :s

[drm_wayne]

Also, the players "sight" is too high in HLBSP maps in FitzQuake, Q1BSP works normal.

[Jukki]

Baker, i think i have found a bug. IF you walk in on func_wall you get stuck.

I didnt see anything wrong in qc (this is while using hlbsp)

[Baker]

Baker, i think i have found a bug. IF you walk in on func_wall you get stuck.

I didnt see anything wrong in qc (this is while using hlbsp)

I will investigate that one. I plan to make an optional HLBSP build for this engine: viewtopic.php?f=3&t=4921

Whatever you are using FitzQuake plus for, FitzQuake V Mark is far better and just as easy to compile. Except I don't plan to add HLBSP to FitzQuake Mark V, but I will put in an optional HLBSP support #define so you can turn that on in compile.

See FitzQuake Mark V change log: http://quake-1.com/docs/utils/fitzquake_mark_5.txt

[I might need you to private message me something to test your issue with.]

[Jukki]

Sure, i am using fitzquake plus for couple of reason.

1. hlbsp (our mapper doesnt like to use qbsp XD )
2. similiarities to psp engine, easier to swap code betwen the engines
3. I dont want the pc version to have many advantages over psp version, so fitzquake+ suits well our needs.
4. its nicer to add new stuff in the engine yourself