The International Simutrans Forum

 

Author Topic: Bug: Player can DUPE vehicles  (Read 756 times)

0 Members and 1 Guest are viewing this topic.

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Bug: Player can DUPE vehicles
« on: August 17, 2018, 03:42:10 PM »
Certain vehicles can be manufactured for free. (´・ω・`)

An example of the procedure to reproduce:
1. Purchase BR-Class21 in the Railway depot(diesel)
2. Upgrade BR-Class21 to BR-Class29
3. Click the "Copy Convoy" button in the depot window

Then you got a duplicate of BR-Class29 for free. :o
No matter how many you make it is free.
You can also use "Replace" instead of "Copy Convoy".

This can be done on all remodeled vehicles for which cost is not set.
Here are some examples. (I think this is not all.)
Code: [Select]
LMS-rebuilt-royal-scot
LNWR-renown
LNWR-8wheel-radial-brake-lav-front
LNWR-8wheel-radial-brake-lav-rear
LNWR-8wheel-radial-lav
LNWR-6wheel-lav
BR-Class485Front
BR-Class485Rear
EDIT: Note that I have not checked all vehicle, so there are other possibilities to exist.
« Last Edit: April 08, 2019, 12:33:09 PM by Ranran »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #1 on: March 10, 2019, 02:41:37 PM »
Thank you for your report - I infer that this is caused by not checking whether a vehicle marked as "available_only_as_upgrade=1" is present in a convoy to be copied: the proper behaviour would be to prohibit the copying of a convoy where any vehicle has this attribute.You will need to change the Japenese translation text of "Can't buy obsolete vehicles!" to something that applies also to vehicles available only as an upgrade.

I think that I have now fixed this for copying; can you describe in more detail how this might apply for replacing so that I can try to fix it there, too?

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2596
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #2 on: March 10, 2019, 03:01:48 PM »
Quote
Thank you for your report - I infer that this is caused by not checking whether a vehicle marked as "available_only_as_upgrade=1" is present in a convoy to be copied: the proper behaviour would be to prohibit the copying of a convoy where any vehicle has this attribute.You will need to change the Japenese translation text of "Can't buy obsolete vehicles!" to something that applies also to vehicles available only as an upgrade.
A better behaviour would be for it to automatically factor in the cheapest purchasable base vehicle cost when copying, and only fail if none is still available for purchase.

If the player can still buy a base vehicle and upgrade it then there is no reason they should not be able to copy the upgrade since they could effectively make clones of it but with a lot more micro involved.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #3 on: March 10, 2019, 03:10:26 PM »
Are there any non-trivial cases where it is possible and realistically likely to be desirable for players to wish to purchase a vehicle and immediately upgrade it? In such a case, one would anticipate that the better behaviour would be to allow purchasing the upgraded vehicle anew in the pakset.

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #4 on: March 10, 2019, 04:25:25 PM »
Thank you for working on this.

Since "Can not buy obsolete vehicles!" is a term of standard's, it seems that extended can not have different translations via simutranslator.
I think it is necessary to detach the translation text from standard once as suggested by Makie.


How to use Replace:
(1) Now I have 10 BR Class 09
(2) replace with BR Class 29 like this image
(3) All are exchanged for BR Class 29 for free, and you just get the money you sold BR Class 09  ;)


Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2596
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #5 on: March 10, 2019, 06:17:58 PM »
Quote
Are there any non-trivial cases where it is possible and realistically likely to be desirable for players to wish to purchase a vehicle and immediately upgrade it? In such a case, one would anticipate that the better behaviour would be to allow purchasing the upgraded vehicle anew in the pakset.
Convenience. One might want more convoys to service a line and so instead of assembling a new one, order a copy of an existing one which might contain upgraded vehicles.

Alternatively one could define a "copy type" for such vehicles. This is the vehicle type that is ordered when copying as a substitute, rather than ordering in an upgrade type. This would make much more logical sense without removing any convenience from the player.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #6 on: March 10, 2019, 10:49:09 PM »
Ranran - I am not able to reproduce this, since I am unable (by design) to upgrade a locomotive that is not marked as upgradable to the class 29 to the class 29. Can you explain how you were able to do this?

Dr. Supergood - a copy type is an interesting idea, although this sort of additional feature is a very long way down the queue of tasks.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2559
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Bug: Player can DUPE vehicles
« Reply #7 on: March 11, 2019, 07:15:16 AM »
Immediate upgrade might be interesting if one has several older vehicles stored in the depot, and wants to use those in cloned convoys

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #8 on: March 11, 2019, 09:04:21 AM »
Ahh, there certainly is a procedure to select BR Class 29, but it is viable.

(1) Select BR Class 21 for replacement vehicle
(2) Change to Upgrade mode
(3) Check "Show all" checkbox
(4) Now BR class C9 becomes selectable



If you buy a lot of inexpensive locomotives temporarily, you can get many BR Class 29 cheaply.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #9 on: March 11, 2019, 02:24:48 PM »
Do I understand correctly that this exploit requires the option to allow buying obsolete/out of production vehicles to be enabled?

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #10 on: March 11, 2019, 02:54:59 PM »
No, I don't think so.
It is possible if you own one BR Class 21.
Just replace BR Class 21 to BR Class 29 and replace another vehicle with BR Class 29 at the same time by using "Replace all in line" or "Replace all" option.
When BR Class 21 runs out, you can not DUPE BR Class 29 anymore, but you can replace all owned vehicles with BR Class 29 from one BR Class 21.

And this depends on the vehicle. If there are vehicles that can be manufactured in a year that can be upgrade it will not be affected by allow buying obsolete/out of production.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #11 on: March 12, 2019, 01:37:42 AM »
I see that the mechanism for this is potentially complex and may need a significant amount of work to fix. Given that vehicle replacement is due for an overhaul when the work on vehicle-maintenance branch resumes, I suspect that it might be more efficient to focus on getting to the point of being able to do that by dealing with the critical bugs, testing integrating the UI features that you have written, then starting the process of bringing that branch up to date and working on that again, trying to remember to incorporate a fix to this during those works.

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #12 on: April 08, 2019, 12:37:16 PM »
I think this is also a pakset balancing problem.
If cost is set to 0 (or nothing is set), the vehicle is considered to have no value and the resale value is 0.
If the value is properly set, you can recover a lot of expenses even if you sell it after upgrading. (e.g. BR class 31)

On the other hand, upgrading a vehicle that has been sufficiently exhausted and selling it immediately may allow you to collect more money.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #13 on: April 08, 2019, 09:12:43 PM »
It is an interesting question of what the cost of a vehicle that can never be bought new should be. Can anyone think of a sensible way of deciding this?

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #14 on: April 17, 2019, 04:43:23 PM »
It is an interesting question of what the cost of a vehicle that can never be bought new should be.
This issue is not limited to vehicle that can never be bought. This applies to all upgradable vehicles.
And after all I think this is a code base issue.


The problems are roughly divided into two cases.


As an example, suppose that the manufacturing cost of the vehicle is 10000.


1) If the upgraded car does not have cost setting, upgrading makes the vehicle worthless.
This case is only seen in the available_only_as_upgrade vehicle in 128.Britain-Ex.

The vehicle value (resale value) will change as follows.

The vehicle becomes worthless from the moment of upgrading.  ::'(
That way the player will suffer unfair disadvantages. The player may notice his stupid act when scrapping his upgrading vehicle. (´・ω・`)
(This is the issue I reported in my last post.)

