Suggestion:Not sure if it is at all possible (if not please ignore this )

I often like to make minute changes to other GRFs, replacing just certain graphics and keeping the rest as is. (for example I have edited the UK-roadset in my games in such a way that it displays sidewalks also on rural roads)Now I do this by recompiling the edited GRF, just with a change to the original name and keeping the same GRF-ID, so I can easily find it in my unused GRF-list next to its original version and it will also not disrupt my save-games or scenarios.

However, in some cases depending on the license of the GRF, these kind of changes are not allowed to be publically released and one needs to contact the original creator(s) of the GRF and donate these sprites, hoping they will be implimented (or implimented as extra option via parameter). This process can take up some time as some creators cant be contacted easily or dont want to make the changes to their GRF.An example I could give for this is with one of my own sets, the Fake Airport Objects. For the taxiways I use yellow lines, some people suggested that they would like these lines to be thinner/sharper. I dont agree Therefor I wont impliment this (not even as a parameter, I really dont like the look of it ). The set is GPL licensed though, so someone else could make these changes and re-release the set, but if they dont add it as a parameter they will need to release it as a completely separate set, including also graphics that havent been changed. But hopefully that wont be necessary anymore if my suggestion is feasible....

Therefor I would like to know if it is possible to have an option to change graphics within a GRF, working a bit like Action-5 in NFO for replacing base set sprites not present in the original TTD.For example, by combining the unique GRF-ID of a GRF with an offset to the graphics within it that you want to change.

Bounding boxes are mostly a myth. While there is a thing called "bounding boxes" in the game, I am 99% sure whoever hinted towards them did not know how bounding boxes work, and bounding boxes won't help fix your issues.The purpose of bounding boxes is to sort sprites within a tile. But in case of NewObjects there is only one thing on the tile (your object), so there is not much to sort. People often think they can use bounding boxes to sort stuff against stuff on neighbouring tiles, however bounding boxes have hardly any influence on that. (mostly because bounding boxes only affect "how" to draw, but not "what" to draw)

Regarding bounding boxes:For NewObjects the only part you may possibly want to adjust is "zextent" in the "building" part of your "spritelayout".Set it to approximately reflect the height of your object. That helps in case of bridges next to your object.

Regarding glitches:You need to distinguish two types of glitches:* Glitches because sprites change the order they are drawn in. ("how" to draw)* Glitches because sprites are skipped, and not drawn at all. ("what" to draw)

Bounding boxes help in the first case, but not in the second.The most often glitch I see is the second case, when sprites extent over the left or right corner of the tile. In that case you have to cut the object more precisely. (Changing bounding boxes does not affect this, because this is an issue about "what" to draw, and bounding boxes have no influence on that)

if you want to check your bounding boxes, you can enable newgrf developer tools in the console, and then press Ctrl+B ingame to have the game display them.

what you want to do is have your bounding box roughly the size of the object you draw, but avoid having two bounding boxes overlap (touch is usually fine, although there are some exceptions). that means, sometimes you can avoid glitches by making the bounding box smaller, instead of larger.

the game handles overlapping bounding boxes very poorly (and also, there is no good way to handle it. fixing it for one case will break it for other cases)

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

Hello!How can I check in NML whether the leading vehicle in the train is engine or not?I'm using some switches with PARENT argument to determine wagons appearance. But they generates some glitches when the train is waiting in the depot without engine. In this case variable date_of_last_service for the first vehicle (wagon) returns undefined value.Is it posible to check engine-specific variable (for example: power) to determine vehicle type?

Hello!How can I check in NML whether the leading vehicle in the train is engine or not?I'm using some switches with PARENT argument to determine wagons appearance. But they generates some glitches when the train is waiting in the depot without engine. In this case variable date_of_last_service for the first vehicle (wagon) returns undefined value.Is it posible to check engine-specific variable (for example: power) to determine vehicle type?

I think you have 4 options, based on needs, requirements and future plans:1: You could check for vehicle_is_potentially_powered, if I read the spec right it should return false if the leading vehicle cannot deliver power, which defines a wagon. I'm not sure what would happen if you also use the power callback and that returns 0 in some cases for engines.2: You check for a range of vehicle IDs, just like I do in the 2cc TrainsInNML to check if wagons can be attached to a train. The check itself has no potential side effects, as it only depends on one value that does not change unless you change it. Downside is that it would break compatibility if you already released your work and the ID grouping has not yet been implemented.3: Define livery overrides for the wagons on the engines. This only makes sense if the wagons should normally not be used separately of engines and the properties depend on the engine that is in front of them.4: Check for vehicle_is_in_depot and show some default graphics if that is the case.

You could check for vehicle_is_potentially_powered, if I read the spec right it should return false if the leading vehicle cannot deliver power, which defines a wagon. I'm not sure what would happen if you also use the power callback and that returns 0 in some cases for engines.

Thank you, Transportman! I hope that vehicle_is_potentially_powered will be good way for better research. Other methods looks like less usefull, because I have too many loco's and wagon's combinations in my set to prepare all livery overrides or to check all dependencies ID by ID (my engines are not grouped in the way easy to do it).

The "only" problem is that the animation is incredibly fast and kinda glitchy, which I would've thought according to https://newgrf-specs.tt-wiki.net/wiki/N ... tion_speed it shouldn't be. But playing around with values and trying some different things didn't really get me anywhere. Didn't find much in the documentation about animation either :/

So as usual I don't really know what I'm doing here. I'd appreciate if someone could point me in the right direction

edit: &$/$( Figured it out. Should have looked at OpenGFX landscapes first, but forgot it had an animated wind power thing. So I did the frames like that:

OBJ_BUILT had the fun effect of updating all parking lots whenever a new parking lot was built if I remember that right. Not exactly what I wanted in this case but who knows, might make sense for some obscure object of some kind (a counter-object ^^).

So I'm trying to change a few properties based on chosen parameter settings (properties for which there are no callbacks), and instead of defining all-new items I tried using some kind of nested ternary operators, like so:

Well, I wasn't sure because I've never seen or done anything like this before; I've always defined all properties explicitly except for callbacks. After reading a post about how ternary operators should be avoided I thought there might be some fault with it, so I wanted to make sure.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum