Spring 100 flying with fuel

[PepeAmpere]

Critical issues of flying with fuel

Finally i committed three autotests to help you to comfortably repro following four bugs:

• spring crash if there are less pads than planes (repro with bombers) - bug report - https://trello.com/c/2GRwouVE/112 (link to autotest is part of bug report)
• landing on moving pad + bad attaching unit to moving pad - bug report - https://trello.com/c/w8mA9ryp/113 (link to autotest is part of bug report)
• broken refuel generally for gunships - https://trello.com/c/ZflnRdPz/115 (link to autotest is part of bug report)
• lost ability to attack after desctution of pads and making new ones - https://trello.com/c/cfcND0a0/114 (link to autotest and repro is part of the bug report)

All issues are well described in our ticket system. If you meet any issues, ping me via PM or directly in trello, if you have account.

For testing use our repo game version on bitbucketor use game version i packed for you - NOTA 1.88c

In autotest descriptions there are attached starscripts for nota1xxx and for nota188c (depends if you use repo version in nota1xxx.sdd or solid pack nota188c.sdz)

Btw, autotest are not finished, yet, so they do not spawn logs and they do not end automatically, it will be added later. But they are good enough to repro all bugs.

[hokomoko]

Can you post this on https://springrts.com/mantis ?

[PepeAmpere]

Can you post this on https://springrts.com/mantis ?

I already did in:

• https://springrts.com/mantis/view.php?id=4785

Others (including you) did

• https://springrts.com/mantis/view.php?id=4616
• https://springrts.com/mantis/view.php?id=4744
• https://springrts.com/mantis/view.php?id=4707
• https://springrts.com/mantis/view.php?id=4599
• etc.

So if its just about having a ticket, take those, many of them closed with bug still in engine.

I think many of those things can be related together, so maybe you should create some EPIC task (or other uber-task) covering all those issues together. I do not know engine dev workflow and also i have just reporting rights in mantis. You can arrange it better with full rights (enabling you to change state of some tasks, editing things, etc.). I provided extensive description, repro, autotest replication, so for you its just about adding links to my reports and data.

[Silentwings]

many of them closed with bug still in engine

You have the option to re-open your report if you believe a bug is still present.

[hokomoko]

Putting all this information+tests on mantis will make sure reports aren't closed until the tests pass.
When you're distributing it over many places, you're just lowering the chance of it getting fixed to your liking.

[Google_Frog]

Have you reconsidered using Lua instead of the engine refuel system?

[hokomoko]

I really really want to remove the current aircraft refuel and repair support from the engine as this is a terribly hard coded behaviour at the moment.
Implementing a superior system in lua is definitely possible (as done in ZK) and very much recommended.
It will definitely work better than now.

[Super Mario]

I really really want to remove the current aircraft refuel and repair support from the engine as this is a terribly hard coded behaviour at the moment.
Implementing a superior system in lua is definitely possible (as done in ZK) and very much recommended.
It will definitely work better than now.

Be sure to remove other hard coded game mechanics such as the metal and energy economy as afaik they part of the "todo" list for a very long time.

[hokomoko]

Be sure to remove other hard coded game mechanics such as the metal and energy economy as afaik they part of the "todo" list for a very long time.

Nah, I don't feel like it.

[raaar]

I really really want to remove the current aircraft refuel and repair support from the engine as this is a terribly hard coded behaviour at the moment.
Implementing a superior system in lua is definitely possible (as done in ZK) and very much recommended.
It will definitely work better than now.

Be sure to remove other hard coded game mechanics such as the metal and energy economy as afaik they part of the "todo" list for a very long time.

disagree. Don't "fix" what isn't broken.

[Super Mario]

I really really want to remove the current aircraft refuel and repair support from the engine as this is a terribly hard coded behaviour at the moment.
Implementing a superior system in lua is definitely possible (as done in ZK) and very much recommended.
It will definitely work better than now.

Be sure to remove other hard coded game mechanics such as the metal and energy economy as afaik they part of the "todo" list for a very long time.

disagree. Don't "fix" what isn't broken.

Why do you want to keep the hard coded mechanics for? That is something that the game dev should implement himself. It's the remains of the engine from "porting" ta to 3d, yet attempt to do a general engine now. I call it being consistent with game design.

Be sure to remove other hard coded game mechanics such as the metal and energy economy as afaik they part of the "todo" list for a very long time.

Nah, I don't feel like it.

If you're going to clean the room, you might as well clean the house.

[PepeAmpere]

I really really want to remove the current aircraft refuel and repair support from the engine as this is a terribly hard coded behaviour at the moment.
Implementing a superior system in lua is definitely possible (as done in ZK) and very much recommended.
It will definitely work better than now.

I do not say i disagree, but i have not army of slaves which does that for me. Thats really not solution to problem, if some tech is not working correctly. If noone plan to fix it, disable that tech in engine completely then.

Guys, i do not need to hear that i should do that in Lua (I answered this already - before - directly - to googleFrog and also to Hokomo). I know I handle this mechanic in Lua but I would like to do other things than reimplementation of feature which engine promised to support. Once engine devs clearly say - ok, its shity and we do not have plan to support it, its acceptable. Once the feature is still there, i expect it will be fixed.

When you're distributing it over many places, you're just lowering the chance of it getting fixed to your liking.

