Any stuff we want to "break" with next version ?

[SeanHeron]

Tentative list of suggestions to Engine devs for "breaking" changes to make:

• Include automatic Resources.lua in base

----------
Since all games that are not adapted/maintained are going to be broken with next (major) Engine version anyway, it could be seen as an opportunity to "break" even more stuff (regarding backwards compatibility) with minor added pain. Of course I'm thinking of changes that can be made with a relatively small effort, comparable to that for switching modinfo or adding GameStartSpawner.lua (ie not something like enforcing lua unitdefs ).

I for one would certainly support any changes in this manner, but there's none that really spring to my mind. So - any suggestions?

P.S. I'd have posted this in development (since after all, it's Engine side changes that'd need to be made), but really I'm asking game devs. I'm implicitly assuming the next major version is still far enough away for suggested changes to be implemented and game devs informed in a timely enough manner - happy to take engine dev input on that (cause I've not checked back with anyone).

Edit: removed incorrect info.
2nd Edit: added suggestion to forward to Engine Devs.

[Master-Athmos]

Well that resource Lua shouldn't really be considered to be bundled with the engine as it adds nothing to it. Each mod / game developer can choose for himself to either write down all bitmaps he wants to use by himself or let that automatic list creator do that job. No need to enforce people to go the one "right" way for doing it...

Of course just one release breaking stuff would be nice but I don't think that's realistic as we probably don't have (work-)time nor all the ideas as to what should be changed to pack it into a single release. In the end I don't see that many areas where real work is needed. I guess it's just about some spots were TA related hardcoded behaviours got introduced like e.g. for the resource system. Rethinking those spots might be a good idea...

While I don't have lots of concrete ideas I would like more control over hardcoded things like what defines the time or costs for operations like e.g. resurrection. Those things are hardcoded to consider certain stats from the respective units just as some premade values and a few that can be defined by the developer and which then get calculated in a certain way. I'd like to see those things getting completely customizable so you can set your own rules...

[FLOZi]

Well that resource Lua shouldn't really be considered to be bundled with the engine as it adds nothing to it. Each mod / game developer can choose for himself to either write down all bitmaps he wants to use by himself or let that automatic list creator do that job. No need to enforce people to go the one "right" way for doing it...

Just, wrong. The point is if it were in base (or rather added to the code in base so existing resource.tdf are still loaded) it would mean that the majority of mods no longer needed to write their own. It takes an annoying and seemingly pointless step out of the mod making process and makes adding image resources to a mod more transparent to the mod maker.

But whatever, I don't expect it to be added anyway.

I'd like the TEDClass hack for factories to be binned and do away with the tag altogether, infact, as that is its only purpose.

[SeanHeron]

Each mod / game developer can choose for himself to either write down all bitmaps he wants to use by himself or let that automatic list creator do that job. No need to enforce people to go the one "right" way for doing it...

They still could choose - and you wouldn't be forcing a "right" way - since you can still override with a resources.lua included in your game.sdd. I think using resources.tdf wouldn't work anymore though (unless you included the parser for that within your resources.lua or something like that). Hence why I was saying you'd have to shift and potentially rename you're texture files. Hmm - of course alternatively you just transfer you're resources.tdf to a resources.lua - so actually it's pretty minimal effort (I portayed that incorrectly in my first post... my bad).

I guess if someone set up the parsing of resources.tdf in a resources.lua - which should be possible - then I wouldn't see any reason not to switch. All you'd need to do then would be plonk in that file, and everything works the same as it was.

[Argh]

Just, wrong. The point is if it were in base (or rather added to the code in base so existing resource.tdf are still loaded) it would mean that the majority of mods no longer needed to write their own. It takes an annoying and seemingly pointless step out of the mod making process and makes adding image resources to a mod more transparent to the mod maker.

But whatever, I don't expect it to be added anyway.

I'd like the TEDClass hack for factories to be binned and do away with the tag altogether, infact, as that is its only purpose.

I agree with all of this. And you don't have to use it, by any means- you can always write another piece of Lua to override it, if you really want to.

