Page 64 of 69

Posted: Tue, 12. Jul 16, 19:16
by w.evans
12.July 2016 - MICT_supp2 updated to v0.52

Fix: Ships captained or piloted by non-Split captains in a MICT Squadron subordinate to a combat ship will now actually attack.

My apologies for this oversight. Thanks to milk@lowshake aka Sahnetrommel for the report that cracked the issue and for pointing out that it still didn't work.

Posted: Tue, 12. Jul 16, 20:49
by alexalsp
Hello w.evans.

supp2

Code: Select all

w.e_mict

aiscripts

fight.attack.object.fighter.bigtarget.xml
fight.attack.object.fighter.xml
MICT.move.escort.capital.xml
move.escort.capital.xml
move.escort.xml
move.generic.xml
move.refuel.xml
player.default.xml

<DIR>        w.e_mict\extensions\carriers\aiscripts\

move.generic.carrier.xml
What is this for ?

It is necessary or not?

Code: Select all

<DIR>        w.e_mict\extensions\carriers\aiscripts\

move.generic.carrier.xml


Posted: Tue, 12. Jul 16, 21:05
by w.evans
Hi alexalsp,

it's for compatibility with MM's Carriers mod, to send the signal for coordinated travel between zones for squadrons.

Posted: Tue, 12. Jul 16, 22:43
by alexalsp
I understood )). I thought you forgot file. ))

Posted: Tue, 19. Jul 16, 21:55
by w.evans
19.July 2016 - Miscellaneous IZ Combat Tweaks updated to v0.69

Slight performance optimization of the Defence Officer script.

.......
Please let me know if this should be optimized further, particularly for people who are using MICT or the MCT with CWIR. Further optimization will, however, start eating into functionality.

