Well, after quite a few hours of building a model, tearing it apart, trying every combination i can think of, i'm left to resorting to ask if someone can rejig the collision-detection system in Oolite. pleeease. I think it's a fairly major part of the game in that it will open up a load of potential for bigger, more interesting, more complex models and missions. i fully appreciate this might be a hugely complex undertaking tho, so if the coder people think it's too much/unworkable, that's fine : had to ask tho.
as i was saying to Commander McLane tho, i'll be buggered if i can work it out : Doc boxes are fantastically accurate - if i come in wrong to a coriolis or a hOopys, i trash my shield no bother at all. in my new model though, i can fly through entire walls. i've tried everything i can think of, making my thing a subent/not a subent, turning faces in or out, nothing works, i just merrily breeze through the walls. tch.
Collision Detection
Moderators: winston, another_commander
-
Killer Wolf
- ---- E L I T E ----
- Posts: 2278
- Joined: Tue Jan 02, 2007 12:38 pm
-
JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Collision-detection is an ongoing problem. Giles did rewrite it from scratch a few official releases ago, but it doesn’t seem to have been sufficient. As you say, redoing it (again) would be a major project.
Related to this is another, less user-visible problem which has come up between developers a number of times: the way Oolite currently handles meshes (loaded models) and the hierarchy of entity types is a mess and needs major surgery. It’s been attempted a few times, but each attempt has ground to a halt. Getting this right would make it easier to hack on the code, making things like, say, Oolite Arena at least potentially doable. It would improve performance and memory efficiency. It would also very likely require a complete rewrite of the collision handling. Rewriting the collision handling, then doing the major surgery, then rewriting the collision handling again does not appeal.
Assuming I can stay focused on Oolite, the “major surgery” will be my main project for the next year. This time, I intend to make a plan of action in advance, and work as much as possible directly on the main line of code, in steps that keep it functioning. Previous attempts have broken partily because they’ve ended up diverging too much from the trunk, and keeping them in sync became too big a portion of the project.
Related to this is another, less user-visible problem which has come up between developers a number of times: the way Oolite currently handles meshes (loaded models) and the hierarchy of entity types is a mess and needs major surgery. It’s been attempted a few times, but each attempt has ground to a halt. Getting this right would make it easier to hack on the code, making things like, say, Oolite Arena at least potentially doable. It would improve performance and memory efficiency. It would also very likely require a complete rewrite of the collision handling. Rewriting the collision handling, then doing the major surgery, then rewriting the collision handling again does not appeal.
Assuming I can stay focused on Oolite, the “major surgery” will be my main project for the next year. This time, I intend to make a plan of action in advance, and work as much as possible directly on the main line of code, in steps that keep it functioning. Previous attempts have broken partily because they’ve ended up diverging too much from the trunk, and keeping them in sync became too big a portion of the project.
E-mail: [email protected]