Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: SteveAlt
« on: August 20, 2009, 09:19:20 AM »

Quote from: "sloanjh"
I'm at year 18 of my conventional start, and in the midst of my 1st NPR encounter, so I thought I'd put out some observations on the rewrite.

1)  Overall, it's GREAT!!!  I've just gotten done running 3 1-day updates with a 2-minute sub-pulse size, i.e. 720 pulses per turn, and it only takes 20-30 seconds per turn.

2)  Ok, now the bad news - the reason that I'm doing 2-minute pulses is that Aurora is still letting contacts get deep into the sensor envelope when doing large-scale (e.g. 1-day) updates.  The first time I played the 1st contact scenario, Aurora chose a coarse (15-minute?) update, which put the gunboats that were intercepting me deep (about either 1/4 or 3/4 way - I don't remember which) into the range at which I should have detected them.  So I still had to fall back to a saved DB and replay it with a finer-grain update  The performance improvements mean I was able to do this, however.
The default sub-pulses are 30 minutes for one day updates. If the general consensus is that the game is running well with 48 sub-pulses, I can up that to 15 or even 10 minutes per sub-pulse.

Quote
3)  While I was waiting for jump technology, I did a lot of updates (10-15 years) where nothing was happening except civie shipping shuttling back and forth between Earth and Mars.  Once the civie orders issue was fixed, I still was doing 1.66 day or 2.5 day updates (depending on where Earth and Mars where in their relative orbits) rather than the 5 day updates I would have preferred.  The reason for this is that the civie ships seem to pile up together at the planets when the updates are too long.  I think this has to do with conditional orders not being checked during pulses; instead they're only checked at the end of the turn (at least it used to be this way).  So a ship would drop off its load of goods at Mars and wait before deciding it should head for Earth for a new load.  Note that I'm not 100% sure about the above - my prejudices were set while the civies were broken, and it might be that the order chaining is set up to not "pause" at the end of an update before going on to the next task.  On the other hand, I think I'm still seeing them pile up at the planets when Earth and Mars are close together.
New trade runs are setup at the end of a turn after all movement is complete. I did this for performance reasons - mainly because the code carries out a search for all commodities between all planets for each fleet ready for a new trade run and I didn't want that happening every sub-pulse. Although I guess I could flag those fleets that had already been checked and failed to find a trade run and only check them again post-movement.

Quote
4)  More good news - while I was doing e.g. the 2.5 day updates, Aurora was running faster than in previous versions.  In previous versions, I'd time-share by reading while Aurora was thinking.  In 4.2x, I don't quite have time to switch to the book before Aurora wants another click.
That's good to hear. It sounds like the rewrite was worth it overall but I may need to revisit the default number of sub-pulses. I would be interested in feedback from other players as well on that point.

Steve
Posted by: sloanjh
« on: August 18, 2009, 11:12:11 PM »

Quote from: "sloanjh"
Oooh Cool!!!  I just lost contact with some aliens, and Aurora left a location marker for where the contact was lost, along with a "tail" to show heading.  Thanks Steve - that's exactly the sort of thing I was looking for with the lost contact stuff!!!

John

Oops.  Looks like what was really going on what that I lost active contact (but still had thermal).  The next timestep I lost all contact and they disappeared (i.e. no marker where they went away).  OTOH, the message losing thermal contact remembered which ship the thermal corresponded to (a good thing).

John
Posted by: sloanjh
« on: August 18, 2009, 11:00:39 PM »

Oooh Cool!!!  I just lost contact with some aliens, and Aurora left a location marker for where the contact was lost, along with a "tail" to show heading.  Thanks Steve - that's exactly the sort of thing I was looking for with the lost contact stuff!!!

John
Posted by: sloanjh
« on: August 16, 2009, 04:18:43 PM »

I'm at year 18 of my conventional start, and in the midst of my 1st NPR encounter, so I thought I'd put out some observations on the rewrite.

