67418ff96d6e9

67418ff96f37d
24 Guests are here.
 

67418ff96fde3sarge945

67418ff96fe61
Honestly the best thing they could realistically do to improve the life and longevity of the game is release the SS2 source (or preferably, the NewDark source). But I doubt we're going to see that, there's too much money to be made from "enhanced editions"
Acknowledged by: bombum

67418ff97040eZylonBane

67418ff97049f
But a port of a game from one system (the PC in this case) to a different system (modern consoles) doesn't seem to me to be accurately described by "Enhanced Edition", somehow.
A port of a game from one system to another is called... a port. The "Enhanced Edition" business refers to the improved assets. They could have called it Enhanced Edition even if they were just sticking with NewDark.
67418ff9706f6
hello, it seems you want also to include fan translations for this enhanced edittion, I am almost finishing the translation for portuguese and if you want to include in the game here is the link https://github.com/luigge/Traducao-SystemShock2-PT_BR

also if theres anything on this repository you want written in english for better understanding, I can translate it.

67418ff970a71eldrone

67418ff970ac7
hello, it seems you want also to include fan translations for this enhanced edittion, I am almost finishing the translation for portuguese and if you want to include in the game here is the link https://github.com/luigge/Traducao-SystemShock2-PT_BR

also if theres anything on this repository you want written in english for better understanding, I can translate it.

Muito obrigado!

Making a note of this one! Our lead developer is brazilian, and so is my wife! I'm currently working from Tocantins this summer.
67418ff970e85
If Dark Souls Remastered is anything to go by, sometimes "remastered" means "literally the original version again with a community fix applied"
Dark Souls Remastered looks considerably worse than the dsfixed original, as they had to go from a beta version with messed up lighting.
« Last Edit: 05. July 2024, 14:31:04 by Marvin »

67418ff97111csarge945

67418ff971175
Dark Souls Remastered looks considerably worse than the dsfixed original, as they had to go from a beta version with messed up lighting.

Wow I did not know about the lighting issue. Can you provide some examples?
67418ff971328
That's my best guess, it's hard to fuck up that much on purpose. Thought that was common knowledge: https://www.reddit.com/r/darksouls/comments/89it7e/remastered_worse_armour_textures_and_lighting/

If you have some time to kill: https://www.youtube.com/watch?v=n2eos3V7jTI

An actual port of the 2012 original was indeed made.. for Switch: https://www.reddit.com/r/NintendoSwitch/comments/9hquui/dark_souls_remastered_on_switch_reverts_all/
« Last Edit: 05. July 2024, 14:36:41 by Marvin »
67418ff971655
Kolya
Suddenly, I came across another archive disc found in my storage, which has all videos from the early Robotkid's website. And the mentioned colonoscopy recording is... IN THERE!!

https://drive.google.com/file/d/1QFwsFh2mVFkaChwGvxCmdP-P0lp5BuwB/view?usp=sharing

It's clearly a vhs rip, and it was downsampled to 1 fps for a reason. But that's the actual file that was presented to the public. Maybe not safe for work.
Acknowledged by: unn_atropos

67418ff9719c4voodoo47

67418ff971a11
I've read that in the StarCraft1 ghost voice.

and I think I'm going to pASS on that.

67418ff971bcfsarge945

67418ff971c1f
I've read that in the StarCraft1 ghost voice.

Did somebody call for an exterminator?

67418ff972366eldrone

67418ff9723c5
Just a tiny update on things, and this will be more on the technical side this time.


There's work going into figuring out various weird quirky limitations, I've been deep diving into the workings of the engine for months now.
And these words will be as is and can't be taken as definite (things can change):



How mods are being combined and prioritized are being worked over a bit more, such as possibility of combining string files in a better way.

Looking into .dml's and having them be applied in mod order to avoid having to worry about patch-dml's of vanilla patching mod gamesys.

Materials now fully work on ai meshes just as they do on static meshes.

envmaps/cubemaps/incidence now uses normals of objects and are drawn in one pass, no more faceted objects (but you can still split up edges to get proper normals here) (incidence is absolutely amazing and was completely unusable in newdark previously)

more dynamic script application is being discussed (first empty script slot etc), and a way to concatenate arguments in the script argument properties via .dml's, so you can add or replace a previous script arg.

Personally I've been looking as much into the viewmodel (arm and guns) as I can, and concluded it should be possible to bypass weapon stuff and make custom weapons that don't have to follow the limitations of the hard coded system.

The new weapon stuff currently parses all the information from weapon properties, as well as a few additional NVscript args to build up the new viewmodel, and it's entirely in squirrel, this allows for post fire ejection of shotgun shells and can be extended to anything imaginable.

I'm doing some research into making melee weapons more easy and flexible, including an idea to have the melee weapon viewmodel pick the world model and attach it to an empty handed viewmodel, so that new melee weapons could be implemented without having to touch rigged meshes.

There'll be a toolset  (collection of scripts and batch files) I hope I can release in the future to make asset-exportation way more seamless than it is now, I have it down to one .bat file to export models from blends, textures from .psd's, animations, scripts, dml's, compile a motiondb and copy them all into a modfolder, in just two clicks, and the setup is just a single config file.

