Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
This action allows you to easily adjust the Field of View (FOV) of camera nodes, either instantly or with a smooth transition over a specified duration. https://samgrady.itch.io/dynamic... |
||||
|
There is this extension by JIC that does this for almost every property of any scenenode. You can animate them or change them instantly. https://vazahat.itch.io/coppercu... This, in my opinion is very good thing to have than having individual extension for each thing. One extension that does everything. It's kind of underrated but is very useful to non-coder like myself. |
||||
|
I didn’t know about its existence, but I disagree with the idea that using bulky behaviors with a bunch of different variables is more convenient, as it creates poor project "readability". Otherwise, I created this action because I was asked to, so obviously, people find this kind of thing useful. |
||||
|
Thanks!! GURU for not appreciating OP work. While JIC (VAZAHAT) himself is genuinely a person of an excellent nature and very helpful. But there are lot of community members who are more of fanboy to this engine and to him. I believe they can't appreciate something similar created by others. On the other hand VAZAHAT gave up on this engine and is no more involved in Game Development anymore. Let there be space and appreciate little efforts made by other community members too. |
||||
|
Guest2 Well, I understand what guest_Guru saying. If there’s a more functionally complex behavior, why not use it? I’m just saying that sometimes it’s more convenient to implement everything through more compact solutions, which simplifies the readability of the project, since non-coded projects often have very complex visual structures. When I write code for myself, I can implement most of it in one block, and that makes my work easier because I won’t have to click through a bunch of behaviors and actions to implement or debug something. So I think he’s just questioning what the advantages are in choosing between two different codes, not realizing that these codes serve different purposes, even though, as I understand it, JIC allows you to implement the same thing as my action. |
||||
|
It’s like, for example, opening a door. Someone might write code that’s specifically designed just for opening a door, taking into account different parameters for that action. But instead of one event, there could be two or three that do the same thing, but each would be simpler to read and wouldn’t have, say, 6-7 different variables. In the end, by combining them, you could create more mechanics than just a simple door opening. These simpler methods would be more practical than a more complex and detailed code that allows you to adjust a dozen parameters for the door. This isn’t exactly a parallel example to the actions we’re discussing, but what I’m saying is that sometimes using simpler things lets you implement more complex stuff if you use them the right way. The attitude like 'why write actiond that do what’s already covered by others?' is exactly the kind of mindset that shows why the CopperCube community is so weak, and why the materials for the engine are so limited. Why bother making anything at all? There's the documentation with the API description, and let everyone just write their own code. |
||||
|
Sorry, I didn't wanted it to be a topic of debate. I appreciate your work. It is just me who prefer single thing that does most of the work for me. I apologize if my comment was demotivating. Keep creating more extensions Sam, I love your playstation stuff. |
||||
|
I'm not demotivate, and I didn’t mean to sound that way or make it seem like I was trying to offend you. I was just explaining my position regarding bulky actions and behaviors, as well as the idea that there’s no point in comparing certain pieces of code because they can be used for entirely different purposes. For example, when I published a third-person camera controller, I got similar questions about why my code was needed if smnmhmdy had already made a better controller. But the issue was that he made a third-person character controller, while mine was a camera controller — completely different things. That’s why, sometimes, users here, without understanding anything about programming and often without even trying out the functionality provided to them, start making such comparisons (not saying this about you, just an example). |
||||
|
|
){kind=link}