actually rather: most settings except a few network and UI settings - those which do not influence how the game progress works once the map is started and left to run on its own (e.g. with AIs playing it).FooBar wrote:some (settings) are stored in the savegame rather than read from the config
Moderator: OpenTTD Developers
PM me if you have a patch for either of these that you want testing
running OTTD 1.0.0
If he hasn't figured it out by now, it's probably not needed any more.
Either way, the FAQ also has the answer
I have a little story to show what can go wrong. One game on a little map became my favourite, Tatminster Transport, it was called, on a tiny little temperate island. I played and played and played, and then trams came along, so I added the Serbian trams which I think were the only ones available at the time. Then I added the cantilever bridge renewal, those bridges are the only things I can't stand in the original graphics. Then I added a tiny GRF of my own, one tram taken from the Serbian set and made refittable.Alberth wrote:Nice idea, but how do you decide 'it works'? 'Not crashing' is not the same as 'working'.Jacko wrote:But: heres an idea, if you had saved before you did it, and it messed your whole game up, you can reload the save and not do the change, and if it works carry on regardless
In fact, a simple plain crash is quite rare. Much more often something very small gets corrupted, which you don't notice at first. As the game progresses, the bad data gets used, and affects other data, and so on, until you eventually notice something missing, or wrong.
That may however be a long time.
So far, everything looked[/i] okay. It wasn't. When I load a Tatminster save from that point in time now, I see ghost UFOs: UFO shadows sit around permanently in places where they once exploded. At the time I couldn't see that, so I added the UKRS too. I did this the right way, I scrapped every single train before adding the GRF, and built all new trains afterwards. Everything was fine for 20 years of gameplay. The ghost UFOs appeared after an upgrade of OpenTTD during this period. I didn't care much, other than taking it as evidence to stop adding GRFs.
Anyway, I mentioned the ghost UFOs in #openttd one time, probably just after they appeared, and one of the devs gave me a patch. He said "Apply this, load that game, and it will remove all invalid vehicles. Then load it with unpatched OpenTTD to actually play it." So I did. All seemed fine. Now, I go through phases. I play OTTD for a few months, and then don't for many months. I got my 20 game years of play in after using that patch, and stopped playing.
When I came back to the game, Tatminster Transport wouldn't load: "Broken savegame -- Referencing invalid vehicle." Ouch! I really wanted to play it. I went back and back through the saves looking for one that would load. I found one. Annoyingly it was from before I added UKRS, and surprisingly it showed the UFO ghosts which I previously hadn't seen until later in play. This is evidence that the save was damaged before I knew about it. I played on anyway, made a couple of saves, quit for the night. Next day, my new saves wouldn't load! Even though I can load some saves of that map, I can't play them because any further saves I make will be broken too. It's about as upsetting as a game gets, because I enjoyed Tatminster more than almost any other map I've played and I remember accomplishing a particularly tricky bit of track-work within it but can't remember the details.
I hope one day you'll remember how you solved your tracks problem. (The precise details are usually not that important, often there is just one key step that you made in your mind which is the valuable bit as it can be applied in other situations too.)
But noone as far as I can see it said why. And I think this is a really good question to ask, because systems which exist and have flaws should always be asked for why those flaws exist.
From what I understand the concept looks like this (Picture one shows the openttd base and the newgrf thats plugged into it, but not connected to the other newgrfs).
(Picture 2 shows the way from what I understand openttd handles the newgrfs)
The main question is stated in picture three where its asked why content could not be added into a running game (which makes no sense so far, its like as if f.e. in minecraft, once you have startet a world you couldnt add any content through mods? Or like in other games where modding is present... what would you think if you couldnt add any content in a running game? It just makes no sense to tell people that they have to start all over again once they want to have something new.
Removing maybe not necessary. but it is also a thing that a clean and good architecture can support. Other examples have proven this.
It could be at all that its just because I dont really understand how openttd is build up in reality, but what I'm almost sure of so far is that its fact that these problems with newGRF adding and removing them later is simply derived from a not so well thought on architecture.
I would be really interested in hearing everything about this
Also, excuse the sloppy ms paint grafics and mabye some weird way of talking, which is mainly because its really late.
- Picture one shows the openttd base and the newgrf thats plugged into it, but not connected to the other newgrfs
- Picture one.png (4.04 KiB) Viewed 9101 times
- Picture 2 shows the way from what I understand openttd handles the newgrfs
- Picture two.png (8.79 KiB) Viewed 9101 times
- Picture three.png
- (8.71 KiB) Downloaded 4 times
All the glitches, etc. Are solved when the respective NewGRF updates, which solved exactly the same problem on other OpenTTD with these settings off. Yay.
To note, i'm just actively adding things or updating things, and/or removing unneeded things that only full up the NewGRF slot.
Crashes... happens in the middle of the game, that re-loading the same save won't make it. The only s*** part (but then it's only one game...). The next major glitch now I notice is the game lags a lot while playing my latest game. Using an old built of cargodist (at the time of 1.2.0 beta 4 !)... and that haven't solved at all.
(Alberth, I'm not going to say this all is safe, it's like undervolting devices, which you never know the device limits, and its vary from one to another)
@Sonic TTD : you've to remember, apart of Alberth's point, that there's an interaction between a NewGRF and another... if the phone's off, then your call stops isn't ?
Essentially the reason you're advised not to do it is because a NewGRF has the potential to permanently alter the base configurations of the core game, and there is no dependable, reliable way to roll back those changes if you remove it. Much like in reality, once you have changed the world, there's no changing it back exactly the way it was before.
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | RoadTypes?
So this basically means that at the current state it could really be very hard to remove newGRF packages from a running game.The red and green blocks are not that nicely separated, the red stuff becomes part of the base, and its information gets spread throughout the green block.
But what about adding new? Can these already existing newGRF alter openttd's executions in such a way that new stuff won't get in anymore?
Whats happening when the game is loaded at first?
One weird thing that happened when I tried out adding newGRF in a running game with scenario_developer switch turned on, is this one: No matter which newGRF I add, the first thing I notice is that the option to build electrified rails disappears. Thats weird. But I would like to know how such a thing can happen in the first place. This rather seems to me like a weird architecture instead of logical results when the Idea is to let packages add content to the game.
/edit: Oh wait, I forgot. newGRF not only enables openttd to add content to the game, but even alter it. Could that be a rule which allows these results to be valid?
A little off-topic but for me pretty important: What really impresses me, is the multiplayer performance of the game even in large maps with many clients. Do you have a documentary about the networking architecture so that I could have a look into it?
Not only remove is tricky, any form of change is tricky.SonicTTD wrote:So this basically means that at the current state it could really be very hard to remove newGRF packages from a running game.The red and green blocks are not that nicely separated, the red stuff becomes part of the base, and its information gets spread throughout the green block.
- Updating a newgrf (eg to a new version) means that some of the red data is modified. What is not modified however are derived values (that is, values that are computed from the red data)
- Adding a newgrf may de-activate other newgrf or base data. As such 'adding' is equivalent to 'remove', even though they feel like totally different operations.
It means your idea of "add content" is wrong.SonicTTD wrote:One weird thing that happened when I tried out adding newGRF in a running game with scenario_developer switch turned on, is this one: No matter which newGRF I add, the first thing I notice is that the option to build electrified rails disappears. Thats weird. But I would like to know how such a thing can happen in the first place. This rather seems to me like a weird architecture instead of logical results when the Idea is to let packages add content to the game.
NewGRF is not about adding content, it gets assimilated into the base. There is no distinction between 'base' and 'addon' internally. As such the 'red' blocks don't exist, the base just grows a bit and soaks up the red blocks completely.
We considered making a better separation, but building a wall between base and newgrfs means that every access needs to go through that wall, which would kill performance (even today without wall, getting images from a newgrf is already a problem, see FS#4934). In addition, NewGRFs are so powerful that the effort would fail due to the incredible complexity, or you'd have to drop some NewGRF functionality. The latter of course means some NewGRFs don't work any more.
So, the only way out to get a robust/stable program was to drop the ability to change the world while playing. For some reason however, users refuse to accept that limit (unlike the zillion other limits that the program has), and abuse developer settings.
Indeed, your idea of 'add' is dead wrong. There is no 'add' or 'remove' or so. The best you can do is "change", and a change can cause basically anything.SonicTTD wrote:/edit: Oh wait, I forgot. newGRF not only enables openttd to add content to the game, but even alter it. Could that be a rule which allows these results to be valid?
There are no simple rules to decide whether some NewGRF change will fail or not. When you see it failing immediately is the lucky case. If things do seem to work at first, deep down you may have messed up some data that spreads slowly, and later in the game surfaces.
Basically, every machine computes the next state locally, so only speed of progress needs to be synchronized, and actions that are performed by the users have to be distributed to all clients. Afaik there is no documentation on it other than the source code.SonicTTD wrote:A little off-topic but for me pretty important: What really impresses me, is the multiplayer performance of the game even in large maps with many clients. Do you have a documentary about the networking architecture so that I could have a look into it?
Performing very good and being open to changes via the newGRF system (changes in terms of that you can add content and behavior to the game in the way its recommended now). The downside of it is simply that one can't change anything once a game is started.
So far, because this is the main reason I got involved in this stuff (changing newGRF after the start of a new game) at all is this one: I didn't know. And its sometimes frustrating to see that there are just one or two settings which you would like to have changed before the game was run, but didn't know about, because no one knows that newGRF packages AND settings can't be changed after start. Only way to find out is that all the buttons ui in the game is disabled after the start and then the next step is that you got into these forums or the wiki and find out that this is done by design.
So to stop this from happening (meaning players get into this so often, opening new threads with questions about this) what about having a message displayed in the game which gives a quick overview of the newGRF system once the user starts playing around with it (f.e. setting up newGRF packages and then starting a server or a singleplayer game)?
It could be like this:
"Welcome to the newGRF System.
This system enables everyone to select special packages which add content to the game, and this in a very optimized and well performing way. The only downside of it is that, after you've started a game with a set of newGRF packages selected, you won't be able to change the packages anymore (only if you start a new game with them). So please be cautios, try out anything new and look for all the settings before you really start a game which you want to take very long, just to be sure you will have an enjoyable play."
Mabye one button below with the Text: "Okay, I understood and will think twice before making a final selection. Thank you for telling me this before I run into hours of trouble. You are great OpenTTD-Devs. I love you."
What do you think about this?
I think that's sufficient proof people don't read windows or take them seriously. (Edit: People ignoring that window is the reason we took out the setting for users, it caused too many bogus crash reports.)
Adding another window thus won't work either.
Personally, I believe the only way to end these disucssions is to also take out the developer settings.
But you didn't understand what I mean.
The window I mean should be displayed as soon as people start actively using the newGRF system, not when they try to do something thats not so good, so that they know that they should make sure everything is as they want instead realising too late that they cant change it anymore.
Please really try again understand my Idea, because I really think that it is not such a bad idea considering making your players more happy in ways of keeping them from frustration
- This is what you see if you open openttd (like it is today)
- opening_screen.jpg (646.71 KiB) Viewed 9010 times
- This is what you see if you open up the newgrf settings dialog (even for the first time).
- current_first.jpg (425.14 KiB) Viewed 9010 times
- This is my idea which the user should be presented to _the_first_time_ a user open this dialog to become fully aware of what this system is about and which its limits are.
- future_first.jpg (427.77 KiB) Viewed 9010 times
The best way is to make the settings can't be changed from console at all, but people can still change them from .cfg file. (Try to scarry them away RIGHT here.) I believe that way, no loss done; the one who do it won't complain about such things as they're fully aware.
Users browsing this forum: Google [Bot] and 7 guests