Right now the enhanced asset stuff is very likely to depend on SCP to work, and it's waay more extensive than was planned in the beginning, but as always: SCP (and the other mods) are fine without it.



There's a lot of things going on behind the scenes as always, everyone is very busy, so I appreciate everyones patience, and the contributions that makes this possible.
Acknowledged by 2 members: ZylonBane, voodoo47

67418ff9726a8ZylonBane

67418ff972706
envmaps/cubemaps/incidence now uses normals of objects ... no more faceted objects
They always used object face normals. I'm guessing you mean they now use the Gouraud normals.

you can still split up edges to get proper normals here
Seems like it would be preferable to extend the MTL syntax to allow selecting whether face or Gouraud normals are used for a material.

incidence is absolutely amazing and was completely unusable in newdark previously
Well that isn't true. Its utility may be limited, but it's perfectly functional in NewDark. For example you can use it to make screens fade out when viewed off-center, simulating the display characteristics of LCD panels. I've used it to simulate snow sparkle, by making bright pixels appear and disappear on the surface as the player moves around.

Since EE is essentially using an all-new renderer, would it be safe to assume that the glitches when Gouraud-shaded and non-rectilinear textured polygons are partially offscreen no longer exist?
67418ff972c38

Looking into .dml's and having them be applied in mod order to avoid having to worry about patch-dml's of vanilla patching mod gamesys...

Personally I've been looking as much into the viewmodel (arm and guns) as I can, and concluded it should be possible to bypass weapon stuff and make custom weapons that don't have to follow the limitations of the hard coded system.

The new weapon stuff currently parses all the information from weapon properties, as well as a few additional NVscript args to build up the new viewmodel, and it's entirely in squirrel, this allows for post fire ejection of shotgun shells and can be extended to anything imaginable.

I'm doing some research into making melee weapons more easy and flexible, including an idea to have the melee weapon viewmodel pick the world model and attach it to an empty handed viewmodel, so that new melee weapons could be implemented without having to touch rigged meshes.

Hypothetically, does this also mean you can decouple arm models from weapon models, so a mod can now reflect a player career choices/level actions? So you could have a Navy arm-sleeve for players choosing Navy, a different Psi arm-sleeve for Psi players etc? If so, that'd be fantastic news. I know there's newer SDKs for Half Life 1 that allow this e.g. mappers can now more easily have the player use scientist arms, then change them to HEV arms, when the player gets a HEV suit later on.

There'll be a toolset  (collection of scripts and batch files) I hope I can release in the future to make asset-exportation way more seamless than it is now, I have it down to one .bat file to export models from blends, textures from .psd's, animations, scripts, dml's, compile a motiondb and copy them all into a modfolder, in just two clicks, and the setup is just a single config file.

Absolutely, please release those tools if you can: there'll be a whole new audience checking out Enhanced Edition & thus potentially a new generation of modders, so easier to use tools, would be a godsend. Even if we have to pester Nightdive on your behalf, hopefully it won't come to that!

On another note, I know I'm the dumb, incredibly naive ideas guy, there's a ridiculous amount of complexity involved and so on. You've said here previously, that the Half Life 1 method of "put a skeletal animation joint on the mouth, with the audio file volume controlling its movement" won't work on the vanilla models, as there's not enough space on the vanilla models for such a method, which is 100% fair and valid. No point in having a solution that doesn't work both with vanilla and enhanced models!

However...for very obsessive/determined modders who don't mind deliberately breaking vanilla model compatibility, would it possible to add in a mouth joint, that's not working in the game only due to an deliberate "typo" in the code? So for FM authors or campaign modders, they can easily fix the "typo" to enable it, albeit it'll obviously only work with Enhanced Models? HL1's method allowed for both plain maps & vastly more expansive mods, to implement custom dialogue very easily. Just make the custom sound file in the required format and voila: no need to muck around with face posing, syncing up mouth movements etc like in later games. Plus it's from 1998, so it'd be era appropriate for the level of graphic fidelity Enhanced Edition is going for.

67418ff97313celdrone

67418ff973196
They always used object face normals. I'm guessing you mean they now use the Gouraud normals.

They didn't use any information from the model, it created a new polygon per polygon, flat shaded.

Now it's always using the normals of the vertices and drawing it in one pass, so you can have any combination of smooth and flat shaded surfaces, so safe to say a flat surface is still going to be a flat surface.

Seems like it would be preferable to extend the MTL syntax to allow selecting whether face or Gouraud normals are used for a material.
Well that isn't true. Its utility may be limited, but it's perfectly functional in NewDark. For example you can use it to make screens fade out when viewed off-center, simulating the display characteristics of LCD panels. I've used it to simulate snow sparkle, by making bright pixels appear and disappear on the surface as the player moves around.

It's up to the model data. If it's an entirely smooth shaded model, it'll be treated as such, and if it's a hardshaded cube or similar by design, it will be so.

Since EE is essentially using an all-new renderer, would it be safe to assume that the glitches when Gouraud-shaded and non-rectilinear textured polygons are partially offscreen no longer exist?

