please give sub-entities a visible property and/or show and hide methods.
maybe even give ships attachment points where subents of defined types can be mounted.
Love, Anja
Dear Santa
Moderators: winston, another_commander
- Wyvern Mommy
- Deadly
- Posts: 185
- Joined: Sat Apr 02, 2011 7:14 pm
- Location: Beyond the final Frontier
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: Dear Santa
I understand the second, but not the first. Can you elaborate?
- Wyvern Mommy
- Deadly
- Posts: 185
- Joined: Sat Apr 02, 2011 7:14 pm
- Location: Beyond the final Frontier
Re: Dear Santa
as i understand the current subent system, there's only two methods. one mounts all subents indiscriminately, the other kills subents individually. at best, subents to be hidden can be moved into other structures present.
let's take a look at actually visualized weapons pylons. in the setup there would have to be a subent designed for every mountable weapon on every pylon, then the unused ones would have to be killed.
for one thing, that principle can enlarge plists overwhelmingly fast. for another, it's kinda inflexible.
clearly, the system takes only into account structures vanishing by being destroyed.
it doesn't take into account objects appearing, like cargo pods being scooped up and appearing on an open cargo bed.
furthermore, there no way to change the appearance (textures) of a subent. for each set of textures a complete subent has to be mounted. again, the unused ones destroyed after all are created.
a simple "visible" property would greatly enhance the system. subents could be shown, hidden and replaced simply by setting them as visible or not.
let's take a look at actually visualized weapons pylons. in the setup there would have to be a subent designed for every mountable weapon on every pylon, then the unused ones would have to be killed.
for one thing, that principle can enlarge plists overwhelmingly fast. for another, it's kinda inflexible.
clearly, the system takes only into account structures vanishing by being destroyed.
it doesn't take into account objects appearing, like cargo pods being scooped up and appearing on an open cargo bed.
furthermore, there no way to change the appearance (textures) of a subent. for each set of textures a complete subent has to be mounted. again, the unused ones destroyed after all are created.
a simple "visible" property would greatly enhance the system. subents could be shown, hidden and replaced simply by setting them as visible or not.
Re: Dear Santa
This one should be possible already - use the JSWyvern Mommy wrote:furthermore, there no way to change the appearance (textures) of a subent. for each set of textures a complete subent has to be mounted. again, the unused ones destroyed after all are created.
setMaterials
or setShaders
method on the subent.
Code: Select all
ship.subEntities[0].setShaders({ ... })
- submersible
- Commodore
- Posts: 264
- Joined: Thu Nov 10, 2011 7:49 am
Re: Dear Santa
and you could effectively disappear a subent with a shader whose fragment-part simply callscim wrote:This one should be possible already - use the JSWyvern Mommy wrote:furthermore, there no way to change the appearance (textures) of a subent. for each set of textures a complete subent has to be mounted. again, the unused ones destroyed after all are created.setMaterials
orsetShaders
method on the subent.Code: Select all
ship.subEntities[0].setShaders({ ... })
Code: Select all
discard
Povray Planets - Planet textures for your galaxy
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: Dear Santa
The developers will have to correct me on this, but I think the main difficulty is that Oolite is written in a way that keeps the shape and the attributes of things completely separate.
Subentities are merely a convenient way of creating more complex models. They don't have any specific relation to equipment, or functionality of the ship. (With the exception of ballturrets. But then again, any subentity can become a ballturret, simply by declaring it to be one in its shipdata. It doesn't need to be shaped or placed like a turret.)
On the other hand, the functionality and equipment of ships don't have or need any physical representation at all. They're invisible.
As far as I understand, that's the opposite of the concept of "hardpoints", where each component of your ship needs a physical representation on the ship model, and you can for instance put either an engine or a weapon to a specific point, but not both. And there is only a limited number of such points on each model. (I only learned about hardpoints from the Kickstarter and subsequently on the forums of Limit Theory, because Oolite is basically the only game I'm playing.)
I don't know how difficult it would be to re-write Oolite in a way to support this approach, but I guess that it would involve a re-write indeed.
Years ago I suggested that each equipment item should have a model as well, that would rotate on the F3-screen when scrolling through the list, just like the ships on the F3-F3-screen. And I think I also somehow had the idea that these equipment models could be attached to your ship as well. This would make sense at least for pylon-mounted equipment, but also for instance for fuel scoops. But Oolite doesn't really support this. Griff's Cobra III with external missiles exists, but it's actually a clever fake. Even if you removed the missile subentities, the ship would still carry four missiles and would be able to fire them, because the actual missiles are invisible until they're launched.
Subentities are merely a convenient way of creating more complex models. They don't have any specific relation to equipment, or functionality of the ship. (With the exception of ballturrets. But then again, any subentity can become a ballturret, simply by declaring it to be one in its shipdata. It doesn't need to be shaped or placed like a turret.)
On the other hand, the functionality and equipment of ships don't have or need any physical representation at all. They're invisible.
As far as I understand, that's the opposite of the concept of "hardpoints", where each component of your ship needs a physical representation on the ship model, and you can for instance put either an engine or a weapon to a specific point, but not both. And there is only a limited number of such points on each model. (I only learned about hardpoints from the Kickstarter and subsequently on the forums of Limit Theory, because Oolite is basically the only game I'm playing.)
I don't know how difficult it would be to re-write Oolite in a way to support this approach, but I guess that it would involve a re-write indeed.
Years ago I suggested that each equipment item should have a model as well, that would rotate on the F3-screen when scrolling through the list, just like the ships on the F3-F3-screen. And I think I also somehow had the idea that these equipment models could be attached to your ship as well. This would make sense at least for pylon-mounted equipment, but also for instance for fuel scoops. But Oolite doesn't really support this. Griff's Cobra III with external missiles exists, but it's actually a clever fake. Even if you removed the missile subentities, the ship would still carry four missiles and would be able to fire them, because the actual missiles are invisible until they're launched.
Re: Dear Santa
There's certainly no requirement in Oolite for form to follow function (in the way that Elite: Dangerous looks like it will have, for instance), and with our casual approach to scale it would be difficult to introduce one globally (not to mention the havoc it would wreak on existing ship OXPs). So really only the lasers and pylons follow the hardpoint approach, and that doesn't show on the model (forward frangible subentity lasers excepted)Commander McLane wrote:The developers will have to correct me on this, but I think the main difficulty is that Oolite is written in a way that keeps the shape and the attributes of things completely separate.
I don't know how difficult it would be to re-write Oolite in a way to support this approach, but I guess that it would involve a re-write indeed.
On the other hand, there's nothing to stop an individual ship being written like it was true - see the Griff Krait, for instance - it just requires some clever scripting. And with the new condition scripts you could take an internal hardpoint approach if you want: this is a small ship, so you can fit any two of ECM, Energy Unit and Wormhole Scanner, but not all three.
Switchable external hardpoints would need you to be able to add an arbitrary entity to a ship as a subentity at runtime, which would probably the easiest way to implement the feature request. I'd have to look at how practical that would be: it might not be too difficult, though the "restore sub entities" method would probably have the effect of "reset to factory condition", and save/load for the player ship could be complex (or very simple, if it was left to the OXP to sort...).
- Eric Walch
- Slightly Grand Rear Admiral
- Posts: 5536
- Joined: Sat Jun 16, 2007 3:48 pm
- Location: Netherlands
Re: Dear Santa
Ships and subents currently have a "isVisible" property. It just has a slightly different meaning. It does show if the player can see a ship or subEntity, but this is based on distance. Very useful to skip time consuming animations when the player does not see the object or subentity in the first place. Or you could remove objects from the system when no longer visible, instead of doing it based on a self calculated distance to the player.Wyvern Mommy wrote:please give sub-entities a visible property and/or show and hide methods.
UPS-Courier & DeepSpacePirates & others at the box and some older versions