how much of DFU is moddable at the moment?

[Turalyon]

So i've really been digging this project so far, and despite the modding scene not yet taking off, I really wanna take a shot at creating my own overhaul for it. Specifically, I want to replace all the 2D sprites in the game world with 3D models (and for the NPCs/Monsters/Player with new animations) unfortunately it seems like the current modding support doesn't cover that kinda stuff so I'd like to hear how much of the core game is modifiable at the moment.

Can I replace NPCs/Creatures/Player with 3D models that have custom animations and AI? Is it possible to add more detail to randomly generated terrain or new biomes? what about new buildings or replacing older ones? and can I just drag and drop in assets for scenes or objects made with unity into the game and have it work fine? or is there some complicated process of having to work in unity with a very specific way to get stuff not originally made for daggerfall working in it (specifically for C# scripts). Is there any custom syntax or coding language I'll have to follow or does the standard C# workflow work fine for DFU?)

[l3lessed]

Much of the core game is completely accessible and modifiable. Technically, if it can be coded into unity, it can be put into the game. The question is, what is exposed openly to the modding system itself, and what would require you submitting your own branch changes for future DFU Engine updates. Or, if need be, you can release a separate build that changes the core files to meet your project needs; that is what I'm doing currently, until I can either get the changes into a future branch or the modding system makes the assets I need accessible coding wise.

I can tell you the modeling area isn't as simple as just replacing assets. The original game was developed when 3D modeling was in its infancy in general, and was literally showing up in games for the first time in history. As a result, it was not designed with any consideration to 3D models and animations, unlike modern games, where you can plug and play these assets easily because almost every engine now uses 3D space and modeling as its base for its rendering systems.

However, they are getting close to finalizing the first 3d model replacer for non-combat NPC's.

However, to get 3d model replacement for any npc that can engage in combat, we need to rewrite the enemyAttack.cs script and a number of other ones. These scripts, because of how the original engine worked, rely on the frame/animation state to trigger certain codes. However, modern 3d animation systems weren't built with the concept of using individual sprite frames since you're talking 60FPS animations.

This is the same with the hand and weapon models. I have worked heavily in this area for 2 years now creating a project that smooths out the 2d attack animations using modern coding tricks. You run into the same issue here with importing in 3d models. The combat system, especially for the first person/player, is intricately tied to the animation system, which uses a 5 frame count. You can't remove/replace the sprite system without rewriting the FPSWeapon, WeaponManager, and other script files to update the engine code to work with and trigger properly during a 3D Animation.

The one good note on the First Person weapon side is I've already programmed in a dynamic raytrace arc calcuator to simulate and detect the physical arc of a weapon and if it would hit something. This is the first big step to getting in first person animations. I do hope to, at some point in the near future, start taking a crack at setting up the script and importing in first person models and animations.

Here's my project revamping the weapon animation and combat system by recoding core script files and setting up a completely different build from base DFU; You can also find tons of info on the first person combat system in it.
viewtopic.php?f=14&t=2533

Here is the current work being done on 3D model importing. Again, this is only for non-combat NPCs currently because of said limitations above.
viewtopic.php?f=14&t=3594

[Turalyon]

Much of the core game is completely accessible and modifiable. Technically, if it can be coded into unity, it can be put into the game. The question is, what is exposed openly to the modding system itself, and what would require you submitting your own branch changes for future DFU Engine updates. Or, if need be, you can release a separate build that changes the core files to meet your project needs; that is what I'm doing currently, until I can either get the changes into a future branch or the modding system makes the assets I need accessible coding wise.

I can tell you the modeling area isn't as simple as just replacing assets. The original game was developed when 3D modeling was in its infancy in general, and was literally showing up in games for the first time in history. As a result, it was not designed with any consideration to 3D models and animations, unlike modern games, where you can plug and play these assets easily because almost every engine now uses 3D space and modeling as its base for its rendering systems.

However, they are getting close to finalizing the first 3d model replacer for non-combat NPC's.

However, to get 3d model replacement for any npc that can engage in combat, we need to rewrite the enemyAttack.cs script and a number of other ones. These scripts, because of how the original engine worked, rely on the frame/animation state to trigger certain codes. However, modern 3d animation systems weren't built with the concept of using individual sprite frames since you're talking 60FPS animations.

This is the same with the hand and weapon models. I have worked heavily in this area for 2 years now creating a project that smooths out the 2d attack animations using modern coding tricks. You run into the same issue here with importing in 3d models. The combat system, especially for the first person/player, is intricately tied to the animation system, which uses a 5 frame count. You can't remove/replace the sprite system without rewriting the FPSWeapon, WeaponManager, and other script files to update the engine code to work with and trigger properly during a 3D Animation.

The one good note on the First Person weapon side is I've already programmed in a dynamic raytrace arc calcuator to simulate and detect the physical arc of a weapon and if it would hit something. This is the first big step to getting in first person animations. I do hope to, at some point in the near future, start taking a crack at setting up the script and importing in first person models and animations.

Here's my project revamping the weapon animation and combat system by recoding core script files and setting up a completely different build from base DFU; You can also find tons of info on the first person combat system in it.
viewtopic.php?f=14&t=2533

Here is the current work being done on 3D model importing. Again, this is only for non-combat NPCs currently because of said limitations above.
viewtopic.php?f=14&t=3594

Hmmm, interesting. So you're saying that most of the game IS moddible, but it'd require you to edit the source code and engine or whatever for DFU to allow more substancial changes to the core function of the game and it's limitations beyond the current version that's adherent to the way daggerfall functioned on launch.

Will I need the separate source code for the project, or can I edit all of the core engine within the unity editor itself? how should I go about creating and editing my own github fork or whatever for the project that my team and I can work on? because I'm not too familiar with how to set up a project like this, but I plan on potentially hiring and working with a few people I know who'd love the challenge of rebuilding and expanding a core game like this.

I should be able to remake the core scripts to allow for more 3D models and animations along with more advanced systems beyond the limitations of daggerfall (like for locations and shit) so lemme know if that's something within the realm of possibility right now

[MasonFace]

. . . I plan on potentially hiring and working with a few people I know who'd love the challenge of rebuilding and expanding a core game like this.

If you're planning on spawning a commercial project from DFU, I suggest you take a look at this thread. It may give you some pointers on where to start and some pitfalls to avoid.

Will I need the separate source code for the project, or can I edit all of the core engine within the unity editor itself? How should I go about creating and editing my own github fork or whatever for the project that my team and I can work on?

Go to the DFU source GitHub page and fork the project. There is a "fork" icon at the top right of the GitHub page. You'll need to be logged into GitHub in order to do it. Then download (or "clone") this new forked project onto your computer and open your cloned project in Unity. It's a little outdated but there is a tutorial here. Once these files are on your computer, you can edit them however you wish without effecting the main DFU repository.

[Turalyon]

. . . I plan on potentially hiring and working with a few people I know who'd love the challenge of rebuilding and expanding a core game like this.

If you're planning on spawning a commercial project from DFU, I suggest you take a look at this thread. It may give you some pointers on where to start and some pitfalls to avoid.

Will I need the separate source code for the project, or can I edit all of the core engine within the unity editor itself? How should I go about creating and editing my own github fork or whatever for the project that my team and I can work on?

Go to the DFU source GitHub page and fork the project. There is a "fork" icon at the top right of the GitHub page. You'll need to be logged into GitHub in order to do it. Then download (or "clone") this new forked project onto your computer and open your cloned project in Unity. It's a little outdated but there is a tutorial here. Once these files are on your computer, you can edit them however you wish without effecting the main DFU repository.

awesome, thanks for the help man. One of my first goals is to rewrite the scripts involving NPC/creatures to use standard 3D methods of animation for models rather than the frame-based 2D sprite animation states. I know that the enemyAttack.cs, FPSWeapon, WeaponManager are among the scripts I'll have to rewrite but what other stuff will I need to change or overhaul to have 3D characters and monsters function cohesively in DFU without the base of frame states? and do you have any tips on how to rewrite or get pre-written code involving 3D NPC behavior and animations to work within DFUs mechanics and general engine?

I will likely be getting professional help with this of course, but while I'm a skilled designer, my programming knoledge in unity is somewhat limited, so I'd like to know how exactly DFU goes about working with the 2D sprites animations states and how they interact with the mechanics of the game, as well as some tips on replacing those scripts with a more modern model based one that works within DFUs engine.

[MasonFace]

You will need to modify the DaggerfallMobileUnit script. It is in charge of displaying the correct animation frame on the sprite object, among other things.

You'll need to get a reference to the MobileUnitSummary, in particular its State, then set your 3D model's animation to to that state using an Animator Controller.

You should then be able to scrap some functions like "UpdateOrientation()" and "OrientEnemy()" since you will have no need to set the image of a sprite based on what direction they're facing.

I'm sure there's more to it than that, but I think what I've said is accurate.

[Turalyon]

You will need to modify the DaggerfallMobileUnit script. It is in charge of displaying the correct animation frame on the sprite object, among other things.

You'll need to get a reference to the MobileUnitSummary, in particular its State, then set your 3D model's animation to to that state using an Animator Controller.

You should then be able to scrap some functions like "UpdateOrientation()" and "OrientEnemy()" since you will have no need to set the image of a sprite based on what direction they're facing.

I'm sure there's more to it than that, but I think what I've said is accurate.

I see, interesting. It seems like it'd be fairly easy for me to work out, but I feel like the best method would be to rebuild those scripts from the ground up with a more standard 3D focus rather than just editing/fixing the current scripts to work with 3D. Would that be a viable option to create an entirely new system for animating NPCs and stuff that uses 3D models instead of 2D sprites? or could that potentially break a ton of other stuff if the current scripts are gotten rid of and replaced?

[MasonFace]

Would that be a viable option to create an entirely new system for animating NPCs and stuff that uses 3D models instead of 2D sprites?

I'm not sure. I think I would just modify it instead of starting over, but it could be accomplished either way.

[l3lessed]

Just due a full project object reference on the script and its objects/classes to track down how intertwined the script is with other scripts/parts of the engine. As long as you ensure required connected script objects are still present and the namespace is kept, it should work.