HEXEN II community work and discussion

[Seven]

Hello szo,

Thank you very much for your link.
The HCC compiler works fine.



Hello Mathuzzz,

Thank you for the information about uqehx2hcc.

Regarding the spider bug:
I played around and tested several constellations, to see why you do not face this issue, while I do.
My findings are:
Playing with a progs.dat compiled with HCC does not show this spider bug in the way that a progs.dat compiled with fteqcc V1.0 does.
Timing is important here.
In original Hexen2īs 1st map: Blackmarsh you have to run straight forward up the ramp, break through the glass and fight the spiders quickly.
You will encounter quite often (not always) with fteqcc V1.0 progs.dat that the spider will not die. Doesnt matter how long you punch it.
With HCC compiled progs.dat the spiders die as quickly as they should, except sometimes it takes more punches to kill them. But they keep always killable.

But nevertheless the spider "issue" is noticable in both compiled progs.datīs. While HCC does seem to handle it somehow better and the bug is not leading to an invincible spider here, so it is *almost* not noticable in-game.
Didnt test it with uqehx2hcc.
I used FTEQW and JSHEXEN2 for my testings (both engines show identical behaviour).

As mentioned above these are just my testing results...
fteqcc V1.0 is already 2 years old (I cannot use a newer version). Maybe things are different now.


Anyhow, it is good to be able to play around with HexenC now
I like many new features/possibilities of HexenC compared to QuakeC.

[szo]

Regarding the spider bug:
I played around and tested several constellations, to see why you do not face this issue, while I do.
My findings are:
Playing with a progs.dat compiled with HCC does not show this spider bug in the way that a progs.dat compiled with fteqcc V1.0 does.
Timing is important here.
In original Hexen2īs 1st map: Blackmarsh you have to run straight forward up the ramp, break through the glass and fight the spiders quickly.
You will encounter quite often (not always) with fteqcc V1.0 progs.dat that the spider will not die. Doesnt matter how long you punch it.
With HCC compiled progs.dat the spiders die as quickly as they should, except sometimes it takes more punches to kill them.

Maybe the damage inflicted has some randomness built into it and that'z why it may take some more punches to kill them.

But they keep always killable.
But nevertheless the spider "issue" is noticable in both compiled progs.datīs. While HCC does seem to handle it somehow better and the bug is not leading to an invincible spider here, so it is *almost* not noticable in-game.

I never actually ran into this bug: I believe fteqcc has some code generation bug. But I do not think that any issue is present with the binaries output by hcc.

[Spike]

regarding the spider bug, camera_time and spiderActiveCount are part of the same union and share the same offset.
if(targ.camera_time>=time&&!deathmatch)
[will cause the spider to be invincible, with a 'camera time %f' bprint in the released hc code]
if((self.spiderActiveCount += 1) > self.spiderGoPause && random()>skill/5)
[where spiderGoPause is initialised to 35 and reset to something between 16 and 32 later and spiderActiveCount reset to 0 if it passes]
if skill is set to 5 for some reason, the spider is pretty much guarenteed to be invincible thanks to its frame interval ticking faster than time and the spiderActiveCount (aka: camera_time) field never getting reset.
So even in a well behaved qcc, the spiders can be invincible at some point, but not normally much beyond 35 seconds into the game (higher skills will potentially extend that timer by a lot, and attacks can).
If they're invincible for much longer than that with fteqcc and not other hccs, chances are its the += operator 'returning' the wrong value (ie: 0), which can be tested for by spiders that do not pause in their attempts to get close to you.
If you want to check to see if the hcc sidesteps the issue by not honouring .unions, you can use the 'give camera_time' and 'give spiderPauseCount' commands in fteqw. if they say the same index then the .union was honoured, and they'll be different if the .union was not honoured (and spiders will never be invincible).
either way the other issues seven reported are more worrying.

[szo]

regarding the spider bug, camera_time and spiderActiveCount are part of the same union and share the same offset.
if(targ.camera_time>=time&&!deathmatch)
[will cause the spider to be invincible, with a 'camera time %f' bprint in the released hc code]
if((self.spiderActiveCount += 1) > self.spiderGoPause && random()>skill/5)
[where spiderGoPause is initialised to 35 and reset to something between 16 and 32 later and spiderActiveCount reset to 0 if it passes]
if skill is set to 5 for some reason, the spider is pretty much guarenteed to be invincible thanks to its frame interval ticking faster than time and the spiderActiveCount (aka: camera_time) field never getting reset.
So even in a well behaved qcc, the spiders can be invincible at some point, but not normally much beyond 35 seconds into the game (higher skills will potentially extend that timer by a lot, and attacks can).

Since this spider thing is getting attention, does the following patch fix it?

Index: gamecode/hc/portals/damage.hc
===================================================================
--- gamecode/hc/portals/damage.hc	(revision 5216)
+++ gamecode/hc/portals/damage.hc	(working copy)
@@ -796,7 +796,7 @@
 	if (!targ.takedamage)
 		return;
 
-	if(targ.camera_time>=time&&!deathmatch)
+	if (targ.flags&FL_CLIENT&&targ.camera_time>=time&&!deathmatch)
 		return;
 
 	if (targ.classname=="monster_yakman"&&targ.pain_finished>time)

[Seven]

Hello Spike,

Thank you for your post and explanation.

I did what you said to test this:

If you want to check to see if the hcc sidesteps the issue by not honouring .unions, you can use the 'give camera_time' and 'give spiderPauseCount' commands in fteqw.

if they say the same index then the .union was honoured, and they'll be different if the .union was not honoured (and spiders will never be invincible).

The values are always different (doesnt matter if I use the fteqcc or hcc compiled or original progs.dat):



But still, the behaviour is different between fteqcc and hcc compiled progs.dat (like I wrote above).



Hello 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.




Hello Korax,

I wanted to test your new engine V1.16, but it seems to be a 64-bit version only. There is only 1 UQE-Hexen2 download on your webpage.
I am using XP and UQE-Hexen2.exe tells my that it is not a Win32 application.
Do I have a chance to use your engine with Windows XP ?


Thank you,
Seven

[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....

[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

[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.

[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.)

[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.

[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

[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.

[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.

[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?

[webangel]

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