Transport Tycoon Forums

Three words Hyronymus.

_________________
¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨ Wiki ¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨¨*:•:.,¸¸,.:•:*¨

I figured. Understandable - the effort you've poured into this one is already commendable!

I hope your co-operation goes well though.

Wasila

_________________

I saw what you did there before you edited your post but did not have the time to reply ...


Thank you for the kind words. Very much apreciated.

We'll see what the future brings.

Any of the following scenarios is possible ...
- A few people are interested and we make a new patchpack together.
- I restart a new one on my own but at a much slower pace than before.
- I continue improving this one on my own (no I did not forget the many help and feedback I received) and might completely branch of trunk at some point.
- I start spamming the bugtracker with smaller patches that have a chance of getting in trunk.

_________________
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first!
All included patches have been modified and are no longer 100% original.

See the first post of my thread, please.
Thank you very much for understanding.

Based in my own experience, developing a patch pack and contributing to OpenTTD are not incompatible goals. I chose to organize my old TPPP as a patch queue to be able to keep each feature as an independent unit. Besides being in my opinion a simpler way to develop something that adds a bunch of wildly different changes to an existing source, one of the advantages of this approach is to allow you to continue independent development of each one of the parts. This helped in getting some of the patches in shape for trunk inclusion. When one of the parts is included in trunk, you only need to remove it from your queue and fix any possible rejects. To avoid problems, you can keep simpler patches that are more likely to be included at the beginning, while keeping the huge ones that you don't see being included in trunk at the end.

What I want to say with this is that a patch pack can benefit OpenTTD development. It is possible to maintain a patch pack and still try to get some of its parts into trunk. Because of that, I hope that you consider a solution that does not involve an indepent development. Working on different directions would be less helpful for everyone involved

_________________
Spanish translation of OpenTTD
Extended heightmaps

Have fun, don't quarrel too much and add as many advanced settings as you can.

No worries just yet ... branching off would be a "last" solution that I am not looking forward to.

I am aware that many points I (read: we) put my finger on were implemented in trunk (and patches) in some form or another; I would like this to continue but at the same time I am very well aware of the many hurdles that lie in front of me to simply bump my patchpack to current trunk.
Also as I used SVN and my patchpack is one big megafile to be applied it is nearly impossible to split it up in branches or pull out a patch and replace it with another (newer) version of the same feature. Even I do not recall the many adjustments I made to the various patches (and trunk code) so I am not really expecting anyone to join me in this one.

I know of the advantages of using HG now and am planning on using this if/when I (?or we?) restart a patchpack.

I am still looking forward to continue contributing to the development of trunk itself in one way or another.

_________________
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first!
All included patches have been modified and are no longer 100% original.

See the first post of my thread, please.
Thank you very much for understanding.

when you "restart" the patchpack, it might be considered whether it's better to base it on release (1.2.x) and restart it practically every year. this may be less troublesome than if you constantly bump for trunk version.

_________________
You might not exactly be interested in Ferion, but if you are, have fun

The problem with using stable builds is theres usually no patches made for stable's, usually just the nightly builds. And even if you had a patched stable that doesnt mean everything going to work.

_________________
Nekomasters Projects...
# Utah Lake > v 1.00
# Generic Australian Rail Set (GARS) R&D

how is that relevant, if the patches are made for nightly builds three years ago?

no. but it is way easier to shoot a standing target than a moving one.

the point is, the current patchpack is stuck in some very intermediate nightly, so you don't have the up-to-date-ness of a nightly anyway, so you may as well pick a stable...

_________________
You might not exactly be interested in Ferion, but if you are, have fun

Glad to hear that

_________________
Spanish translation of OpenTTD
Extended heightmaps

Have fun, don't quarrel too much and add as many advanced settings as you can.

Morning y'all,

My first post after months of lurking...
Although I've been interested in getting involved with OTTD development for a long time, only now my job grants me enough free time to get back to programming in the open source domain.

Since I've been a professional programmer for 15 years now, that will be a busman's holliday for me, but who cares. During the last 4 to 5 years I've been "promoted" away from the day-to-day coding to project leader and test supervisor duties. I don't mind the payment upgrade, but I miss getting my hands dirty on some serious coding.

Since I've been juggling whole projects lately, I've learned a thing or twelve about project management, so maybe I can offer some suggestions.

First of all, a trunk-fork would be a crippling blow to the project really as NewGRF's would start to become incompatible over the time. Not all GRF authors will bother checking their creations for compatibility with three versions (TTD-Patch, OTTD, ChillTTD). Not to mention that it would probably split the fan base into those, who stay with the original OTTD and those, who follow the forked patchpack version.