(But on the other hand, it is possible to DUPE this free cost vehicle using replace as it is the original theme of this thread.)



2) If the upgraded car has cost setting, it is a hotbed of cheating.
This applies to all upgradable vehicles.
As an example, suppose that the value(cost) of 12000 is set to the upgraded vehicle.

2a


2b


Regardless of when you upgrade or what value is set for upgrade cost, upgraded vehicle will be the value set for cost.
Upgrading timing can be arbitrarily delayed. Please check the above two graphs. Even though the total cost paid is the same, the value of the 15th year is different.
There should be various upgrading from small remodeling to big remodeling. So it's not always correct that a remodeled vehicle has lower value than the original vehicle.

One of the current issues is that it will be considered as new immediately after upgrading.

For example, a push-pull steam locomotive can greatly help this cheating.  ::-\
Please use steam locomotive which can be upgrade to push-pull for a long time without upgrading. When it reaches the end of its life, if it is no longer needed, converting it into a push-pull and selling it immediately will return more cost than purchasing it, it is taken with a little upgrading cost though. Oh, yeah, it was as if it was a free rental fee. (´・ω・`)錬金術師らんらんよー


Well, after all, either pattern can be used to cheating. (´・ω・`)

Quote
Can anyone think of a sensible way of deciding this?
Here is my idea for consistency without making major changes:

- Change the code to take over the manufacturing date when upgrading. That is, upgrading never changes the year the vehicle was born.
- Describe the asset value when the vehicle is new in the dat file. For example, the value to be described there is the manufacturing cost + upgrade cost.


The transition of vehicle value is as follows:



For example, if it is manufactured and upgraded immediately, it has an asset value of 12000.
If upgraded after 15 years of manufacturing it has only 7000 asset values at that time.
The value decreases with age. Upgrading does not fully restore its value, but will increase the value somewhat.

It doesn't matter what age vehicle can upgrading. Only the year in which the vehicle was born is relevant.
Because the year of birth and the year of upgrading is changed by the action of the player. It doesn't always go according to historical facts.


I think this will prevent players from cheating. :police:
« Last Edit: April 17, 2019, 05:01:43 PM by Ranran »

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #15 on: April 18, 2019, 03:44:09 PM »
Quote
Here is my idea for consistency without making major changes:

