units not retreating to nearest repair station

[wzdev-ci]

keyword_repair resolution_fixed type_bug | by psychopompos

---

many units, when ordered to a repair station, are not going to the nearest(alternatly, not going to the one specified by clicking) and are going to (seemingly) the most recently built station.

---

Issue migrated from trac:763 at 2022-04-15 19:03:39 -0700

[wzdev-ci]

psychopompos uploaded file savegame.zip (225.8 KiB)

[wzdev-ci]

Per commented

---

I don't see any wounded/damaged units in that savegame...

[wzdev-ci]

psychopompos commented

---

there are a few not at full health (they are kind of... occupying the same space), however, that is not the point. if you select all the units under the transport, then send them for repair/click on the repair station right beside them, many of the units will proceed the whole way across the map to the most recently built repair station.

[wzdev-ci]

Per changed status from new to closed

[wzdev-ci]

Per set resolution to wontfix

[wzdev-ci]

Per commented

---

The units are not damaged, so when you click on the repair centre, it immediately sends them on to its delivery point, which you have planted near the newest repair centre very far away.

There is no bug here.

[wzdev-ci]

Refardeon commented

---

There is bug. HowToReplicate (with my savegame): Use group 4 and send it to the repairbay south of it. As you will see some of the units will move to the repairbay in the east.

[wzdev-ci]

Refardeon uploaded file repairs.zip (97.0 KiB)

[wzdev-ci]

Per commented

---

That is not a bug, either. The two repair centres are close and decide to split the work between them. It looks weird only because the droids are not damaged, and so do not queue up.

[wzdev-ci]

psychopompos uploaded file savegame.2.zip (190.8 KiB)

[wzdev-ci]

psychopompos commented

---

A) that is not what is happening per, how exactly did you check to replicate? B) the recent behavior of this BUG, is recent, previously, you click your unit, click a rep centre, the unit went to THAT rep center. now, it matters not what method you use, the units go to the last centre you built. C) in the OP the delivery point of the rep centre in the base, is directly north of the base, not on the east side of the map.

D) here is a new save, comander one is sitting right beside a rep centre, its delivery point is in default position, click the commander, click the repair station, the commander and its units will ignore it and go to the last built station. D2) find the aa units beside the HQ, select them, click the rep centre in the middle of the base(feel free to check its delivery point first, which is just north of the base), they will ignore the one you told them to go to, and proceed right to the LAST BUILT REP CENTRE.

[wzdev-ci]

Per changed resolution from wontfix to ``

[wzdev-ci]

Per changed component from Campaign to Engine: other

[wzdev-ci]

Per changed priority from minor to critical

[wzdev-ci]

Per changed milestone from unspecified to 2.2.3

[wzdev-ci]

Per changed keywords from ` torepair`

[wzdev-ci]

Per changed status from closed to reopened

[wzdev-ci]

Per changed operating_system which not transferred by tractive

[wzdev-ci]

Per commented

---

Ah. I missed something. My bad. Although it did go to the repair facility's designated delivery point, it was the wrong repair facility that was called for the droid. Basically, another repair facility noticed that the droid was fully healed, and sent it to its own delivery point. That should not happen.

Zarel - this is your code. The attached patch seems to work, but I would like you to consider further corner cases.

[wzdev-ci]

Per changed status from reopened to assigned

[wzdev-ci]

Per set owner to Zarel

[wzdev-ci]

Per uploaded file fixdeliverypoint.diff (0.8 KiB)

Make sure repair facility is not run on a droid that has another repair facility specifically set for it

[wzdev-ci]

psychopompos commented

---

no worries, i should have been more descriptive in describing how to replicate. will remember for future

[wzdev-ci]

Zarel commented

---

Hmm, this is rather messy logic to be dealing with. I'll think about it.

[wzdev-ci]

Zarel changed status from assigned to accepted

[wzdev-ci]

Zarel changed status from accepted to closed

[wzdev-ci]

Zarel changed resolution from ` tofixed`

[wzdev-ci]

Zarel commented

---

(In [8159]) 2.2: Partially fix bug #763: Units not going to specified repair facility.

[wzdev-ci]

Zarel changed status from closed to reopened

[wzdev-ci]

Zarel changed resolution from fixed to ``

[wzdev-ci]

Zarel changed status from reopened to accepted

[wzdev-ci]

Zarel commented

---

Other half still isn't fixed yet.

[wzdev-ci]

gitsvngateway changed status from accepted to closed

[wzdev-ci]

gitsvngateway changed resolution from ` tofixed`

[wzdev-ci]

gitsvngateway commented

---

(In [8220]) Merge branch 'master' into lua2. There were some troubles with the line endings of AIV, which were changed to CRLF. I kept them LF.

• master: (320 commits) A small cleanup in runLoadSave function (plus ForceEditor remnants were removed). Fix drawing of radar dishes that broke in [8189]. Correct mitigation for error resulting in #962, this fix should make game continue Remove unused code and correct PIE documentation. Number of texture animations and playback rates do not Clean up renderStructure() a bit to remove unused or duplicate code. Use OpenGL matrix commands to Added support for ATI-specific version of two-sided stencil extension (GL_ATI_separate_stencil) in pie_DrawShadows. Will decrease CPU usage when using ATI cards. updated makefiles for the new original mod. Change Foldername from Old School to original. Add readme.txt and update the images/frontend0.png Fix bug that would allow artillery to use sensors without regard to actual visibility of target. Stop stripping debug information from release binaries in Mac OS X. Fix #883 assert on savegame load during campaign. The problem is that you load droids Fix scrGroupAddAreaNoGroup script function, was called as scrGroupAddArea instead. Explicitly link against libintl. Display SQLite version during startup. Addresses #936. Add the new Old School Mod to the SVN (trunk and branch). Pies for Multiple muzzle flashes feature #824 (part 2). Additional code changes for Multiple muzzle flashes feature #824. Fix bug #939: Cannot compile in Linux. Partially fix bug #763: Units not going to specified repair facility. ...

Conflicts: data/mods/multiplay/aivolution/multiplay/skirmish/player0.slo data/mods/multiplay/aivolution/multiplay/skirmish/player1.slo data/mods/multiplay/aivolution/multiplay/skirmish/player2.slo data/mods/multiplay/aivolution/multiplay/skirmish/player3.slo data/mods/multiplay/aivolution/multiplay/skirmish/player4.slo data/mods/multiplay/aivolution/multiplay/skirmish/player5.slo data/mods/multiplay/aivolution/multiplay/skirmish/player6.slo data/mods/multiplay/aivolution/multiplay/skirmish/player7.slo src/Makefile.am src/objmem.c src/scriptai.h src/scriptfuncs.c src/scripttabs.c win32/Warzone2100.sln

From: Gerard Krol gerard_@gna.org

[wzdev-ci]

Per changed status from closed to reopened

[wzdev-ci]

Per changed resolution from fixed to ``

[wzdev-ci]

Buginator changed milestone from 2.2.5 to 2.3

[wzdev-ci]

Buginator commented

---

Milestone 2.2.5 deleted

[wzdev-ci]

Zarel changed milestone from ` to2.3.1`

[wzdev-ci]

Zarel commented

---

I'll get to this some day...

[wzdev-ci]

cybersphinx changed milestone from 2.3.1 to unspecified

[wzdev-ci]

Per changed status from reopened to closed

[wzdev-ci]

Per changed resolution from ` tofixed`

[wzdev-ci]

Per commented

---

Not sure what remains to be done for this. Closing until further notice.