Yeah, I think that's the case.

There's been a bunch of optimizations in this area, but I can't go into specifics.
Kex is a framework, a sort of layer, so most of the work has been in actual dark engine code.

One thing for example is that I've made all doors actual properly shaded objects with hard edges where you would expect them to be, and you're very likely aware of what happens when you change doors from a smooth shaded object to one with hard edges where the side of the door is a flat surface instead of a gouraud rounded blob.

67418ff97374feldrone

67418ff9737b6
Hypothetically, does this also mean you can decouple arm models from weapon models, so a mod can now reflect a player career choices/level actions? So you could have a Navy arm-sleeve for players choosing Navy, a different Psi arm-sleeve for Psi players etc? If so, that'd be fantastic news. I know there's newer SDKs for Half Life 1 that allow this e.g. mappers can now more easily have the player use scientist arms, then change them to HEV arms, when the player gets a HEV suit later on.

Absolutely, please release those tools if you can: there'll be a whole new audience checking out Enhanced Edition & thus potentially a new generation of modders, so easier to use tools, would be a godsend. Even if we have to pester Nightdive on your behalf, hopefully it won't come to that!

Most of it is batch-scripts to work with already existing exporters for blender for example, it could work with any kind of exporter.

It sort of parses a blender scene for collections, and uses their name and other information, then passes that on to the actual exporter and does a behind-the-scenes exporter without the dialogue window.

So I just keep a collection with the name of the .bin file, and the config just sets up the path to whichever mod folder I'm using.


But on arms: Yeah, technically it's already decoupled and could be material-changed to have different arm textures, but that requires a bit more work, but the arms just use one texture now for both melee weapons and ranged weapons.

On another note, I know I'm the dumb, incredibly naive ideas guy, there's a ridiculous amount of complexity involved and so on. You've said here previously, that the Half Life 1 method of "put a skeletal animation joint on the mouth, with the audio file volume controlling its movement" won't work on the vanilla models, as there's not enough space on the vanilla models for such a method, which is 100% fair and valid. No point in having a solution that doesn't work both with vanilla and enhanced models!

However...for very obsessive/determined modders who don't mind deliberately breaking vanilla model compatibility, would it possible to add in a mouth joint, that's not working in the game only due to an deliberate "typo" in the code? So for FM authors or campaign modders, they can easily fix the "typo" to enable it, albeit it'll obviously only work with Enhanced Models? HL1's method allowed for both plain maps & vastly more expansive mods, to implement custom dialogue very easily. Just make the custom sound file in the required format and voila: no need to muck around with face posing, syncing up mouth movements etc like in later games. Plus it's from 1998, so it'd be era appropriate for the level of graphic fidelity Enhanced Edition is going for.

Like anything, any improvements in these areas would require ripping out the entire skeletal mesh system in dark engine, which is not the easiest feat, and I've already bumped into so many areas where I wish I had this ability.

67418ff973971eldrone

67418ff9739c0
ZylonBane
But as an example: Here's one test .bin I used to see that these things were working properly (and yeah, I know, cubemap orientation is borked atm):

67418ff973aa1ZylonBane

67418ff973af1
Impressive. And yeah, Looking Glass/Irrational did like to use Gouraud shading on large flat surfaces to crudely simulate per-pixel lighting.

67418ff973c99eldrone

67418ff973d00
Impressive. And yeah, Looking Glass/Irrational did like to use Gouraud shading on large flat surfaces to crudely simulate per-pixel lighting.

gouraud was pretty much standard at that time, but what they didn't want to do was split up edges because they likely were very strict on the vertex budet.

Splitting up an edge would require unique vertices for both sides of that hard edge.

67418ff973e7dsarge945

67418ff973ecd
Honestly, the big feature us modders need is proper string file support and the ability to add custom sounds.

Adding scripts to the last script slot dynamically is cool and all, but already somewhat doable with some script hacking. It's pointless unless we also have DML concatenation for properties like DesignNoteSS so that script parameters can by preserved between mods without being overwritten.

Please see my DML Wishlist for more information about this and other limitations.

Also, I can't edit that post for some reason, but another thing to look into is making objects created via DML have actual collision and work properly. Currently, objects like crates created via DML can be walked through as if they don't exist, and if you ever cross the 0,0,0 location in the map, will instantly teleport to 0,0,0 and become solid. This desperately needs fixing. The current workaround is to spawn a marker where you want your object to be via DML, and then either using NVScript or some custom squirrel to actually spawn the object at it's location, which is tedious and annoying.
« Last Edit: 18. November 2024, 12:32:29 by sarge945 »

67418ff973fb8voodoo47

67418ff974007
yes, this is the dml phys props limitation. also you should be able to edit that post now.

not aware of any issue with adding sounds though? I mean sure, they have to be in that annoying ADPCM format, but that's not a big deal. maybe you mean the sound schema count limit?

Your name:
This box must be left blank:

The deck number where you shall meet Dr. Janice Polito:
24 Guests are here.
I am a string, yet not the hand.
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
67418ff977f85