Page 2 of 14
Posted: Mon Sep 06, 2010 7:01 am
by Kaks
Switeck wrote:
Do "sunskim-trader" still almost always kill themselves visiting the sun to refuel? Or are they automatically given heat shielding if doing that? What of their poor escorts (Mambas and Sidewinders) -- do they still die?
Up to fairly recently not all 'native' sunskimmers were protected adequately, but, in trunk, all system generated sunskimmers - and their escorts - should be able to survive long enough to fill their tanks & jump out...
However, if an OXP assigns a sunskimming AI to specific ships - ones already in flight, say - it's down to the OXP maker to make sure the selected ships & escorts are adequately protected.
Posted: Mon Sep 06, 2010 7:52 am
by Eric Walch
Switeck wrote:I have been frustrated with enemies fleeing on what I call a "straight-and-stupid" (from straight-and-level in aviation) when I'm on their tail...so caracal helped me (meaning he did most of the work
) make a modified pirateAI.plist for better pirate behavior. They will attempt a minor heading/rotation change when hit if they are already in a fleeing state.
I don't know if that really does work as fleeing ships look at their target and than take a course just away from it. When you let them turn, they should resume the old path quite soon.
But, on the other hand, there was a bug in the fly-away routine in Oolite. I fully investigated that for the normal (non-combat) fly away code. That is fixed in trunk now.
However, the fleeing mode uses a similar fly away code that has probably the same flaw. I did add a note in trunk with this part of the code but did not find time to do any testing. And I don't want to apply any fix before doing that. Those fly-away bugs have been there since before 1.65 so it are not very noticeable bugs for the normal player.
What the code tries to do is calculate a random offset from the target at the start of the flee and than always flee in a straight line from that offset, relative to the target. That way it always should fly out of the firing path of the aggressor.
(But for two months now, I have problems committing my trunk code, so I stopped working on the code)
Posted: Mon Sep 06, 2010 9:29 pm
by Eric Walch
Eric Walch wrote:I did add a note in trunk with this part of the code but did not find time to do any testing. And I don't want to apply any fix before doing that.
Switeck, when you can build trunk, you could test that change yourself.
Go to the function "trackPrimaryTarget()" in shipEntity.m. There are 4 lines marked with "note#". Delete in all 4 lines the "reverse" variable. (This reverse is wrong here and makes that the ship rolls the wrong way when retreating).
Now the ship does make small evasive maneuvers based on a "jink" setting. For fleeing the current jink value is to small so I went to shipEntityAI.m and changed
Code: Select all
- (void) performFlee
{
behaviour = BEHAVIOUR_FLEE_TARGET;
frustration = 0.0;
}
into
Code: Select all
- (void) performFlee
{
behaviour = BEHAVIOUR_FLEE_TARGET;
jink.x = ((ranrot_rand() % 256) - 128.0) * 50;
jink.y = ((ranrot_rand() % 256) - 128.0) * 50;
jink.z = 1000.0;
frustration = 0.0;
}
Now the ships constantly move out of your laser path. I added the factor "50" to get a strong effect so that should probably get reduced and further tweaked. It was just a short test of me to see if I could make the jink during retreat working, and it did.
So basically Giles already put the code in but it just was not completed. However, this changes known behaviour so any change must be handled with care before it can end up in Oolite itself.
Posted: Wed Sep 08, 2010 8:22 am
by Switeck
Sadly, building the trunk is a ways beyond my current ability.
Even scripting is very hard and I'm trying to stick to "easy" things at first.
Posted: Sun Sep 12, 2010 5:27 am
by Switeck
Switeck_mod_v0.2.oxp.zip
...is now available at:
http://www.mediafire.com/?7lwutb9cn5cacd5
Noteworthy Changes:
New Savegame:
A 3rd added savegame is Adder Broke Start -- no money, no witchfuel, no heat shielding (that's normally standard on Adders), no cargo, and no missile. In my own experience, after busting asteroids between Lave and Lave's sun, it didn't prove much harder than the Hard difficulty Adder start. It was just 1 extra hour of being resourceful at finding asteroids and not getting killed doing it.
Suicide-by-sun bug reduced:
Any NPC ships with "sunskim-trader" primary role gained heat_insulation = 2; (or 3; ) and should not automatically kill themselves as they near the sun. Their escort ships AND most any NPC ships that might be "forced" into the "sunskim-trader" primary role gained heat_insulation = 2; as well.
Minor ai improvements for ship behavior, in the form of edited AI.plist files.
Missile reload time reduced from v0.1's average of 8-10 seconds to 4-8 seconds. You'll almost need to hold the E key down to kill the flood of missiles from ships that have 4 or more missiles.
Some of these changes hopefully will be invalidated by Oolite v1.75 changes -- such as a better fix/workaround for the Suicide-by-sun bug, most of the ai improvements, and Thargoid/Thargon issues.
Posted: Sun Sep 12, 2010 8:38 am
by maik
Thanks Switeck, I updated the OXP's Wiki page and the OXP list accordingly.
Posted: Sun Sep 12, 2010 10:14 am
by Eric Walch
Switeck wrote:Any NPC ships with "sunskim-trader" primary role gained heat_insulation = 2; (or 3; ) and should not automatically kill themselves as they near the sun. Their escort ships AND most any NPC ships that might be "forced" into the "sunskim-trader" primary role gained heat_insulation = 2; as well.
Dit you test all this? Because I am sure your ships will still burn away with those values. A year ago, I did a research for an optimal value. For a fast viper 2 might be enough but with a ship as slow as an Anaconda you have to raise the value to at least 7. You can check this with the console. I followed a lot of the ships in the past and raised the value until they did make the jump safely. For the anaconda I had to go up to a heat protection of 7
. Than I went to a system with a very big sun, making the voyage extra long. There a value of 7 was not even enough.
However, since Oolite 1.74 do all ships that launch from a station as sunskimmer get a heat protection of at least 7. And the heat protection of escorts is raised to that of their mother on launch. (In trunk Anacondas now even get a value of 8 )
The same raise of heat protection happens to sunskimmers (and their escorts) added by the populator.
The only point were things still go wrong is with entering traders. They now just have a 33% change to go sunskimming. But because they often were added original as plain traders in an other system, they have not automatically the heat protection. Any entering trader could go sunskimming, even traders with no fuel-scoops. So the only sensible fix would be to remove the selection by chance (in enteringTraderAI.plist) and replace it by a selection of the ships capacities. However, that will need the introduction a new command to trunk like "checkSunskimStatus" and the station must than give all plain exiting traders that have the sunskimmer in their role set, a full sunskim quality (scoops and heatprotection) ....
Posted: Sun Sep 12, 2010 3:08 pm
by Switeck
No I didn't test sunskiming traders enough.
Then again, I did say it'd only reduce it...not eliminate it.
Well, I guess that gives me a reason to make mod v0.3!
I shudder to think how I can make a harder savegame for it.
Start out as fugitive with lots of Trumbles on board?
...At an anarchy. (Riedquat?)
maik wrote:Thanks Switeck, I updated the OXP's Wiki page and the OXP list accordingly.
Thanks!
Posted: Mon Sep 13, 2010 6:49 am
by Kaks
Eric Walch wrote: So the only sensible fix would be to remove the selection by chance (in enteringTraderAI.plist) and replace it by a selection of the ships capacities. However, that will need the introduction a new command to trunk like "checkSunskimStatus" and the station must than give all plain exiting traders that have the sunskimmer in their role set, a full sunskim quality (scoops and heatprotection) ....
Err, in trunk all sunskimmers added to the populator are already given adequate protection, yes, even when entering the system and they fall within that 33% chance. (Unless I've done something wrong).
The only thing that will be needed in the future, is for oxp makers to create their own sunskimming ships with adequate protection. And possibly for oxp makers to make sure not to assign sunskimming AIs to pre-existing, weaker, ships.
Posted: Mon Sep 13, 2010 5:37 pm
by Switeck
What about all escorts?
Does the sunskimmer added protection in trunk get extended to them too, when their mothership is told to take a sun-dive?
Posted: Tue Sep 14, 2010 6:33 am
by Kaks
Yep. It appears I might well have missed out one special case, but yes, if mommy is reinforced, the escorts are too!
Posted: Sun Oct 10, 2010 2:07 am
by Switeck
My next goal is a better scavenger behavior by ships passing through a system. Cargo Canisters should probably be grabbed by almost any passing ship with a fuel scoop that doesn't have a full cargo load.
In my scavengerAI.plist tests so far, it's a bit of a disaster.
Under:
"DOCK_WITH_STATION" =
{
ENTER = (setTargetToNearestStation, "setDesiredRangeTo: 5000.0", performIntercept);
I added:
UPDATE = ("pauseAI: 60.0", "setStateTo: LOOK_FOR_STUFF"); // Added! Check for loot again every 60 secs.
And also under:
"GO_TO_STATION" =
I added:
UPDATE = ("pauseAI: 60.0", "setStateTo: LOOK_FOR_STUFF"); // Added! Check for loot again every 60 secs.
...But ship after ship pass within 15 km (even closer than 2 km!) without scooping them up.
Considering enteringTraderAI.plist is set like this:
"DECIDE_ROUTE" =
{
ENTER = ("rollD: 7");
"ROLL_1" = ("switchAITo: scavengerAI.plist");
...
"ROLL_7" = ("switchAITo: scavengerAI.plist");
...I'm reasonably confident that they are in scavenger mode.
Even enteringPirateAI.plist should set "clean" and "minor offender" pirates to scavengerAI.plist ...so I am at a total loss as what's going wrong.
Posted: Sun Oct 10, 2010 9:42 am
by Eric Walch
Switeck wrote:...I'm reasonably confident that they are in scavenger mode.
Even enteringPirateAI.plist should set "clean" and "minor offender" pirates to scavengerAI.plist ...so I am at a total loss as what's going wrong.
You could look in my ups_courier.oxp. It contains a "route1scavengerAI.plist" that just does what you want. Those ships just fly from witchpoint to main station and scoop all cargo they meet on their voyage.
Its a plain trader AI, but instead of constant looking for hostile ships it is constant looking for floating cargo. When you have ups installed you will sometimes find those ships in the spacelanes.
Posted: Sun Oct 10, 2010 10:53 am
by Commander McLane
Eric's suggestion is surely a sensible one.
I could only add that the scavengerAI contained in Oolite isn't made for cruising the spacelane from witchpoint to station in the first place. By (Oolite-) definition scavengers are ships that launch from a station, clear any debris around that station, return to that station, and dock with it again. The built-in Oolite scavengerAI provides exactly this (and only this) behaviour.
So if you want ships on the witchpoint-planet route to go and scoop loose containers, it's not a good idea to let them have scavengerAI at all. Instead you would have to start with one of the cruise AIs (route1traderAI or route1patrolAI) and modify it by including a search for debris. Which is what Eric did in his AI.
Posted: Sun Oct 10, 2010 11:12 am
by Switeck
Oddly, I have UPS-courier v1.7.2.oxp installed. I'll look into it.