Actors which needs to be fixed or improved

[Ozymandias81]

After recently fixes done by AFA for the debris mound, we definitely need to see if actors can be improved or fixed once more, and possibly with this issue I'll keep track of problems noticed, so the list may be updated from time to time.

ALL THE FOLLOWING PROBLEMS NOTICED UNDER GZDoom g4.3pre-357-g1085287af 64bit

SOLVED ElectricalArc actors: their invisible puffs kills actors even where they shouldn't, and it happens for both variants (vertical/horizontal). As a test try on TEST_ACT map at the start, check your right side and walk along the walls until you are right down the ElectricalArc: you get killed, even enemies

SOLVED PlayerFollower actors: it seems that they can't climb or jump or in any case reach BJ if some actors or portals are in their way, noticed on C3M5_A when we kill all tanks and rendez-vous with Yevgeny. Sometimes when you are very far, the follower appears right behind you again and then all is good, but this would also prevent to have help from the follower in some situations. Also I didn't tested the prisoner on C1M2, but I heard from someone that it has similar problems on that map too behaviour-wise

SOLVED HeatEffectGiver inheritance with FireSpawner: Torm said that HeatEffect doesn't get removed when a FireSpawner gets deactivated or activated, but I can't reproduce it

SOLVED Debris_Wood_FloorCeiling actors: if they get hit from below, they doesn't "die", but just fall from where they are, like if gravity being set again (and also die since they are not shootable anymore). Jump inside the pool from TEST_ACT in front of you and aim to one of them

SOLVED Enemies behaviour in general with Portals: it seems that enemies aren't capable to see or target us if we stand in front of them "behind" an interactive portal. This is highly noticeable on C1M5 Hotel de la Mort restaurant and C3M5_A entrance to Chancellory

[Talon1024]

Regarding the FireSpawner, I was unable to reproduce the issue wherein the heat effect doesn't get removed when the actor is deactivated. I created a simple test map which allows the player to toggle a FireSpawner with a script, and I had no issues.

I used Thing_Activate and Thing_Deactivate to toggle the fire effects. I did not remove the FireSpawner from the map.

[Ozymandias81]

You are right, I simply reported what Torm said but neither I can't reproduce it. Gonna adjust that.

[Tormentor667]

Check the train area of C3M5_A. In one of the last train cabins before the crash and explosion happens, there is an inactive fire spawner. It adds the heat effect to the player screen despite being inactive.

[AFADoomer]

• Electrical arc issues should be fixed in fe940ce80176e34544c7ccdf1153240016f98a08.
• Playerfollower issues should be resolved as of db339d037f6cc6cd49dfd97e23dfe8dac957c402.
• FireSpawner activation problem should be fixed in 35edd0ad14ff4f1e7306fe94fb91c59f1a545bc0.
• Debris_Wood_FloorCeiling (and breakable vent and manhole cover) should be fixed in e332b74f549f17413c52eac5b3495ff51a0be9d0.
• The enemy behavior you're seeing with portals is normal for GZDoom with the portals configured as they were... If you want enemies to be able to see though a line portal, the line portal must be set to "Static (Eternity style)". Fixed for C3M5_A Chancellory entrance and C1M5 restaurant and salon entrances in 5971ff0c8003d8600c53cd3e205062a7947645bd.

[Ozymandias81]

About what Torm said, yes noticed that a while before you did the fix (which in the end was not possible to understand on my end due to zscript XD) Aaaand yes, all your fixes have been set as SOLVED , later will come with more in case I can't fix them (if I spot some). Atm busy with BlooM so expect some slow progress in November from me about BoA commitment, mainly to the fact that we are going to have another release near Christmas (brightmaps and actors rework from me)

[Tormentor667]

Awesome work guys :)

[Ozymandias81]

Okay guys here we go with some new stuff that's crucial and needs to be fixed, mainly from N00b tests at issue #178

ALL THE FOLLOWING PROBLEMS NOTICED UNDER gzdoom-x64-g4.4pre-65-g78bae1f16

• [x] Toilet soldier cause a crash when he wakes up from the toilet, happens for example on C3M5_C, there is only 1 of it so easily trackable (green door). Happens even playing the map normally.

  Should be fixed in 0d722ef1d31901dc0bcfc1e14f2b4b931b1fd490. - AFA

• [x] Being killed by Goebbels produce another crash, now into Playerfollower https://user-images.githubusercontent.com/59409713/74602804-c60cf380-50bd-11ea-945d-72b5cb973c05.png

  Should be fixed as of e9e2128e1b2adfa4427e2ebd16fd1e07c461345f (line 638 of the playerfollowers.txt commit). - AFA

• [x] MengeleBomb kills anyone, even invulnerable players or playerfollowers, and can also kill Mengele itself... Could be related to GrenadeBase since the decorate code doesn't have any issues

  The decorate code has issues. Check parameters on A_SpawnItemEx... You have 64 and 128 in the flags field for the ZyklonBCloud spawn calls. 64 is equivalent to SXF_TELEFRAG, so if the bomb goes off under an actor, they get telefragged... I can fix, but the bombs then do no damage, which I don't think is desired. - AFA

