Recent posts

#1

Other paksets / Re: pak72.Elegance half height...

Last post by _Hajo_ - Today at 01:14:22 PM

A lot of features have been added to Simutrans while I was away. I must admit I don't know about road signs at all. I'll check the wiki and other pak sets to learn about them.

I think you can borrow some content from pak64 directly. The size difference is not that big.

#2

Simutrans-Extended major projects / Re: Schedule features: technic...

Last post by jamespetts - Yesterday at 11:37:11 PM

I have been spending some time working on this over the last few days, and have committed the results to the ex-15 branch. The basic code for consist orders is now implemented (albeit the dividing/joining code is not yet fully implemented; some elements of the joining code have been implemented; the simple type of consist order in which a consist will take vehicles from laid over consists waiting at the same stop is what is implemented so far) and what I have tested of it so far is working. I have successfully separated a locomotive from a rake of carriages, left the carriages at the station in its own newly created consist, set to be laid over, and had the locomotive continue to the next station.

The UI issues mean that I have not yet been able to test this fully yet, although they have had the benefit of allowing me to test some significant edge cases and adapt the code to deal with those edge cases (e.g., a specified consist containing no powered vehicles, a specified consist containing only one vehicle when the previous consist contained 7, etc.).

One thing that I have realised during this implementation process is that it may well not be feasible to implement the priority rules. The data structure for these is below to remind us of what was intended for them.

Code Select Expand

/*
* These rules define which of available
* vehicles are to be preferred, and do
* not affect what vehicles will be selected
* if <=1 vehicles matching the above rules
* are available
*
* The order of the priorities can be customised
* by changing the position of each of the preferences
* in the array. The default order is that in which
* the elements are arranged above.
*
* + Where the vehicle is a goods carrying vehicle: otherwise, this is ignored
*
* NOTE: This feature is currently unimplemented. This seems to conflict with the
* priority order of vehicle description elements in the consist order elements.
* It is hard to imagine how this might be implemented.
* Query whether this should be removed.
*/

enum rule_flag
{
prefer_high_capacity = (1u << 0),
prefer_high_power = (1u << 1),
prefer_high_tractive_effort = (1u << 2),
prefer_high_brake_force = (1u << 3),
prefer_high_speed = (1u << 4),
prefer_high_running_cost = (1u << 5),
prefer_high_fixed_cost = (1u << 6),
prefer_high_fuel_consumption = (1u << 7),
prefer_high_driver_numbers = (1u << 8),
prefer_high_staff_hundredths = (1u << 9),
prefer_low_capacity = (1u << 10),
prefer_low_power = (1u << 11),
prefer_low_tractive_effort = (1u << 12),
prefer_low_brake_force = (1u << 13),
prefer_low_speed = (1u << 14),
prefer_low_running_cost = (1u << 15),
prefer_low_fixed_cost = (1u << 16),
prefer_low_fuel_consumption = (1u << 17),
prefer_low_driver_numbers = (1u << 18),
prefer_low_staff_hundredths = (1u << 19)
};

static const uint8 max_rule_flags = 20u;

uint32 rule_flags[max_rule_flags]
{ prefer_high_capacity,
prefer_high_power,
prefer_high_tractive_effort,
prefer_high_speed,
prefer_high_running_cost,
prefer_high_fixed_cost,
prefer_high_fuel_consumption,
prefer_high_driver_numbers,
prefer_high_staff_hundredths,
prefer_low_capacity,
prefer_low_power,
prefer_low_tractive_effort,
prefer_low_speed,
prefer_low_running_cost,
prefer_low_fixed_cost,
prefer_low_fuel_consumption,
prefer_low_driver_numbers,
prefer_low_staff_hundredths
};

The difficulty at present is that this clashes with the current priority system, which is to treat each vehicle description in each consist order element as being ranked in order of priority. This was complex enough to implement in code, but I cannot at present see any way of making a large number of priority rules work. I will leave the data structures in for the present in case either I come up with a sensible way of doing this, or anyone else would like to implement this in the future.

For the present, therefore, we do not need a UI for priority rules.

One other small feature that I have added is the ability to mothball vehicles. This is partly implemented in that the simulation aspect of this is implemented (but not tested), but the UI aspect is not yet implemented, meaning that it has not been possible to test this. The idea is that vehicles that are mothballed cease to incur the monthly fixed maintenance cost, but it costs 1 month's worth of fixed maintenance cost to mothball a vehicle and a further 1 month's worth of fixed maintenance cost to unmothball it. The intention is that it should only be possible to mothball vehicles in a depot and that are not part of a convoy/consist, albeit this needs to be enforced via the UI.

