TheLacus wrote:What you can do even now is to set a component, Plane for example, as the parent and all the Plane.xxx as their children.
I've just made a PR which allows an empty prefab to be the parent, so this will be a possibility, too. Just pay attention to the origin.
Good work with the chair
Sorry how do you set a parent within a prefab? Google only gives me answers in the form of C# code and I have no idea where to begin
Every time I make a prefab with more than one component then every single model in the game disappears.
You can do it from the hierarchy window.
Drag the prefab in the scene view, change the parenting and the drag it again in the project window.
Let me know if you need additional help.
TheLacus wrote:You can do it from the hierarchy window.
Drag the prefab in the scene view, change the parenting and the drag it again in the project window.
Let me know if you need additional help.
Thanks again. I think I did the parenting thing right but it still ends up breaking the game. I also tried removing the particle fx and light components but same result
And if someone is up to the scripting, it would be very possible to turn off fire particles during the day and enable at evening. This would look cool as hell.
I agree with both your statements. The lamp is great and toggling the fire would be nice too. This also reminded me that windows emission color needs to be addressed for imported buildings, so I took the opportunity to do both.
daynight.png (14.51 KiB) Viewed 16375 times
The last two fields allow modders to set optional emission maps and override default colors.
Hi, I've had a quick read through these modding tutorials but I'm not clear if/how existing DFU classes could be extended so that behaviour can be overridden. Is this possible? What I'm thinking is intercepting calls and adding new behaviour. Pretty sure any events can be reacted to, but I wondered if mods could hook in anywhere?
Not everything has mod hooks or mod capability. My thoughts have always been to add these incrementally over time or in response to sensible requests for a certain capability.
I don't think it's a good engineering exercise to try and make absolutely every class mod-capable. Not even high-end commercial games do that. Mod capability usually runs along the lines of asset injection and script execution back to exposed hooks in game. There are also limitations of the MCS compiler such that most game classes simply could not be implemented outside of normal AOT builds.
Anyone that wants to make huge sweeping changes to the core game are probably better off starting with a fork of the code. But I'm all for adding sensible hooks for mods to inject or override behaviours where reasonable.