Auto RETURN

[-Archmage-]

It's annoying when a unit runs off and goes on a one-man-crusade, especially when his sight radius is higher(like an archer). Multiple times I've had units run around and give away strategic bases I was building. It would be nice to have this toggleable, and defaulting too on.

All you would have to do is tell the unit to return the position it was idle at last. Because it attacks and then stops, but if is attacked then returns to the last idle spot, it'll go back to your base instead of sitting out being vulnerable.

[-Archmage-]

Only asking for Auto-RETURN.

[D.U.P.A.]

It's one of those cases, when developers don't bother to fix the bug or implement an essential functionality, calling it "feature" instead. Already happened to me with Telerik, where you couldn't filter only by date (had to include time too), they said that it's not a bug and it's how it meant to be.

Knowing this won't be implemented, I tried to mess with source code myself and after spending the whole day figuring how to compile (f**king stackdumper) I finally make this feature working. To prove I'm not telling porkies lying I there is included video below. Sorry for bad quality, but it was my first screen capture video ever. It still needs testing as bugs may appear. Maybe annoying part is that unit needs to walk to the point of seen enemy even when it's defeated.

I know you left, but this feature may be useful for other players, but especially me. Even though developers probably won't like I mess with their code.

_{Edit by Omega: I need to fix the bloody Youtube code soon. In the meantime, here's a link since embedding isn't working properly:}

[Omega]

Even though developers probably won't like I mess with their code.

That's not necessarily true. Even if the developers might disagree with a patch, I'm sure the community at least welcomes the ability to apply this patch themselves (one of the best things about open source programs).

Anyway, could you please upload a diff of your changes? The developers could consider implementing your changes, and if not, individuals have the option to apply the patch themselves.

[D.U.P.A.]

I'm not skilled with svn, at work we use tfs with visual studio, what would be an equivalent of "view pending changes" if you know to do it?

[tomreyn]

Code: [Select]

svn diff > filename.patchGenerally, in case your goal should be to get code merged, it's best not to blame developers for the decisions they may have made, but to try a positive approach.

[D.U.P.A.]

Would that filename.patch file be enough?

However I would probably need to optimize, I don't do well in c++, maybe there are things that shouldn't be done, although when playing I didn't encounter issues except for rare crashings (mostly in debug mode though). Now I did also that unit returns if it ventures too far from guarding point, however the distance constant should be stored somewhere and not directly in the code (I would need to talk with developers).

Tomreyn, are you a developer too?

[Omega]

Would that filename.patch file be enough?

Yes.

However I would probably need to optimize, I don't do well in c++, maybe there are things that shouldn't be done, although when playing I didn't encounter issues except for rare crashings (mostly in debug mode though).

That's a good idea. Stability is pretty important. It should be determined if the crashes were due to your changes or because of something else (in which case, we need to find out what that is).

Now I did also that unit returns if it ventures too far from guarding point, however the distance constant should be stored somewhere and not directly in the code (I would need to talk with developers).

It's a bit slow for the summer, but the easiest way to get in touch with the devs real time is IRC channel (particularly #megaglest).

[D.U.P.A.]

Here is the patch file. Needs some reviewing though

http://pastebin.com/1hBNw6it

+

[tomreyn]

Please rework / minimize the patch, you have both lots of removals followed by lots of inserts which look very much the same (possibly due to tab/space conversion or line endings?), as well as changes for files which I don't think you wanted to submit (*.vcproj) there.

I'm not a MegaGlest programmer, I just help with hosting, communication, strategy, and a bit of PHP and shell code.

[Omega]

Alternatively, if SVN diff is giving you issues and you know which files you modified, you can manually download the original files and compare your modified files with the originals.

On Linux (or Windows if you install MinGW), you could simply run diff file1.cpp file2.cpp > patch.diff, which will compare the files file1.cpp and file2.cpp and redirect the output to a file named patch.diff. If there are still excess lines in the diff (ie, lines stating changes where none occurred), you could try experimenting with flags like -E (ignores tab expansion), -b (ignores space changes), or --strip-trailing-cr, which strip carriage returns (on the Windows line feed).

