Working on a fork of OpenTTD

[DeletedUser21]

I hate GRFs

Uhm... Keiji, I suggest you duck for the heavy things Dalestan will throw at you now.

Well anyway, your plan really sounds ambitious but it also sounds very good. I wish you the best of luck with your fork.

[Aegir]

I hate GRFs

Uhm... Keiji, I suggest you duck for the heavy things Dalestan will throw at you now.

Or the rest of the community.

Ahh, this thread is so much more amusing when you're old enough to remember that Keiji = iNVERTED = BobXP and all the various fun and games from times gone by.

Me? I don't really care. Forks come and go (OpenTTD challenge spinoff for example. Although that wasn't 'Waaah, you won't let me code how I want, I TEH FORK UR CODE LAWL' (Like Beryl), it was a seperate project with a seperate gameplay aim altogether).

As I understand it there's coding style enforcement in large projects for a reason. To make everyone _elses_ life easier and to prevent the code-base turning into some sort of spaghetti mess (Or spaghetti western).

enjoy ur codebase lawl

[DeletedUser21]

Keiji = iNVERTED = BobXP and all the various fun and games from times gone by.

I know that, but some people really do mature.
I just wish him goodluck since he would indeed need that. And maybe he does succeed on his own or get help from other people, there is nothing wrong with that right?

[iNVERTED]

Well anyway, your plan really sounds ambitious but it also sounds very good. I wish you the best of luck with your fork.

Yeah, but I suddenly realized this is probably going to die as soon as I get bored of openttd and work on one of my other billions of projects. Eh, we'll see.

Uhm... Keiji, I suggest you duck for the heavy things Dalestan will throw at you now.

Or the rest of the community.

Keiji = iNVERTED = BobXP and all the various fun and games from times gone by.

I know that, but some people really do mature.

I don't even remember someone called Aegir from years ago... and more importantly, if you still have a grudge of me you can just shut up and not read this topic.

As I understand it there's coding style enforcement in large projects for a reason. To make everyone _elses_ life easier and to prevent the code-base turning into some sort of spaghetti mess (Or spaghetti western).

Well to me most of the code in OTTD, especially the internals, are a spaghetti mess. Hence why I am rewriting them.

[DeletedUser21]

Hey I don't hold a grudge against you! I support you! That is because I endorse people to behave in some kind of mature way. (We all have our 'things' but in a general manner I mean. )

I hope you don't give up on the project if your interest in OTTD has dropped. And if you do, I hope you will pick up again later.

Mr. X sets mode on +cheer

[DaleStan]

and as for GRFs, I hate GRFs

Why?

