View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0018769 | Starward Rogue | Suggestion | Mar 4, 2016 8:02 pm | Mar 7, 2016 4:05 pm | |
| Reporter | ptarth | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.016-1.017 | ||||
| Fixed in Version | 1.016-1.017 | ||||
| Summary | 0018769: Allow XML to set familiar Orbital Radius | ||||
| Description | Currently Orbital Radius is set in GameConfig.sys (90 to 100). I'd like to be able to specify it on the familiar and have it also impacted by the familiar's parent entity. Note that this would be a second tag on the familiar's parent (base familiar orbital or something) because not all entities will have a reliable square/round hitbox to produce a visually consistent orbit. | ||||
| Tags | No tags attached. | ||||
|
|
Direct of rotation and speed of rotation would also be nice. This may cause conflict with orbits of different sized familiars at different speeds (and directions). |
|
|
To make sure we're talking about the same thing: 1) FamiliarType.SimpleCircleOrbit completely ignores GameConfig.OrbitalAreaMinRadius. It uses GameConfig.OrbitalAreaMaxRadius if it's the 8th-or-earlier familiar (with that familiar type), and multiplies that by 1.5 if it's later. 2) FamiliarType.NormalOrbit uses both values, but it's not really a radius of an orbit there, just a radius of the area that it flops about in basically at random. 3) Direction of rotation and speed of rotation have meaning for FamiliarType.SimpleCircleOrbit, but not for FamiliarType.NormalOrbit. 4) FamiliarType.SimpleCircleOrbit sets up the angle based on how many familiars of that type are in that "ring", to evenly space them out. Significantly changing the orbital radius, or changing the rotation speed or direction at all, would leave weird gaps in the ring. 5) I don't think either the parent or the familiar need "a reliable square/round hitbox" for any of these purposes, it's all based off the center points. Unless I'm forgetting something. So, what exactly are you trying to do? Get something like SimpleCircleOrbit, or something like NormalOrbit? If the former, we'll probably need to add a new FamiliarType.PtarthsCrazyOrbit and it can use whatever values you set. But it wouldn't try to fit them into rings with each other or with SimpleCircleOrbit familiars, because it wouldn't be meaningful in the general case. |
|
|
I think it would be cool to set the SimpleCircleOrbit parameters. Let's call r, speed and starting offset (parent entity has the center then offset would be 0 - 359) our variable parameters from XML. Then you could have something like a boss with orbitals with orbitals with and interesting visual. I'll call it FamiliarType.VariableSimpleCircleOrbit :) Edit: Derp.. Looking at it, you could still keep the simple circle auto spacing and second ring spacing (unless I'm reading it very wrong). |
|
|
My original plan was to have familiars that mimic solar system/Atomic orbits. I took the large Sphere boss and gave him 4 familiars using SimpleCircleOrbit. Because the Sphere boss is so large, the familiars' image (in orbit) was overlapping the image of the boss. This is due to orbital distance being defined globally. If the orbital distance could be set per familiar and parent then we would be able to control the orbital radius and have as little or as much overlap as possible. For the other things I realized that after the later. Unless there is a way to synchronize familiars, you get undesired oddities in spacing, distance from parent, speed, direction, and so forth. My original proposal was trying to create a setup where the engine would automatically be able to handle a wide variety of familiars oribital paths. I later realized this was going to be a lot of trouble. There is also a massive performance problem if you have 50 or so familiars in the same room. I was able to set a ring of 8 nonrendering hitboxless familiars as the first ring, placing subsequent familiars into that ring, and effectively doubling the visible orbital radius. However, frame rate was halved in that experiment (note: There were a "couple" of other orbital familiars going at the same time). What I wanted was essentially what Cinth states. A FamiliarType.PtarthCrazyOrbit that I can define the distance from parent, speed (also include direction of travel), and starting offset. This would put all of issues with keeping orbiting familiars in sync in the handle of the XML coder. You can't keep the orbital spacing or second ring placement, because you wouldn't be able to identify which familiars have the same orbital path in a straightforward fashion. And then later we can talk about elliptical orbitals, z-axis orbitals, z-axis elliptical orbitals, multiple (3+ origin point) orbitals, transitioning origin point orbitals, and.. Actually, seriously, ellipitcal orbitals should be straightforward enough, just define two points relative to the center of the parent entity. |
|
|
You can shrink down the img with the XML btw. |
|
|
For 1.016: * Added new FamiliarType: PtarthianOrbit ** Behaves like SimpleCircleOrbit, but doesn't try to automatically space out the familiars in a ring. Only works properly for a familiar defined by a familiar sub-node on an entity, won't work well if just put in the normal "familiars" list or otherwise deployed. * Added new sub-node type for entity nodes: familiar ** Basically this is like adding something to the end of the "familiars" list that's already there, but allows you to set some additional info. ** Attributes: ***type (entity) ****the actual familiar type, same as if you'd put it in the "familiars" list ***minimum_difficulty (DifficultyType), maximum_difficulty (DifficultyType) ****the lowest and highest difficulty where this entry will be considered (default: always consider) ***chance_out_of_100 (int) ****if this is set, and set to a value less than 100, each time it considers spawning this familiar it only has this % chance of actually doing so ***radius (int) ****only meaningful with PtarthianOrbit, sets the radius of the circular orbit ***starting_angle (float) ****only meaningful with PtarthianOrbit, sets the starting position on the circular orbit, in terms of degrees around the circle ***rotation_reversed (bool) ****only meaningful with PtarthianOrbit (works for SimpleCircleOrbit, but is weird there), if set this makes the familiar rotate in the other direction than it would normally ***override_degrees_per_second (float) ****only meaningful with PtarthianOrbit (works for SimpleCircleOrbit, but is weird there), if set this overrides the speed of the orbit (which is normally based on the familiar's speed); you can use negative values instead of the rotation_reversed flag if desired ***suppress_line_of_sight_check (bool) ****only meaningful with PtarthianOrbit, SimpleCircleOrbit, and NormalOrbit, if set this causes the familiar to skip the normal "don't fly through walls" logic *****if you know the familiar will always be in an open space where it doesn't need to check this, or if you want it to fly through walls, this flag helps lower the CPU cost of the familiar because it's not having to do LOS checks every frame Thanks :) Example usage, put this on a player mech: <familiar type="TestFamiliar2" radius="300" starting_angle="45" rotation_reversed="true" override_degrees_per_second="180" suppress_line_of_sight_check="true" /> |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Mar 4, 2016 8:02 pm | ptarth | New Issue | |
| Mar 4, 2016 8:02 pm | ptarth | Summary | All XML to set familiar Orbital Radius => Allow XML to set familiar Orbital Radius |
| Mar 4, 2016 8:32 pm | ptarth | Note Added: 0045366 | |
| Mar 5, 2016 4:11 pm | keith.lamothe | Note Added: 0045369 | |
| Mar 5, 2016 4:11 pm | keith.lamothe | Assigned To | => keith.lamothe |
| Mar 5, 2016 4:11 pm | keith.lamothe | Status | new => feedback |
| Mar 5, 2016 6:59 pm | Cinth | Note Added: 0045370 | |
| Mar 6, 2016 12:18 pm | Cinth | Note Edited: 0045370 | |
| Mar 6, 2016 4:46 pm | ptarth | Note Added: 0045371 | |
| Mar 6, 2016 4:46 pm | ptarth | Status | feedback => assigned |
| Mar 6, 2016 8:28 pm | Cinth | Note Added: 0045374 | |
| Mar 7, 2016 4:05 pm | keith.lamothe | Note Added: 0045376 | |
| Mar 7, 2016 4:05 pm | keith.lamothe | Status | assigned => resolved |
| Mar 7, 2016 4:05 pm | keith.lamothe | Fixed in Version | => 1.016-1.017 |
| Mar 7, 2016 4:05 pm | keith.lamothe | Resolution | open => fixed |
