HEXEN II community work and discussion

[szo]

I've updated fteqcc, Index of /moodles/fteqcc which should fix the miscompilation crashes.

I gave this one a try to see whether it compiles our hcode, it seems
like you have an issue with loop{} constructs: it is a feature in hcc
which is actually an optimized version of while(1){} or do{}while(1)
with the always-true condition eliminated. (and I do love that one.)

[Spike]

@Mathuzzz, works for me...

@seven, flames (and various explosion sprites) should probably be additive rather than blended, for dp/fte you can get that with self.effects |= EF_ADDITIVE; flag before calling makestatic.
regarding transparency in fte - fte loads the (default) shader before the texture rather than the other way around (texture first is pointless if the shader doesn't use that texture), and doesn't then hack the shader based upon what channels there are in the default texture (because that would be evil and would break things that use the alpha channel for things other than transparency via glsl). setting the entity's .alpha will still hack the shader blend mode and sort order though, but only on entities that have that field set because there really isn't any clean way to do it and its mandatory for every single mod that uses .alpha (or ef_additive, of course)...
I've updated fteqcc, Index of /moodles/fteqcc which should fix the miscompilation crashes.

[Mathuzzz]

I completely agree. jsHexen was always on the top of my list. It would be really great if he would continue with his work.

[Seven]

Thank you Spike and szo for your comments about the movement speed. I fully understand.
Then I will continue using sv_maxspeed "400" to prevent this.
As far as I understand you, 400 is also the default cl_forwardspeed and cl_sidespeed in Hexen2.


Also Thank you Spike for explanation of the fte particle system and fteextensions + H2 support.
I will try to use vanilla nq syntax/code and see if I can do something in H2...

Very interesting for me to read, that you even made a "DP-imitation" feature for effectinfo.txt in FTE for Quake.



Hello Mathuzzz,

Regarding your transparency question on models:
In DarkPlaces this is absolutely possible. You only need external .tga texture and you can withit make your model partial transparent.
I just tried it with the gruntīs skin and it worked out of the box.
In FTEīs Hexen2 it doesnt work (I tried it with the spider skin and a_torch skin). Which most probably is due to a missing cvar setting. Otherwise I see no reason why FTE should not be able to do it like DP does it. Spike will most probably have the hint


That is one of the reasons why I love Jeankīs jshexen2 extended engine so much.
It has the best particle effects I ever saw in a Hexen2 engine.
He even used that transparent model affect you mentioned by default on his flame models

I tried to make a screenshot that shows it (you see it better in-game ...).
It looks fantastic.



Here some of his screenshots I just found:




It is really a pity that his model code does not allow us to use external ones like in some other H2 engines.
I remember your thread over at inside3d about the HUD-weapons (ported from Heretic) that doesnt work in jshexen2.
If he would still be here with us, he would surely be able to fix it.
Maybe I will try to email him


Regarding sprite animations/usage.
They are handled and animated very similar like models.
You can loop them like a flame model for example.
dpmod has some sprite torches for example.
The "small mod compilation" extended it one step further and added selectable torches (model/sprite/particles).

Best regards,
Seven

[szo]

@szo,
Hi, does your engine supports external textures (.tga, .png...) now?
In the last version I tried there was no support.

No, not yet.

[webangel]

@szo,
Hi, does your engine supports external textures (.tga, .png...) now?
In the last version I tried there was no support.

[Mathuzzz]

I was wondering, how is FTEQW compatibility with Hexen 2? Last time I tried it, it was some time ago and had still some flaws, like sprites and some animations missing. Has there been any progress/plans for improving it?

Seven,
thatīs great you are getting interested in particles. Last few days I was trying to figure out how to use sprites. Sprites may not have been the way they wanted to go, but game with such limits could have made better use of them. I was thinking I would create torch fire with sprites(I hated Hexen 3D fire from the moment I was it That leads me to my other issues with transparency. I guess that just using external tga with alpha is not enough to have transparent texture, right?

[szo]

3.) Spider bug
Thank you for your fix szo.
I assume that it will be added to your actual V1.28 HexenC code ?

Yes, will be part of 1.29 when I make a release. Until the next uhexen2
v1.5.7 happens, see here: http://uhexen2.sf.net/devel/

One more question regarding the version number V1.28:
When I start your HoT V1.5.6 it says in the lower left corner: V1.28
This is confusing, as I expected V1.5.6 in that corner (as the version
of the engine should be displayed and not the HexenC version, no ?)

Yeah, our versioning and its in-game display is weird: we got the 1.x.y
triplet as our release version number model from our ancestor Anvil of
Thyrion back in 2004 when we actually didn't plan on doing much and
therefore didn't plan on changing the internal engine version numbers.
When things got out of hand, I began changing the internal engine
version but still used the triplet as our version number system because
we got used to it, sigh..

RE: speed thing: It has always been that way in hexen2 and I agree that
it is weird, but it has became part of the gameplay since its release
and I wouldn't feel happy with an idea of changing it for now.

[Spike]

movement speed:
yeah, hexen2 is weeeird... but its always been weeeird, so its hard to fix such things due to potential backlash (messes up stuff like hexen2-done-quick). :s
cl_forwardspeed+cl_sidespeed are traditionally set to about 400. sv_maxspeed set to 640. and yes, those normally get clamped by maxspeed ensuring maximum speed is always clamped properly. otherwise they're just purely axial. sadly the speeds are absolute values (thus specific to each axis) rather than simply scalers.

@seven
the fteextensions.qc file doesn't support hexen2 at this time. Generally though, you can just copy out the nq versions of the globals+fields+builtins into your hexen2 mod and they'll just work fine. If you're using a more traditional hcc, you'll need to remove the 'optional' keywords and likely change the way builtin indexes are defined.
(The issue is due to the file reitterating the system globals+fields+vanilla builtins etc, just needs extra code and testing tbh)

pointparticles+particleeffectnum+traileffectnum exist in fte and will function as you expect (small note: particleeffectnum acts as a precache rather than merely a lookup, so you should generally ensure its called at the start of the map or the client might ignore effects the first time they're used, due to packetloss) (additionally, trailparticles follows the original argument order, you can set dpcompat_trailparticles if you want compat with dp's reinterpretation of the builtin - or you can just use traileffectnum).
the names used can be scoped such that "myset.myeffect" will load 'particles/myset.cfg' and find the 'myeffect' effect if it has not already been loaded.
omitting the 'myset.' part will use particle sets only if they were named via r_particledesc (which can also explicitly override stuff like 'myset.myeffect', if needed).
if you specify a particle set named 'effectinfo' (either via particleeffectnum or r_particledesc), fte will attempt to interpret the dp-specific effectinfo.txt file. However, this is not well tested, is thus very likely to not be identical to DP (if you can pinpoint a difference, let me know that difference and I'll fix it), and is more limited than an fte-native particle effect.

[Seven]

Hello,

First of all I have to say, that I am really happy that Baker gave us the possibility of the subforum "Other Games". It is wonderful to have so many Hexen2 devs and modders/mappers/fans in one place.
I am not aware of other forums with such a great Hexen2 activity.


Now back to the topics:

1.) Movement speed
I am sorry that I my prior post was not good/exact.
What I wanted to say is:
With default configs all Hexen2 engines have this behaviour, that (when "always run" is enabled) you move faster when you push the forward button and then additionaly the sidestep button.
This may be also the case in the original Hexen2 engine, but isnīt this weird ?
When you run zick-zack you run much faster than only forward.

In Quake for example, this is not the case.
There seem to be an internal engine code that forbids to raise the speed when forward + sidestep is pushed together.
Isnt this also possible for Hexen2 engines ?

I use these button combinations a lot when dodging and moving around enemies. It is weird when I also boost my speed when pushing both buttons... Dont you think so ?

Yes, that code must consider the "Boots of Speed" movement raise (like szo mentioned), but a good coder can do this I guess



2.) UQE-Hexen2 V1.16
I know that my Windows XP is old, but that it doesnt get supported anymore out of the box is suprising
V1.14 still works with XP, so I am using this version (it works with Razumenīs mod Ravenhurst as it seems).
Thank you KrossX for uploading a "WinXP" build of V1.16, but the necessity of Visual C++ VS2012 Runtimes makes me still hesitate.