(I think that's just about the heaviest thing I can throw, Mr. X.)

[PouncingAnt]

and as for GRFs, I hate GRFs

Why?

(I think that's just about the heaviest thing I can throw, Mr. X.)

You mean, thats all you can throw at him before he gives a reason why he hates it

I hate GRFs

Uhm... Keiji, I suggest you duck for the heavy things Dalestan will throw at you now.

Or the rest of the community.

Ahh, this thread is so much more amusing when you're old enough to remember that Keiji = iNVERTED = BobXP and all the various fun and games from times gone by.

Me? I don't really care. Forks come and go (OpenTTD challenge spinoff for example. Although that wasn't 'Waaah, you won't let me code how I want, I TEH FORK UR CODE LAWL' (Like Beryl), it was a seperate project with a seperate gameplay aim altogether).

As I understand it there's coding style enforcement in large projects for a reason. To make everyone _elses_ life easier and to prevent the code-base turning into some sort of spaghetti mess (Or spaghetti western).

enjoy ur codebase lawl

It may well be that this fork produces some results that we can transfer back into OpenTTD. So *please* show some support!

This doesnt need to be about coding differences (and I dont think a debate about that is appropriate, so I'll say no more). We can use this fork to test the gameplay of unimplemented ideas. Its a darn good excercise! I support what Keiji is doing wholly

[richk67]

We have a gazillion ideas, and a ton of patches that are functionally interesting, but suck code-wise.

Anything developed in this fork will be useless to ottd-trunk, as the starting base is several THOUSAND revisions old. If any good ideas are developed, they would need recoding from scratch to work with ottd-trunk.

If you want to see any possibility of features in an alternate ottd making its way into trunk, you need to stay as close to trunk as possible, keep it in sync, code to the style and standard of trunk. All these iNVERTED has already ruled out.

I wish him well - and I'll go buy shares in pharmaceutical companies... he is going to have a headache of enormous proportions. (MiniIN was bad enough!!)

[DaleStan]

(I think that's just about the heaviest thing I can throw, Mr. X.)

You mean, thats all you can throw at him before he gives a reason why he hates it

Except that that requires a *valid* reason. "I didn't design it so it must be crap" and "I have no idea how it works so it must be crap" aren't valid. Nor are hyperbole or FUD.

[Ailure]

"I didn't design it so it must be crap" and "I have no idea how it works so it must be crap" aren't valid. Nor are hyperbole or FUD.

Reminds me...

What's the main reason you use a such old revision? Is C really that much better than C++, and for what reasons?

[Jupix]

If I understand the situation correctly, this is a project started, maintained and developed only by iNVERTED, so he may use the nightly rev / programming language / features he pleases without having to explain his choices ("properly" or not) to anyone.

[PouncingAnt]

Dalestan: Of course I know I shouldn't dig

We have a gazillion ideas, and a ton of patches that are functionally interesting, but suck code-wise.

Anything developed in this fork will be useless to ottd-trunk, as the starting base is several THOUSAND revisions old. If any good ideas are developed, they would need recoding from scratch to work with ottd-trunk.

If you want to see any possibility of features in an alternate ottd making its way into trunk, you need to stay as close to trunk as possible, keep it in sync, code to the style and standard of trunk. All these iNVERTED has already ruled out.

I wish him well - and I'll go buy shares in pharmaceutical companies... he is going to have a headache of enormous proportions. (MiniIN was bad enough!!)

Useless to the ottd-trunk? That doesn't matter one bit. What matters is that we're exploring ways of implementing these ideas. Its an important step in progressing ideas.

So they'd need recoding from scratch! Thats a good thing too, in my book! Theres not been a time where I coded something and thought afterwards that I should have started the project just a bit differently from the start.

As I say, this is a good experiment in the implementation of the ideas put forth. Even if it comes to nothing more than that, it will be worth it. Don't you agree?

[richk67]

Err... no. If you want something in trunk, code it for trunk. There is far too much for the devs to do rather than do the recoding work for someone's experimental patch in another code-base.

We have design ideas and test code and patches galore... we dont need experiments in design & implementation; we need good solid live code for all the features people clamour for. An experiment (except if very short term) is unnecessary on a project such as OTTD. And an experiment on an incompatible code-base proves nothing whatsoever, and is more likely to lead development down blind alleys.

If someone wants to really do something of value, then follow mart3p's example; develop a feature, test it, debug it, update it for trunk, take advice, make it compatible style and code-wise, test it, test it again, and then celebrate when its in trunk.

IMO the only benefit from iNVERTED's exercise is to iNVERTED's skill base. It proves nothing about what can or will happen in trunk.

I had all this when I did MiniIN. "Are you testing patches for trunk?" No. "When will feature XYZ be in trunk? Its in MiniIN." It wont. And I had made a special effort to a) keep MiniIN load-compatible with trunk, b) up to date with trunk. (BTW there is no sour-grapes there... I was under no illusions that anything I did in MiniIN would have any significance to trunk... it was just hard convincing everyone else.)

It is just not realistic to think that anything that happens in a fork will have any bearing whatsoever on trunk. Only a branch has that possibility - a branch that is based on current trunk, is kept in sync, and doesnt wholesale reject the advances in OTTD over the last 3500 revisions.

[iNVERTED]

Hey I don't hold a grudge against you! I support you! That is because I endorse people to behave in some kind of mature way. (We all have our 'things' but in a general manner I mean. )

I hope you don't give up on the project if your interest in OTTD has dropped. And if you do, I hope you will pick up again later.

Sorry, I misquoted. I was talking to Aegir when I mentioned the grudge. And yeah, this is based on an ancient revision because I had actually started this months ago, then got bored and left it for ages, but I will always come back to it eventually.

and as for GRFs, I hate GRFs

Why?

(I think that's just about the heaviest thing I can throw, Mr. X.)

I want to make file formats generic. I have developed a file format called XDA (eXtensible Data Array) which is like XML but much much smaller because it is in binary rather than using stupid XML tags. It therefore makes sense to me to use XDA for every single thing that I code. Besides that, it would be much easier for "GRF" developers to simply save their image and load OTTD to test, without having to use grfcodec every single time they want to test. Hence why I am using a BMP + XDA combination, and whenever I bother to learn how to use PNG files, then make that PNG + XDA.

IMO the only benefit from iNVERTED's exercise is to iNVERTED's skill base. It proves nothing about what can or will happen in trunk.

That's exactly the point. I love playing OTTD, and I wish the features mentioned in my first post existed, which is one reason why I am making them. The other reason is just as you said - to drastically increase my programming skill so that I can finish Fusion, which is my main project and will bring together all of my other projects.

btw. blame school for lack of updates.

[jonty-comp]

I want to make file formats generic. I have developed a file format called XDA (eXtensible Data Array) which is like XML but much much smaller because it is in binary rather than using stupid XML tags. It therefore makes sense to me to use XDA for every single thing that I code. Besides that, it would be much easier for "GRF" developers to simply save their image and load OTTD to test, without having to use grfcodec every single time they want to test. Hence why I am using a BMP + XDA combination, and whenever I bother to learn how to use PNG files, then make that PNG + XDA.

Ooh, nice idea!
I've always found NFO waay to hard to work with, but I've been doing things with XML-type stuff for ages with little problems.
Keep it up!

P.S. I see this as a potential possibility for server-side graphics, that would be awesome in multiplayer.

[DaleStan]

I want to make file formats generic. I have developed a file format called XDA (eXtensible Data Array) which is like XML but much much smaller because it is in binary rather than using stupid XML tags.

How is XDA more generic than GRF? The grf container can hold any number of things, normally called "sprites", which can optionally be compressed using at least two different algorithms, and carry almost no meta-data. If you want these "things" to be "files", prepend a header indicating this, and containing name, timestamps, and external compression scheme, if used.
If you want these "things" to be "8-bit sprites", prepend a header indicating this, and containing the necessary meta-data.
If you want these "things" to be "NFO code", prepend a header indicating this.
If you want these "things" to be something else, prepend a header with the appropriate indications, and the appropriate meta-data.

The only GRF-enforced meta-data is the length of the "thing", and a single byte indicating the presence or absence of grf-internal compression.

Besides that, it would be much easier for "GRF" developers to simply save their image and load OTTD to test, without having to use grfcodec every single time they want to test.

What? Its hard to press [up][enter] before testing? This is news to me.

[PouncingAnt]

Err... no. If you want something in trunk, code it for trunk. There is far too much for the devs to do rather than do the recoding work for someone's experimental patch in another code-base.

-sigh- I'm not proposing for a second the Devs should do that work. Why would you assume that? Theres hundereds of programmers out there who could do it, not just the devs.

We have design ideas and test code and patches galore... we dont need experiments in design & implementation; we need good solid live code for all the features people clamour for. An experiment (except if very short term) is unnecessary on a project such as OTTD. And an experiment on an incompatible code-base proves nothing whatsoever, and is more likely to lead development down blind alleys.

This experiment will be useful. Experimentation is a good foundation for improvement. We're going to get a gameplay test of these features to see if they're viable. Possible problems to be encountered will be made clear (though may of course be obsolete), for one thing. There is much to be gleaned from this, it just requires a bit of scientific thinking.

If someone wants to really do something of value, then follow mart3p's example; develop a feature, test it, debug it, update it for trunk, take advice, make it compatible style and code-wise, test it, test it again, and then celebrate when its in trunk.

For the most part I agree, actually. Its true that it is better practice to do one patch at a time. I can see this branches code getting irretrievably entangled with its own code, making it god-knows-how difficult to implement into a real patch.

It is just not realistic to think that anything that happens in a fork will have any bearing whatsoever on trunk. Only a branch has that possibility - a branch that is based on current trunk, is kept in sync, and doesnt wholesale reject the advances in OTTD over the last 3500 revisions.

I think better to say its not realistic to assume that nothing that happens in the fork will have any bearing on the trunk. I'm not talking about the relatedness of the fork's code to the trunk. It doesn't matter that the code obviously wont work first-second-or-third attempt at implementation into the trunk. This is about how to implement ideas into the game, whether they fit with the game. The code can be redone, its the idea thats important, and I for one want to see the ideas in action.

[iNVERTED]

Lots of pro-GRF words

I think I'll resort to quoting this:

If I understand the situation correctly, this is a project started, maintained and developed only by iNVERTED, so he may use the nightly rev / programming language / features he pleases without having to explain his choices ("properly" or not) to anyone.

Anyway, just because I'm using XDA doesn't mean you can't use GRFs as well. GRFs that worked with r5929 will also work with my fork. It's not like I'm going to disable using them. That would be silly.

The main advantage of XDA is its inbuilt ID system. Each key is given a unique ID. This is very useful for things like savegames, as if a feature isn't available in a certain program version it can be ignored, and if required data isn't present in the XDA file, this can be noticed and a default value given. This is certainly better than having to run totally separate code for every single minute difference in the savegame format.

Besides that, it would be much easier for "GRF" developers to simply save their image and load OTTD to test, without having to use grfcodec every single time they want to test.

What? Its hard to press [up][enter] before testing? This is news to me.

It's not hard to press up->enter, but you can't deny that it saves time.

[DaleStan]

The main advantage of XDA is its inbuilt ID system. Each key is given a unique ID. This is very useful for things like savegames, as if a feature isn't available in a certain program version it can be ignored, and if required data isn't present in the XDA file, this can be noticed and a default value given. This is certainly better than having to run totally separate code for every single minute difference in the savegame format.

And this has what to do with the price of tea in China?

(Also, stop conflating NFO and GRF. They are two completely separate entities.)

[Killer 11]

Well maybe he just wants to reinvent the bicycle....
If i were him i would just code a good tool to create GRF files instead of making a new format...