1)  Overall, it's GREAT!!!  I've just gotten done running 3 1-day updates with a 2-minute sub-pulse size, i.e. 720 pulses per turn, and it only takes 20-30 seconds per turn.

2)  Ok, now the bad news - the reason that I'm doing 2-minute pulses is that Aurora is still letting contacts get deep into the sensor envelope when doing large-scale (e.g. 1-day) updates.  The first time I played the 1st contact scenario, Aurora chose a coarse (15-minute?) update, which put the gunboats that were intercepting me deep (about either 1/4 or 3/4 way - I don't remember which) into the range at which I should have detected them.  So I still had to fall back to a saved DB and replay it with a finer-grain update  The performance improvements mean I was able to do this, however.

3)  While I was waiting for jump technology, I did a lot of updates (10-15 years) where nothing was happening except civie shipping shuttling back and forth between Earth and Mars.  Once the civie orders issue was fixed, I still was doing 1.66 day or 2.5 day updates (depending on where Earth and Mars where in their relative orbits) rather than the 5 day updates I would have preferred.  The reason for this is that the civie ships seem to pile up together at the planets when the updates are too long.  I think this has to do with conditional orders not being checked during pulses; instead they're only checked at the end of the turn (at least it used to be this way).  So a ship would drop off its load of goods at Mars and wait before deciding it should head for Earth for a new load.  Note that I'm not 100% sure about the above - my prejudices were set while the civies were broken, and it might be that the order chaining is set up to not "pause" at the end of an update before going on to the next task.  On the other hand, I think I'm still seeing them pile up at the planets when Earth and Mars are close together.

4)  More good news - while I was doing e.g. the 2.5 day updates, Aurora was running faster than in previous versions.  In previous versions, I'd time-share by reading while Aurora was thinking.  In 4.2x, I don't quite have time to switch to the book before Aurora wants another click.

Overall - THANKS!!!!

John
Posted by: sloanjh
« on: June 26, 2009, 08:55:28 PM »

Cool!!!  I suspect that the increased performance will help a lot in moving through the calendar once the game becomes complex (with multiple NPR).

John

PS - Have fun in Vegas!
Posted by: Steve Walmsley
« on: June 26, 2009, 04:57:33 PM »

Latest update on the rewrite. The program is pretty much back in one piece and I have processed increments up to one day in length plus a couple of 5-day increments. The performance is staying on track with the larger increments. For example, a 3 hour increment with five minute sub-pulses takes about seven seconds. A good example of this is the detection of an NPR scout in my latest fiction update. It was detected pretty much on the edge of sensor range without any prior checks (I had forgotten it was in the system).

There is now an 'Automatic' option for sub-pulses instead of a 'None' option, although you can still select your own if required. The default sub-pulse lengths are shown below. If you use the player-specified increment length, it will use the closest default option for sub-pulse length.

Up to 60 seconds: 5 seconds
2 minutes: 10 seconds
5 minutes: 15 seconds
20 minutes: 60 seconds
1 hour: 2 minutes
3 hours: 5 minutes
8 hours: 15 minutes
1 Day: 30 minutes
5 days: 2 hours
30 days: 6 hours

There are some bugs but so far they are relatively straightforward and I am working through them as I play. I think it will probably be at least a month before v4.1 though as I am playing poker a lot at the moment and I am going to Vegas for 2 weeks for the WSOP.

Steve
Posted by: Steve Walmsley
« on: June 14, 2009, 12:07:02 PM »

I think I might have resolved the issue regarding the lack of NPR missile defence. Due to the screwup mentioned above I have been stepping through the code and spotted that the NPR allocation of missiles to launchers doesn't seem to happen unless the fire control has a specific target. If it is just setup for generic pont defence, then, as far as I can tell, the allocation code is never called. This is based just on reading the code though, rather than an actual test. I should know for sure once the current battle reaches a point where the NPR is defending against the Commonwealth missile strike. If that is the case, I cannot figure out how I didn't manage to spot before releasing v4.0b but at least NPRs will suddenly get a lot better in v4.1 :)