Posted: Wed, 20. Jul 16, 06:30
by Nikola515
Thanks for suggesting this mod and it woks like charm ;) Also I'm using mod that have engineers in station so they are fixing all S/M ships assigned to station (so it seems) :D Also I'm using BlackRains Player Shipyard mod and it seems some of ships are not working with this mod. For example Succellus Vanguard Destroyer is now acting like regular destroyer and it wont use main cannon anymore :( Is there anything you can do about that ???

And by the way I'm loving this mod and watching cap ships do what they should have been doing on first place :D

Posted: Wed, 20. Jul 16, 07:30
by w.evans
Hi Nikola,

I actually just suggested the repair ship part, but you're welcome to the rest of the mod as well of course. I'm glad that you like the rest of it as well!

About BR's ships, we cooked up a way to communicate between mods (was actually Marvin Martian's idea, I think, but the method that works between MICT and Marvin's Carrier mod works with everything else as well) and that is included in CWIR. Possible that BR didn't include it in Player Shipyards since that was already done at the time, if I remember correctly.

Problem was that MICT didn't know that that (those?) ships have front-mounted weapons and that they should act like long-ranged ships (point forward, stay at close to maximum weapons range). The file basically registers them with MICT as LR ships.

You could ask him about it. The file is extensions\cwir\md\wwx_carriercompat.xml in CWIR. Should be possible to just drop that file into the corresponding folder in Player Shipyards.

About station-based engineers repairing fighters, they don't. That's explicitly set to work only for repair ships (L and XL non-combat ships with MICT crews and construction drones). However, the Construction Vessel is an XL ship, so that's probably your CV's engineer at work!

Posted: Wed, 20. Jul 16, 16:37
by Nikola515
Thanks for info :D Ill ask BR if he can do anything about it.

Posted: Thu, 21. Jul 16, 19:52
by Scoob
Hey w.e.

I just updated to the latest MICT (+ Sup2, 3 & 6) along with updated CWIR.

Thing have been going well, but I just noticed an anomaly...

My Arawn was engaging two Xenon K's at close-range, and was about to end the first, when it suddenly started boosting out of the Zone. I checked and Shields were still comfortably over 50% and targets were both in range.

Despite the Captains orders still showing it attacking the first Xenon K, he's now proceeding to boost out of the Zone, and is now way out of weapons range.

Note: I suspect this isn't a MICT or CWIR issue directly, rather it's caused by the screwy Zone borders throughout HoL. I.e. I'm right next to a station in one Zone, but still listed as being in another Zone. In this case the Xenon K I'm attacking did not show as in my Zone, even though they obviously are....I'm right next to a station in the heart of the Zone, not near the border at all.

Anyway, as I said, likely not a MICT issue, but I think this (I think) vanilla problem is giving MICT a headache!

Scoob.

Posted: Fri, 22. Jul 16, 20:32
by w.evans
Hey Scoob,

can you still remember what the captain said he/she was doing before they started boosting away? If they didn't say anything and started changing behavior, that would be useful information as well.

Also, a save would be good, although i won't be able to look at it until next week. During the problem is good, right before the problem with instructions to repro would be better. (Repeated that for anyone else who looks in here. You knew the drill long before I ever did.)

Posted: Fri, 22. Jul 16, 20:54
by Scoob
Hey w.e,

The Captain said he was "Attacking Xenon K". Save has been overwritten now, sorry!

To be honest, I think this is 100% down to HoLs screwed up and overlapping Zones. I.e. I'm listed in one Zone, yet am directly adjacent to, and attacking, a ship that's listed in a neighbouring Zone. However, neither of us are near what you'd consider the border area, but comfortably inside one Zone.

As one of the Xenon K's moved out of weapons range, my Arawn correctly tried to boost to get closer, but thought it was in a different Zone, rather than just a handful of KM away.

Another example is where I'm in "my" Zone (previously unknown) and launching from my Warehouse and strafing directly UP, sees me entering another Zone! Local Zone map doesn't show my Warehouse a couple of KM away, but shows the other Zone.

Basically, I don't know what you could do about this if the game tells you your target is in another Zone, and you try to move towards it in said other Zone, yet it actually isn't/ in that Zone at all, but right next to you in your current Zone....*sigh* I said Zone too many times.

Scoob.

Posted: Fri, 22. Jul 16, 22:24
by w.evans
Scoob wrote:Basically, I don't know what you could do about this if the game tells you your target is in another Zone, and you try to move towards it in said other Zone, yet it actually isn't in that Zone at all, but right next to you in your current Zone....*sigh* I said Zone too many times.
If that is the problem, fix could be to move relative to the target's zone. Makes more sense anyway since where the ship currently is isn't really relevant to figuring out where they want to go, unless they also have to figure out how to get there.

Problem would be something someone (I think you? Not sure) pointed out though: they will follow a target they're attacking regardless of where that target is (or goes). Guess a middle ground could be to have them store where they were before the fight began and have them go back there after it's done. Would then make it possible to distract ships patrolling one zone and have them go haring off after something to different zones though.

Opinions?

...
How's performance with CWIR since the last MICT optimization, by the way? Any better?

Posted: Fri, 22. Jul 16, 23:24
by Scoob
I have little understanding of how movement etc. works in Rebirth. I mean, if a move order has to contain Zone information for example, then the broken Zone borders are going to confuse things. If however, programmically, you can just see coordinates, then it'd be easier. Too sleepy to really ponder this now lol.

Not been able to put enough time in to assess any performance improvements yet, but will let you know.

Scoob.

Posted: Sun, 24. Jul 16, 15:11
by w.evans
Ok, just back.
Scoob wrote:I mean, if a move order has to contain Zone information for example, then the broken Zone borders are going to confuse things.
Shouldn't matter. Position coordinates have to be plotted relative to something. Vanilla, with MICT, and with most (all? can't remember anymore) of the movement scripts I've looked at, zones are used. Can't speak for others, but I tend to stick with zone coordinates because those work with everything.

