[Dragoniz3r]

I have been working recently with Karajorma, trying to add multiplayer respawn points that are definable in FRED, which have some other "special" qualities. In the particular instance we've been working with, there's a huge asteroid that has some hollow areas in it, and it would be nice if we could spawn ships in them. Now, of course the bounding-box calculations for normal respawning prohibits this.
Our idea was to add an object flag which marked the object (probably a waypoint) as a known-safe respawn point, even if the bounding boxes say otherwise. This is trivial. However, we're then stuck with the not-so-ideal solution that you can have ships spawning on top of each other.
We've really only seen one solution: Draw a line between how big "small" and "large" objects are, and check only for collisions with "small" objects. It gets worse here though, because then you have the situation where you get shoved into the middle of a "large" object when it tries to solve a collision with a "small" object. The way we've seen around this is to find a new respawn point if the one you chose has a "small" object at it, and if you can't find an empty one, then you've gotta do what you gotta do. There's a couple things to do about it, but they're not the point of this topic.
Our question is, does the way I've described sound too hacky to you? Both Karajorma and I are a bit nervous with making an arbitrary decision about what's "small" and what's not, but we're having a hard time seeing another way.

[Goober5000]

Paragraphs please.

[WMCoolmon]

Add the ability for ships to spawn around other ships, as well as a 'max spawn radius'. That way, you have a limit to the spawn area so that more than one ship can spawn, but you can also limit the spawn point according to the amount of space.

Another solution might be to have an option to turn off ship-to-ship collisions for all spawning ships when they spawn, until they leave the zone. (This is really easy to do - create a spawn_index variable for ships, and set it to the object index of the spawning point. In the physics code, check to see if this variable is not equal to -1, and equal, when a ship collision occurs. If the value is the same, the ships don't collide. Once the ships have left the spawn radius, this value is set back to -1.)

[Dragoniz3r]

Add the ability for ships to spawn around other ships, as well as a 'max spawn radius'. That way, you have a limit to the spawn area so that more than one ship can spawn, but you can also limit the spawn point according to the amount of space.

Another solution might be to have an option to turn off ship-to-ship collisions for all spawning ships when they spawn, until they leave the zone. (This is really easy to do - create a spawn_index variable for ships, and set it to the object index of the spawning point. In the physics code, check to see if this variable is not equal to -1, and equal, when a ship collision occurs. If the value is the same, the ships don't collide. Once the ships have left the spawn radius, this value is set back to -1.)

Neither of those solutions are any more ideal than what we have already come up with, they're both just as hacky, and they're more work.

[WMCoolmon]

I don't follow. What I've described has been used in other games, since at least Starcraft. It's not hacky - it makes perfect sense for ships to not collide with other ships that are also spawning, so you don't get messed up problems occuring every time someone spawns. And it makes more sense than having 20 different spawn points so you don't have to worry about things getting clogged, especially in an asteroid field, where you have numerous 'small' objects that are the size of a ship which can also trigger the selection of a new spawn point.

And it makes more sense to turn off collisions for 'small' objects than 'large' ones because then you would be able to simply fly through the asteroid. This would be a nightmare in CTF games. And it solves the problem of having an arbitrary ship size for determining collisions, because this determines the collision status based on whether the ships are spawning or not (which is really what matters).

Adding a variable to struct ship, setting that variable when ships spawn, turning off collisions when that variable is equal on two ships, and resetting that variable when ships move a certain distance away from another object are all very easy. Only thing I see is that there might be some multi sync issues, but I think they'd be less noticeable than if a ship got stuck between a ship and a wall while spawning and ended up flying straight into the enemy flagroom.

[Dragoniz3r]

I don't follow. What I've described has been used in other games, since at least Starcraft. It's not hacky - it makes perfect sense for ships to not collide with other ships that are also spawning, so you don't get messed up problems occuring every time someone spawns. And it makes more sense than having 20 different spawn points so you don't have to worry about things getting clogged, especially in an asteroid field, where you have numerous 'small' objects that are the size of a ship which can also trigger the selection of a new spawn point.

The problem with them is that they operate on the concept of spawn "areas" rather than spawn points. We have no way to set spawn areas in FRED. The game object structures have no way to represent how big the area should be. We'd then be stuck having to make an arbitrary decision in the code about how big areas should be.

And it makes more sense to turn off collisions for 'small' objects than 'large' ones because then you would be able to simply fly through the asteroid. This would be a nightmare in CTF games. And it solves the problem of having an arbitrary ship size for determining collisions, because this determines the collision status based on whether the ships are spawning or not (which is really what matters).

I think you're a bit confused about what I'm saying. When you look at the code, during a respawn of a ship (in multi), it checks the respawn position against the bounding boxes of other objects. If there is a collision, it moves the spawning ship to a place where it's no longer colliding with anything.

My change would have no effect whatsoever on the collision detection as you fly around. It would just change the calculations made for when you respawn. So you wouldn't be able to fly through asteroids or anything else. It would just mean that it would allow you to spawn a ship inside the bounding box of a "large" object (which works fine when you have hollow or concave objects), while still taking into account collisions with "small" objects like other ships, so you don't spawn inside another ship.

Adding a variable to struct ship, setting that variable when ships spawn, turning off collisions when that variable is equal on two ships, and resetting that variable when ships move a certain distance away from another object are all very easy. Only thing I see is that there might be some multi sync issues, but I think they'd be less noticeable than if a ship got stuck between a ship and a wall while spawning and ended up flying straight into the enemy flagroom.

Again, this introduces a bit of an arbitrary decision about how big the areas should be (no way to set them in FRED), it adds more calculations to the main game loop (rather than my method, which adds calculations that are done only when a ship respawns). We want to avoid the ugliness of ships passing through each other. Stuff like that completely ruins the realism you may be trying to portray. We're trying to solve the problem of allowing you to spawn near/in concave/hollow objects in a way that's completely transparent to users. That means no uglinesses like flying through stuff.

[karajorma]

Well respawning ships are already invulnerable for 5 seconds anyway so collisions are not a problem.

The problem is that it's someone what ugly to have one ship spawn on top of another one. FS2 never suffered from that because it made sure it defined a number of respawn sites equal to the number of ships that could be in the mission. I'd prefer to avoid taking a step backwards when implementing respawn points if I can avoid doing that.

[taylor]

I don't follow. What I've described has been used in other games, since at least Starcraft. It's not hacky - it makes perfect sense for ships to not collide with other ships that are also spawning, so you don't get messed up problems occuring every time someone spawns. And it makes more sense than having 20 different spawn points so you don't have to worry about things getting clogged, especially in an asteroid field, where you have numerous 'small' objects that are the size of a ship which can also trigger the selection of a new spawn point.

The problem with them is that they operate on the concept of spawn "areas" rather than spawn points. We have no way to set spawn areas in FRED. The game object structures have no way to represent how big the area should be. We'd then be stuck having to make an arbitrary decision in the code about how big areas should be.

All you should have to do is set a spawn point and a radius for it.  Every object has a set radius, so there is nothing arbitrary about it.  The code then has an area around that point to work with and could place a spawning ship anywhere in said radius from the spawn point.  Position/collision detection would be based on a random point in the radius, taking the radius of the spawning ship into account, and making sure the ship fit in the allotted area.  That gives you a predetermined number of areas, as well as a predetermined area size, to spawn in.  It should take care of most the spawn-on-top-of-something bugs as well without making the code overly complicated.

The big point here is that if the current respawn code isn't good enough to handle this, then it should be fixed.  Hacking in something that you have to do a lot of compromizing on just so it works with the existing respawn code isn't a good solution.

[Dragoniz3r]

The big point here is that if the current respawn code isn't good enough to handle this, then it should be fixed.  Hacking in something that you have to do a lot of compromizing on just so it works with the existing respawn code isn't a good solution.

Of course, if you've gotta hack something in, it's a bad idea. That's why I came to ask here whether making an arbitrary distinction between "small" and "large" objects was too hacky. However, the current respawn code could be made to work in a much more predictable and acceptable way than spawn "areas."

There are other problems with spawn areas, but they're not horribly important, and I'm going to bed.

[WMCoolmon]

I don't even understand what the point of this thread is anymore. Are you looking for advice, permission, what? Constructive replies are being met with "No, it's too hard" and "No, that's a bad idea. Bye."

If you're not even willing to add a couple controls to a FRED dialog because it's too much work, then I would say that a non-hackish solution may not be your cup of tea. Contributions are appreciated, but in this case all you seem to be doing is asking if your solution is OK, and then telling us that your way is the only one that you're willing to do. That never goes over well.

[Colonol Dekker]

What about setting arrival cues in the arrival SEXP to be for near an OR list using several independant waypoints as a basis?

IE spawn <100 certain ship
OR wp1
OR wp2
etc
etc


 

[karajorma]

I don't even understand what the point of this thread is anymore. Are you looking for advice, permission, what? Constructive replies are being met with "No, it's too hard" and "No, that's a bad idea. Bye."

If you're not even willing to add a couple controls to a FRED dialog because it's too much work, then I would say that a non-hackish solution may not be your cup of tea. Contributions are appreciated, but in this case all you seem to be doing is asking if your solution is OK, and then telling us that your way is the only one that you're willing to do. That never goes over well.

The thing is that I've spent a couple of hours discussing the problem with Dragoniz3r on IRC so some of the suggestions you mentioned have been raised before and rejected. For instance having ships respawn on top of each other was a possibility we kicked out very early on simply because it looks ugly as hell.

I think the best solution is to have a respawn area rather than a a point for FRED defined points and simply use the old code if no points are defined. I think Dragoniz3rs problems are stemming from the choice to use an altered waypoint to define where a respawn point will be rather than marking out an area in much the same way as the asteroid code marks out a box. Yes using a definable area might be harder to add in FRED but if the price is that it's easier to use to solve the problems in the FS2 code then I think it's a tradeoff worth making to have a non-hacky solution.

What about setting arrival cues in the arrival SEXP to be for near an OR list using several independant waypoints as a basis?

The issue is not telling the ship where to spawn. That's pretty trivial. The issue is that the game won't let a ship respawn within the bounding box of another ship. Which means that you can get ships spawning kilometres away from anything because although you are no where near the surface of a ship you are within the bounding box.

It also prevents you having a holllow asteroid and spawning ships in the middle  for instance.

[Colonol Dekker]

OK, now i see  Does it have to be a ship entry or can you create a new static asteroid field, with one huge asteroid?

[karajorma]

For what we're trying in BtRL we just used a big asteroid model and gave it a ships table entry.

Once Kazan's asteroid upgrade is done, who knows?