0.6 plans

[klauss]

What are you talking about? vs_options has been done this way for _years_ ...it was never changed to a header accessed global variable. I'm not changing things, i'm staying consistent with the way the class has been used all along.

Huh... then I apologize. But still, the diffs told me you were adding externs, just don't, add it in the header, and remove the rest instead. Same amount of work, but in the right direction.

I've had enough dealings with C++ to be rather certain an extern in the headers is the better way to go.

You quote maintenance but an extern in a header only helps the guy who is changing things underneath the people who use it, it doesn't help the people using it.

It serves the people using it by guaranteeing binary compatibility in the face of changes. It's no small feat.

[safemode]

I think I'll be doing more options changes over the course of the week and redesign its interface. I hope by the weekend I'll have it fully done and the game will finally have one options interface.

I would like if anyone having difficulty with Python detection and what not in py3 branch to post issues and paths to correct those issues so when we merge to trunk it will solid for more that just one dist

[safemode]

Also if anyone has any ideas of android type apps related to the project I do android apps. I've been trying to think of something related to VS that would be worthwhile and it's been hard to think of something on my own that would be halfway useful. Maybe something more in-game oriented would be more interesting. Either way. ideas relating to spreading interest in the game to cross boundaries into android can't be anything but good for the project and I have experience working with android . so throw me your ideas along with what we have going on for 0.6 .

[klauss]

Totally unrelated, but I'm finding it difficult to build py3 branch on gcc 4.5. I don't think 4.5 is old enough to leave unsupported, so I'm probably going to commit some fixes in that direction shortly (mostly related to pragmas introduced for warning cleanup).

[safemode]

how outdated is your dev environment? 4.6 has literally been out 2 years. 4.7 is even in Debian.

[www2]

i have some request for 0.6
1. this one is for the pc and android a server admin app
2. a new account server and a Vega Strike ACCount server Protocoll (vsaccp) that run as a program not as a web script
3. new web front end for the account server (that is my task )
4. create a new database (i plan to all so dising)

[safemode]

BTW, there should only be like two uses of pragmas related to disabling warnings that are accepted as being OK due to optional pointers from boost.

but using such old versions of GCC will seriously impact vectorization and available cflags. 4.6 has significant improvements in that area . 4.7 is even better.

not sure why you would still be building with 4.5 but you will be seeing the game through a poor lens. we should all be developing with the latest tools available in dists.

[safemode]

I've been reading other posts about factions and unit balance. I think we need to make the user choose a species or faction. if we want to give factions a identity, and enforce that then the player would be subject to the same rules. ie. only certain upgrades available and only certain ships dictated by faction

[klauss]

how outdated is your dev environment? 4.6 has literally been out 2 years. 4.7 is even in Debian.

openSuse 11.4, that's a year and something ago. It's EOL, but I imagine other slower distros will still have 4.5. I don't even want to wonder what debian stable has (you're talking wheezy, stable is a LOT older).

i have some request for 0.6
1. this one is for the pc and android a server admin app
2. a new account server and a Vega Strike ACCount server Protocoll (vsaccp) that run as a program not as a web script

Oh, yeah. I wish I had time to spare for this, but an account server and server admin in general in xmlrpc would be wonderful, especially because it'd be braindead easy to make frontends for it, and the server would be simple as hell too with python.

3. new web front end for the account server (that is my task )
4. create a new database (i plan to all so dising)

Just use SQLAlchemy for the XML-RPC based account server, and you can support many databases, including sqlite, in a jiffie.

[klauss]

BTW, there should only be like two uses of pragmas related to disabling warnings that are accepted as being OK due to optional pointers from boost.

I've been looking for alternative ways of disabling the warnings... to no avail. So I'll tend to agree with you. But GCC 4.5 disallows pragma diagnostic inside functions, and it warns it doesn't support push when put outside, so it really doesn't help for 4.5. I wrapped it in if __GCC_BLAH__ >= 4.7 and it builds fine (that file, other stuff creeping up).

but using such old versions of GCC will seriously impact vectorization and available cflags. 4.6 has significant improvements in that area . 4.7 is even better.

Yeah, as with python 3.3, we can support building with lesser versions, but with the caveat that performance will suffer. No big deal.

not sure why you would still be building with 4.5 but you will be seeing the game through a poor lens. we should all be developing with the latest tools available in dists.