But it is well past time to make adding these things into a game a less-annoying, less-arbitrary process. And I suspect that 99% of us won't want to bother, because, well... uh... they all go into the same texture atlas anyhow, so why continue to maintain something else?

As another example, it's annoying that the engine forces all movetypes to either be KBOT, TANK, HOVER or SHIP. We're tied to arbitrary OTA stuff there.

[Das Bruce]

Replace the word mod with the word game where appropriate.

[Lurking]

If it would be possible to break DSD with the next version that would be awesome.

[SeanHeron]

As another example, it's annoying that the engine forces all movetypes to either be KBOT, TANK, HOVER or SHIP. We're tied to arbitrary OTA stuff there.

I'd agree, but I guess I was thinking of Engine changes which are both easy for Game devs to implement - but also require only minimal efforts for our Engine devs (cause I don't really want to be striding up to them with a list of demands...). Might be something worth collecting seperately though (ie - which TAisms are still around that we could really do without).

Replace the word mod with the word game where appropriate.

That makes sense to me, but I don't know if it warrants the extra effort required both of game and engine devs.


As I've not made my view clear above - I'm all in favor of adding the automagic resources.lua to /base. Benefits I see are twofold - Benefit of simpler system for people stumbling into the Engine freshly. And probably the larger, ease of dependencies without requiring to emulate the resources.lua anew in each (ie also allowing dependency to be used by various games). Yes, of course that is also possible by getting game devs to switch over, but that's a slower and unsure way of setting the standard.

The only real argument against I see is that if there's no resources.lua in mod files, aforementioned people (coming fresh to our engine) also don't have a convenient list of textures provided in /base to stumble over. Worth the tradeoff, I think.

[Master-Athmos]

Benefit of simpler system for people stumbling into the Engine freshly.

I'd rather do an official "empty mod file" and put it there - that probably would be an enormous help for new people anyway as although there currently exist some of those empty modfiles you pretty much have to ask for some to dig them out for you as links to them slumber somewhere in the forum...

Did anyone test it in terms of special characters btw? I don't want to start an entire discussion about this being inlcuded in base or not - my opinion is that it's handy and definitely should be included in an empty mod but I don't see as to why people who didn't name things exactly as the bitmaps are named should adapt to that now. Ok - it's nothing more than putting the current base resource.lua into their mods / games so the new automagic gets overwritten and that's also why I'm not going to make a big deal about it...

So are there no more ideas about what could be changed to make things more accessible and remove TAisms or in general one-way premade formulas? Maybe we could list things were simple premade formulas are applied. Off the top of my head I just can recall those:

• Capturing
• Reclaiming
• Repairing
• Ressurecting
• Experience Bonuses (starting with units stats, going up to weapon stats like sprayangles)
• Crushing wrecks (I'm not 100% sure how that got determined but iirc the needed strength got calculated by several things)

EDIT:
Oh - one more thing. Maybe the whole flanking bonus should be made into FBI tags or something. I don't think it ever got extended over the global settings you gave somewhere in the gamedata folder of your project and then you had to apply new values for certain units via COB. That had something tricky about it though iirc as at least I once played around with that but couldn't force new values but maybe I just did something wrong...

[zwzsg]

Crushing wrecks (I'm not 100% sure how that got determined but iirc the needed strength got calculated by several things)

There is a Mass tag in features. There is a CrushStrength tag in the units moveinfo.

How the default value of CrushStrength is calculated when it's not set is irrelevant as any properly made mod should not forget to specify its Mass and CrushStrength values.

[SeanHeron]

Agree with Z there.

@Athmos:

Capturing,[...], Ressurecting

I guess you're referring to them all using HP and buildspeed for how fast they work? (I don't actually know if they do... not worked with them much). The way to solve that would traditionally be to add additional unitdef entries for eg captureSpeed, etc. and perhaps also getCapturedSpeed, etc. - and, where they are not used, default to what is used now (so buildspeed and HP). So no breaking there --> This would be for the new topic I suggested of "TAisms we want to be rid of" (feel free to make that :D).

Good call on the Experience though! The topic was being discussed just recently - it didn't really come to a consensus though...
If the path of axing all XP effects, and leaving the Engine to only record the XP value (then reimplementing all XP effects via a Gadget) was taken though, that'd fit right in with this topic. That first requires a Gadget doing afformentioned tasks though (going to Engine devs before doesn't make sense).

