Yet another autoslope patch (in trunk since r11107)
Moderator: OpenTTD Developers
Re: Yet another autoslope patch (90 percent complete)
First post updated.
If you are experienced in newgrfs, please take a look at my remarks. Feel free to flame me, if I wrote wrong things (especially about TTDP's behaviour).
If you are experienced in newgrfs, please take a look at my remarks. Feel free to flame me, if I wrote wrong things (especially about TTDP's behaviour).
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Yet another autoslope patch (90 percent complete)
Nope. Changing the height is (or should be, at least) a valid behaviour. Consider something like a vineyard, which just shapes itself to whatever land it happens to be on.frosch wrote:1) The maximal tile height must not be changed. (I.e. things cannot fall down)
And all default industries allow terraforming.
I agree that 3C needs a little more information to be useful, but defining a feature-specific 60+x variable that is only useful in one callback is not the way to do it. I'd try mightily to pack the necessary information[0] into vars 10/18 instead.
Failing that, take 7B as a global variable, akin to vars 10/18, that provides parameterized information, relative to the current feature, callback, and, if necessary, the contents of the GRF registers. In any case, I see no reason to provide both an industry and an industry tile variable for the slope-to-be.
[0] I think x and y offset of the tile whose north corner is being modified, and direction of that modification (up/down) should be enough, but I haven't thought about it too particularly hard.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Yet another autoslope patch (90 percent complete)
That's good news. Waiting imaptiently for the last 30%... or perhaps it's 20%...frosch wrote:Well, thanks to Rubidium, about 70% are in trunk.
Re: Yet another autoslope patch (90 percent complete)
I know that TTDP behaves like this, but I do not like this behaviour. Property 0D 'land shape flags' is 0x10 by default for all tiles except the bank. This disallows construction of the industries on non-flat land. Why should autoslope be allowed to change the slope to a slope, where the industry cannot be build on?DaleStan wrote:And all default industries allow terraforming.
Alternatively I suggest a new entry in indtile prop. 12 'special flags', that restricts the cases the autoslope callback has to handle:
0x00: Do not check property 0D, but disallow steep slopes. (looks like current TTDP behaviour)
0x02: Check property 0D (independent of callback 2F usage). This implies denying of steep slopes.
0x04: Do not check property 0D, allow steep slopes.
0x06: Do not check property 0D, allow everything, even changing the maximal tile height.
By the way: I would really like to know the vinegrower, who allows me to raise his vineyard by 25 meters.
I like this one. During the autoslope-callback variable 7B+x would then be 'land info of nearby tiles after terraforming'.DaleStan wrote:take 7B as a global variable, akin to vars 10/18, that provides parameterized information, relative to the current feature, callback
I would suggest, that varaction type 89/9A decides if the position is given relative to the calling industry tile or relative to the industry origin.
That is not enough. The autoslope callback is called for every industrytile that is involved into the terraforming. In one terraforming operation multiple corners can change, but the callback is only called once for the final slope.DaleStan wrote:I think x and y offset of the tile whose north corner is being modified, and direction of that modification (up/down) should be enough
OTOH is x and y offset relative to the industry origin needed? Or is it enough, that the callback can be adjusted for every industrytile ID.
This would be a candidate for variables 10/18.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Yet another autoslope patch (90 percent complete)
OK, I misspecified. "The tile whose north corner the user explicitly modified."frosch wrote:That is not enough. The autoslope callback is called for every industrytile that is involved into the terraforming. In one terraforming operation multiple corners can change, but the callback is only called once for the final slope.DaleStan wrote:I think x and y offset of the tile whose north corner is being modified, and direction of that modification (up/down) should be enough
The modification direction (up/down), the general direction of the modification (N/NE/E/..., which can be gathered from the XY offset of that tile), and the current shape of the current tile seem like they ought to be sufficient to determine the final shape of the current tile.
Granted, some thought concerning what changes could be caused is required. This is:
(1) The callback wouldn't be being called if there wasn't some change,
(2) That change must include the corner of the current tile closest to the north corner of the explicitly-modified tile, and
(3) That change must be in the same up/down direction as the change to the north corner of the explicitly-modified tile.
Am I missing something here?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Yet another autoslope patch (90 percent complete)
Towns, industries and AI players can terraform all 4 corners of a tile at once.DaleStan wrote:Am I missing something here?
My patch disallows autoslope for those, but I do not know about TTDP. Perhaps it calls the callback multiple times in that case.
Apart from that: The changes of the slope should be easy accessible from the newgrf, without distinguishing a lot of cases (what was the slope before, which corner is modified, what would be the result of this...). Further I would like if the most common cases were covered by an Action0 property.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Yet another autoslope patch (90 percent complete)
That's very unlikely to happen. Not when there's already a callback that does the job.frosch wrote:Further I would like if the most common cases were covered by an Action0 property.
Properties can be replaced by callbacks, but I've never seen a callback get replaced by a property.
And how do you define "common cases"?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Yet another autoslope patch (90 percent complete)
The four cases in my post above.
If you want to allow changing the maximal height of the tile, you will need a Action0 property to stay compatible, don't you?
If you want to allow changing the maximal height of the tile, you will need a Action0 property to stay compatible, don't you?
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Yet another autoslope patch (90 percent complete)
Industries can terraform!?frosch wrote:Towns, industries and AI players can terraform all 4 corners of a tile at once.
I'm pretty sure TTDPatch disallows autoslope for AI players. In fact, it goes whole hog and disables buildonslopes. I've never seen a town use buildonslopes for a road either, so that's probably disabled too.
I don't follow. It is almost possible, if not absolutely possible, with some spec adjustment, to use only callbacks and no action 0 properties at all. I don't advocate this solution, but that doesn't make it any less possible.frosch wrote:If you want to allow changing the maximal height of the tile, you will need a Action0 property to stay compatible, don't you?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Yet another autoslope patch (90 percent complete)
(svn r11107) -Feature: some tool so one can still build tunnels under rails (and other structures) when the owner of the structure built it on foundations and if you have enough "empty" space ofcourse. One could use the tool for some other construction needs too. Patch by frosch.
haha(svn r11108) -Fix (r11107): somebody forgot to add some file Spoils the fun of the previous cryptic message though.
src/autoslope.h
nice, autoslope seems to be in trunk now.
*<(:-}
Re: Yet another autoslope patch (90 percent complete)
awesome, congrats to frosch!
*yaaaaaay* one thing less the patch guys can tease us for not having
*yaaaaaay* one thing less the patch guys can tease us for not having
- belugas
- OpenTTD Developer
- Posts: 1507
- Joined: 05 Apr 2005 01:48
- Location: Deep down the deepest blue
- Contact:
Re: Yet another autoslope patch (90 percent complete)
And one thing MORE we have to thank them for inventingRoujin wrote:awesome, congrats to frosch!
*yaaaaaay* one thing less the patch guys can tease us for not having
Wonderfull job frosch
Give us more!
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
Re: Yet another autoslope patch (90 percent complete)
Autoslope is in OpenTTD trunk? SWEET! OpenTTD is finally 'playable' .
Freakin' sweetness folks. It's sad, I know, that one minor feature lacking turned me off, but TTDPatch spoiled me .
Freakin' sweetness folks. It's sad, I know, that one minor feature lacking turned me off, but TTDPatch spoiled me .
Currently working under the name 'reldred' on Github, and Discord.
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
NFO/NML coder, part-time patch writer for JGRPP, and all round belligerent.
14:40 <orudge> I can't say I discriminate against any particular user
14:41 <Aegir> orudge: I can!
Re: Yet another autoslope patch (90 percent complete)
confirmed
Frosch:
What about enhanced tunnels or coustum bridge heads next?
Frosch:
What about enhanced tunnels or coustum bridge heads next?
Re: Yet another autoslope patch (90 percent complete)
And PBS?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Yet another autoslope patch (90 percent complete)
@7of9, Aegir:
Do not forget your roots.
My goal was never and will never be to directly copy a feature from TTDP. I have stressed my own brain and the brains of the discussion-participants on the first page, how autoslope should work. The autoslope patch differs in certain places from TTDP's behaviour, and only imitates it in places, where newgrf compatibility dictates it. On a code level they are not comparable at all.
Second I only code features, I want to play with, or which are fun to code. Neither of your suggested features belong in this category. If I would be better in assembler coding, I would also code for TTDP.
I am very impressed by the skills of the TTDP developers, and I do not like if you make fun of it. Especially if this interpretes my work in such a direction.
Sorry, I do not know if my english skills were sufficient to express myself, but I hope you got the point.
Do not forget your roots.
My goal was never and will never be to directly copy a feature from TTDP. I have stressed my own brain and the brains of the discussion-participants on the first page, how autoslope should work. The autoslope patch differs in certain places from TTDP's behaviour, and only imitates it in places, where newgrf compatibility dictates it. On a code level they are not comparable at all.
Second I only code features, I want to play with, or which are fun to code. Neither of your suggested features belong in this category. If I would be better in assembler coding, I would also code for TTDP.
I am very impressed by the skills of the TTDP developers, and I do not like if you make fun of it. Especially if this interpretes my work in such a direction.
Sorry, I do not know if my english skills were sufficient to express myself, but I hope you got the point.
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Yet another autoslope patch (90 percent complete)
I doubt you'll find any feature anywhere that is code-level comparable. Such things just don't happen with languages and objectives that are so vastly different.frosch wrote:The autoslope patch differs in certain places from TTDP's behaviour, and only imitates it in places, where newgrf compatibility dictates it. On a code level they are not comparable at all.
I think the point is that us Patch players have a few features that we have forgotten how to live without, and until they all appear in Open, we aren't going to like Open quite as well as we like Patch.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: Yet another autoslope patch (90 percent complete)
Another awesome feature in the trunk!
So now that you've gotten this done, what will happen to the horizontal/vertical foundations patch you were working on?
So now that you've gotten this done, what will happen to the horizontal/vertical foundations patch you were working on?
Re: Yet another autoslope patch (90 percent complete)
Well, since r11128 (again thanks Rubidium) the halftile-foundation-patch does no longer overlap with other patches, that are WIPs. But next weekend I am busy...Acerbus wrote:So now that you've gotten this done, what will happen to the horizontal/vertical foundations patch you were working on?
But because it is you: I have collected some screenies from my last savegames with that branch. They show your anti-zig-zag foundations in action
- Attachments
-
- Acerbus' anti-zig-zag-foundations in action
- halftile3.png (179.67 KiB) Viewed 817 times
⢇⡸⢸⠢⡇⡇⢎⡁⢎⡱⢸⡱⢸⣭⠀⢸⢜⢸⢸⣀⢸⣀⢸⣭⢸⡱⠀⢰⠭⡆⣫⠰⣉⢸⢸⠀⢰⠭⡆⡯⡆⢹⠁⠀⢐⠰⡁
Re: Yet another autoslope patch (in trunk since r11107)
looks nice
your contributions are really great frosch keep up the nice work
your contributions are really great frosch keep up the nice work
Who is online
Users browsing this forum: No registered users and 9 guests