Next build (M Series)

Goals for next build + the people who are most likely working on them, as I understand them - feel free to add/edit.

  • Navy implementation/balance (Nemo)
  • Integrate/balance Zerg’s new cover and AP/armor systems (Nemo)
  • Paratroop/glider system (Zerg)
  • Further development of the GM tools (Nemo)
  • Standardize sound fx/unit ack volumes across the board (I’ll help with this if someone has a method for me to follow)
  • More voices/fx? (yuri + Neddie?)
  • Run some events with Lyuban? (Neddie, would you be up for this?)
  • Play lots!

Tobi - I assume you’re still neck-deep in the Lua unit scripting stuff, and Zerg I left you off here because I don’t know what you’re most excited to work on. Just give me a poke about what you’re interested in.

Possible projects for me (not sure if I will do all of them):

  • Gliders/paratroops (do we have models yet?)
  • Python .tdf parser
  • Tutorial gadget

Models for gliders are made, and I imagine yuri can crank out whatever we’re missing.

Tutorial gadget is awesome, but I figure the easiest way to do this would be via quantum’s mission maker?

What’s the plan for a python .tdf parser?

It would basically read .tdf files and convert them to a Python dict. Then you could perform mass edits on the data; I might even try supporting conversion to Lua.

Oh, neat. I’m happy to do mass edits by hand, but that sounds like a handy thing in general.

I was also thinking about GUI, Zerg.

Then you can re-use Spring’s Lua TDF parser in python :stuck_out_tongue:

Also note that with Lua unit definitions and a good design there should be no need for mass edits. Mass edit would mean after all that some value is identical or based on some other values for a unit, and that’s exactly what can be done using Lua unit definitions. (e.g. unitdefs_post.lua, AFAIK)

As for me, I was busy with Spring stuff itself last weeks, (lobby) server move, server performance problems, etc.; LuaCob is on hold for me until lurker finishes framework, though I might take over again if he doesn’t hurry up :slight_smile:

Also exams are coming soon and still need to start learning like 150 distributed algorithms by heart, so my time will be a bit limited :mrgreen:

Ouch, good luck Tobi.

Thanks, I’ll definitely check that out when I get a chance.

This touches on a debate that occasionally came around when I was still working for CA. My view on it is that postdefs are great for testing and modoptions, but when it comes to permanent changes, I prefer the numbers to be directly visible in the unit files. There are downsides too, of course; for example, if you want to add a new unit but also want it to fit certain patters, it may be easier to do that using postdefs than a standardization script; it’s just that I believe the benefits of mass edits outweigh those of postdefs when it comes to long-term changes.

The Lua unit script stuff is sounding really sweet; I think it will really help maintainability. Thanks for your work on that.

Good luck! I imagine I will be facing similar things in a few years…

I agree on the unitdefs vs post defs stuff - we’ve had a couple semi permanent changes hosted there over the last few months, and for people who were looking up balance stats in the unit defs, it created a real problem - modifiers like 2x ammo cost in postdefs, and there’s no way to know unless you go and read through all of post defs or I tell you.

Documentation can solve this problem somewhat, but in general I think it is better organizational practice to keep all unit stats in the same file.