Steve
Posted by: Steve Walmsley
« on: June 14, 2009, 10:22:52 AM »

Quote from: "Andrew"
Quote from: "Steve Walmsley"

Similarly for defensive fire, if you fire missiles at an NPR ship and then advance time by 30 mins or even 5 mins, it is possible those missiles will hit the target before the NPR can launch anti-missiles against them. Although this should be ameliorated a little by the code in v4.0 that tries to anticipate when a missile will enter sensor range of its target, NPR escorts are often in separate fleets and are therefore not checked for missile detection because they are not in the target fleet. This scenario could explain those reported situations where NPR escorts have not fired at incoming missiles but have then attacked player ships with their size 1 missiles.

Steve
I don't think that was the only cause as in at least one of these situations I was using 5 second increments because my own fleet was defending itself against long range missile fire. There was also a message visible in the SM View indicating that they where trying to fire at the incoming missiles but had no missiles for the launchers.
It looked to me that when they started firing size 1 missiles it was after they had fired off all of their larger long range missiles
Thanks for letting me know. I'll see if I can figure out what is causing that. Although it may be academic anyway. I just started fighting an engagement to test the new object-oriented code and I appear to have broken missile defence :)

Steve
Posted by: Andrew
« on: June 14, 2009, 06:06:21 AM »

Quote from: "Steve Walmsley"

Similarly for defensive fire, if you fire missiles at an NPR ship and then advance time by 30 mins or even 5 mins, it is possible those missiles will hit the target before the NPR can launch anti-missiles against them. Although this should be ameliorated a little by the code in v4.0 that tries to anticipate when a missile will enter sensor range of its target, NPR escorts are often in separate fleets and are therefore not checked for missile detection because they are not in the target fleet. This scenario could explain those reported situations where NPR escorts have not fired at incoming missiles but have then attacked player ships with their size 1 missiles.

Steve
I don't think that was the only cause as in at least one of these situations I was using 5 second increments because my own fleet was defending itself against long range missile fire. There was also a message visible in the SM View indicating that they where trying to fire at the incoming missiles but had no missiles for the launchers.
It looked to me that when they started firing size 1 missiles it was after they had fired off all of their larger long range missiles
Posted by: Steve Walmsley
« on: June 12, 2009, 12:57:39 PM »

Another update:

The rewrite is 95% done and I am starting the test phase. This will take a while though as so much has changed. After that I will go through the Bugs and Suggestions threads, although some of those may no longer be applicable because of the changes. As part of the testing, I came across a circumstance I hadn't fully considered before but which might explain the reports of NPRs not firing any anti-missiles. The potential problem occurs because while detection takes place after each sub-pulse, firing only takes place after all movement is complete. This has a couple of implications for NPRs that usually will not affect players.

The first is with regard to offensive fire. When you are firing weapons on your own ships, you very likely advance time enough to reach the next reload or recharge point. However, as you don't know when NPRs are firing, especially if they are launching missiles at long range, you could easily advance time too far. For example, an NPR could fire a salvo of missiles at you without you even knowing the NPR fleet was there and then you might select a 30 minute increment. The first wave of missiles would spend 30 minutes moving toward you and the second NPR launch would only take place at the end of that thirty minutes. The NPR missile waves could therefore arrive too far apart to trouble your defences.

Similarly for defensive fire, if you fire missiles at an NPR ship and then advance time by 30 mins or even 5 mins, it is possible those missiles will hit the target before the NPR can launch anti-missiles against them. Although this should be ameliorated a little by the code in v4.0 that tries to anticipate when a missile will enter sensor range of its target, NPR escorts are often in separate fleets and are therefore not checked for missile detection because they are not in the target fleet. This scenario could explain those reported situations where NPR escorts have not fired at incoming missiles but have then attacked player ships with their size 1 missiles.