[Ozymandias81]

That's true, really losing track of some stuff here and there... And well MengeleBomb has not been added by me originally, will find a way to fix later then, thanks again for you fixes!

[Ozymandias81]

• [ ] I have managed to get one of the problems that N00b experienced with dying enemies: if you check the first 3 images from here you'll see that Scientist2 is dead but still behave as a living entity, he can't be killed though. It happened only once but on that particular zone I also got 2 crashes though, this with gzdoom-x64-g4.4pre-80-g9e5444f8a. Something related to the dodge feature maybe @AFADoomer ?

[Ozymandias81]

• [x] @AFADoomer Sorry to bother you again, but spot something odd: on C3M6_B go to this place and walk all over the courtyard, everything seems fine. But once we look down the well, I get 2 fps and that stays forever. If I freeze, fps turns again better, but once I unfreeze slowdown happens again. If I remove the rope and its target, I don't get any slowdown, maybe something not set correctly on map for those actors or is the target too far from the rope? Or is it something different? Tested with r082 of gzdoom. RopeSegment is the actor that decrease performance, if I set a lenght happens the same (tried with 1024, but there were 257 ropesegments).

[AFADoomer]

It's because there are a crap-ton of bats in the well that are all trying to interact with the rope all at once. Remove the bats via 'remove batfamiliar' of 'kill all' or whatever, and there's no lag.

If we want to keep the effect of all of the bats flying out of the well, we need to get rid of the rope and figure out some other way to keep the player from falling down the hole...

[Ozymandias81]

Well forgot to say that I did my tests with and without bats, and without bats slowdown occurs once you try to interact with the rope with Use key, while going down. I am aware of the remove thing and at first glance thought it was that (where also the ropespawner explains that any actor which has ISMONSTER flag set, its interactivity is negate, unlike playerfollowers).

On a total different note, could it be possible for playerfollowers to cure players once we have less than 25hp? That could improve gameplay and turn battles less stressfull (obviously this shouldn't happen when morphing into tanks, but implement this only if you think that shouldn't haul thinkers). And about the slowdown I get on c1m4, it seems related to whizzer checks, since I noticed that thinkers jumps from 5-6 to 70-80 for each shot which crosses near me and enemies

About bats I think I'll adopt a different trap, where they spawn from angles somewhere and gets pushed towards the player, like with c1m6 smokemonster battle plus add a candle at the bottom of the well as clue for something there

[AFADoomer]

I get no slowdown when the bats aren't there. Climbing has never worked well inside of the well because there's barely enough room for the player to fit beside the rope, but I don't get lag.

EDIT: OK, found the problem. Every segment of the rope was ticking all at once, instead of detecting that they are in a vertical stack and letting the top segment do all of the ticking. Not sure when this broke, but it works well enough now.

The playerfollower (Ascher specifically) already cures the player once he's below 40 health. Set the heal trigger threshold via the 'PlayerFollower.HealPlayer' property.

For C1M4, the whizzer checks are part of the problem... Overall the slowdown is caused by the number of enemies active at once on the upper surface of the dam, all with line of sight to the player, all firing tracers at once. I don't get any lag, but I can see the high think times - I might be able to tweak enemy firing so that enemies respect MaxTargetRange and don't ever fire if they're outside of that range - which would probably be more realistic, but also might break other maps. This map was already the reason that I ZScriptified the tracer actors in order to optimize them... The first part of the map was nearly unplayable before that.

EDIT: Added MaxTargetRange to Nazi class, kept unlimited range for snipers and bosses.

[Ozymandias81]

Sorry for the health thing, since I am not the one who maps wasn't aware of that variable XD , but well not then some maps may use it and for a good reason. Will test C1M4 asap and tell you how it goes now, thanks :)

EDIT: Looks like the problem is still there, I even tried to remove splashes, but at least now enemies doesn't have a bullseye... Maybe there is something that has MOVEWITHSECTOR somewhere and slowdown the performance?

[Ozymandias81]

Okay @AFADoomer the problem comes from @Tormentor667 changes to the map somehow, since with this commit I don't have any issues with thinkers... Wonder what is it though, maybe the ladder with the portal?