- Change the code to take over the manufacturing date when upgrading. That is, upgrading never changes the year the vehicle was born.
- Describe the asset value when the vehicle is new in the dat file. For example, the value to be described there is the manufacturing cost + upgrade cost.
Based on my last post, I made a testing patch to take over the vehicle manufacturing date at the time of upgrading.

https://github.com/Ranran-the-JuicyPork/simutrans-extended/commits/takeover-the-manufacturing-date
Please check carefully.

Replace bool upgrade with build_date and judge it upgrade when passed the build_date value.

This patch makes the vehicle honest and teaches you the correct age, unlike a adult woman on first meeting. (´・ω・`)
There is no need to complain about her age of the appearance anymore, as the value is declining. In the west side of Japan you can still see many very old trains. They are often changing parts and changing appearance. It will probably be able to simulate it correctly.


:warning: Remember that it is necessary to re-set "value" correctly in dat for vehicles that only appear by upgrading.
It would be worthwhile to eradicate worthless vehicles except in the case of simulating divisions divided by different goods categories such like 0 length.

For instance:

6 months ago, this company bought a lot of BR class 21.
3 months ago, this company upgraded all BR class 21 to BR class 29.
2 months ago, this company lost a lot of credit. Because BR 29 has no asset value. (As an aside, upgrade will not reflect assets changes until next month)
1 months ago, this company sold all BR class 29.
Now, this company just lost money and credit.
(´・ω・`)THE END

Players will suffer such disadvantages without noticing. Bless them.(´・ω・`)

While this patch does not prevent player from using the replace method to create upgraded vehicles in an unauthorized way, it does prevent them from being replaced for free with high performance vehicles if they have the right cost.


I suppose this code may also help at the time as it seems to plan to buy and sell used vehicles between players.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18425
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Bug: Player can DUPE vehicles
« Reply #16 on: April 18, 2019, 03:58:10 PM »
Thank you for this. One of the reasons that I have not looked into this in too much detail is because this overlaps somewhat with a substantial planned featureset on which work was started at the beginning of 2018 (on this branch) before being suspended to deal with critical bugs. I am planning to resume this work fairly soon, critical bug reports permitting, so changes of this sort need to be fully compatible with the plans for this branch.

May I ask - are you familiar with the work relating to that featureset? If not, I can point you to the threads discussing it. It has not been worked on for quite a while now, and the branch will be stale and will need some significant work to bring it up to date with the current master, but this set of features is quite a high priority for balancing work.

Offline Ranran jp

  • *
  • Posts: 353
  • Languages: ja
Re: Bug: Player can DUPE vehicles
« Reply #17 on: April 18, 2019, 11:33:34 PM »
IMO, the hole of the specification described above has been a fatal effect on the game balance. Especially in multiplayer games.
You can only ask participants to stop using it unless the pakset creator stops the upgrade feature. There is no choice but to leave it to their conscience. If possible, this problem should be resolved. :police:


this overlaps somewhat with a substantial planned featureset
Is it about overhauling that you think this patch is overlapping?

I think this patch is the foundation rather than overlapping.
Although we may implement this earlier or at the same time, I do not recommend doing this later, as it is the foundation.

Because in the real world, manufactured date of a vehicle has meaning, and just because it has been remodeled or overhauled, it will not erase the data of its manufacturing date.
That is, the data on when the last overhaul was done should be divided into separate fields and recorded.
And as I explained so far, the date of manufacture should be kept as a source of asset value judgment. It should not be rewritten at least after every upgrade or overhaul.
Is it possible that the overhaul system will cause problems if the day the vehicle is born is recorded?


Quote
so changes of this sort need to be fully compatible with the plans for this branch.
I just changed the passing of variables between functions, and the data structure recorded has not changed at all.
Currently, since the date on which the upgraded vehicle was upgraded is recorded as the date of manufacturing, it has been changed to record the date of manufacturing.
(As a result, there is no possibility that the asset value of the vehicle will be recovered illegally because the value is subtracted by age. It is the intent of this patch.)

And the upgraded date is data that is not useful except for displaying as a record and it is currently working as a hotbed of cheating. This may or may not exist.
In my patch, the data of the upgrading date disappears because that field was unified to the manufacturing date.
If that data is needed I think it should be added newly, but that would just be an addition ON the foundation.
Therefore, whether it is necessary to display the upgrade date may be the agenda of that branch, but If we could not find a smarter solution using it I think it is irrelevant to this issue.


Quote
are you familiar with the work relating to that featureset? If not, I can point you to the threads discussing it.
I think that is a fascinating feature. But I may be misunderstanding what is overlapping. In that case, it will be helpful if you can point it out.  :-[
Mechanical translation such as Google translate is good at translating German to English, but it is very pooooor at translating English into Japanese. (´・ω・`)