Oolite Bulletins

Ganelon wrote:

Commander McLane wrote:

One other tweak would be needed: Currently pirateAI has an in-built delay of action. A pirate doesn't got after you immediately after you crossed his path. So, if you're very quick with step 4, it's theoretically possible that step 7 never happens. The obvious solution is to shorten the pirates' delay.

I'm not sure how long the delay spoken of is, but if it's made too short or eliminated, we could lose some of the illusion of the game AI being people in other ships. At present, when a ship comes on your screen there's a moment before it reacts to you that is logically while the (albeit fictional) commander of the other ship is noticing you on their scanner, ID-ing you and deciding what to do about you. While it's not impossible that there may be commanders somewhere in space who instantly attack anything that moves, most would probably take a little time before deciding if they should risk their ship.

I've no clue how things work from a technical point, but the in-ooniverse way of dealing with it would obviously be to tie the delay to game time, not real time. So if the TimeDrive speeds up time by a factor of 10 (random number picked out of my head - I really have no clue how much faster you go on Jumpdrive), an AIdecision that usually takes 10 seconds to make would take 1 second with TD activated.

But I'm sure the guys who actually know how things work under the hood will be along shortly to tell us all about why this plan won't work...

CheeseRedux wrote:

Commander McLane wrote:

One other tweak would be needed: Currently pirateAI has an in-built delay of action. A pirate doesn't got after you immediately after you crossed his path. So, if you're very quick with step 4, it's theoretically possible that step 7 never happens. The obvious solution is to shorten the pirates' delay.

I take it that this delay is a real time delay and not a game time delay? Because otherwise it would not apply.

Good point. It's an AI pause, which means it is a game time delay. So you can safely disregard my remark, I think.

On second thoughts, perhaps not so safely. Currently the TAF works by skipping AI cycles. Only every second AI cycle gets executed with TAF = 2; and only one in 16 cycles with TAF = 16. That's why for instance NPC escorts get off-route with a higher TAF. Performing only 1 check out of 16 causes a dramatic loss of accuracy. The same would apply to scanning for prey in case of pirates, I think, making it more likely for the prey to get away unscanned.

Commander McLane wrote:

CheeseRedux wrote:

I take it that this delay is a real time delay and not a game time delay? Because otherwise it would not apply.

Good point. It's an AI pause, which means it is a game time delay. So you can safely disregard my remark, I think.

On second thoughts, perhaps not so safely. Currently the TAF works by skipping AI cycles. Only every second AI cycle gets executed with TAF = 2; and only one in 16 cycles with TAF = 16. That's why for instance NPC escorts get off-route with a higher TAF. Performing only 1 check out of 16 causes a dramatic loss of accuracy. The same would apply to scanning for prey in case of pirates, I think, making it more likely for the prey to get away unscanned.

Well, since I seem to be in brainstorm mode today, how about this: A two-speed TimeDrive. One TAF for yellow, a faster one for green.

The yellow TAF could be set to something that would allow you to reasonably hold position with another ship, making escort missions less of a drag, whereas the green TAF could be set to whatever speed the game can handle while still performing a reasonable amount of AI operations.
I realize that this would have some effect on AI-AI interactions beyond the player's scanner range, but would anyone ever notice? Again, someone with the technical knowledge will have to answer that one.

To incorporate this in my original travel description (Numbers are just used for illustration, and not meant as suggestions):
You have some sort of company, so condition is yellow. Using TD sets TAF to 5x. As soon as scanner is clear and condition goes green, TAF goes to 15x. If at any point condition changes to red, TAF=1.

Or given that TAF is currently a power of 2 thing, 4x and 16x for yellow and green respectively...

If you're going to go down the path of using time acceleration, bear in mind that for keyboard users, the up/down/roll keypresses are 'accelerated' also.

i.e. at x1, you get a normal response from the keyboard, but at x2, x4 etc, the keyboard is much more sensitive. Ditto with mouse and I suppose joystick control.

I've observed in Pioneer, the ship orientation controls are independant of the time acceleration factor; maybe the same thing would need to be implemented for Oolite...

CheeseRedux wrote:

Commander McLane wrote:

CheeseRedux wrote:

I take it that this delay is a real time delay and not a game time delay? Because otherwise it would not apply.

Good point. It's an AI pause, which means it is a game time delay. So you can safely disregard my remark, I think.

On second thoughts, perhaps not so safely. Currently the TAF works by skipping AI cycles. Only every second AI cycle gets executed with TAF = 2; and only one in 16 cycles with TAF = 16. That's why for instance NPC escorts get off-route with a higher TAF. Performing only 1 check out of 16 causes a dramatic loss of accuracy. The same would apply to scanning for prey in case of pirates, I think, making it more likely for the prey to get away unscanned.

Well, since I seem to be in brainstorm mode today, how about this: A two-speed TimeDrive. One TAF for yellow, a faster one for green.

The yellow TAF could be set to something that would allow you to reasonably hold position with another ship, making escort missions less of a drag, whereas the green TAF could be set to whatever speed the game can handle while still performing a reasonable amount of AI operations.
I realize that this would have some effect on AI-AI interactions beyond the player's scanner range, but would anyone ever notice? Again, someone with the technical knowledge will have to answer that one.

To incorporate this in my original travel description (Numbers are just used for illustration, and not meant as suggestions):
You have some sort of company, so condition is yellow. Using TD sets TAF to 5x. As soon as scanner is clear and condition goes green, TAF goes to 15x. If at any point condition changes to red, TAF=1.

Great idea. Maybe 16x is too much, as it disrupts the AIs. 8x for green and 4x for yellow. And I second the idea of setting TAF to 1 at red.

Bugbear wrote:

If you're going to go down the path of using time acceleration, bear in mind that for keyboard users, the up/down/roll keypresses are 'accelerated' also.

i.e. at x1, you get a normal response from the keyboard, but at x2, x4 etc, the keyboard is much more sensitive. Ditto with mouse and I suppose joystick control.

I've observed in Pioneer, the ship orientation controls are independant of the time acceleration factor; maybe the same thing would need to be implemented for Oolite...

Yeah, another great idea. Maybe combine both of the above, either in next version or in an OXP?