Engine Testing - 28 Jan 2013 (91.0.1-1204-g0f1f5f1)

[abma]

We still try to make soon a release, so an other testing version. This time we already made a release branch, so only fixes will be made until releases.

Major changes are:
- added experimental mapgen
- each buildslave build uses now its own dedicated subdirectory (currently linux32/linux64/win32/osx64), some things are broken because of this. afaik the stacktranslator / pr-downloader engine downloading and maybe other stuff, too, but will be fixed at some point
- some new sim/weapon features
- ~600 commits since last testing release (so many other hidden changes...)

For details of changes look at the "92.0" section in changelog.txt.

See the Testing Release Wiki page for general info about how to obtain the release, and an archive of all testing releases since the last stable one.

If you find a bugs, please report in this thread or on Mantis.

Remember to attach infolog.txt as file, if you crash!

[Silentwings]

Great work, will start testing!

[gajop]

this needs to be documented a lot better: http://springrts.com/wiki/Mapgen
it generates a random map? why would we ever want the engine to do that?
wouldn't it be much better if we had a way of creating a map of size x/z and a way of saving the current map to a file, callable from lua?
am i missing something here...?

[gajop]

also, since that commit seems to add a virtual archive, can you please make those bindings available to lua?

[abma]

this needs to be documented a lot better: http://springrts.com/wiki/Mapgen
it generates a random map? why would we ever want the engine to do that?
wouldn't it be much better if we had a way of creating a map of size x/z and a way of saving the current map to a file, callable from lua?
am i missing something here...?

afaik the plan with mapgen is also, to generate the map with lua that resists inside a game archive. but its not finished, just a start. making the bindings available to lua is planned, too. MadrMan can maybe say more to this. a generated map has the big benefit that it doesn't need to be uploaded and downloaded.

[gajop]

afaik the plan with mapgen is also, to generate the map with lua that resists inside a game archive. but its not finished, just a start. making the bindings available to lua is planned, too. MadrMan can maybe say more to this. a generated map has the big benefit that it doesn't need to be uploaded and downloaded.

Well it is about time engine can generate and save a map in its' own format, I agree on that. (You are adding save with this one, right?)
Howerver, no random generation should be a part of the engine as it's vague and really hard to generalize. Even on a high level (what the end-users would see), there are a lot of different map types, e.g.: pangea, contintents, small/large islands, archiepelago, europe/mediterrain/americas-like maps, etc.
There are far more low-level map settings that one can come up with, and I haven't seen anything that can be easily generalized in a way that all map-generators would later use, except for map size.
Stuff like this should be avoided: https://github.com/spring/spring/commit ... 2d55#L7R20
Just provide us a way to create a map of certain size and give us a way to save the current map, generating it won't be too hard after that. If you want, you could specify a generator in the engine which would invoke lua to generate the map (just do the random generation fully in lua).

Also, while heightmap modification via Lua is relatively easy, texture is not and the only texture map editor I've found (Pako's) show some of these issues quite well:
- it's really slow to export it, and it exports it in a bunch of small PNGs...
- modifications aren't really easy to achieve, and there are issues with the spring's fixed square sizes (although that may be a bug of the editor)
So could you work a bit more on improving lua bindings in regards to that instead?

[PepeAmpere]

• Is normal that updating paths takes around 1 minute for 20x20 gadget generated map?

btw it works good, thx for it

[Beherith]

Thats a goddamn impressive changelog, I cant even tell which one to get the most excited about. I promise we'll be good and test a lot :)

[jK]

• Is normal that updating paths takes around 1 minute for 20x20 gadget generated map?

btw it works good, thx for it

yes, that's the reason why (static) paths are cached.

[PepeAmpere]

• Is normal that updating paths takes around 1 minute for 20x20 gadget generated map?

btw it works good, thx for it

yes, that's the reason why (static) paths are cached.

Ok, if it cannot be faster, make there some counter pls, changing status line, some percents. Looking at static loading screen for 1 minute can be frustrating for some players and they can think the game crashed.

[xyz]

Hello,
I've gave the static linux build a spin yesterday (me vs 1 ai), and so far it feels solid.
1 issue that I found:
On a map with no water or water that is not dynamic or bump I get 250+ fps, but once I change the water to either dynamic or bump the fps drops to 45 for dynamic and around 80 for bump, and no matter where I look on the map it will never go above.
I only used the multi-thread build.

Specs:
Fedora 18 64b
AMD FX 8350
16 G Ram
NVidia GeForce 9800 GT

Thanks.

PS: There might be an issue with the AIs and path-finding getting their production buildings stuck by unit not leaving them.

[pheldens]

0133e63570462efd8cc59263296a20eab93e4c39


AAI 0.9 works with:
xta-9.71

AAI 0.9 is broken with
xta-9.72
xta-9.725 Broken
xta-9.725-patch_1.7 Broken:

Other AI's segfault

Code: Select all

