Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

abma
Spring Developer
Posts: 3535
Joined: 01 Jun 2009, 00:08

Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by abma » 06 Aug 2014, 01:33

release candidate #3 for 98.0!

as we found a serious bug, this RC was delayed, give it a try!

Changes

changes since RC2:
  • modrules: add system.pathFinderUpdateRate tag
  • fix buildslaves: all builds contain the java ai interface + ais (again)
  • allow to set default IP/Port by config (HostIPDefault, HostPortDefault)
  • allow all tcp-connections with luasocket as default
  • a LOT of other small changes! (also git commit log!)
To make the next release post more interesting i need your help. i want to add screenshots & maybe a video to the release post, current screenshots/text snippets are:
http://springrts.com/wiki/ReleaseNotes:97.0


Changes in Detail:
changelog.txt (is currently the same as for rc2)
git diff last rc to HEAD

no breaking changes known atm since 96.0


Download
See the download page for how to get it.


Bugs

If you find a bugs, please report to Mantis.

Please attach infolog.txt as file, if you crash!

current release (known) blocking bugs no major bug.
0 x

User avatar
Jools
XTA Developer
Posts: 2802
Joined: 23 Feb 2009, 16:29

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Jools » 07 Aug 2014, 10:02

It works fine (tested -208), except that it still opens the game in the wrong monitor. If this is not controlled by spring, does anyone have an idea where this can be controlled? I have win7.

I can go to windowed mode, drag the app to the right monitor, and then go fullscreen again, but this has to be repeated each time the game loads. There must be a way to force the environment to remember where to open the app, right?
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by jK » 07 Aug 2014, 11:53

Jools wrote:It works fine (tested -208), except that it still opens the game in the wrong monitor. If this is not controlled by spring, does anyone have an idea where this can be controlled? I have win7.

I can go to windowed mode, drag the app to the right monitor, and then go fullscreen again, but this has to be repeated each time the game loads. There must be a way to force the environment to remember where to open the app, right?
try to set the `primary` monitor (right click on desktop -> settings -> ...)
0 x

User avatar
Jools
XTA Developer
Posts: 2802
Joined: 23 Feb 2009, 16:29

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Jools » 07 Aug 2014, 12:00

I already have my primary monitor set. Spring always opens in my secondary one, ie. the one without the taskbar.
0 x

User avatar
Silentwings
Moderator
Posts: 3565
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 08 Aug 2014, 00:47

I love the new stuff coming in 98.0!

I still don't understand why double press shift/alt is being used for switching chat mode. I've not heard anyone express support for it and have heard several people object.

I know of two small "breaking changes" for game devs. Synced/unsynced gadget now recieving the same callins/actions is potentially able to break stuff. Having Spring.GetGameSpeed() no longer accessible from synced code could also potentially break stuff.

The changelog is missing Spring.AssignPlayerToTeam.

I've made a PFS-update related mantis, will likely make more in next few days as I test...
0 x

Google_Frog
Moderator
Posts: 2432
Joined: 12 Oct 2007, 09:24

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Google_Frog » 08 Aug 2014, 09:36

I still need a way to make the PFS-update cost reasonable. Simply reducing the rate of update would work fine for now.
0 x

User avatar
Silentwings
Moderator
Posts: 3565
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 08 Aug 2014, 12:40

For me the easiest solution looks like reverting https://github.com/spring/spring/commit ... 6a864aed25 until a way of doing it without (as far as I can tell) harming sim peformance is found.
0 x

Google_Frog
Moderator
Posts: 2432
Joined: 12 Oct 2007, 09:24

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Google_Frog » 08 Aug 2014, 15:01

That is a fairly important fix as hovercraft can behave fairly stupidly without it. I would prefer a slower update rate.
0 x

User avatar
Silentwings
Moderator
Posts: 3565
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 08 Aug 2014, 17:35

Judging by Kloots comments on my original mantis ticket #4461, these issues are nothing more than an unintended effect of the commit that addressed #4419. I'm not against sorting #4419 but to me its a minor thing; preventing hovercraft occasionally getting lost on steep ground is absolutely not worth either (a) a (probable bug that causes a) significant reduction in sim speed or (b) a significant reduction in pathing quality (which is my best guess for what happens with a lowered PFS-update rate).
0 x

User avatar
Anarchid
Posts: 1377
Joined: 30 Nov 2008, 04:31

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Anarchid » 09 Aug 2014, 01:26

preventing hovercraft occasionally getting lost on steep ground is absolutely not worth either (a) a (probable bug that causes a) significant reduction in sim speed or (b) a significant reduction in pathing quality
significant reduction in pathing quality
I'd say that hovers getting stuck in steep shores that they consider pathable (and which are not), while ignoring paths where they could actually pass is in fact a significant reduction in pathing quality.
0 x

User avatar
Silentwings
Moderator
Posts: 3565
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 09 Aug 2014, 03:03