Forget about openSuse 11.4 (even though it matters a lot), debian stable. We cannot leave debian's latest stable unsupported (I mean, it would be crazy). Debian stable has python 3.0 IIRC, so we might be able to support it with the in-tree boost, it's just a matter of sprinkling a few ifdefs.

[safemode]

I would suggest removing system boost support and forcing in-tree only. we are current there and it is unnecessary to add an avoidable dev inconsistency. dev environments need to be current. there is absolutely no reason to work on supporting lib APIs that are already deprecated or obsolete. that is just stupid.

[www2]

Savemode
I think we need set the baseline for gcc as the last version of gcc in ubuntu (GCC 4.6)

[klauss]

I would suggest removing system boost support and forcing in-tree only. we are current there and it is unnecessary to add an avoidable dev inconsistency. dev environments need to be current. there is absolutely no reason to work on supporting lib APIs that are already deprecated or obsolete. that is just stupid.

Distros require that we use system libs when possible. In fact that's the whole reason d'etre of system boost options.

[safemode]

I created the system option because in tree was always outdated. it should be something we support for testing purposes but on final build, it would be better to build against the boost we are coding for instead of relying on any combination of boost versions linked to any number of different Python versions. I have like 4 or 5 in my own system. picking the right one to link to will be totally dependant on whatever that dist sy links to the standard .so name. not good for trouble shooting issues that will come up. all the Python 3 libs will be trouble enough.

[klauss]

I created the system option because in tree was always outdated. it should be something we support for testing purposes but on final build, it would be better to build against the boost we are coding for instead of relying on any combination of boost versions linked to any number of different Python versions. I have like 4 or 5 in my own system. picking the right one to link to will be totally dependant on whatever that dist sy links to the standard .so name. not good for trouble shooting issues that will come up. all the Python 3 libs will be trouble enough.

