Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Vengence on November 13, 2011, 05:01:07 pm
-
This is just something that suddenly struck me as I was talking to a friend. Would multipart or blob turrets still function if parented to a subobject that is animated? Like imagine guns on the UEF Solaris' spinning section. Would they still function and remain on the animated system? Or would they simply float into the air?
-
I think the visual model will rotate, but the actual turret's collision. firepoints, etc will not.
Cause that's what happens with regular susbsystems.
-
Derp well there goes several good ideas in the drain :p. Thanks for clarifying.
-
they will 'work' in that they will fire and it will look like it is coming from the right place, but they will aim thinking they are in the submodels default position, so they will effectively shoot at nothing. though it might be 'good enough' if you just want it for the atmosphere, I would give the weapon on it a very wide field of fire, though so it is less obvious what is happening. keep in mind they will work perfectly fine when the submodel is in the default position, so things like docking arms would work.
-
sounds like it would just need to plug the parent's matrix into the turret calculations. of course it doesn't do this now, to eliminates a lot of matrix multiplication which would slow up the code. frame of reference conversions would just need to follow the hierarchy chain, and multiply in each matrix along the way. once the potential targets are in the turret's frame of reference a firing solution could be established.
-
If that's the case Bobboau then there is some hope, at least what I had in mind specifically involves more 'sliding' and shifting and less rotating overtly. THe turret's field of fire, if 180 should still roughly be in the same region.
Forgive me for saying, Nuke, I'm not very fluent in scripting and most of what you said went over my head :(. Considering I don't exactly know what the parent matrix is or what it involves with multiplication or a frame of reference. :confused:
-
Nuke description pretty much sums up what I had to do when I wrote the $attach_thrusters feature, and I've been thinking of extending the functionality to things other than thrusters. So, it might become possible sooner or later.
-
i think this kinda thing needs to be done on a more fundamental level. freespace has always assumed no more than 3 levels of hierarchy, and all of which is treated as being in the ships reference frame instead of a local one. turrets were either upper, lower or singlepart, in order to simplify the maths.
one problem is many of the pof chunks that contain position data dont have a binding to a subobject (which can contain position, orientation matrix, and a link to its parent's data through a parent sobj num), from which a conversion between world space and any subobjects frame of reference with respect to the entire hierarchy chain and vise versa could be done. the method proposed for engine points for example is somewhat of a work around. on top of that there is no easy method to import transform data from the source model (this data is actually stripped out when the model is converted, this is why you need to reset xform in max). so the orientations of relevant subobjects need to be entered manually, through uvec and svec subobject props. id actually like to see many of the pof chunks replaced by tables, so that they could be made more mutable and upgraded continuously without also needing to update pcs2 to understand new chunk formats.
if for example you wanted to make the primary firing points follow some subobject's rotation, like a spinning ship section, somewhere you would need to tell the game what subobject those gunpoints are relative to. a rotating object rotates because its matrix is updated every frame, so if you multiply the subobjects orientation matrix by the gunpoint vectors (this is called a transform in the graphics world), they will inherit the subobjects rotation. of course this wont wok unless the points are in the subobjects frame of reference, they might wobble because of a bad offset. you would just have to subtract the subobject position from them (this could easily be done only once at parse time) before the points were rotated to the subobjects matrix.
you could could solve the problem piecemeal, each time you need to have something inherit somethings rotation. add a feature and wait for modders to ask the same feature be applied to something else. or you can do it for all of them by adding something like a $inherit parents transform: yes submodel property/table entry. if excluded then the "everything in model space" mentality is used and stuff works normal. on top of this you still need to come up with a way to tell the engine in which submodel the the data in question is attached to. granted you can kinda do some of this stuff in scripting, not that i was about to advocate it for this kinda thing.
If that's the case Bobboau then there is some hope, at least what I had in mind specifically involves more 'sliding' and shifting and less rotating overtly. THe turret's field of fire, if 180 should still roughly be in the same region.
Forgive me for saying, Nuke, I'm not very fluent in scripting and most of what you said went over my head :(. Considering I don't exactly know what the parent matrix is or what it involves with multiplication or a frame of reference. :confused:
then learn how things work in a game engine.
-
I understand now Nuke ;), thanks for the explanation.
then learn how things work in a game engine.
Hehe, I wish. I'm an artist who can understand some tidbits of programming, not a programmer at all :sigh:. Learning and writing code for any engine is far beyond the reach of my knowledge, least until I can take some classes on the subject.
-
Learning and writing code for any engine is far beyond the reach of my knowledge, least until I can take some classes on the subject.
All ya need is a good reference of the programming language, a good solid grasp of logic, an endless coffee supply, and a quiet Summer in the Bahamas. ;)
I think for the turrets though, you might have to apply an individual AI segment per turret. Going back to Vengence's example, if you had 4 turrets on the spinning section, each turret needs to know what to fire at and what to ignore as its spinning around.
Although having all turrets focus on one target as they're spinning around is something to muse about, it's not a good idea if the Solaris is under attack from all sides.
-
All ya need is a good reference of the programming language, a good solid grasp of logic, an endless coffee supply, and a quiet Summer in the Bahamas. ;)
That, more or less, is how I learned to do everything I know how to do.
-
I have a semi related question - what if instead of putting the object with a rotating subobect (and a turret on that), you made separate entities?
Like imagine a base surrounded by 3 large defense rings that rotate (classic ring puzzle style) around each other. Instead of making the rings subobjects
of the base, why not make each ring it's own fake ship, and just set it to spin on one axis? Turrets would be interior and exterior of each ring. Sort of a similar
idea to how the hapan battle dragons worked in SW's novels. As one turret cools, another swings into place ready to go.
Would that work or would it still cause the turrets to freak out as it spun?
-
Well I don't have a shortage of scripting or programming books thanks to my father. Plenty around this place in a lot of languages. I have done some scripting in the past but I found that I am useless without references or my notes, granted I could 'read' some scripting/programming to a degree. That's a start I suppose. At the least when I do get around to learning this stuff I could probably add some features of my own given time ;).
From what you're saying, JG, it should work if said rings are their own ships and are static in FS-Open. Granted I don't know how well that would work if said spinning object is supposed to belong to a ship holding it. So I suppose good for stations, if you told it to constantly spin I guess.
-
Learning and writing code for any engine is far beyond the reach of my knowledge, least until I can take some classes on the subject.
All ya need is a good reference of the programming language, a good solid grasp of logic, an endless coffee supply, and a quiet Summer in the Bahamas. ;)
I think for the turrets though, you might have to apply an individual AI segment per turret. Going back to Vengence's example, if you had 4 turrets on the spinning section, each turret needs to know what to fire at and what to ignore as its spinning around.
Although having all turrets focus on one target as they're spinning around is something to muse about, it's not a good idea if the Solaris is under attack from all sides.
i dont really think this will be an issue. the ai should be able to determine what it can and can shoot at frame to frame (or timestamp to timestamp to save cpu time, not sure if turrets update every frame). if the turret's target falls out of its fireing arc, the turret will re-acquire another target. its no different from a bomber turret firing at targets while the ship is rolling. it can still acquire targets and score hits.