Transport Tycoon Forums

andythenorth wrote:

Leanden wrote:The game is released under a GPL licence, and evidentally development is somewhat stagnant. Why not make a full on branch which becomes a Trunk of its own.

Hasn't JGR effectively done this already?

As has Cirdan and his New Map Features?

Time for a little friendly level setting.
Today, the 17th day of the 9th month of the 2017th year of our Lord, I mark my 72nd year of existence. About 100 years ago (very approximate) somebody developed the infernally combustible engine. Old Nellie was effectively consigned to the glue factory. At approximately the same time, somebody developed a largely inefficient electrical engine for automobiles that seemingly soon abandoned the field to the more efficient infernally combustible engine. The electrical developers did not give up and today we see the rebirth of the electrical automobile, still a bit buggy, but orders of magnitude more efficient than when in it's original concept. So, what does this all have to do with backwards compatibility?
1. The vehicle remains true to it's original purpose: The elimination of the need for the frequent purchase of a new pair of shoes while retaining the added benefit of conveyance from point A to point B and back again.
2. If the battery on your Telus should expire before reaching the next convenient battery charging station, old Nellie is still available for hire to assist you in the completion of the transport of your Telus to that inconveniently remote convenient battery charging station.

Stay the course, Andy. Some of us actually see and appreciate the method to your madness.

P.S. No! I do not want a gift wrapped horse for my birthday, no matter the prettyness of the ribbon.

wallyweb wrote: P.S. No! I do not want a gift wrapped horse for my birthday, no matter the prettyness of the ribbon.

Probably some horse cookies?

congratulations
Michael

SimYouLater wrote:My conclusion is that I think the total backwards compatibility is no longer possible without killing this project.

The problem is not backward compatibility between trunk and NRT, the problem is the backward compatibility with oldNRT and newNRT, so if we put oldNRT in trunk we'll have a problem, currently there isn't a problem, don't make it so, and please stop talking of the infamous backward compatibility like it's a monster because it can be handled nicely as we found while working on some NRT features.

mean people wrote:...things I hope I wouldn't read again...

Also, we are not OTTD devs (me and andy), we got some help from the devs yes, it's not a secret, we do it for free, and we do it by discussing with devs, players and grf developers in a civil manner.
And even we would like NRT in trunk yesterday.

We do it with our timing, while we do other things, we are not crowfunded or paid in any other mean than greetings and thanks.

I think we made a mistake to present the feature we are working on to a demanding and greedy public, we could have kept it secret until done, but we needed feedback on the feature and instead we are receiving feedback on our work method: we aren't at school or at the workplace and we do what we need to do as we want to do it(period).

From now I'll only discuss about the patch features and how to develop them.

Feel free to bash me for this, I'm speaking for myself and not for the devs or even andy, but I think I'll ignore you all and continue my work as I feel to do.

To everyone that replied: You've all made very good points. As I said, there was a part of me I knew I shouldn't give up, no matter how much people told me to. Maybe the backwards compatibility is that for OpenTTD. Considering it could break patch packs, and to get back to NRT...

I do agree NRT's redesign of not just roads and trams but also rails is important. I have no coding skill in that field, and this is just my take...

Project 1: Tracktypes Redux
Redo Railtypes as a patch under that new system (catenary an extra type and railtypes with exponential increase), have people test it as they did NRT, and then when good enough, have it placed in a patch pack (JGR seems most popular, a JGR eXperimental branch is likely what people will pay attention to) to make it work.

If it is workable and will not hamper more than 20% of future additions with it's imperfection, it stays in. Otherwise, it is removed from the eXperimental branch and back to the drawing board. The new solution will be looked at by that same 80% to see which of the two was better, and if the old was better then a step back? Otherwise, judge the new and better one again by a 70% standard. If it doesn't meet that, rinse and repeat with -10% to the standards.

To ensure people don't complain, eXperimental will need that huge warning: DO NOT DOWNLOAD IF CONCERNED WITH SAVE GAME COMPATIBILITY!

Project 2: RoadTypes
Implement the above in NRT for roads, trams and road/tram catenary. Same set of steps.

[+] Spoiler

