Some Problems i forsee with Spring

[Kloot]

The path estimation is a special case since it parallelizes well by nature and lives outside of the simulation loop (so the lifetimes of the threads there are limited to its local scope). And IMHO, what it "shows" best is how easy destroying sync in a threaded context is.

It's possible to pull pathfinding and los map updates into threads 'relatively' easily.

Far from it.

otherthings you may want to think about is a ... lua -> opengl interface

You mean like the one that already exists?

[zwzsg]

dinocool sounds suspiciously like a vet modder smurf.

[Auswaschbar]

Removing stuff already in the engine does not make sense, and only force people do to double work. Making engines stuff optional / removable for speed increase is a good thing.

[lurker]

It's possible to pull pathfinding and los map updates into threads 'relatively' easily.

Far from it.

Well I did put relatively in quotes. The way I see it, you have multiple copies of the LOS map, one in use and one being updated in another thread, with some increase in the lag time on it updating when units move. You'd also have to have pathfinding and map distortion in that thread with copies of the data and short delays on the distortions actually interacting with units. And if you disable map damage, threading pathing becomes downright simple. Units request paths in one slowupdate, they receive paths during the next one. Am I missing something important?

[Kloot]

For pathfinding, the problem is that paths are not only requested during SlowUpdate()'s, and all of those requests (now) must finish within a single frame or the simulation can't proceed. OTOH, piling up requests at the SU booth instead and handing them off to a helper thread en masse along with a copy of the simulation state at that SU frame runs the risk of not getting answers back in time (without barriers) for all when there are many units around. Also, that approach incurs a potential waiting time of up to 31 frames: 15 in the worst case to wait for the next SlowUpdate flush, plus another 16 for the paths. Microing units would become impossible.

[lurker]

I see some slowupdates and some startmovings. It should be entirely possible to split the code here a bit so that only the directly-path-related code runs when the pathfinder returns, and have this happen something quick like 2-5 frames later.

AIs and lua could either have a fancy system installed, or they could get paths in the sim thread.

[Otherside]

we all know how a good engine should be ... we all know how a perfect Spring Engine should be, we all know what is missing

a good lobby client

[TwiNHeaD]

...every feature of spring should be optional and modular...

Totally agree. +1
This is a wash for any IT initiation. TA or not TA doesn't matters.

The time will come when devs have to write patches for patches that work on dependencies of other patches that didn't work with patches previously allocated in patches written before patches that they were intended to patch for dependancy. Not clear? So tell me what is "patch" now in context (bloated informational swamps from ms omitted, cause they have commercial clause) .

You need a firm agenda and strong database management, dear Sirs.
No future for The best Strategy in the World without it .

[Gota]

True..some hardcoded stuff don't even work well as OTA relics..since many of OTA's features cannot be replicated by simply choosing a certain behavior from the engine..like the fact units will always shoot at radar blips unless you put them on hold fire in which case they wont shoot at enemies even when they are adjacent to them...
The engine is also not flexible enough in terms of unit motion and pathfinding.
Some tags are dominant and include too many things about the way the unit acts,things that should ultimately be up to several tags to allow to create more diverse behaviors.

[Hoi]

every feature of spring should be optional and modular

+1 to this, however much more is possible then when I discovered spring (about a year ago) there is still alot of work to be done.

[KDR_11k]

I think it might be a good idea to make obvious OTAisms default to off though (especially things like nanospray/nanoframes, construction is in many RTSes but that specific effect is only in TA). It's pretty silly how many things you have to turn OFF to get a basic behaviour.