Then you are missing a sense of scale. The scenario you quote affects pathing for a single movetype in a relatively unusual situation, in a way that is easily worked around by thinking for 0.1 sec and then manually adding a waypoint. On the other hand, PFS-update affects pathing of every mobile unit all of the time, simspeed affects basically everything all of the time and from the players perspective there is no workaround for poor results of either.

(Also your terminology is wrong - there is not a reduction since afaik, but I've not actually tested myself since it's never bothered me, hovers behave this way in 96.0.)

There is not alot to be gained from discussion here - point is that these ill-effects are very likely just some complicated bug from Kloots commit and probably the only sane thing to do is wait until Kloot gets around to looking at it again.
0 x

User avatar
Anarchid
Posts: 1377
Joined: 30 Nov 2008, 04:31

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Anarchid » 09 Aug 2014, 10:05

hovers behave this way in 96.0.)
They don't.
Then you are missing a sense of scale
I'm weighting a breach of contract ('pathfinder finds pathable paths') vs performance regression ('pathfinder should be fairly fast'). I weigh breaches of contract more heavily.

You are basically suggesting that hovercraft should not be a supported/maintained part of Spring pathfindinf, much like FPS.

I am not suggesting that the performance decrease is a good or tolerable thing, and a fix to the hover issue that wouldn't drop perf would be nice.
0 x

User avatar
Silentwings
Moderator
Posts: 3565
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 09 Aug 2014, 10:14

You are basically suggesting that hovercraft should not be a supported/maintained part of Spring pathfindinf, much like FPS.
Thats a hopelessly ridiculous thing to say. If you'd bothered to read my posts, my clearly and repeatedly stated prefered solution is:
these ill-effects are very likely just some complicated bug from Kloots commit and probably the only sane thing to do is wait until Kloot gets around to looking at it again.
These are obviously different and I have said absolutely nothing about what one might do in the situation that a large loss of simseed is an unavoidable consequence of fixing #4419.

edit:
hovers behave this way in 96.0.)

They don't.
Turns out you are wrong, they do - I just tested it, and could reproduce #4419 in 96.0. http://s15.postimg.org/9anh9d7y3/hovers.png.

Testing on latest (and maybe no one else has?), it seems that #4419 is actually not fixed; the path (and passability) that it produced was different http://s10.postimg.org/ov2j6obd5/hover2.png and by eye appears good, but the end result was the same; it vibrated a bit and then got stuck http://s14.postimg.org/54vpv1ynl/hover3.png.

Perhaps beside the point but imho that map has a badly designed heightmap, in the sense that there is too much jaggedness in the pathability around its lakes. This was just something I learned years ago to avoid - it's always been an issue to varying extents.
Last edited by Silentwings on 09 Aug 2014, 11:10, edited 1 time in total.
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14552
Joined: 17 Nov 2005, 02:43

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Forboding Angel » 09 Aug 2014, 11:10

The hovercraft bug is unacceptable. A very large part of Evo's gameplay centers around the use of hovercraft.

Just because you do not really use something, silentwings, does not mean that other people don't either.
0 x

User avatar
Silentwings
Moderator
Posts: 3565
Joined: 25 Oct 2008, 00:23

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Silentwings » 09 Aug 2014, 11:11

READ THE POSTS. The "bug" is NOT fixed, is NOT a regression and ABSOLUTELY NOWHERE have I indicated that I didn't want it fixed.

How hard can it be ... to point out that a failed attempt to fix it has done alot of damage.
0 x

abma
Spring Developer
Posts: 3535
Joined: 01 Jun 2009, 00:08

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by abma » 09 Aug 2014, 12:48

i couldn't find it yet, but how can the unsynced heightmap be disabled? maybe this slightly improves performance, not sure.
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by jK » 09 Aug 2014, 13:16

-_-'

please at least check first, before doing blind assumptions ...
0 x

abma
Spring Developer
Posts: 3535
Joined: 01 Jun 2009, 00:08

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by abma » 09 Aug 2014, 13:17

how can the unsynced heightmap be disabled?
...
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by jK » 09 Aug 2014, 13:19

you can see the performance cost of UHM without disabling it ...
0 x

User avatar
Anarchid
Posts: 1377
Joined: 30 Nov 2008, 04:31

Re: Engine Testing - 97.0.1-206-g8576ee8 (06. Aug 2014)

Post by Anarchid » 09 Aug 2014, 14:54

Turns out you are wrong, they do - I just tested it, and could reproduce #4419 in 96.0. http://s15.postimg.org/9anh9d7y3/hovers.png.

Testing on latest (and maybe no one else has?), it seems that #4419 is actually not fixed; the path (and passability) that it produced was different http://s10.postimg.org/ov2j6obd5/hover2.png and by eye appears good, but the end result was the same; it vibrated a bit and then got stuck http://s14.postimg.org/54vpv1ynl/hover3.png.
I stand corrected.
I wonder if you were able to reproduce it after the 'fix' commit because of BAR hovers being anyhow (minor settings, footprints, etc) different to ZK ones.
0 x

Locked

Return to “Engine”