[aegis]

Oh - one more thing. Maybe the whole flanking bonus should be made into FBI tags or something. I don't think it ever got extended over the global settings you gave somewhere in the gamedata folder of your project and then you had to apply new values for certain units via COB. That had something tricky about it though iirc as at least I once played around with that but couldn't force new values but maybe I just did something wrong...

bonus shield?

[Master-Athmos]

@zwzsg:
Ah ok so the mass tag for feature works and is the only value. Wasn't sure about that...

@SeanHeron:
With all those builder related stuff I meant like e.g. the energy consumption when doing a resurrection is this:

Code: Select all

UseEnergy(ud->energyCost * resurrectSpeed / ud->buildTime * modInfo.resurrectEnergyCostFactor)

You of course have some influence on it but if you e.g. want to have a constant rate of energy consumption that a ressurector needs that's a dead end because it's hardcoded that way...[

bonus shield?

I thought bonus shield was dead?
http://springrts.com/mantis/view.php?id=680
http://springrts.com/phpbb/viewtopic.php?f=12&t=11021

But maybe things changed again. The wiki doesn't get updated that often anyway and so there's hardly a way to look it up - I recently did write in some additional tags but still lots of stuff like the new paralyzeonmaxhealth tag or whatever it's name was still isn't there like some others too I guess...

[FLOZi]

I don't see as to why people who didn't name things exactly as the bitmaps are named should adapt to that now

If people already have their own resources in their mod/game, then they already have their own resources.tdf/lua which will override that in the base content. They won't have to change ANYTHING. Any mod with an existing resources setup will have to change NOTHING AT ALL if they DON'T WANT TO.

[Master-Athmos]

Well all the recent tdf based mods would need to paste what currently is the base's resource.lua. But again I told my opinion and don't see much use of starting a big discussion. I also don't want to say that this new resource.lua is bad or something. Actually I think it's very neat...

So let's focus on what Sean intended this topic for...

[FLOZi]

Well all the recent tdf based mods would need to paste what currently is the base's resource.lua. But again I told my opinion and don't see much use of starting a big discussion. I also don't want to say that this new resource.lua is bad or something. Actually I think it's very neat...

So let's focus on what Sean intended this topic for...

My automagical version already includes those things (caustics, smoke & scars - but I should point out here that the engine is hardcoded to load those defaults, so they don't even need to be in the base content resources.lua), and, as I stated when i first posted it, it needs someone with better lua-fu than myself to give it the once over and integrate with the current resources.lua code in base (mainly the inclusion of tdf parser)

[SeanHeron]

My bad - again. I guess FLOZi and I had a slightly different understanding of how it would be integrated - I thought/think it would be fine to include as-is, which would mean games needing to slightly change stuff, one way or the other.
FLOZi, as I now understood it, you're saying only include it if we can fix it up so that it still loads resources.tdf by default. In that case it wouldn't actually be a breaking change anymore, which doesn't change that it'd be worth doing.

[FLOZi]

I'd like the TEDClass hack for factories to be binned and do away with the tag altogether, infact, as that is its only purpose.

All hail kloot:

http://github.com/spring/spring/commit/ ... 110c943b47

[Pxtl]

I'd like the TEDClass hack for factories to be binned and do away with the tag altogether, infact, as that is its only purpose.

All hail kloot:

http://github.com/spring/spring/commit/ ... 110c943b47

Code: Select all

if ((ud.speed > 0.0f) || ud.canfly) {

How does this not break immobile builders?

[MidKnight]

Any stuff we want to "break" with next version ?

How does this not break immobile builders?

Am I missing something here?