The defensive fire should be improved anyway in v4.1 due to the small sub-pulses that should take place as a missile approaches its target. Even so, I have added some additional code to try and avoid both above situations in v4.1. At the start of an increment, Aurora will check for any existing fire orders for fire control systems. If it finds any, it will calculate the shortest reload or recharge time (if any) before weapons associated with that fire control are ready to fire and will reduce the increment to that length. This means that you don't have to worry about your own weapon reload times as Aurora will not advance time beyond the point at which they are due to fire. More importantly, it will allow NPRs to fire their weapons at the correct rate and should allow anti-missile launchers to fire as often as possible. This may cause a few short increments to occur for no apparent reasons but this will be for those situations where NPRs are fighting each other.

As fire control assignments are already unset if the target is out of range and NPRs review their firing decisions every increment, this should will not cause any unnecessary reductions in increment length. However, I hope it will increase the capability of NPRs considerably.

Steve
Posted by: Steve Walmsley
« on: June 08, 2009, 09:21:05 PM »

Quote from: "sloanjh"
Actually, this (detection of bad guys when they transit into a hostile system) is working really well in v4.0b.  As you say, (I think) an interrupt event gets generated, whether or not the WP is picketed.  In addition, Aurora seems to be calculating arrival time so that it stops at the time of transit (which shouldn't be expensive, since there's no N^2).  So I'm not sure how your idea is different/better than what's being done now in v4.0b.  I would keep things the same as v4.0b, with the following minor tweaks:
I have to completely rewrite it anyway as it is all database-based at the moment and the new version only uses objects. What I am trying to do is remove the performance-intensive check at the start and replace it with something more reliable and that only interrupts if a detection takes place. There is also the concept of hostile/neutral/friendly/allied contacts in v4.1, so I don't want to interrupt for all detections.

Quote
1)  Do a detection check (for that ship) when the ship transits, and only halt the increment if the ship is detected.
While I was pondering how to tackle this part of the rewrite, I realised that a detection check is carried out anyway when a ship transits to see if anyone detects the jump point as a result of the transit. So I just added a little extra code that flags an interrupt if this detection is by a hostile or unknown race. This removes the need for any upfront checks. The only downside is that a ship may lose a few minutes of movement but as I noted above that has very little gameplay effect.

Quote
2)  Do a detection check on the pre-transit side too (for the transiting ship).  Right now, a bad guy who's glowing like the Sun can blow right by my pickets on the "friendly" side of a WP if a typical large increment is being used - when the increment stops, they're on the other side of the WP and undetectable.  If you knew a ship was going to make a transit, you could give the WP the ship's signature and see if anyone could detect it - if so, treat it like a missile engagement with the ship being the missile, i.e. take some smaller sub-pulses.
The detection code is already in v4.0 for the obervation of transit on the entry side. It just didn't stop time. The rewritten code should handle that. As far as the approach goes, the sub-pulses should take care of detecting ships on approach. Even using 1-day increments and 30 minute sub-pulses, a ship moving at 4000 km/s can only cover about seven million kilometers, which is not a huge distance compared to likely sensor ranges.

Quote
3)  This doesn't solve the "bouncing geo-survey" problem, where an NPR geo-survey ship keeps transiting back and forth between two fully surveyed systems, and one side of the WP is under observation.  I think that problem needs to be solved on the AI side, though.
I agree.

Quote
As far as my personal preferences on the "realism" issue go, my v4.0b game has led me to the viewpoint that I'd rather err on the side of detecting things that should be detected over getting information that I'm entering a system with bad guys in it.  I also find it useful to get a "something's about to happen" indicator so that I can back up my DB in case a detection gets missed and I need to re-play with smaller increment.  I've found that I have a pretty good idea where the bad guys are if I know about the race, so the only situation where I think you'd be getting much additional info is when transiting an already explored system that the bad guys have snuck into, and even that wouldn't be a lot of info since I typically don't go looking through my fleets to see who just transited if I get an NPR interrupt.

Steve
Posted by: sloanjh
« on: June 08, 2009, 12:40:24 AM »