Eddi offered the most sensitive option, I think. A patch as massive as CargoDist will probably never make it into the trunk. Programmers are notoriously territorial animals, so it is a tough sell to get the major trunk players to accept such a complex inclusion. What is possible, however, is to synchronise the patch pack to the trunk versions.

Let's say you decide to "restart" the patch pack. To get that off to a good start, you would select a bunch of patches to include, and integrate them into the current major trunk revision, which would be 1.2.0. For clarity reason, you would call it 1.2.0 as well. Once it is stable, the features are frozen, which means that no new features will be added in any of the patches. The only development that will be going on in this branch, is bugfixing and compatibility fixing to the minor trunk releases, like the current 1.2.1.

Simultaneously you have a second branch, lets say you start that at revision 1.2.50. That way the revision number clearly shows what's what. 1.2.<50 are "stable" releases correlating with the stable releases of mainstream OTTD and 1.2.>50 are the bleeding edge versions, which include the same bugfixes and compatibility fixes as the <50-revisions, but also get new features. This might create a bit of a work-overhead, as you have to back port all bugfixes from the >50 revisions to the <50 revisions, but you can always release a "stable" ChillPack!OTTD whenever OTTD releases a minor trunk release.
Those of a more adventurous disposition can meanwhile choose to plug the latest 50+ revision into an OTTD nightly. Inclusion of new patches into the pack would only happen in the 50+ revisions, keeping the 50- revisions stable. As I said, it is a wee bit more work than absolutely neccessary, but it will give the ChillPack users the option of playing a reasonably up-to-date version in comparison to the vanilla release.

The critical question is whether or not a 1.2.0 based ChillPack will be stable before the "trunkies" release 1.3.0. If not, it would make sense to start development at the current trunk-nightly and have no stable release. The first stable one would then be ChillPack 1.3.0.

On a technical level I would suggest to depart from the monolithic patch approach. I would suggest to keep each patch seperate. That'll probably add a gazillion #ifdef's to the source, but it also allows to disable patches at source level (via ./configure parameter). That makes it easier to discontinue patches that are terminally broken or have found their way into the trunk. Imagine the trunk does some major changes to map handling, which would break the heightlevels patch. Instead of nerfing the whole patch pack, you could temporarily disable it via hardwired ./configure option. All other patches in the nightly would still work and those, who want the heighlevels patch can revert back to the latest stable release. Once the heightlevel patch has been fixed, it can be re-enabled in the next nightly.

That got a bit long for a first post, didn't it Hope I didn't come across too head-teachery, just wanted to offer some advice from experience with commercial project management.

Cheers,
Lukenwolf

_________________
Dont bother asking for cures or an answer, god is the one who gave you the cancer.

I think it would really help chill if he had another programmer (and maybe a alpha tester) to help him with new builds as from what Ive seen, Chill doesnt have all the time in the world lately

I'd volunteer to be a tester if it would help, at least until i get a job (which Ill probably still have time) or school (same as before, unless im working as well).

_________________
Nekomasters Projects...
# Utah Lake > v 1.00
# Generic Australian Rail Set (GARS) R&D

To keep something as complex as ChillPack on track and up-to-date with the trunk you'd probably need two or three programmers. I volunteer to help with the coding, but I cannot promise more than two or three hours a day, due to having a day job

The real important thing would be testers, lots of 'em, especially those, who manage to describe bugs in a way that enables programmers to retrace the conditions, which led to the malfunctions.

_________________
Dont bother asking for cures or an answer, god is the one who gave you the cancer.

Would having a powerful enough computer to record video of whats wrong help? Also Ive got all the time in the world lately so play testing is something I could do to keep my self from going insane from lack of something better to do

_________________
Nekomasters Projects...
# Utah Lake > v 1.00
# Generic Australian Rail Set (GARS) R&D

There are two things a good tester needs:

a) a predatory instinct
b) lots of patience.

I'll try to explain using an example. Let's take the bug in the programmable signals patch that made the game crash, when an exit signal was deleted that was referenced in the programmable signals program. I'm pretty sure that bug was found, because someone accidentally deleted such an exit signal. A good tester would have found that bug within 5 minutes.

Usually, when people start testing a new software, they say "Let's look if that new feature works like it should". These folks are nice testers. The first thing a good tester says is "Let's see if I can break it". An experienced tester would have said: Let's look at this new programmable signal thing. That signal relies on those other two. Let's see what happens if I delete one of them. *BOOM*

Testing if a new feature is working correctly is always the second step. First you always try to make it crash. That's not to frustrate the developers, but to find the bugs instead of stumbling over them.