EDIT: Here the proof: C1M4_A is the old map that comes from that commit I said, and as you can see thinkers (sorry that stat values doesn't fit the screen, but there are fps on top right) goes from 20 to 60/70ish maximum, even in crowded zones. Instead with recent C1M4 (which has spotlights) it start with 40-60 and then once I shoot or an enemy sees me it jump to 100-300

[Tormentor667]

Regarding C3M6_B: It's okay for me to remove the bats from the well or the rope and block the player, it's not really needed.

Regarding C1M4: The commit you linked is your own commit, I am not sure if you really mean that?

[Ozymandias81]

What I mean is that before your recent changes to the map, there were no stuttering problems, even using actual code for enemies which is demonstrated on the video. If you check c1m4 history, the map I used is the last commit I did for it then after that you did edits to the map. Why I am saying this? Well it is simple: I don't know exactly how many changes have been done to the map but the last I was aware of the ones done on my last commit for such map. So I assume that you have probably included something on the map that involuntarily have compromised map performance.

About the rope thing: it is fixed now, I will edit the well but keep the secret which is cool and also important for the player, specially after fighting all those bats (they'll come from another zone directly inside the courtyard, and also add block monsters lines over the well just to be sure)

[Tormentor667]

I can only imagine that the portals are the problem

[Ozymandias81]

Yes, it is caused by the first portal with the ladder going down, I tried removing actors from both portals but didn't solve the issue, but if I remove said portals everything runs fine... Later I'll figure out what to do. The other portal works fine (last flak zone)

[Ozymandias81]

Fixed C1M4 but there is a zone where riflemen doesn't see nor aim at you (it was the same even before my changes, but actors where less reactive since they had Ambush Player flag, now not set)

[Username-N00b-is-not-available]

@AFADoomer, @Ozymandias81, @Talon1024:

The code which is concerned with throwing projectiles in the Doom engine behaves quite simplistically. It is non-Newtonian, which is even more noticeable in BoA: for example, if you move with a constant velocity, do not turn and then try to shoot, you can see the projectiles diverge from the 'center of the screen', i. e. the line of fire (see video: weapons.zip). In this case the player's reference frame should be inertial, but it isn't.

I propose to add the shooter's velocity to the projectile's after spawning, so that the movement is more realistic. For monsters there will be no point in adding this, as they always stand still while hurling missiles (at least in original Doom; and, apparently, most of the basic enemies in BoA also do so), but for the player the improvement will be noticeable; as all their projectile weapons all shoot in a straight line (or don't they?), this will be a significant change. Also, as a first-order approximation this will fix the problem with Tesla Cannon to some extent (shown in the video).

The manipulations to accomplish the goal are quite simple, you can just change every instance of

A_FireProjectile("SomeTypeOfBullet", ...);

in the weapon code to

let bullet = A_FireProjectile("SomeTypeOfBullet", ...);
if (bullet) bullet.A_ChangeVelocity(vel.x, vel.y, vel.z);

I can do this myself, I just want to know if the team is interested in such things (and I am not just adding this feature because there may be some magic tricks with projectile velocity in BoA code I do not know about, and so I might break them by implementing this).

P. S. By the way, seeing one of my previous proposals (with tanks) uncovered that it was a shitty idea, like any other one in most situations, the turret movement is inadequate (for example, if a tank stands in a long 'corridor' such as the second one in C1M0, and the player strafes much while running to it, the tank just shoots at the walls). The algorithm should probably be enhanced: since we already have InterceptTarget, it would make sense to 'move' it to the position (like a solid object, considering every obstacle on the way) instead of 'teleporting': https://github.com/Realm667/WolfenDoom/blob/492e904730b7096374ee460a80ebfa045325318e/scripts/actors/enemies/tanks.txt#L594

[Tormentor667]

I am okay with this change if @AFADoomer approves this.

[AFADoomer]

For simplicity's sake, I updated the base class that all of the player's bullet projectiles inherit from to account for velocity instead... Also made a few other tweaks for pseudo-realism.

Adding velocity to the Tesla cannon lightning fixes nothing; trust me, I've tried it... I re-added it because, why not... I think it makes things worse.

I'm not sure what you want from the tanks... Strafing sounds like a fantastic way to avoid having a tank aim at you, so this sounds like intended behavior.

For any changes to the intercept code, I'll have to defer to @Talon1024 .

[Username-N00b-is-not-available]

@AFADoomer: thank you for the addition!

I noticed a slight problem, though: if a bullet (for example, from kar98k) hits some enemy, it changes its pitch considerably (managed to capture the moment). This is even more noticeable with rapid-fire weapons. fixed quicker than I wrote the message.

Screenshot


Regarding Tesla, maybe the model just needs to be spawned or warped more often (didn't see the code for it), anyway it definitely is not the main goal for now.

As for tanks, I mean this.

Screenshot + madskillz

 

Also, FastProjectile's velocity can be modified this easily? Then, maybe there is a hack proper way to remove action of +NOGRAVITY on it?

[AFADoomer]

Ah, OK. I see what you mean. I don't know that there is a good way to make that change...

Rather than remove NOGRAVITY from the projectiles, I already added a slight downward velocity over time that scales with the projectile's speed (so that I can control the speed of fall, so that faster projectiles fall more slowly).

And with standard gravity the bullets will most probably hit the ground too fast. 15.0 / speed serves this purpose well, I just wanted to ask about the possibility. --N00b

Yeah, it was intentionally done this way... Could probably also remove NOGRAVITY and change the projectile's gravity amount, but... Same effect. - AFA