Quote from: "Steve Walmsley"
Quote from: "sloanjh"
Something that occured to me while writing the bit about "realism" in the last post....

In my next game, I think I'm probably going to turn off the computer-controlled NPR.  The reason for this is that they don't seem to be running their civilizations aggressively enough - I've been in contact with 2-3 (much higher tech) NPR for 5-10 years now and they've been ineffective at coming out after me.  What I'd REALLY like to do is have a mechanism to turn a "known" (shows up on the diplomacy screen) computer-controlled NPR into a player-controlled NPR, i.e. make it visible and taking orders in SM mode.  Would that be difficult to code up?
I will be trying to make them more aggressive in the future. For my first attempt I was just trying to get them working :-)  I think they behave best when you are first making contact, though - the "what kind of contact is that and just how capable are they" effect is much more stimulating than role-playing both side.  Hence the "take over control" thought - to get the adrenaline spikes off the initial encounter, then to run them as a "smart" opponent.

Your diplomacy comment reminded me of something I've tried to do on my own in the past - decide on racial strategies to abide by when role playing.  For example, a paranoid race might picket all known WP with armed ships, and blow away anything making transit (which makes negotiation a little difficult :-) ).  There's also a "how expansionistic are they" question - do they just want to sit in their home system, or are they rabid explorers?  It would be nice if part of NPR generation looked at the racial characteristics and picked such a set of strategies, similar to the commander characteristics that are generated.

John
Posted by: Steve Walmsley
« on: June 08, 2009, 12:33:53 AM »

Quote from: "sloanjh"
I'm actually suggesting something that (I think) is a lot simpler, and would probably speed up performance, due to cutting the number of sensor checks.  The missile picket stuff is just a side-effect/bonus.
As it is 6.30am here I really need to get some sleep before answering this so I'll get back into it tomorrow :)

Steve
Posted by: Steve Walmsley
« on: June 08, 2009, 12:28:29 AM »

Quote from: "sloanjh"
Something that occured to me while writing the bit about "realism" in the last post....

In my next game, I think I'm probably going to turn off the computer-controlled NPR.  The reason for this is that they don't seem to be running their civilizations aggressively enough - I've been in contact with 2-3 (much higher tech) NPR for 5-10 years now and they've been ineffective at coming out after me.  What I'd REALLY like to do is have a mechanism to turn a "known" (shows up on the diplomacy screen) computer-controlled NPR into a player-controlled NPR, i.e. make it visible and taking orders in SM mode.  Would that be difficult to code up?
I will be trying to make them more aggressive in the future. For my first attempt I was just trying to get them working :). After v4.1 is done, I intend to spend a lot more time with NPRs both in terms of their actions and in terms of adding more varied types of ships. I have already added NPR FACs for v4.1. In addition, they will be using diplomacy in v4.1 so you will have neutral or perhaps even allied NPRs. However, having said that, when I finally get around to working on my planned book using Aurora as the basis I will very likely run with NPRs turned off as well. Controlling all sides is more useful when you want to engineer certain scenarios or role-play a race in a certain way.

Turning an NPR into a player race is actually relatively straightforward. It may not make it into v4.1 but I will add it for v4.2. However, you can't have a part-controlled NPR as it would override any orders you gave. It would have to be an NPR or a human-controlled empire. What would be far, far more difficult would be turning a player race into an NPR

Steve
Posted by: sloanjh
« on: June 08, 2009, 12:08:34 AM »

Something that occured to me while writing the bit about "realism" in the last post....

In my next game, I think I'm probably going to turn off the computer-controlled NPR.  The reason for this is that they don't seem to be running their civilizations aggressively enough - I've been in contact with 2-3 (much higher tech) NPR for 5-10 years now and they've been ineffective at coming out after me.  What I'd REALLY like to do is have a mechanism to turn a "known" (shows up on the diplomacy screen) computer-controlled NPR into a player-controlled NPR, i.e. make it visible and taking orders in SM mode.  Would that be difficult to code up?

John