[f=0000000]  -> Version: 91.0.1-1234-g0133e63 develop (OMP)
[f=0000000]  -> Connection established (given id 0)
[f=0000000] Player user finished loading and is now ingame
[f=0000000] GameID: 0eb10a515ce2aca996c03f461cdf4421
[f=0000000] SkirmishAI (ID = 0, team ID = 1) is using cheats!
[f=0000000] <SkirmishAI: E323AI 3.25.0 (team 1)>: Logging disabled
[f=0000000] Error: Segmentation fault (SIGSEGV) in spring 91.0.1-1234-g0133e63 develop (OMP)
[f=0000000] Error: Stacktrace:
[f=0000000] Error: This stack trace indicates a problem with a Skirmish AI library.
[f=0000000] Error:   <0> /lib/libpthread.so.0(+0xf820) [0x7fcabed46820]
[f=0000000] Error:   <1> /usr/src/spring/rts/ExternalAI/SSkirmishAICallbackImpl.cpp:4302
[f=0000000] Error:   <2> /usr/src/spring_91.0/AI/Wrappers/LegacyCpp/AIAICallback.cpp:1502
[f=0000000] Error:   <3> /usr/src/spring_91.0/AI/Wrappers/LegacyCpp/AIAICallback.cpp:772
[f=0000000] Error:   <4> /usr/src/spring_91.0/AI/Wrappers/LegacyCpp/AIAICallback.cpp:1334
[f=0000000] Error:   <5> /usr/src/spring_91.0/AI/Skirmish/E323AI/ARegistrar.h:18
[f=0000000] Error:   <6> /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/basic_string.h:270
[f=0000000] Error:   <7> /usr/src/spring_91.0/AI/Skirmish/E323AI/CE323AI.cpp:60
[f=0000000] Error:   <8> /usr/src/spring_91.0/AI/Wrappers/LegacyCpp/AIAI.cpp:163
[f=0000000] Error:   <9> /usr/src/spring_91.0/AI/Skirmish/E323AI/AIExport.cpp:119
[f=0000000] Error:   <10> /usr/src/spring/rts/ExternalAI/SkirmishAILibrary.cpp:95
[f=0000000] Error:   <11> /usr/src/spring/rts/ExternalAI/SkirmishAI.cpp:57
[f=0000000] Error:   <12> /usr/src/spring/rts/ExternalAI/SkirmishAIWrapper.cpp:191
[f=0000000] Error:   <13> /usr/src/spring/rts/ExternalAI/EngineOutHandler.cpp:592
[f=0000000] Error:   <14> /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/../../../../include/c++/4.6.1/bits/stl_iterator.h:742
[f=0000000] Error:   <15> /usr/src/spring/rts/Game/NetCommands.cpp:177
[f=0000000] Error:   <16> /usr/src/spring/rts/Game/Game.cpp:904
[f=0000000] Error:   <17> /usr/src/spring/rts/System/SpringApp.cpp:946
[f=0000000] Error:   <18> /usr/src/spring/rts/System/SpringApp.cpp:1028
[f=0000000] Error:   <19> /usr/src/spring/rts/System/Main.cpp:63
[f=0000000] Error:   <20> /usr/src/spring/rts/System/Main.cpp:150
[f=0000000] Error:   <21> /lib/libc.so.6(__libc_start_main+0xed) [0x7fcabb5c717d]
[f=0000000] Error:   <22> /usr/src/glibc-2.14.1/csu/../sysdeps/x86_64/elf/start.S:116
*** glibc detected *** "spring": free(): invalid pointer: 0x0000000001301960 ***
Segmentation fault

game hangs/crashes on ever quit (leaves me in the debugger) is this optional?

stable for the rest (single thread)

[Jools]

Spring 91.0.1-642-gdbf9540 develop (OMP)
Using game: XTA 9.725 [patch 1.7]

KAIK 0.13
---------

Error: Exception: Access violation (0xc0000005)
Error: Exception Address: 0x747943df

AAI 0.9:
--------
Stable

E323AI 3.25:
------------
Stable

RAI 0.601:
----------
Stable, but took very long to initialise.
Warning: [Watchdog] Hang detection triggered for Spring 91.0.1-642-gdbf9540 develop (OMP).

CppTestAI 0.1:
--------------
Stable (I think this is just a sandbox ai; does nothing)

[PepeAmpere]

CppTestAI 0.1:
--------------
Stable (I think this is just a sandbox ai; does nothing)

This ai in this engine version sometimes crash the game. When I was testing it on gadget generated map, there was fail after "gameStarted" event.

[Jools]

Tested this this version now, and KAIK doesn't crash in this one for me.

Spring 91.0.1-1232-gadd1be5 release (OMP)

By the way, there is a bug/misfeature regarding the way attacks work. You cannot now dgun buildings, you can only dgun ground. If you choose to dgun your own building, the order is converted to an attack order, which is not executed on own stuff it seems (not even unfinished stuff). See illustration:

Give D-Gun order:


Outcome: normal attack order, not exucuted




Furthermore, the a bad attack order is not cancelled by the GUI, even though it shows the new cursor. You can still get your LLT busy attacking your own stuff, even though the cursor says that won't happen.

See this illustration:

Try to give attack order with LLT:


Outcome:



I guess the idea is that mods would themselves deal with this situation. It's a lot more complicated than to just show different cursors. The behaviour should take into account that:

- multiple units can be selected
- units that can move should not be affected by the fact that object is outside range, they can simply move there
- labs can give attack orders, they become rally points for units produced in them
- kamikaze type units have no formal weapons, but they are still attack units in effect.

This is the logic I implemented for xta, feel free to improve it...

http://code.google.com/p/xta-springrts/ ... toofar.lua

[Beherith]

Jools that dgun thing is not new, since dgun targets now. If you try to target something allied, it will not fire.

[knorke]

not sure if the AAI crash is new, it crashes even in 91.0, for example on maps with no metal.
In the log where you say AAI crashed, it says E323AI? Or is that just random?

in xta 9.725 patch 1.7 i can dgun my own buildings, in 91.0

[Jools]

Ok, but do we want this behaviour? I usually use dgun to quickly remove unwanted elements when I need to build something new.

It's not present in spring 91.0

Edit: I mean, especially unfinished stuff should be dgunnable.

[Kloot]

Read. The. Changelog.

! all weapons will now obey avoidFriendly, avoidNeutral, avoidFeature + avoidGround

-->

1. dguns are weapons
2. avoidFriendly defaults to true
3. what's the fix for 91.0-style behavior...?

[Jools]

Fix is: make those parameters configurable by mod. We have to be able to dgun features.