3.) Spider bug
Thank you for your fix szo.
I assume that it will be added to your actual V1.28 HexenC code ?

One more question regarding the version number V1.28:
When I start your HoT V1.5.6 it says in the lower left corner: V1.28
This is confusing, as I expected V1.5.6 in that corner (as the version of the engine should be displayed and not the HexenC version, no ?)



4.) Particle effects in Hexen2
Mathuzzz and KrossX mentioned the new particle effects from Veirdo for Hexen1 Mageīs weapons (for Doomsday engine).

That was one of the points that made me interested in modifying HexenC, as I know that Spikeīs engine can also create custom particle effects.
That would be FTE-only but I have to live with a similar restriction for a Darkplaces-only mod (for Quake). It is sometimes impossible to create something wich is engine independent...

Hello Spike,
Thank you for working on fteqcc at the moment.
The issue with Hexen2 compiling prevents me from using it, but I need it for the particle-thing, as it needs fteextensions I think.

I have one major question:
You already explained how it works to modify original Hexen2 particle effect names.
But I do not know how to add new custom effect names (DP calls them effectnumīs) in the HC-code for fte.
DP uses this QC line (example for coordinate-specific-particles):

pointparticles(particleeffectnum("my_custom_effect "), org, '0 0 0', 1);

And something like this for a particle effect which is bound to an entity:

