Being irritated at city store-fronts not facing the street, I delved into the code and have made a first attempt at supporting "Auto" rotation (rotation=254; 255 is used for random) just like building a house or attraction does.
github branch (https://github.com/jamespetts/simutrans-extended/compare/master...lindleyw:auto-factory-rotation?expand=1)
I am somewhat confused why so many subroutines, or "methods", are repeated rather than combined throughout the codebase. For example, tool_build_land_chain_t::work() and tool_build_factory_t::work() really differ only one calling factory_builder_t::build_link() which returns an integer count, and the other calling factory_builder_t::build_factory() which returns a fabrik_t*. Surely these should both call a single helper subroutine, but I'm not familiar enough with C++'s object system to know how to do that. That way I can code the "auto rotation" just once, as you'd expect. Also the mix of "factory" versus the German"fabrik" makes coding a constant little hassle.
Also, when building a factory, is_area_ok() in bauer/fabrikbauer.cc knows the location of the road adjoining the new factory or store-front, but it has no way to pass that along because is_area_ok() just returns a boolean. (I still cannot fathom why the English words t-r-u-e and f-a-l-s-e are used instead of 0 and 1 for Boolean variables.) How would I best go about storing the road orientation for use when we actually build the factory? It's bad practise, surely, to re-compute things like this.
This interesting - thank you, and certainly a worthwhile thing to do. I notice no changes to Makeobj; I have not done much with the building orientation code, which is at least mostly if not totally unchanged from Standard, so I am not sure whether there is a need for additional code to indicate which is the front rotation or whether this is already built in.
Also, I notice the following code from this branch which does not appear to have anything to do with building rotations:
const crossing_desc_t *crd = crossing_logic_t::get_crossing(wtyp, w->get_waytype(), 0, 0, welt->get_timeline_year_month());
if(crd!=NULL) {
// If existing way is water, then only allow building if desired way (presumably road) has max axle load of 0.
if ( (w->get_waytype() == water_wt) && (desc->get_axle_load() > 0)) {
return false;
}
It is not clear what is intended here - can you elaborate?
That would somehow assume a certain orientation as standard. Are you assume the same as city buildings?
And the different naming comes from automatic translation patches.
And finallz, I think this is useful for standard, and I could look into this. May I move this to extension requests?
Quote from: prissi on September 22, 2019, 02:27:00 PMThat would somehow assume a certain orientation as standard. Are you assume the same as city buildings?
Yes. With zero pointing at lower-left of your screen as per usual. No changes required to makeobj or anything.
Quote from: prissi on September 22, 2019, 02:27:00 PMI think this is useful for standard, and I could look into this. May I move this to extension requests?
Yes, please. I can code this into Standard first and then port back to Extended.
Quote from: jamespetts on September 22, 2019, 01:01:17 PMAlso, I notice the following code from this branch which does not appear to have anything to do with building rotations...
Ah, that was a simpler re-coding of the other thing I was working on, permitting bridleways to cross small streams, trying to make it general rather than so special-case, and eliminating the need to modify makeobj.
I have now moved this to extension requests as suggested by Prissi.
As to the other code relating to bridleways, I suggest that you remove it from this branch and add it to its own branch specifically for the bridleways feature; that should be discussed in its own thread, separate to this.
I'd like to mention the option of 8 rotations for single-tile factories, just as they exist for single-tile citybuildings - to enable corner stores ;D
To make full use of it, they would have to also support clusters and the res-ind-com distinction, such that a store in the style of terraced houses could cause a block of terraced residentials to spawn. (Both would have no influence on where the factory is placed, but would influence which citybuildings would spawn around them) Alas, that would be a seperate request, just worth mentioning.
Good point, Leartin. I wonder whether 1x1 city factories could be handled just like houses, and all other factories code mostly unchanged... hmmm