Spring RTS Engine

Yeah I figured. So many things are reliant on versions being separated that putting them together would cause a lot of annoyance and angst I'm thinking.

Google_Frog wrote:Would work on lua lobby possibly extend to engine changes?

It would involve engine (and pr-downloader) changes. In particular I expect the following major features implemented:
- Restart into specific engines
- Search rapid games and install tags which can be automatically updated (old rapid tag)
- Run Spring without map (and not just fake "BlankMap")

Forboding Angel wrote:If lua lobby core were a rapid package, keeping project's lua lobby updated would be trivially easy.

Well I don't see Chili or LUPS being used as dependency, so I'm not sure this would work better.

gajop wrote:

Forboding Angel wrote:If lua lobby core were a rapid package, keeping project's lua lobby updated would be trivially easy.

Well I don't see Chili or LUPS being used as dependency, so I'm not sure this would work better.

I would happily use both as dependencies, saves me the trouble of maintaining them. They aren't on rapid though, so I can't.

Forboding Angel wrote:I would happily use both as dependencies, saves me the trouble of maintaining them. They aren't on rapid though, so I can't.

Knowing that you're a linux user and seeing you roll your eyes at that... The irony, it doth slay me.

Both are on rapid and have been for some time.


However, rapid still doesn't correctly grab dependencies, at least not via SL download archive tool.

FLOZi wrote:Both are on rapid and have been for some time.

https://springrts.com/wiki/Rapid_Tags

They aren't on the list? What are their tags?

FLOZi wrote:However, rapid still doesn't correctly grab dependencies, at least not via SL download archive tool.

Rapid works perfectly. SL is the one that fails (seriously, why would you use SL for downloading rapid packages? :-/ Hell, zkl is awful and even it manages to get game dependencies properly (not map dependencies though)). PR downloader is part of the engine now, you can just feed it a console command, or if you're on windows you can use my pr downloader menu: https://docs.google.com/file/d/0B25BbZx ... MwRlE/edit

Or you can use the downloader built into SWL (It's a frontend for pr-downloader) on any OS: https://415a950abc581c17904719844496567 ... JXR1pRV2M/

Forboding Angel wrote: https://springrts.com/wiki/Rapid_Tags

They aren't on the list? What are their tags?

chiliui:stable, chiliui:test and lups:stable, lups:test
This is exactly the reason why we need the search extension in pr-downloader.

PS: i18n and modelshaders are also on rapid, but probably never used like that either.

Forboding Angel wrote:

FLOZi wrote:I vote for a mass wiki editing

You jest, but this is actually an excellent idea tbh.

Only half jesting. Getting working templates for lua API and then a mass edit to convert everything into the templates is a feasible and desirable achievement imo.


btw re: rapid, pretty sure i tried it direct with the cl pr-downlaoder tool too without luck; I should point out that I was using the (at the time brand new) 'dependency is a rapid tag' feature, so it may well be that it correctly downloads solid dependencies such as spring features but not rapid tags?

Spring features isn't a solid archive (I'm assuming that's what you meant when you said solid, as in solid == sdz/sd7) though (barring the ancient 1.0), however, I haven't tried using a rapid tag as a dependency (from a game archive) like "spring-features:test". I always point it to a specific one like "Spring Features v1.9".

If I'm using pr downloader directly then ofc I use the tag (test/stable), but you can feed it a specific version as well.

There's an update announcing the new LD for 26-29th August. It will be hosted as usual but with the big exception that voting will be disabled. I think this defeats the purpose of doing a jam and I feel like I would rather do something else - like a Chobby jam.

Thoughts, opinions?

I'm totally down for Chobby. I'm not a luaguy so I'm not sure where I could be helpful. Perhaps UI design? I'm good at that, or if you plan on having the ability for background lobby music I could do that, or even button sound effects, background art?/etc.

Regardless, I'm totally down.

Forboding Angel wrote:I'm totally down for Chobby. I'm not a luaguy so I'm not sure where I could be helpful. Perhaps UI design? I'm good at that, or if you plan on having the ability for background lobby music I could do that, or even button sound effects, background art?/etc.

Regardless, I'm totally down.

Any help is more than welcome. We (GoogleFrog, TurBoss and me) have already (re)-started the work on it, and it's going well. The same as LD, we use Gitter to communicate, and you can find the room in the README (https://gitter.im/Spring-Chobby/Chobby).

We are currently doing (or rather *did*) the most important parts of design. You can check the repo (https://github.com/Spring-Chobby/Chobby) for the current state, although the button sizes/positions still aren't finished and some things are a bit off so it's advisable to talk on chat to see what design we have in mind.

We haven't touched on the chili skin, which is something we will definitely need help with. I don't want to stick with the default one for a number of reasons. UI, background and generic brand art will also be needed. Music and sound too I suppose although much lower on the priority.

PS: Whether or not we end up running a Chobby jam, I strongly suggest that people interested in it join beforehand to at least get acquainted. Things like design are usually best done over a long period of time which allows you to discuss and think things through, while the jam tends to be a coding frenzy that gets a lot of laborious stuff done fast.

I don't care whether voting happens or not, but I'm on holiday then and I think realistically my chances of gradually getting into some lua coding over the summer are zero. Sorry!