Version 2.0 - Look to the Future

[andythenorth]

We shouldn't need to make special/separate versions for either game.

We don't need to TTDPatch is a dead project. Just the information hasn't propogated everywhere yet

Welcome to the forums.

[FooBar]

Sad, Yes. But wasted effort? Not at all. At the very least it inspired OTTD!

Oh no, certainly not a wasted effort, not at all. Without it there probably wouldn't be an OpenTTD right now, but you arrived at that conclusion already yourself

BTW thanks for FIRS and the Tram Tracks.

You're welcome. FIRS, at least the current FIRS, is mostly the work of others though. Unfortunately I currently don't have enough time to be involved it that.

[Level Crossing]

While the devs state that there are good reasons that TTDP features (like custom bridgeheads) are not in OTTD, only one dev (Michi-cc) has actually bothered to actually comment in a thread that has working patches for custom bridgeheads (and multiple railtypes, etc.). (http://www.tt-forums.net/viewtopic.php?f=33&t=58420) And even he only 'took some very tiny peeks'.

Are the devs really that eager to include new features, especially since they (except one) have ignored someone who has done the work for them?

[andythenorth]

While the devs state that there are good reasons that TTDP features (like custom bridgeheads) are not in OTTD, only one dev (Michi-cc) has actually bothered to actually comment in a thread that....

You are an idiot. As you are dissatisfied with the service, someone will be sending you your money back.

[Rubidium]

What makes you, Level Crossing, think that the other developers have ignored the thread? Is there really a reason for half a dozen people to say roughly the same thing?

Furthermore it's, like so many patches, coming at a notoriously bad moment in the development cycle of OpenTTD. Just before branching the next stable branch meaning we're working hard on fixing all the regressions coming from other places, including tracing some desyncs which takes a lot of time. Not to mention fixing issues with extra zoom, 32bpp graphics and fixing up the tools so they support that as well (something people have been working on since the summer of 2004).

So the amount of things with a higher priority than some enormous patch which requires countless hours of reviewing was quite significant. You should be really happy that someone actually took a look at some of the patch. For what it's worth, I myself did look through it as well but did not find anything significantly different than what michi already stated. Furthermore the actual author thinks that it's not finished yet which means things might still need to drastically change.

Anyhow, please come back asking for custom bridge heads when they are in a stable release of TTDPatch. Otherwise, feel free to try any of OpenTTD's non-stable builds that contain custom bridge heads.

[Digitalfox]

Guys, please take a deep breath and stop this silly war of words, that no one wins a thing...

(This next part, obviously Devs and people with some knowledge of the development of OpenTTD, might as-well skip)

We are the RC (Release Candidate) moment, where the trunk is mostly paused just waiting for fixes...

So until the 1st of April, things will remain calm, even if there are people with new patches full of new features...

So let's give some time and will to the people in charge of OpenTTD, to have custom bridgeheads or not.

I'm not going to make me sound some like a expert in the source code of OpenTTD, cause I'm not, but things (features) that involve the map array tend to be very complex and time consuming...

Personally, I'm watching the topic with the work of cirdan and see where it goes
http://www.tt-forums.net/viewtopic.php? ... 0&start=20

[Level Crossing]

You are an idiot.

Starting with a comment like this makes it very hard to resist the urge to ignore the rest of your post. Considering that the rest of your post contains nothing about the actual topic, I wouldn't have missed much.

What makes you, Level Crossing, think that the other developers have ignored the thread? Is there really a reason for half a dozen people to say roughly the same thing?

Furthermore it's, like so many patches, coming at a notoriously bad moment in the development cycle of OpenTTD. Just before branching the next stable branch meaning we're working hard on fixing all the regressions coming from other places, including tracing some desyncs which takes a lot of time. Not to mention fixing issues with extra zoom, 32bpp graphics and fixing up the tools so they support that as well (something people have been working on since the summer of 2004).

So the amount of things with a higher priority than some enormous patch which requires countless hours of reviewing was quite significant. You should be really happy that someone actually took a look at some of the patch. For what it's worth, I myself did look through it as well but did not find anything significantly different than what michi already stated. Furthermore the actual author thinks that it's not finished yet which means things might still need to drastically change.

Anyhow, please come back asking for custom bridge heads when they are in a stable release of TTDPatch. Otherwise, feel free to try any of OpenTTD's non-stable builds that contain custom bridge heads.

Thank you. Unlike the poster above you, you have managed to calmly explain why the thread was only commented on by one dev, and say what is taking development priority at the moment. That said, I look forward to the feature eventually entering OTTD.

And tbh, I haven't seen one build of OTTD with custom bridgeheads in a while (except for a patch for some ancient revision). If you could point me to one, I'd be thankful.

[Alberth]

the 'new map features' thread in the development forum afaik

[Level Crossing]

the 'new map features' thread in the development forum afaik

That's the thread we were talking about just earlier, and, as Rubidium stated, it's not finished. By build, I meant binary, which the thread does not appear to have.

[Alberth]

Often someone builds a version and posts it in the same thread. So if a build[1] exists, it is there.
If it is not there, nobody has yet created a binary for it.

Looks like your chance to polish your compile skills


.. [1]: A public build, that is.




Edit: Added footnote

[Captain Rand]

Hi Guys!

Wow! I leave my PC for a day and come back to find I've stirred up a hornets nest

I should start by saying that I've been playing around with programming computers since I first got a Commodore Vic 20 (I recently saw one as an exhibit in London's Science Museum, that made me feel old! And I still have mine.)
I do know the difference between C++ and assembler. You would have known this if you'd read my first post properly-