Ah, ok, I may have mistaken your intentions when adding them (I didn't even remember it was you), but I do not mistake the distro's requirements. I've found they patched VS to build againt system boost, instead of requiring them to patch it, we should support it.

We can always validate version numbers.

In any case, when using system boost, pkg-config should take care of linking against the right one.

[safemode]

system boost was always an unsupported means of utilizing newer versions of boost that vs didn't yet handle. That's it. It doesn't make any sense to make the default method "use whatever you have even though we include a specific and tested version with the source you also already have"

If dists were building VS with the system boost option, it was probably because the versions in VS were not current. Otherwise I'd say it was stupidity on their part. Troubleshooting issues related to using boost versions not shared by all of the developers is much more of a hassle than doing it with one that is. And there is _no_ reason i can think of to not use the version boost that's already there. libboost-python is about half a MB. So there's no real shared benefit there for disk space and VS's main memory use is local caching of textures, both in file compressed form and uncompressed (shared data makes up almost nothing of it's 1.4GB of use). It'll be guaranteed to be built against the correct arch. It'll be guaranteed to be found on any dist. We dont have to worry about catching issues where libboost-python has 64 bit or 32bit versions and is linked against different versions of python and/or boost.

It's vastly simpler on our end. Requires no overhead. reduces build issues downstream and results in no regression with the End User.

I think we'll have enough issues jumping through the hoops distros have created with locations for python3's various build files and libraries on multi-archs.

I'm only saying that this is the way we should go because we're including it anyway. If we're going to have an in-tree boost setup, then we should use it. Not conditionally use it. It doesn't make sense at all not to use it. The only way i would suggest system-boost to be the default is if we got rid of boost from the source and had windows and mac devs just pull their own installation of boost and libboost-python and point the project to that in whatever IDE they use. But even then, we would only be hurting ourselves trying to decide what range of boost is acceptable .... Just tell people "this is what you should use" if you dont use it, it's on you. Sometimes Apple gets certain ideas right... less choice == less unknowns. This is such a situation where we can impose that and it wont hurt anyone.

[klauss]

system boost was always an unsupported means of utilizing newer versions of boost that vs didn't yet handle. That's it. It doesn't make any sense to make the default method "use whatever you have even though we include a specific and tested version with the source you also already have"

I never meant to make it default, only not remove it. Distros will want to set it to YES. If they don't check compatibility first, NOP.

If dists were building VS with the system boost option, it was probably because the versions in VS were not current.

Don't forget patches.

We dont have to worry about catching issues where libboost-python has 64 bit or 32bit versions and is linked against different versions of python and/or boost.

We don't. They do.

It's vastly simpler on our end. Requires no overhead. reduces build issues downstream and results in no regression with the End User.

Agree. I'm using in-tree boost already, and don't see a reason not to (other than to test support for system boost).

[safemode]

we also need to make use of raycollider for when physics frames time slice is too small for the next position of a unit to be within its previous radius. this is important for handling collision detection at large distances without making the matter worse by eating exponentially more CPU, leaving even less time next frame.

it is also infinitely important we tune the scheduler to throttle in favor of units in close proximity to another unit... this can be checked by a local boolean variable set by that unit and unset when opcode detection is triggered. like a heavy weight. 10:1 or so. we should never see clipping or units passing through units

[klauss]

we also need to make use of raycollider for when physics frames time slice is too small for the next position of a unit to be within its previous radius. this is important for handling collision detection at large distances without making the matter worse by eating exponentially more CPU, leaving even less time next frame.

Yeah, I've thought about that, and no. It would only exacerbate the problem of mid-SPEC collisions (or, in general, high-speed collisions), and there isn't any real benefit to my knowledge.

it is also infinitely important we tune the scheduler to throttle in favor of units in close proximity to another unit... this can be checked by a local boolean variable set by that unit and unset when opcode detection is triggered. like a heavy weight. 10:1 or so. we should never see clipping or units passing through units

Yeah, that's weird.

[safemode]

we also need to make use of raycollider for when physics frames time slice is too small for the next position of a unit to be within its previous radius. this is important for handling collision detection at large distances without making the matter worse by eating exponentially more CPU, leaving even less time next frame.

Yeah, I've thought about that, and no. It would only exacerbate the problem of mid-SPEC collisions (or, in general, high-speed collisions), and there isn't any real benefit to my knowledge.

you forget, i dont care about spec collisions because i dont see spec as a useful feature. And if it exists at all it wont be in the way it's used now. The very fact that you can collide while in spec is opposed to the idea of spec in the first place. If you can collide in spec then you can collide with all things in space, which means you will hit matter which normally is very sparse in space with a relative density of lead at SPEC speed. Hence making spec impossible. One or the other, you can't have both superluminal and collisions with other objects.

This is for missiles and other fast moving objects where they are moving too fast for our simulation steps to put the unit within 1 radius of the last position. This is a problem for ships and for missiles and it increases in magnitude the more busy the Draw() frame is and the more busy the physics frame is. The more time between physics frames, the more this problem presents. With hardware graphics, you probably wont notice this problem unless you've got a lot going on in the screen (either bloating the gpu frame or lots of units adding to both). But eventually it will get noticed because we dont handle it well. Put a dozen units on the screen and have them fire missiles at eachother and you're bound to start seeing missiles going right through units. That's not a bug in the collision code, it's a bug in the simulation scheduling and collision code.

it is also infinitely important we tune the scheduler to throttle in favor of units in close proximity to another unit... this can be checked by a local boolean variable set by that unit and unset when opcode detection is triggered. like a heavy weight. 10:1 or so. we should never see clipping or units passing through units

Yeah, that's weird.

It's more cost effective. When units check for proximity to other units anyway they can save that return value to a variable. The next unit will do the same. And so on. It doesn't matter if unit A says it's not close to anything, then later in that frame Unit B says it's close to unit A. That's ok. Position/Physics is calculated serially in VS, not in parallel. Cuz then we can have the physics simulation scheduler instead of picking units at random and only weighing the player a little more in favor, it will recurse through units that say they are in proximity of other units and weigh them more ... perhaps not a boolean but a number indicating the number of units they're close to. Giving the highest number to the player always but then descending by that number. Always giving a unit near units higher priority than units not near other units guarantees that units where there is a chance of clipping or totally missing a collision will get caught before that happens.

Ie, we dont care if we totally allow a unit that's not near anything to move 4x it's radius in one frame if the game is so loaded down that that happens. We ABSOLUTELY can't allow that kind of thing to happen to units that are near eachother.


Edit: i think the way things are done now is a semi-random selection of units but weighted on distance to the player. .. This however, is insufficient. And it doesn't appear to take into consideration speed when calculating what "near" is. There is a lot of room for improvement here. and it will vastly improve gameplay dynamics. It's embarrassing to have a game that looks so good behave so badly.

[klauss]

This is for missiles and other fast moving objects where they are moving too fast for our simulation steps to put the unit within 1 radius of the last position.

Yeah, that's the one case that should be handled. But that doesn't need a full capsule-vs-capsule test, only a ray test.

With hardware graphics, you probably wont notice this problem unless you've got a lot going on in the screen (either bloating the gpu frame or lots of units adding to both). But eventually it will get noticed because we dont handle it well.

IIRC, physics isn't tied to graphics. Physics only advances one step at a time, and when things are way behind schedule, only up to N steps. IIRC.

Anyway, that's not the problem with missiles, IIRC again. IIRC, the scheduler forces missiles on the high-priority slot. They go right through units because they're very very very fast, and sometimes they miss the target having no ray test.

It's more cost effective. When units check for proximity to other units anyway they can save that return value to a variable. The next unit will do the same. And so on. It doesn't matter if unit A says it's not close to anything, then later in that frame Unit B says it's close to unit A. That's ok. Position/Physics is calculated serially in VS, not in parallel.

Actually, we talked about this with hellcatv once. The better way for this to be handled, is to compute a per-unit simulation step based on probability volumes. Ie, you compute the probability volume of a unit as, given acceleration and speed limits within the time quantum, the volume where it could end up in the following T seconds. Then you compute T such that it doesn't result in intersections, apply some maximum, and that's it. Well, with the added complexity that would require having a per-unit value like that, because if you change one T for one unit, you should validate that it doesn't interact with other volumes, but that's not computationally efficient, so some heuristics are called for.

In fact, the usage of probable volumes is the main heuristic at work, because you could simply compute a curved trajectory, but that wouldn't account for possible acceleration variations that could be induced by quantum changes. Using volumes, you can change the simulation step of units without invalidating other units' quantum selection.

Anyway, in that way, you have almost perfect simulation at almost optimal speed.

Always giving a unit near units higher priority than units not near other units guarantees that units where there is a chance of clipping or totally missing a collision will get caught before that happens.

Which is essentially the main proposition of probability volumes. The idea of "probability volumes" though is specifically coined to optimize the case of flocking (units in formation), which are close to each other, but have really stable paths.

Edit: i think the way things are done now is a semi-random selection of units but weighted on distance to the player. .. This however, is insufficient. And it doesn't appear to take into consideration speed when calculating what "near" is. There is a lot of room for improvement here. and it will vastly improve gameplay dynamics. It's embarrassing to have a game that looks so good behave so badly.

The randomness is in phase offset, but not frequency. Frequency is deterministically derived from distance to player and unit role.

[safemode]

This is for missiles and other fast moving objects where they are moving too fast for our simulation steps to put the unit within 1 radius of the last position.

Yeah, that's the one case that should be handled. But that doesn't need a full capsule-vs-capsule test, only a ray test.

that's what i said. ray testing needs to be done for units that are moving more than their radius per physics frame. I'm also saying, that when a unit is near another unit, it needs to not move more than it's radius when at all possible (scheduling changing).

With hardware graphics, you probably wont notice this problem unless you've got a lot going on in the screen (either bloating the gpu frame or lots of units adding to both). But eventually it will get noticed because we dont handle it well.

IIRC, physics isn't tied to graphics. Physics only advances one step at a time, and when things are way behind schedule, only up to N steps. IIRC.

umm. Physics and graphics are serial operations. They dont work in parallel (though i wish they did) and they both have to complete in a given amount of time. How you dont think how one is then dependent on the other in order for the game to both be smooth graphically and smooth physics-wise is perplexing. When physics gets behind it doesn't make things run in slow motion. We use real time and simply make the unit take bigger steps VS.

Anyway, that's not the problem with missiles, IIRC again. IIRC, the scheduler forces missiles on the high-priority slot. They go right through units because they're very very very fast, and sometimes they miss the target having no ray test.

they go through the units because their steps per physics frame are too large because they're not on a high enough priority. The scheduler isn't executing it's physics updates often enough. You should never have a unit that can become near another unit in the next frame be moving in steps that are beyond it's own radius. Ray colliding is an option but the problem is indicative of scheduling and general performance of both the drawing frame and how long physics updates take. If we can't check missiles often enough for the 1 radius rule, then yes, we will be relying on ray colliding. But missiles aren't the only area where we muck up priority of physics frames.

It's more cost effective. When units check for proximity to other units anyway they can save that return value to a variable. The next unit will do the same. And so on. It doesn't matter if unit A says it's not close to anything, then later in that frame Unit B says it's close to unit A. That's ok. Position/Physics is calculated serially in VS, not in parallel.

Actually, we talked about this with hellcatv once. The better way for this to be handled, is to compute a per-unit simulation step based on probability volumes. Ie, you compute the probability volume of a unit as, given acceleration and speed limits within the time quantum, the volume where it could end up in the following T seconds. Then you compute T such that it doesn't result in intersections, apply some maximum, and that's it. Well, with the added complexity that would require having a per-unit value like that, because if you change one T for one unit, you should validate that it doesn't interact with other volumes, but that's not computationally efficient, so some heuristics are called for.

there is no need to compute if it interacts with other volumes. You only need the 1 computation per unit that gets a physics frame update. When you do the collision check it will trigger as expected on one or the other unit. It doesn't have to trigger on both units. Colliding takes care of playing with both.

In fact, the usage of probable volumes is the main heuristic at work, because you could simply compute a curved trajectory, but that wouldn't account for possible acceleration variations that could be induced by quantum changes. Using volumes, you can change the simulation step of units without invalidating other units' quantum selection.

Anyway, in that way, you have almost perfect simulation at almost optimal speed.

Always giving a unit near units higher priority than units not near other units guarantees that units where there is a chance of clipping or totally missing a collision will get caught before that happens.

Which is essentially the main proposition of probability volumes. The idea of "probability volumes" though is specifically coined to optimize the case of flocking (units in formation), which are close to each other, but have really stable paths.

Edit: i think the way things are done now is a semi-random selection of units but weighted on distance to the player. .. This however, is insufficient. And it doesn't appear to take into consideration speed when calculating what "near" is. There is a lot of room for improvement here. and it will vastly improve gameplay dynamics. It's embarrassing to have a game that looks so good behave so badly.

The randomness is in phase offset, but not frequency. Frequency is deterministically derived from distance to player and unit role.

unfortunately the distance to the player makes missiles vs units that are multiple radiuses away from the player not frequent enough. Frequency needs to account for distance of any unit to any unit ... but always putting the player at the top of the list.

[klauss]

umm. Physics and graphics are serial operations. They dont work in parallel (though i wish they did) and they both have to complete in a given amount of time. How you dont think how one is then dependent on the other in order for the game to both be smooth graphically and smooth physics-wise is perplexing. When physics gets behind it doesn't make things run in slow motion.

I gues you haven't played on a really slow computer. I can tell you with complete certaintly, that when a threshold is reached, the game goes in slow motion. The threshols is high. And yes, graphics is serialized, so if the game is doing this bad, it will also have a really low FPS no matter the supeGPU you might have.

they go through the units because their steps per physics frame are too large because they're not on a high enough priority.

Actually, there isn't a high-enough priority slot for them to work. Missiles need ray testing.

But I believe there is another problem. Collisions are designed in VS to have the bigger unit check for the smaller (something required by the spatial sorting in use). Missiles are the smaller, so no matter how high their priorities are, they won't collide with the ships. They only hit the ship when locked, if you check, and that's probably because then you lock a unit, it's popped into the high-priority slot too (assuming you're going to fire on it).

[safemode]

I think the whole bigger and smaller has to do with the possible collision dealing damage and vector changing. I don't think it should affect detection. not saying it doesn't, but it shouldn't. I'll look into implementing ray collision better and changing the conditions we check

[Deus Siddis]

Collisions are designed in VS to have the bigger unit check for the smaller (something required by the spatial sorting in use). Missiles are the smaller, so no matter how high their priorities are, they won't collide with the ships. They only hit the ship when locked, if you check, and that's probably because then you lock a unit, it's popped into the high-priority slot too (assuming you're going to fire on it).

Bah, so that's why dumb fire rockets are so unreliable. Do "bolt" weapons have the same issue?

Actually, there isn't a high-enough priority slot for them to work. Missiles need ray testing.

Just curious, will you run the ray test between the positions of the missile last frame and present frame to check for between-frame impacts with units?