If you're doing your development on Windows, which you appear to be from your video, you could use WinMerge, which I've found quite useful in the past. Not only should it be easy to see your changes in the GUI environment, but you can easily generate a diff (patch) from the tools menu.

[D.U.P.A.]

Yes, I use visual c++ 2010 express. Not all files should included, I had to change main.cpp to disable stackdumper (I have no idea what is it) to make it compile even before doing changes. Files with actual changes are unit_updater.cpp, unit.h, unit.cpp, commander.cpp

EDIT: here are the patch files for changes

http://s000.tinyupload.com/index.php?file_id=96862498839128761174

[titi]

I did not try it yet, but this in general a good idea ( just different from what we have now ). I think this will also effect the AI behaviour in fights.

Thats the reason i don't want to aplly this patch now as we are already in a beta state for a release and I don't want to have a bigger change like this at the current point. I hope thats ok for you :-/ , but this has to wait a bit at the current point.
( @softcoder: please don't apply this now )

[D.U.P.A.]

But it will be avalaible after the current beta release (those versions which you need to get via svn instead of the installer)? Meanwhile I will maybe try to add some other features that could come handy and if I will be able to do them.

[MirceaKitsune]

I hear you... this is one of the things I dislike most as well. Sometimes I leave my units guarding an entrance when suddenly a few enemies come by. My units chase them but never come back after killing them. Slowly they find themselves near enemy towns where they get themselves killed. Would love to see this fixed.

[D.U.P.A.]

So this modification alters AI behaviour?

[Coldfusionstorm]

Unit's should not follow enemy units unless specifically told to.

the current unit follow behavior is very annoying.

[Ishmaru]

So this modification alters AI behaviour?

Yes because if units Auto-return the Ai will not continue to advance toward enemy base, or even enemy long range units.
It would be best to somehow have auto return apply to human players, while Ai continues the old behavior.

[Coldfusionstorm]

Ishmaru, Then it doesn’t alter AI logic, Merely performance.

You mean to say this is how the current AI knows when to attack?, then you could just hide forever untill you have some suck superweapon(im aware there is no such thing.)

Obviusly this does not alter AI behavior.

Honestly, Units should not follow other units unless specifically told to.

[Omega]

Unit's should not follow enemy units unless specifically told to.

I disagree with you here. If I want to create a guard for my heavily turtled base, I simply have to move units to the entrance of my base. When the enemy attacks, my units will attack enemy units. This is possible only because the units follow the enemy. With hold position active, the unit will still attack, but will not follow. This is the opposite of your opinion: instead of explicitly telling units to follow, we explicitly tell units not to follow. If melee units do not follow, they can be easily decimated by ranged enemy units, so I maintain that following should be the default.

However, in my opinion, there should be a maximum follow distance, specified by mods. This would be the distance from the unit's original position which it will follow a foe with the intent to attack before it gives up. This would prevent a unit from being lured to an enemy base (provided the maximum follow distance is short enough). The distance must also be sufficiently large, though, or the unit will not be able to attack foes on, say, the other side of the player's base.

However, none of this applies to auto-return! Auto return is (presumably) used for the sole purpose of moving back to your original position after attacking a unit. It does not apply to instances where an enemy flees to its base. For example, suppose an enemy scout wanders into my base. My units, standing on guard, will run out to attack that scout. And when the scout dies, they stay there. The purpose of auto-return is to move back to their original positions (standing guard) instead of staying scattered at whatever position they were in when the scout was killed.

[D.U.P.A.]

Still no feedback :C

[kagu]

Hey , I like this very much (at least for single player games) , how could I get to test it ?

[D.U.P.A.]

The thing is that is for old version (I wasn't able to compile the new version on visual express 2012)

[titi]

Ups ... I need to look at this again.
I looked at the diff a bit but this has far too many changes you made on your local copy. Needed are just the relevant parts.

I will try to find what I need if its not too difficult. If this does not work it should be reimplemented. ( Thats maybe something for omega ? )

[D.U.P.A.]

However note it was done for 3.8 version, so they may be some outdated code