Having done some programming myself, I'm fully aware that all of this may involve re-writing vast amounts of code. From what I've seen, I know the devs are up to the task.

Go and look, it's halfway down on page 19

Having got that out of the way....

Planetmaker, your English/Chinese book example is the perfect analogy....

You might try to rewrite a chapter in the other language

That's exactly what needs to be done, as Yexo says.....

Any "merging" would require rewriting the features TTDPatch has...........

Furthermore...

......rewriting the features TTDPatch has as patches for OpenTTD, which is what has been happening over time already.

Which is great, it means we're halfway there already. Chill's Patchpack even gets them all working together. So the next step is to get those patches into mainstream OTTD.
Yexo, I did read Rubidiums post, and he said...

in mainstream OpenTTD we only accept features that are sound, don't look like an utter hack and do not break something in ugly ways

Which is the right thing to do. We all want a stable game.

So the major reason for not having those things is: multiplayer;

Scroll back up to see my response.

In fact I've read all the replies I've had, carefully and repeatedly, as I wanted to be sure I wasn't misunderstanding anyone.
When I spoke of convergence, or fusion, or merging, I was referring to a merging of features. Clear now?
And (desperately trying to stay on topic), that is my suggestion for the goal to aim for in V2.0.

Pete.

[andythenorth]

that is my suggestion for the goal to aim for in V2.0.

You might consider making a table or side-by-side list of features from TTDP that you wish to see merged into OpenTTD. I'm sure this would be useful to those who agree with your suggestion for v2.0 and wish to work on it.

[Captain Rand]

Excellent idea.

Pete.

[ZxBiohazardZx]

Signals that will only let selected trains/train types through (Restrictive signalling)
Signals that change red/green state depending on various map state (Programmable signalling)
Non-straight and junction bridge heads (Custom Bridgeheads)
Selection of which disasters may or may not happen
Automatic creation of presignal setups
Configurable steam plumes for steam engines
Independent acceleration model settings for all motive power (unnecessary)
~25 different town growth controls

just some taken from the wiki that i honestly think might be nice to have....

[Tafidis]

Hi all,

Can someone please explain to me why "Custom Bridgeheads" is such a desirable feature? I mean (and correct me if I am wrong) this enables you to use the 1 tile on which is the entrance to the bridge as a normal tile, with junctions, signals etc? Aside from some really crowded situations where I can see this being useful, is it really that essential?

I, on the other hand, would like to see (for 2.0) a total rewrite of bridge/tunnel code so that we have:

a) New memory structure of tunnels/bridges. A memory pool has been suggested several times for this. I am not an expert coder, so I don't know if this is the best way.

b) EACH tile on tunnel/bridge is then a normal tile, which would make placing stations and signals possible

c) These would allow for rudimentary metros/elevated trains without making "full-3d" map array.

I know this is a major project and if my limited knowledge of C++ is useful in any way, I will help. I really think this tunnel/bridge wormhole is a part of OTTD code (inherited, agreed) that is an "ugly hack" as some devs would have put it.

Cheers

[FooBar]

Can someone please explain to me why "Custom Bridgeheads" is such a desirable feature?

Have a look at TTDPatch screenshots in the screenshot section. That should have plenty examples of why one would want custom bridgeheads.
Basically it allows for much nicer design of anything that uses bridges, often more efficient as well.

[icepl]

copy & paste in standard game

[YNM]

Sorry if this is already mentioned before, but I just want to suggesting what to be done to the next future v2.0 release :

1. Either CargoDist or YACD, or something more or less - alike
2. Custom Bridgeheads ? Bring me elevated way too ! (underground things isn't make sense graphically)
3. If you can, draggable tunnels. Having a tunnel enterance on a flat land

I know these aren't easy job... hope we can get there well !

[kamnet]

3. If you can, draggable tunnels. Having a tunnel enterance on a flat land

A tunnel entrance on flat land would be a sinkhole. Not something you want your vehicles driving into, I can assure you

[2457]

i would realy like..
-programmable signals. sure anything can be built with rail tracks/current signals/logic trains, but do i want to sacrifice map area for building such things? no. i would like programmable signals.
-signals on bridges, and in tunnels. no need to explain why.
-non-straigth bridges and tunnels. (and as a side effect, diagonal bridge/tunnel tiles.)
-diagonal roads
-copy paste bin. realy. I would absolute love it. repetative schemes building (like realy big stations, or junctions) would benefit a lot.
-multiplayer server filter, based on actual server settings. I do not like to play on servers with breakdowns enabled. have to join a lot of servers just to find out breakdowns are enabled, and acceleration model is set to original. I have to join a lot of servers one by one till i find one with the -for me- proper settings.

i never managed to understood how come so many signal types had been made, programmable signals would reduce this to 1.did not find a good reason eighter, probably has a good reason from dev side.Still, would be nice to know why it was not done. A patch did have this function but it did not get into trunk.
probably a GUI would be needed to store pre-programmed signals (so people can have an inventory of signals with functionality like pre-signal, block signal.)