Project 3: "Layers"
Once the above is successful, add the "does not interact with other railtypes and road/tramtypes" feature. This might not need as strict of standards. It does mean considering if actual layers are needed instead of just non-interaction, and if "same layer as Xtype ABCD" is good enough.

Project 4: Underground (is not likely)
Another idea is "underground railtypes" which got discarded due to how crazy I tried to make it work. It won't be that simple as another hack. This will be a big project, you will need railtypes that automatically make vehicles translucent, a tunnel that goes "down into" the underground tracktype, underground stations, and the underground types not interacting with the surface at all (ignoring rails, roads, rivers, stations, buildings and even ocean). I say this knowing the requirements mean this will likely never see the light of day.

Project 5: Utilities (need a new approach)
Looking at my ideas for utility types, the hackiness of it is not what kills it (it doesn't help though). This isn't a game that ever supported pipelines or electricity or telecommunications. That is what killed it. OpenTTD is a game about logistics. Telecom and electricity are slightly out of what we would consider logistics, transporting something which isn't physical.

Pipelines would need a different approach to all other transport; the track itself is what carries the goods, and newer/more expensive pipeline would transport more at the same time, creating a constant flow with direction set by the "one-way signal" valves. A big project but not insanely huge. It should include the possibility of someone using it for electricity, telecom or even stranger things, so keep in mind that two-way utilitytype should remain easy to add by another project. Another is considering the retrofitting of the underground types above to utilitytypes, which will complicate things.

Project 6: One-way Tram Tracks (are doable)
One-way tram tracks. There will need to be a lot of interface changes, but it is possible and not hacky. I can provide an image of what I worked out if needed.

Project 7: Bridges (will always be imperfect)
Bridges need better implementation. The work needed is too large for that to happen. I think we'll need to look at bridges with a "what can we leave out to save work because it will never be able to do what we wish it would?" attitude. See Project 9.

Project 8: NewStops
Back to NRT. Once NRT is properly established, work on custom stops. That is not something I can properly estimate the work required, since I don't know how long it took to implement NewStations properly.

Project 9: Elevated Railtypes/Roadtypes/Tramtypes
Take this with a lot of grains of salt, I have no idea what the realities of this are!

[+] Spoiler

Bridges must stay and cannot be properly improved. I noticed the "Underground Metro" railtypes are good for tunnels in general for many situations. A non-hacky version of that for bridges...

Elevated is simpler than underground because it should interact with the surface. It might even be able to make better "bridges" without removing the originals. It is still a big project, no way for me to estimate how big. It could very well be too much.

Project 10: TTDPatch Features Project
NRT should notice that there are still a few features missing that were in TTD Patch, if I remember a comparison page correctly. Diagonal level crossings were one, track/road above tunnels was another. I think this was the page: https://wiki.openttd.org/Comparison_of_ ... h_features

If nothing else above, a project to implement the remaining missing features is needed. It should be compatible with the improved Railtypes, the Roadtypes and Tramtypes, etc. It's relevant towards the backend if not the outward appearance.

---

I'm sorry for the wall of text. This time I said as little as possible about each project, however keeping them separate to reduce feature creep lengthened the list. I used spoilers to hide the projects that didn't have much merit in my eyes compared to the work I knew would be needed.

@simyoulater, I'm unclear once again what your purpose is here. This is the NotRoadTypes thread...as far as I can tell you're now talking about something different. You seem to be replying to points that haven't been made.

I'm aiming to be completely civil here, but your posts frequently confuse me, and I don't know what they add.

andythenorth wrote:@simyoulater, I'm unclear once again what your purpose is here. This is the NotRoadTypes thread...as far as I can tell you're now talking about something different. You seem to be replying to points that haven't been made.

I'm aiming to be completely civil here, but your posts frequently confuse me, and I don't know what they add.

They're suggestions on how to keep NRT the proper size (to not include things outside the scope of NRT). I'm doing the best I can to be to the point, unfortunately it's still not quite good enough.

I'll answer a question, at least...

andythenorth wrote:

SimYouLater wrote:In an open source project it's hard to remember that time still equals money in many ways.

Can you expand? I can't follow this argument as it stands.

This is a volunteer project. Volunteers are spending time to work on it. Time that could be spent working for money. If not, that could be spent taking care of the people you care about. If not that, doing something you enjoy ranging from playing OpenTTD to going on vacation.

All those things you could be doing cost (or earn) money. They also give something (or take time) in return. If you go on vacation, you get a vacation. If you never go on vacation or enjoy anything, saving up for years, when are you going to spend it?

I hope the logic is clearer now.

So, been playing with NTR/RATT more, and I saw there was a new version that had been released recently.
I upgraded my game and I now are a rather large bug :
OpenTTD crashes when I try to close a game or load a save while already playing.
I can load or start a map fine, but trying to go back to the menu crashes OpenTTD, same thing for loading another save while playing.
I have a Windows 7 64 bits. I only have this version of OpenTTD running on that computer.

I looked in the log event, but as far as I'm concern, it's all Greek to me

[+] Spoiler

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2017-09-22T14:40:01.000000000Z" />
<EventRecordID>22022</EventRecordID>
<Channel>Application</Channel>
<Computer>Yu-Li-PC</Computer>
<Security />
</System>
- <EventData>
<Data>openttd.exe</Data>
<Data>1.8.0.27912</Data>
<Data>59af5b0a</Data>
<Data>ntdll.dll</Data>
<Data>6.1.7601.23714</Data>
<Data>58bf89e8</Data>
<Data>c0000374</Data>
<Data>00000000000bf3e2</Data>
<Data>540</Data>
<Data>01d333a89c37fbd7</Data>
<Data>E:\Logiciels\openttd\openttd.exe</Data>
<Data>C:\Windows\SYSTEM32\ntdll.dll</Data>
<Data>e995cc74-9fa3-11e7-b811-240a644acdd1</Data>
</EventData>
</Event>

Mmmh, I cannot reproduce these crashes.
The only crash I'm aware of is loading a savegame, I'm trying to figure out why does it happen...

Also a Window's event log entry isn't really that useful, the game has its own crash logs created in the game folder, so you could attach those.
A savegame and grf configuration would help too.

I can't see any log file, but maybe I simply look for a txt file when it's something else.
Or OpenTTD crashes too hard and doesn't have the time to record a log?
The issue I get is Windows displays a "OpenTTD stopped working" error.

For NewGRF, I have a hefly list of them. I dunno if it's possible to have a "list file?"
A few of those NewGRF aren't on Bananas.

When OpenTTD crashes normally it displays its own error/crash window that will allow you to save a crash.sav, but if OpenTTD crashes completely and violently it doesnt dump any crash data and shows the Windows error message instead "OpenTTD has stopped working" kind of stuff.

It's really cool to see someone finally interesting itself to road's world.

So, i had these road types in mind :

- Roman road : These would be allowed since year 1 (you can't start before). These would be allowing horses.
- Paved road : Appears in 1662, with vehicles based on the carrosses à cinq sols (first public transport system).
- Regular road : Appears in 1850, first with dirt roads then with tar, like for ARRS.
- Heavy-Haul road : Appears in 1937.
- Tramway : Appears in 1850.
- Electrified tramway : Appears in 1918.
- Cable-car : Appears in 1873. If it's possible to do it, the cable-cars wouldn't slow down on a slope unlike regular vehicles.
- Light Rail : Appears in 1990. Its vehicles are allowed on tram tracks, but trams can't go on his tracks. Light rail would have very fast vehicles.

I've got a question... Is NRT multi-core designed? Or it follows the single core design of most of trunk?

NRT is just a variation of trunk with an added feature, so it's the same as trunk.

BTW, trunk is multi-core in some of its features, like when you are saving the game (the short pause is when the entire map is copied before being sent to the saving routine) so you can continue to play the game while it's writing on disk.
The problem with multi-core is that as the game is structured you can't unbind the various parts because they need to be executed in a precise order and timing.
Maybe the UI could be moved in a different thread but this isn't the right place to discuss this.

Also, do you guys plan to make something like the NewStations GUI ? I mean, multiple bus / tram stops ?

acs121 wrote:Also, do you guys plan to make something like the NewStations GUI ? I mean, multiple bus / tram stops ?

This has been mentioned before, but this is beyond the scope of the project.

Actually, it's just that i don't like having stops from the 1970's in 1700 (i start my games very early). It would have been great to include stops for a specific generation. Also, i don't really like the lorry area graphics.

acs121 wrote:Actually, it's just that i don't like having stops from the 1970's in 1700 (i start my games very early). It would have been great to include stops for a specific generation. Also, i don't really like the lorry area graphics.

Unfortunately, there's (figuratively) no programmers to make it happen. This isn't a commercial project and due to Trunk losing most of it's maintenance staff the only truly active part of OpenTTD are the patch packs.

Well, there were programmers for Newstations GRFs, why not here ?

acs121 wrote:Well, there were programmers for Newstations GRFs, why not here ?

GRFs are an entirely different level of programming. The Newstations GRF is built on code that originated with TTDPatch (TTDP) which is NOT a patch of OpenTTD but it is a patch of Transport Tycoon Deluxe (TTD). OpenTTD is an open source clone of TTD that includes most (but not all) features of TTD and TTDP as well as some new features of its own. Most of the developers of OpenTTD are not the same folks that developed TTDP. NotRoadTypes (NRT) and New Map Features (NMF) are branches of OpenTTD but they are NOT OpenTTD. They were created to develop and introduce features that are not yet of interest to the developers of OpenTTD. These new features are too involved to be applied as simple OpenTTD patches.

If you read previous posts to this topic you will see that the original development of NRT, although workable, had to be abandoned due to some coding issues. Quite simply, it is obvious that the project was not yet sufficiently advanced to warrant work on other facets of road types such as bus stations and road stops. You will also notice that from previous posts, the NRT developers have decided to work behind the scenes at their own pace to resolve and produce a properly functional version of NRT without being distracted by a lot of questions. I'm sure your desire for NRT to have the capability of supporting a wider range of road stop/station GRFs has been noted. It is something that I as well would like to see, but I am also sure that this will not happen until the NRT devs have resolved the basic NRT feature to their satisfaction.

Patience grasshopper. All good things will come in their time, and then GRF creators will have the tools to work their magic.

wallyweb wrote:

acs121 wrote:Well, there were programmers for Newstations GRFs, why not here ?

GRFs are an entirely different level of programming. The Newstations GRF is built on code that originated with TTDPatch (TTDP) which is NOT a patch of OpenTTD but it is a patch of Transport Tycoon Deluxe (TTD). OpenTTD is an open source clone of TTD that includes most (but not all) features of TTD and TTDP as well as some new features of its own. Most of the developers of OpenTTD are not the same folks that developed TTDP. NotRoadTypes (NRT) and New Map Features (NMF) are branches of OpenTTD but they are NOT OpenTTD. They were created to develop and introduce features that are not yet of interest to the developers of OpenTTD. These new features are too involved to be applied as simple OpenTTD patches.

If you read previous posts to this topic you will see that the original development of NRT, although workable, had to be abandoned due to some coding issues. Quite simply, it is obvious that the project was not yet sufficiently advanced to warrant work on other facets of road types such as bus stations and road stops. You will also notice that from previous posts, the NRT developers have decided to work behind the scenes at their own pace to resolve and produce a properly functional version of NRT without being distracted by a lot of questions. I'm sure your desire for NRT to have the capability of supporting a wider range of road stop/station GRFs has been noted. It is something that I as well would like to see, but I am also sure that this will not happen until the NRT devs have resolved the basic NRT feature to their satisfaction.

Patience grasshopper. All good things will come in their time, and then GRF creators will have the tools to work their magic.

Actually, this is news to me. I was unsure if NRT was even still happening, it made too much progress to be outright abandoned, but then again...

I hope to see it by the end of 2018 then! NRT would solve so many problems with road graphics, right now I'm using a bootstrapped collection of NewGRFs with Wasteland (all vehicles disabled) and pretending I'm starting in 2518. I miss long games with horse-drawn carts, but then I never completed one because of road graphics glitches in the first place.