Spring 0.77b6 testing

[TradeMark]

It's fine as it is, just make sure the +number is documented in the list of commands.

No its not fine. Nobody will remember, and we will hear all the time: "oh it was TO TIME !"
I really suggest you split the commands into:
/skipto (equivalent to /skip seconds)
and
/skip (equivalent to /skip +seconds)

Any specific tdf tags you mean?

Oh yeah...
viewtopic.php?f=11&t=16463&p=312365

[lurker]

The svn log suggests that spring never used standingfireorder.
If you want a tag spring hasn't used before to work that way, put it in your unitdefs_post.lua.

[TradeMark]

idk was it standingfireorder or not, but some tag it was which was changed.

I clearly remember how i fixed my buzzaws from shooting automatically to enemies by using some tag which now have been changed in new spring version.

[lurker]

noAutoFire was removed because it was pointless in the face of firestate.

[quantum]

I've noticed units going in circles around their target movement point. Rather amusing, that.

turnInPlace = 0 seems to cause that, sometimes.

[Auswaschbar]

For clarification:
/skip 500 will take you to the 500th ingame second
/skip f500 will take you to the 500th frame (== 500/30 secons)
/skip +500 will skip the next 500 seconds

[TradeMark]

For clarification:
/skip 500 will take you to the 500th ingame second
/skip f500 will take you to the 500th frame (== 500/30 secons)
/skip +500 will skip the next 500 seconds

More clear commands would be:
/skipto 500
/skiptoframe 500
/skip 500

So, it will use seconds by default (so everyone will remember it), but when you put "frame" in the end, you will know they are frames and not seconds...

Logical, isnt it? this is how you probably would say them in talking:
"skip to the 500th second" = /skipto 500
"skip to the 500th frame" = /skiptoframe 500
"skip 500 seconds" = /skip 500

nice and clear... no way to get confused.

[Argh]

Metal extractor radius is not being rendered correctly as of r7001. It always shows green, even if the zone is currently occupied.

[Argh]

Starting Spring with r7001 and KAIK crashes. Latest SVN revision did not compile on BuildBot.

[zerver]

zerver, which callins are in the rendering thread? Is there a list anywhere?

No list, but I believe they are all prefixed with "Draw". DrawWorldPreUnit for instance.

[Evil4Zerggin]

It appears there are these "Draw" callins:

DrawWorld
DrawWorldPreUnit
DrawWorldShadow
DrawWorldReflection
DrawWorldRefraction

Between the first two, the following things are drawn, in this order (not sure on what all the depth tests are):
Trees
Non-cloaked units
Pathing (if in debug)
Water
Cloaked units
Projectiles
Sun

[jK]

Zerver isn't able to share a lua enviroment between 2 threads, so it isn't a problem of any callins, it is a problem of rendering in lua in general.
But still it is a problem of lua enviroment sharing and totaly independent of lua itself ... (so it is zerver's problem and not the prob of any lua dev ...)


PS: to complete the Draw callin list:
DrawGenesis
DrawWorldReflection
DrawWorldRefraction
DrawWorldShadow
DrawWorldPreUnit
DrawWorld
DrawScreenEffects
DrawScreen

[lurker]

So does all unsynced lua run in the rendering thread?

[AF]

DrawGenesis

This seems like a whymsical name that renders a chapter of the bible or a star trek superweapon onto the screen

[zerver]

Zerver isn't able to share a lua enviroment between 2 threads, so it isn't a problem of any callins, it is a problem of rendering in lua in general.
But still it is a problem of lua enviroment sharing and totaly independent of lua itself ... (so it is zerver's problem and not the prob of any lua dev ...)

Usage of LUA is already properly synchronized between Sim and Draw (at least I'd like to think so).

A bigger problem is that the Sim thread can acquire some mutexes and then try to make a GL call. Certain GL calls require the Sim to wait for the rendering thread (which processes all calls sooner or later), but if the rendering thread then tries to acquire one of the mutexes that the Sim thread already has, we have a deadlock. This is extremely difficult to solve, and I honestly think it is a better solution to fix the mod in question.

I have made things easy for mod makers who want to support the current multithreading version - the console churns out error messages if GL calls are made from the Sim. It should not be hard to track them down.

Code: Select all

[   3646] GML error: Sim thread called gmlGenLists
[   3646] GML error: Sim thread called gmlGenLists
[   3653] GML error: Sim thread called gmlNewList
[   3653] GML error: Sim thread called gmlPushMatrix
[   3653] GML error: Sim thread called gmlTranslatef
[   3653] GML error: Sim thread called gmlBegin
[   3653] GML error: Sim thread called gmlMultiTexCoord2f
[   3653] GML error: Sim thread called gmlMultiTexCoord4f

The things that remain in the Sim thread are mostly creation of display lists and such. For instance in CA 3073, lups_napalm.lua:
GameFrame()
SpawnNapalmFX()
Lups.AddParticles('JitterParticles2',heatFX)
JitterParticles2.Create()
JitterParticles2:CreateParticle()
glCreateList()

[ginekolog]

I found small bug in 0.77B5:

Units wont return to repair on repair pad until their "Repair level" is changed - clicked. Once this is changed, they work normaly.

Is this perhaps allready fixed?*

[Masure]

Mantis it

[solis]

And what about this error: http://spring.clan-sy.com/phpbb/viewtopic.php?p=315960 ?

[ZellSF]

Disable all graphical effects and see if that works like I asked you to in that thread..

[solis]

Disable all graphical effects and see if that works like I asked you to in that thread..

I have try it. I posted my settings in the thread. I will not write here about it anymore to double the thread, but I would be pleased for any help