Weapon number changes not worth it! pls use previous scheme

[msafwan]

I was trying to test stuff in Latest Develop version and some unit just wont fire (probably caused by weapon number changes).

This is not the only problem! The problem is you need to fix tons of stuff just for this simple number changes and it break the capability to test new engine and compare bugs!

And stuff is interconnected complex system! I cannot fix stuff in other part of the mod even when I'm good at one part of the mod!



Now imagine this:
to test new version you have to fix everything in existing code just to test 1 stuff in new version. This clearly PREVENT you from moving to new engine and create high COST for moving to new engine. It is much easier to not do anything because there's too much problem...

[smoth]

Dev builds have all kinds of things broken. That is why it is a dev build.

Your post is mostly assumptions with little actual information.

Information like build version and what project you use to test the "issue" should be the first thing you post.

[knorke]

Before, some functions starting counting weapons at 0 and others at 1 which was confusing.

! fix {Get,Set}UnitWeapon{Fire,HoldFire,TryTarget,TestTarget,TestRange,HaveFreeLineOfFire} WeaponID argument to use the same 1-starting indexes as rest of lua interface

It breaks everything now but in the future everyone will be so happy about consistency

Btw {Get,Set}SetUnitWeapon -> {Get,Set}Spring.SetUnitWeaponState ?

[smoth]

Do we have a list of updated functions? If so, no big deal to update

[Silentwings]

Yes, a list would be useful! Sounds like a pretty easy thing to fix, I can't see what the fuss is.

[FLOZi]

All but 2 (Get/SetUnitWeaponState) of the 'updated' functions were only just introduced in 94.

Instead of whining, post links to the unit script, unless you're using Get/SetUnitWeaponState in there (which would mean you're doing something out of the ordinary) this change is probably not the issue.

As for suggesting '[02:48:29] <xponen> also there is toooooons of widget using previous scheme' I find it hard to swallow.

I would categorise this change as BC3 - Engine change, games change required that will not work with current version, you must use version checks if you want to run the game under both engine versions.

I would also categorise it as a necessary and long overdue change that I had a hand in requesting.

[BrainDamage]

I wanted to make an elaborated reply about projected future work vs current and the size of actual current scripts to edit, but considering the out of proportion tones you used and the strawman you made ( which flozi partially addressed ) I'm going to simply leave you with this:

[msafwan]

The problem with you guys is you guys create tiny changes here and there (like this weapon number change) but then it force other people to debug what's wrong with stuff while its perfectly working & dependable before.

If it was a really BIG code change that take same amount of your time and my time then its ok, but if its tiny change in your part and it ate my whole day, then pls don't make that change at all.

[Funkencool]

You're not FORCED to do anything, for example ZK doesn't currently use the most recent engine. If you WANT to update your game to work with the newest engine, then you must understand this engine is updated not only for you but for future coders as well. You might not like these changes but I do, because they make sense and I don't have to deal with nuances they fixed.

[FLOZi]

The problem with you guys is you guys create tiny changes here and there (like this weapon number change) but then it force other people to debug what's wrong with stuff while its perfectly working & dependable before.

If it was a really BIG code change that take same amount of your time and my time then its ok, but if its tiny change in your part and it ate my whole day, then pls don't make that change at all.

You act (and claim) that those who support the change don't have code to update. I assure you I have plenty, but it'll at least stop me running into the same bug each new time I use one of the weapon functions.

And if I keep falling into the trap;

[Google_Frog]

To be clear; xponen(msafwan) is not referring to the changes to {Get,Set}UnitWeapon. Those are fine. I am pretty sure he is talking about the behaviour in the most recent test engine in which units with LUS have completely broken firing behaviour. Most do not shoot at all and the ones with many weapons only fire one.

The proper response is to report the bug instead of posting on the forums how the engine devs are breaking compatibility. I tend to assume that 'everything being broken' is not intentional. It is a test version, these things happen, report on mantis.

http://springrts.com/mantis/my_view_page.php

[FLOZi]

Instead of whining, post links to the unit script, unless you're using Get/SetUnitWeaponState in there (which would mean you're doing something out of the ordinary) this change is probably not the issue.

[NeonStorm]

how would you feel if nobody ever looks for consistency and engine is like

foo1(proj, projID, weapon, weaponID)
foo2(projID, weaponID)
foo3(proj, weapon) -- use some other function to get IDs
foo4(projID, proj, weaponID, weapon)

Nobody would use spring - not even the current devs.

For example, I think it is easier to code with all starting at 0, because table[#table] = new entry and i=0 while( i<#table ) and because all other programming languages do it this way.
-> Do you think the Java/Cpp/... or Lua way is better?

What would happen if everybody would request/use his own programming language?

So be happy if someone does something for consistency because:
future compatibility +consistency > consistency > today+future compatibility

[hoijui]

If it was a really BIG code change that take same amount of your time and my time then its ok, but if its tiny change in your part and it ate my whole day, then pls don't make that change at all.

Between two spring releases, there are usually about 1000 commits; let's say 500. Lets assume, 2h .. 30min... 15min! dev time per commit only! let us also be fair, and say that you are alone, and spring devs are 4.

500 * 1/4 * 15min ~= 4 days (8h per day)

... which you should have to do changes per release, fairness wise. everything else is a gift to you, in your way of arguing.
-> just to make clear, that this is no reasonable way of arguing, but totally arbitrary.

[Forboding Angel]

Maybe you should shoot for only 100 - 150 commits per release (release early, release often).