I have also added a simuconf.tab setting for the time taken to shunt vehicles in accordance with a consist order, being the shunting_time_seconds setting. The default is 60 seconds, but Pak128.Britain-Ex is set to 120 seconds, to match the non-turntable hauled reverse timing.

The next step is to see whether I can effect a temporary fix of the UI so that I can test a wider range of consist order operations, including the main goal of the initial stage of work on this feature, which is to effect a locomotive change.

#3

Simutrans-Extended bug reports / Re: Road vehicles do not respe...

Last post by [C] Ranran - Yesterday at 06:33:43 PM

This is not broken as of January 10th (#8f8bce1), but is reproducible in the latest version.


I wonder if this change is involved.
https://github.com/jamespetts/simutrans-extended/commit/12b15d3f41a4916211f1401672dd8ea6af711612

[EDIT:]

#4

Simutrans-Extended development / Re: Replacement of mail coache...

Last post by [C] Ranran - Yesterday at 05:20:32 PM

That's a good point.


From a code perspective, the two dialogs share the same display behavior, but differ in their execution behavior. Because the depot dialog will purchase the vehicle when you select it, while the replace dialog is in the planning stage and will not purchase the vehicle. So adding a vehicle in the dialog is done in different code. I suppose this inconsistency is caused by the coder neglecting to add automatic connection handling to the replace dialog.
However, extended is often based on existing specifications in standard, so it can be difficult to provide precise support for extended additions. Sometimes it takes a lot of effort.

I checked it and found another omission.
The replace dialog does not show changes in station tiles when trying to deselect.
This also happens because the depot dialog and replace dialog are handled differently.

Would it be a lot of work to make the replacement window work similarly to the depot window?

As already mentioned we need to add the code for the replace dialog separately from the depot dialog, but unfortunately this was easy. I have fixed them.

Since the station tile count and vehicle count changes are based on the depot dialog behavior, the replace dialog behavior is inconsistent (deceive the player) with this and players will definitely see it as a bug.

This is a bug fix for depot/replace dialog, so it's included in PR#601. Please confirm.

EDIT:
The one for ex-15 is the ex15-sortable2 branch.

#5

Español (Spanish) / Re: Archivo del foro y addons

Last post by Yona-TYT - January 28, 2023, 11:23:21 PM

Hace años ocurrió un inconveniente donde se perdieron todos los archivos adjuntos del foro, hasta donde se nunca se pudieron ser recuperados.

#6

Español (Spanish) / Archivo del foro y addons

Last post by ivan - January 28, 2023, 09:51:30 PM

Hola a todos, alguien por aquí? jajaja existe aun algun lugar con los addons y archivos qué aquí figuraban? Saludos.

#7

Simutrans-Extended bug reports / Re: Trains entirely ignoring s...

Last post by jamespetts - January 28, 2023, 08:18:49 PM

For the past month or so, builds from latest source all result in trains utterly ignoring signals and every train on the map crashing into each other. This occurs in fresh new games (1850 start, for example) as well as all my old saved games.  I have been building signalled lines for many years; did something fundamental change about how we have to signal lines, or is the codebase broken? Very discouraging.

I cannot reproduce this, I am afraid: using the demo.sve saved game, signals work correctly. Can I check whether you have tested with the downloaded binaries or whether you are self-compiling?

#8

Simutrans-Extended bug reports / Road vehicles do not respect u...

Last post by Junna - January 28, 2023, 05:06:58 PM

Within urban areas, vehicles currently drive at maximum speeds, not respecting the local urban speed limits.

#9

Simutrans-Extended bug reports / Trains entirely ignoring signa...

Last post by wlindley - January 28, 2023, 03:14:37 PM

For the past month or so, builds from latest source all result in trains utterly ignoring signals and every train on the map crashing into each other. This occurs in fresh new games (1850 start, for example) as well as all my old saved games.  I have been building signalled lines for many years; did something fundamental change about how we have to signal lines, or is the codebase broken? Very discouraging.

#10

Other paksets / Re: pak72.Elegance half height...

Last post by Isaac Eiland-Hall - January 27, 2023, 01:45:35 PM

So I definitely miss road signs and fences so far. lol.



Are they on the (pardon the pun) road map, by any chance? I would assume they'd be very low priority. And I guess the only downside to the pak's size is I can't even steal them from another pak without remembering how to make paks and getting graphical. lol.

I may have to do just that, though, since apparently I've decided to play this pak for now