Who's responsible for static items? (jHexen RP)

predcon

Certain 2D static items in the original game, such as statues and torches, all rotate to face the camera. In the jHexen Resource Pack, the 2D items, which are now 3D items, all face in one direction. And by this I mean that all items of the same type face in the same direction, no matter where they are on the map. There's no real compass in the game, so I can't give you a cardinal direction, but I can show you a couple of screencaps taken from a room in the Darkmere area of Hub 2, exhibiting a couple of rows of Minotaur statues. Note that each row is directly across the room from the other, and also note my inability to find the "Take Screenshot" key, and try not to mind the console in the way.

Also, what attachment types are allowed? I've tried every image filetype under the sun, and I keep getting the "The extension xxx is not allowed" message.


Row 1 (Let's call it North)




Row 2 (South)

reg

predcon wrote:

Certain 2D static items in the original game, such as statues and torches, all rotate to face the camera. In the jHexen Resource Pack, the 2D items, which are now 3D items, all face in one direction.

Well, they all face east in the maps, because this angle is represented by zero in the map format, so it's the natural default in the map editor. The items in fact don't rotate, just that they only have sprites showing them from the front. Does this answer your question, as I can't understand what exactly are you asking?

predcon

I was saying that the 3D objects don't auto-face the player the same way 2D objects in the original game do. For instance, in the original Hexen, if you were to circle-strafe a statue or corpse or other static object, you'd only ever see one side of it. My question is "how do we fix it so that each 3D object is aligned properly"? It would probably involve someone going through and re-editing maps and making a patch. Or re-editing the "Decorations" flag menu in the addons selection interface. Right now, the only thing I can switch off is the whole "XCCP Decorations" package. There aren't any individual "Decorations" elements to choose from like there are for every other submenu.

Vermil

All non-player objects in the game world have one of eight facing directions; regardless of whether their sprites have rotations (this can be observed with the stage 2 map cheat).

Raven probably didn't pay any attention to the facing directions for objects that had sprites without rotations, since the facing direction of such objects had no visual effect on things.

The only solutions are to manually edit the maps to change the facing directions of these objects or to alter the model definitions to make the model rotate with the player (by adding df_alignyaw and/or df_alignpitch flags), like the original sprites.

predcon

Which is why I took the time to say "it would probably involve someone going through and re-editing maps and making a patch". Or, edit the Resource Pack's element selection menu, so that I can de-activate the static objects that aren't aligned properly.

Gordon

can't you set it so that it always faces the player like the JDRP dose for the sphere pick ups?

predcon

Which is why Vermil took the time necessary to say "The only solutions are to manually edit the maps to change the facing directions of these objects or to alter the model definitions to make the model rotate with the player (by adding df_alignyaw and/or df_alignpitch flags), like the original sprites".

DaniJ

However neither solution is ideal; A) statue models which rotate to face the camera will always look pretty poor and We can't edit the maps because the maps are part of the original game data, which we cannot alter and then redistribute.

In my opinion the only real options are:
A) Implement an algorithm within the engine that attempts to automatically rotate them in suitable direction (very unlikely we'd hit upon a method to obtain a 100% success rate).
Implement a feature within the engine which allows users to supply additional Thing rotation information which can be used to patch the maps after loading.

The ideal solution would be a combination of both; an automatic solution which works 90% of the time, with the facility for users to manually override when the automatic method fails.

skyjake

DaniJ wrote:

The ideal solution would be a combination of both; an automatic solution which works 90% of the time, with the facility for users to manually override when the automatic method fails.

I agree. In fact, once upon a time in the olden days I did implement an algorithm that rotates 3D objects away from walls, so that, e.g., the Heretic statues would not face walls and Hexen wall torches would have their support rods connected to walls. It seems somewhere along the way this logic has broken down... I should take a look and see what's going on.

predcon

Can the Resource Pack be altered in a way that will let me de-activate the enhanced versions of the statues? The only tickbox available for "Decorations" is, in fact, a package marked "Decorations". There aren't any individual elements to choose from, as there are with the other object subgroups (Monsters, Powerups, etc).

DaniJ

It certainly could be (like jDRP does), however I don't know who is currently in charge of maintaining these packs else I'd put you in contact with them.

mystique

wouldnt it be possible to fix this through special files like maphacks like eduke32 has?

i know eduke32 has the ability to read special .mhk files which allows to rotate all the objects in a map to the right angle

isnt it possible to implent something similar into doomsday?

DaniJ

Indeed it would be possible to implement something similar. I had already planned for something like this to be implemented at some point, which is the reason why the map converter plugin constructs a database of THING properties which exists on engine side, that the game queries after map load (giving the engine a chance to patch the defs).

mystique

neat. if it gets implented id gladly help rotate objects for maps correctly for heretic and hexen both

i always hated that objects in heretic and hexen were rotated incorrectly,
and you'd get statues facing walls and stuff like that when in-game )

so if the option for a filetype to rotate items correctly gets implented id gladly help to fix that for maps

predcon

Maybe this explains why the jHexen Resource Pack is several hundred MB's smaller than the HRP for eDuke32.

mystique

lol no, its more cuz the eduke32 HRP has everything in-game replaced with high-detail models and the XCCP doesnt even have half of in-game items and almost evertyhing is low-poly and low-detail

something like those mhk files eduke32 uses are just a few bytes each, so adding those will hardly make any difference at all in file-size, lol

it is the amount of models and textures it has and the detail to them which makes the eduke32 HRP so much bigger

predcon

What I meant was "Maybe the attention to detail, or lack thereof...." and so forth.

PostFatal

skyjake wrote:

DaniJ wrote:

The ideal solution would be a combination of both; an automatic solution which works 90% of the time, with the facility for users to manually override when the automatic method fails.

I agree. In fact, once upon a time in the olden days I did implement an algorithm that rotates 3D objects away from walls, so that, e.g., the Heretic statues would not face walls and Hexen wall torches would have their support rods connected to walls. It seems somewhere along the way this logic has broken down... I should take a look and see what's going on.

Is this algorithm still around? Am I wrong that these two models were made with stems facing different directions? Wouldn't that make such an algorithm impossible?


I remember going through maps with an editor trying to turn the torches only to watch them turn again before my eyes during testing when they changed state from unlit to lit. I got frustrated and quit.

DaniJ

Certainly if the models are built using inconsistent angles then it won't work as expected. Yes this algorithm is still in place.

PostFatal

DaniJ wrote:

Certainly if the models are built using inconsistent angles then it won't work as expected. Yes this algorithm is still in place.

Not being a modeler, I don't have the slightest idea how to change the angle on one model or the other. As for the algorithm, how is it activated? Or are you saying that it would already be working if not broken? Getting most torches aligned would help determine which model needs the angle changed.

DaniJ

The algorithm works automatically and aligns things according to the angle of the mobj. If the models are authored consistently then they should both align in the same way automatically. If not then the model(s) will need to be manually rotated.

GUN

Just an ask.

Why these both are 2 Models ?

is it not simplier to use the same model but only the second one with the flame effect ?

Milten

I guess because they are 2 different sprites as well, that is why they are 2 different models.