self.traileffectnum = particleeffectnum("my_custom_effect");

Do you have similar possibilities/code-lines in fte ?
Which then could be used for torches or something.
Hexen2 has shootable torches, which is amazing.
Of course I could never ever reach comparable effects like Veirdo, but we can at least try.


Thank you all.
Seven

[KrossX]

As I mentioned Hexen 1, there is new model pack released, containing stunning weapons for Mage. Now when I look at all the brilliant particle effects, Hexen 2 weapons pale in comparison. Is it possible with available engines to create such particle effects?

View topic - Sapphire Wand • Doomsday Engine User Forums

Oh, it's been updated!

As Seven said, Veirdo is a pro and it shows indeed. I'm so glad of his work for Hexen.

[szo]

@szo
yeah that fix should avoid the invincible spider bug in all forms.
I still need to fix fteqcc though I think. those spiders shouldn't be so reliably invincible, I guess I never looked into it further cos its easier to blame someone else's code.

OK, commited the fix to svn at rev. 5225: http://sf.net/p/uhexen2/code/5225/[r5225]
And I actually was able to hit this issue myself: the first spider(s) at just the beginning
of the keep5 map of the expansion pack is a good testing place, especially at skill >= 3.
The patch seems to fix it.

(BTW, this isn't the only expansion pack hcode bug regarding careless use of entity
fields with aliases: Trigger field->dest2 aliases player->super_damage and it causes
a pentacle stuck in a door really invincible in the tibet1 map when using the original
progs: you can hear its irritating sound lasting forever. fixed back in uhexen2-1.5.0
similarly in T_Damage() - svn rev. 3951.)

[Spike]

@szo
yeah that fix should avoid the invincible spider bug in all forms.
I still need to fix fteqcc though I think. those spiders shouldn't be so reliably invincible, I guess I never looked into it further cos its easier to blame someone else's code.

@seven
sv_maxspeed is specified in hexen2's default.cfg so if its set to 320 then its picked up that setting from quake somehow (or the reset to defaults menu option failed to exec default.cfg? I dunno).
my fteqw installation gets 640 by default. :s

'not a valid win32 program' has so so many causes. including manifest dependancy issues, sounds like a missing dependancy. try opening it with depends.exe (from sysinternals, now a division of microsoft), it should give a hint as to what is missing.
/me hates windows manifest files, and being forced to use them (to avoid virtualstores) is not nice.
you can even try providing an empty foo.exe.manifest file next to foo.exe which should effectively null out the embedded manifest and any runtime-specific dependancies.
perhaps try installing the msvc2010 runtime, or whatever version of msvc he uses that you don't have installed yet.

regarding the give command, I should have said spiderActiveCount and not spiderPausedCount sorry, but pausecount=201 shows the union was honoured properly.

[Mathuzzz]

Seven, itīs not 64 bit. Default UQE 1.16 version does NOT support XP. Korax, however, uploaded several pages back a version, which was compatible with XP.

http://quakeone.com/forums/quake-tal...tml#post132177

[szo]

I just tested HoT 1.5.6 and you have this running/sliding issue (like almost all Hexen2 engines have):
When you run, your walking speed is 400.
When you run and push the sidewards button together, your speed will get 800.
So, you are much faster when you run in a zick-zack line.
FTE does not have this. The maxspeed is limited to 400 here.

To also limit the maxspeed to 400 in HoT or UQE or jshexen2 you have to asdd this line to autoexec.cfg:
sv_maxspeed "400"
Assuming that you use default movement values.

Would that not hinder the "boots of speed" thing?
(btw, sv_maxspeed default is 640 so you can go only up to 640 not 800, no?)

Have you tested the T_Damage() bug fix patch I posted?

Hello Korax,
I wanted to test your new engine V1.16, but it seems to be a 64-bit version only.

IIRC, Korax's UQE has never been 64 bit....