This would be true if i will create redundant reports which can desync. I just linked you to all bug reports which are clear, clean, with proper repro and all the time on one place. Also I spent hours of my precious time to prepare you autotests (so saved you or any other engine dev ton of time to get to problem and provided technology which can be reused any time later). I really thought that putting just links in mantis formular proper way wont be problem for any of engine devs to do that properly THIS TIME and to prevent miscommunication THIS TIME. Especially if non-engine devs reports gets closed by "not able to repro in latest build" even if video, replay file and screenshots are attached.

Btw, if some project is using stone age ticket system with stupid distribution of rights, do not throw organization issues on your reporters. Its matter of engine devs to provide user-friendly and maintainable system for reporting issues.

Bugs I report are not ordinary bugs which are unkown and shouldnt be added to line with tons of others. Most of them have already tickets and because their context is not shared between mantis tickets, I use forum to create the missing context and push any of engine devs to some action.

By action i mean to disabling the tech or to do some fix.

[raaar]

Encouraging engine devs to remove features they break is a bad idea.

[hokomoko]

Several points:
1) Making autotests is amazing, and saves a lot of time. Thank you.
2) Having to skip and jump between this thread, your own information management system (which I have no control of) and mantis wastes my time.
3) Your issues aren't closed for no reason, even when you're unaware. When a dev says he couldn't reproduce an issue on latest version, it means they couldn't reproduce it, and they believe it was fixed in a commit between the reporting and the testing. Of course they may be wrong, that's why (1) is so good. It's very insulting to imply we get some perverse pleasure from randomly closing issues.

I've worked my arse off to figure what's wrong in https://springrts.com/mantis/view.php?id=4616 and fix it, I've tested that it works and couldn't reproduce the bugs. Apparently the issues weren't fixed in their entirety, which means there's an unknown amount of work in the future (even removing these features can be a lot of work).

Now to add on this, you first add to my work by forcing (2) on me and second you act as if you're giving me orders:

push any of engine devs to some action

This way of communicating makes it seem like we're on opposing teams rather than cooperating, which is pretty silly.

Also, the reason why I'm interested to know about your thoughts over implementing it in lua, is because I want to know the implications of removing engine support from your perspective.

I'll post my thoughts over the technical details when I'm less tired/pissed.

[Forboding Angel]

I really really want to remove the current aircraft refuel and repair support from the engine as this is a terribly hard coded behaviour at the moment.
Implementing a superior system in lua is definitely possible (as done in ZK) and very much recommended.
It will definitely work better than now.

Please do. While you're at it, move resourcing to lua as well (if you feel inclined ).

[Nemo]

PepeAmpere: Spring development is not part of your AGILE team, you are not a scrum master here :)

This is not a corporate environment where you have any basis for "pushing people to act" or saying things like "I don't need to hear X". There's nobody to escalate to. You are not paying for engine support. Nobody owes you or your game any of their time. The only thing you accomplish when you behave as if you're working in opposition to engine devs is more antagonism. What you said about:

... i have not army of slaves which does that for me.

Applies far more to engine development than it does to game development. By any metric (lines of code / developer, complexity / developer, legacy constraints + decisions / developer, users / developer) engine development has far FEWER resources to solve problems in their domain than you do in yours.

The only ways to get things done here are:

• do it yourself
• collaborate positively with the people who are willing to do it.

If you can't or won't do #1, pissing off the people who might do #2 is going to leave you and your game high and dry.

As an aside, dude, you're doing agile wrong

You should never, ever show your backlog to people outside your team with the expectation that they can make sense of it. It is a tool by and for your team alone; they are awful for external bug tracking: that's not what they're for. Mantis is a solid bug tracker that has been working for over a decade in an enormous number of projects. Whining about Mantis being old and then linking to a trello board is like pounding nails with your iPhone because hammers are "stone age" technology.

[hokomoko]

Please do. While you're at it, move resourcing to lua as well (if you feel inclined ).

It has lower priority for two reasons:
1) It's more work
2) It works better - less bugs/crashes etc.

[PepeAmpere]

PepeAmpere: Spring development is not part of your AGILE team, you are not a scrum master here...

etc..

Pure constructivism from your side. Keep your good advices for some other sort of people, Im not interested.

This way of communicating makes it seem like we're on opposing teams rather than cooperating, which is pretty silly.

Agreed. Its silly but this stinking swamp sometimes do not move ahead if you try ordinary ways. Sorry for beeing rude.

Please make some decision about future of fuel/autorepair system or provide some approximation of what will happend with this tech.

[hokomoko]

Ok, let's get back to the technical issue at hand.
I suggest to replace the current system with the following:
1) A new command CMD_LAND_ON (please give me a better name) will be added that tells an air unit to land on a target unit's piece (two parameters: unitID and piece number)
2) When rearm-refuel is needed a lua callin will be called from which you can give the aforementioned command, or do anything else you want.
3) Two callins will be used for telling when a unit entered the pad and when it left
4) A lua function will be used to tell a unit to leave a pad.
5) A lua function will be able to trigger requesting rearm-refuel

RFC

[Forboding Angel]

Please do. While you're at it, move resourcing to lua as well (if you feel inclined ).

It has lower priority for two reasons:
1) It's more work
2) It works better - less bugs/crashes etc.

Yeah I imagine uncoupling it from the engine is going to be one hell of a task, but you gotta admit, it really does belong in lua. That said, I agree that it is relatively low priority as energy/metal can be turned off/ignored rather easily.

That said, I feel like it would be a significant step forward wrt resourcing in the engine. It should also make it a little easier to implement alternative resourcing shouldn't it?

Anyway, this belongs in a separate thread. The request was mostly tongue in cheek anyway

Edit: Sorry didn't mean to start a riot -_-