20,741
edits
Talk:Scripted AI Objects: Difference between revisions
Jump to navigation
Jump to search
m
→Implementation: more structuring
m (beginning to clean up/structure the discussion - removing the code, because it is being edited as part of the main article already (see my contributions there)) |
m (→Implementation: more structuring) |
||
| Line 23: | Line 23: | ||
This is a quick way of doing the job. Perhaps the "Target" object needs to be completed, with "pylon number" or "pylon position" (and it also could be renamed). This will allow the script to be independant of any aircraft. | This is a quick way of doing the job. Perhaps the "Target" object needs to be completed, with "pylon number" or "pylon position" (and it also could be renamed). This will allow the script to be independant of any aircraft. | ||
== Using geo.Coord objects for dealing with source/targets == | |||
:: a target really is really just representing a position with lat/lon/alt - thus, it would make sense to simply use the existing geo.nas helpers here (geo.Coord) - if you need additional data, you can just sub-class geo.Coord to add your own fields - we are using this method in the MapStructre/TFC (traffic) layer. So I wouldn't make this more complicated than necessary. Obviously, targets/positions may be dynamic/changing, but that can also be realized using a geo.Coord sub-class, or a helper class with a geo.Coord member. Equally, missileType should probably just be another hash with a well-defined set of interfaces/methods. Overall, a simple MVC separation would definitely make sense here, which would allow you to have a custom 3D model, add animations to it, while having a plug&play FDM for different purposes. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:52, 28 October 2014 (UTC) | :: a target really is really just representing a position with lat/lon/alt - thus, it would make sense to simply use the existing geo.nas helpers here (geo.Coord) - if you need additional data, you can just sub-class geo.Coord to add your own fields - we are using this method in the MapStructre/TFC (traffic) layer. So I wouldn't make this more complicated than necessary. Obviously, targets/positions may be dynamic/changing, but that can also be realized using a geo.Coord sub-class, or a helper class with a geo.Coord member. Equally, missileType should probably just be another hash with a well-defined set of interfaces/methods. Overall, a simple MVC separation would definitely make sense here, which would allow you to have a custom 3D model, add animations to it, while having a plug&play FDM for different purposes. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 16:52, 28 October 2014 (UTC) | ||