However, it doesn't really matter which zone the coordinates are relative to. We could use coordinates relative to this zone, a target's zone, a zone at the other end of the Sector, and they would be equally valid. (I suspect coordinates are plotted relative to zone centers, so zone edges shouldn't really make a difference. Yet to be confirmed though.)

That said, there would be a difference in accuracy since error would creep up the larger the numbers are.

Behavior you noticed could happen if coordinates were plotted relative to something, then used relative to something else. (Example, if coordinates were plotted relative to the target's zone then applied relative to this zone.) Took a quick look, and this does not appear to be the case, unless I missed a spot. MICT used to use coordinates relative to the target's zone exclusively, then switched to using this zone a while (months, at least) back.

One thing that just occurred to me: you said the ship boosted off? The boost movement happens in two move actions: one to turn towards the destination, another to actually go to the destination. If the ship is right at the zone border and turns, it could end up in a different zone. In that case, the actual move would be using the wrong coordinates since "this.zone" would now be different.

In that case, hm. Two possible solutions:

- have the movement coordinates plotted after the turn (can't think of how it could fail, but not very efficient),
- use the target's coordinates in all cases (makes more sense, I think, but could lead to the same situation if the target then switches zones between the turn and the move).

Opinions anyone?

@Scoob, will do one of the two fixes if you confirm that the observed behavior ONLY involved boosting to position. If it involved jumping or simply moving, then the cause is something else.

Posted: Sun, 24. Jul 16, 19:37
by Scoob
w.evans wrote:@Scoob, will do one of the two fixes if you confirm that the observed behavior ONLY involved boosting to position. If it involved jumping or simply moving, then the cause is something else.
What I observed involved the Captain boosting to an (incorrect) position, while claiming to be engaging the very Xenon K he was actually rapidly flying away from.

No jumping or normal flight involved, no "retreat" behaviour triggered, purely ship actively engaging the enemy - well within weapons range - then electing to boost away.

Generally combat works very well, so this particular scenario is, I'm sure, linked to screwy/overlapping Zone borders. My ship showing as being in a different Zone to the target ship - yet both being in close proximity - appears to confirm this.

Note: the Zones station/ship list was different for my ship and the Xenon K. However, the enemy ships could be seen on the map. Clicking said ship on the local map would snap my Zone view to the remote Zone.

Cheers,

Scoob.

Posted: Sun, 24. Jul 16, 22:32
by w.evans
24.July 2016 - Miscellaneous IZ Combat Tweaks updated to v0.70

Tentative fix for situation where movement coordinates could become invalid when combat crosses zone boundaries in between two or more consecutive move actions.

Thanks to Scoob for the detailed description of the issue.

...
Please note that this fix is tentative because I have been unable to reproduce this issue, so cause might be different from my best guess. If anyone encounters the problem described in this post:

http://forum.egosoft.com/viewtopic.php? ... 00#4621800

with MICT v0.70+, please let me know.

Posted: Mon, 25. Jul 16, 09:53
by Khugan
Just wanted to say that I am grateful to you for continuing to support this mod. I am just getting started playing XR and I am finding so many mods have been abandoned. I don't blame the authors though. XR shouldn't have taken so long to become a good game. Anyway, thank you w.evans.

Posted: Mon, 25. Jul 16, 18:34
by w.evans
Still play the game from time to time, so it's not a big deal.

Posted: Tue, 26. Jul 16, 01:26
by Scoob
Thanks for the update w.e, I'll test and monitor my ships behaviour.

Quick observation, not related to the above tweak I think.

I just took a "Xenon targeting this Station" mission. A Xenon K appears in the Zone - I assume boosting in - and my Light Sul (with me on board) jumps to engage. However, the K did a short boost its self, I assume to get closer to its intended target, which left my Light Sul off a little bit.

My Light Sul then announces it's boosting to the Xenon K, but it doesn't attempt to turn first. As a result, my Light Sul is performing a long, lazy Arc while boosting....though it's not reaching the usual full boost speed. It's actually getting slightly further away from the target, as it's not able to turn quite sharp enough.

I have seen this sort of behaviour before, but only in much earlier MICT versions. So, the Jumping behaviour was perfect, though the target moved after the jump count-down had started it appears. The boosting to the Xenon K (what the Captain said he was doing) is also as expected, but not him failing to turn first. My Light Sul ideally needed to do a full 180 degree turn prior to boosting.

All this happening with both my Light Sul and the Xenon K in the same Zone to be clear.

Thought: I think a degree of station avoidance is occurring, hence the odd flight path.

Edit: My Slight Sul did eventually get nearer to the Xenon K, but not within weapons range. Oddly it's path was not along a flat plane, rather my Light Sul while originally diving then proceeded to pull up again while executing this long turn. However, after pulling up it stopped turning, and flew straight....the Xenon K was then killed by NPC's. If my Light Sul had continued to turn, it would have been able to engage the target, so why it straightened up I don't know...it was well out of range of any stations by that point.

So, a bit of an anomaly there, but I'll check combat behaviour once again when I am able.

Scoob.

Posted: Tue, 26. Jul 16, 06:51
by w.evans
You mentioned diving. Would the Sul have had to pitch rather steeply on the y-axis to orient properly? That could be causing the problem.

Capital ships (used to be all, since a recent change, most) have a limit to how much they can pitch up or down. However, they don't know that when they start moving, so they try anyway, and just can't. Behavior is as you described: they start turning, then stop, and sort of wobble, turn back, or in really bad cases, start spinning like tops. It's the same problem the Sucellus used to sometimes have orienting to the target.

Could also account for not turning before boost. They had already turned as much as they can, then start moving while trying to continue to turn as much as they can, but can't.

They should recover, but yeah, it might take some time. (Seconds to start to recover, but that might still be too long, as you noticed.)