And the second most important thing is patience. In the above example, validating a bugfix is easy. You know that deleting a signal does always cause a crash. So you go ahead, take the old version, delete the signal and the game crashes. Now you start the new version, do exactly the same and if it doesn't crash - voila, bug fixed and fix validated.

But it get's messy if you have bugs of the type "game crashes occasionally, if two trains are within 10 tiles of one another and one of them carries at least 100t of coal". That's the nastiest test case you can think off, because there is no definitive way to make it crash. It bombs out in only x out of 100 cases. That means, to validate the bug fix, the tester has to observe the same situation over and over again, lets say 100 times. Only if the new version didn't crash once, you can say it is probably fixed and that's still only a statistical probability.

As you can see, effective testing is more than just playing with a bleeding edge version and waiting if something goes wrong.

_________________
Dont bother asking for cures or an answer, god is the one who gave you the cancer.

Breaking things is what I use to do as a hobby when I was younger (specifically, I was breaking electronics and breaking them open to find out what broke and what I could salvage/fix)

Anyways as a tester I'd be testing what I can to make sure everything works, aside from the languages since I only know English, though I do know that sometimes theres problems with GRF's not liking missing or messed up languages, even if your playing with a totally different language. Anyways, I'd play with everything and take note of bugs or crashes when I do things. Having a screen capture going while I play would help so I can retrace what I did to cause the crash and properly report it to get it fixed easier.

_________________
Nekomasters Projects...
# Utah Lake > v 1.00
# Generic Australian Rail Set (GARS) R&D

That might be something to consider although I'd rather pick "a"(*) nightly instead of a stable version to avoid confusion.

(*) Maybe the nightly the stable branch is based on and not call it eg. 1.2.x at all to avoid confusion.


Not at all Eddi, most of the included patches I had to bump (or backport) to "a" revision and then I kept them going.





Edit: Eddi and NekoMaster were inverted in the next quote.
@Eddi: True that a standing target is easier to hit but I would miss out on development of many things, wouldn't I (we)?.
@NekoMaster: True that the included patches (at least most of them) are missing something or are buggy in some way or another (and that is the reason they are not in trunk).

Stuck is such a big word ... I am not yet completely stuck ... I just am short on time ... very very short to test changes made properly.
From what I have been able to test, my last "test" version still works as good as before. It is just that I am afraid something is broken beyond repair and there is so much ... so very very much to test.

Welcome to the forums.

Please allow me some time to respond to your posts. I have some (urgent) personal affairs to take care off at the moment but I will get back to you in more detail abaout what you wrote.

Just one question ... three hours a day to spend is quite a lot and with the experience you have ... sure you'd not rather spend them on trunk itself?
No hard feelings whatsoever if you do.
I mean I would welcome a helping hand very much but please do realise that a patchpack has zero chance of getting into trunk.
Also I am not looking forward to commandeer anyone, just having fun coding and make something many people can enjoy.

Not at all ... no worries.


Ps:
@NekoMaster:
I apreciate your proposal to be a tester but nothing stops you from testing and reporting already right now.
Let me get back to you too.

_________________
Playing with my patchpack? Ask questions on usage and report bugs in the correct thread first!
All included patches have been modified and are no longer 100% original.

See the first post of my thread, please.
Thank you very much for understanding.

I do know that the patch pack won't make the trunk. I chose your patch pack as my point of interest for a reason. It contains many things I actually think should be in the trunk, but they probably will never be included, especially something as massive as Cargodist, which I've been interested in ever since I tested the dark side (Simutrans). I think I can contribute more by helping with the patch pack than squabbling with the trunkies over little patches. I also have some ideas for patches that would fit in the patch pack better than as standalone patches in the trunk.

_________________
Dont bother asking for cures or an answer, god is the one who gave you the cancer.

just for the record: i don't share your pessimism wrt CargoDist ever being included in trunk...

_________________
You might not exactly be interested in Ferion, but if you are, have fun

The main problem with cargodist/dest is that there are two competing ideologies, and that both (last time I really checked = long ago) had some annoying/irritating issues (to me). No idea whether they have been solved though; haven't gotten the time to check that.

Actually, quite a bit of cargodest, cargodist and yacd have ended up in trunk over time. So without that the patch(es) would have been even bigger.

Eventually many things will be added to the trunk and i would like to think that patch packs such as this wonderful one will help to increase interest and also identify and potentially solve some of the bugs that are present in the code.

I am immensely grateful to chill for all the work he has done on this pack and i would have offered my help long ago if it would have been any use. Any non coding help that is needed my offer stands!

_________________
The TT forums trivia tournament! Come along and join in the fun
http://www.funtrivia.com/private/main.cfm?tid=90722