Transport Tycoon Forums

No problem patching and compiling here (Ubuntu x86_64). Nice work!

I won't be able to do a test run until later this week, unfortunately. The previous version of this patch pack didn't crash on me though.

ColdIce wrote: I get errors when i try to compile

http://www.heypasteit.com/clip/J6I

I will have a looksie. I hope I can fix that for you.
Do you get the errors with the pach that Cadde has posted?
I have exluded some of the changes made by Cadde in the Programmable signals patch.
If you can compile that version I will put them back in.

Freak_NL wrote: No problem patching and compiling here (Ubuntu x86_64). Nice work!

I won't be able to do a test run until later this week, unfortunately. The previous version of this patch pack didn't crash on me though.

For me it compiles clean also.

Cadde`s patch compiled successfully, as any other previous patch.

maybe is something that VC++ 2008 doesn`t like. I got that problem before with a patch

ColdIce wrote: Cadde`s patch compiled successfully, as any other previous patch.

maybe is something that VC++ 2008 doesn`t like. I got that problem before with a patch

I had a quick browse through Cadde's patch.

Does making these changes, after applying v5, solve the problem for you?

- Outcomment line 14 in programmable_signals.h:
#include "string.h" <- This should fix the fatal error.

- Change line 171 in vehicle_base.h:
from "uint16 running_ticks" to "byte running ticks" <- This should fix the overflow warnings but instead you may see strange running costs with daylenght settings higher than 3. See a few post back or SpCombs thread.

Those are the most obvious causes to me.
If that does not do it I may have to dig a bit deeper.
Thank you for your time and effort in advance.

ChillCore wrote:from "uint16 running_ticks" to "byte running ticks" <- This should fix the overflow warnings

Huh?
You reduce the number of bits of a variable to reduce overflowing?
It seems to me you just moved the problem (at best).

Alberth wrote: Huh?
You reduce the number of bits of a variable to reduce overflowing?
It seems to me you just moved the problem (at best).

After having increased the variable to avoid the running_ticks overflowing and running costs being messed up from daylenght setting 4 and higher.
I do not have those warnings and when I looked them up in core/overflowsafe_type.hpp the running_ticks being higher seems the most obvious reason for the warnings to emerge.

I know the higher daylenght settings problem is not solved this way ...
I still have running_ticks at int16 and will look further for a better solution.

hmm.. now i get only 4 warnings

os_timer.cpp
openttd.cpp
network_udp.cpp
..\src\programmable_signals.cpp(112) : warning C4800: 'uint32' : forcing value to bool 'true' or 'false' (performance warning)
..\src\programmable_signals.cpp(466) : warning C4800: 'DoCommandFlag' : forcing value to bool 'true' or 'false' (performance warning)
..\src\programmable_signals.cpp(538) : warning C4800: 'DoCommandFlag' : forcing value to bool 'true' or 'false' (performance warning)
..\src\programmable_signals.cpp(657) : warning C4800: 'DoCommandFlag' : forcing value to bool 'true' or 'false' (performance warning)
network_server.cpp
network_gamelist.cpp
network_content.cpp
network_command.cpp
network_client.cpp
network.cpp


I`m gonna try to play the game. i`ll be back with information


LE: I can`t make prog signal to work. The window for settings doesnt pop-up. maybe i`m doing something wrong
the rest of the patches are working just fine.

ChillCore wrote:I still have running_ticks at int16 and will look further for a better solution.

Be aware that Vehicle::running_ticks is also part of the saveload data:

Coldice wrote: hmm.. now i get only 4 warnings

I will report those perfomance warnings you have left there to Owen and ask him what has to happen with "#include strings.h" in programmable_signals.h.
Outcommenting the line does not seem to make a difference. Also in Cadde's patch it is string.h while in Owen's original patch (and the patchpak) it is strings.h ...

ColdIce wrote: I can`t make prog signal to work. The window for settings doesnt pop-up. maybe i`m doing something wrong
the rest of the patches are working just fine.

I do not know if you did something wrong.
See attachment for how it should work, for me it does.

1. Click programmable signal
2. Place signal
3. click program button
4. click signal to program
-> Window should open.

SpComb wrote: Be aware that Vehicle::running_ticks is also part of the saveload data:

Code: Select all

src/saveload/vehicle_sl.cpp:             SLE_CONDVAR(Vehicle, running_ticks,         SLE_UINT8,                   88, SL_MAX_VERSION),

Cool, thank you for the info.
int16 was a typo, I have uint16 in my code.
Could it be that the overflow warnings came from not having changed it there also?
I will change it in my source.

Edit:
Updated the patch to v5_1. You can find it in the second post.

Removed strings.h from programmable_signals.h for some people to be able to compile.
Corrected a typo in vehicle_base.h: uint16 running ticks instead of int16. (I had changed it in my testfolder but not in the folder from where I pulled the patch. Oopsie)
I have also added the needed changes for running_ticks in saveload/vehicle_sl.cpp as mentioned by SpComb.

Could someone please compile with VC++ 2008 or Visual Studio to see if the overflow warnings in aircraft_cmd.cpp, roadveh_cmd.cpp, ship_cmd.cpp and train_cmd.cpp are gone or not? For me the patch compiles cleanly so it is a bit hard to know if my changes fixed it or not.

The performance warnings provided by ColdIce have been reported in the programmable signals thread.

Edit2: Added the patch for ColdIce's build below.

1. programmable signal problem - that was me. it works
2. the new patch compiled ok, only with those warnings.

here is the log http://www.heypasteit.com/clip/J6Z

not compatible with previous save games (r16599)

win32 build (flat_blacktiles.grf not included) READ THE POST BELOW

sorry for double post, but the last build has a problem

towns doesnt expand more that 7x7 tiles, not even in editor.

Thank you for reporting ColdIce.
Also thank you for the binary and the testing.

Quick testing with OpenTTD-1.0.1-RC1 shows that the problem is in trunk.
It will not allow to expand towns with road grids 2 * 2 and 3 * 3.
The original and the improved road grids do allow for expanding.

I tested only in the scenario editor.
I have not yet tested the latest nightly so I do not know if the problem is already reported and fixed or not...
Will try that in a bit.

The next version will be coming soon as I have fixed a the airport bug in the moreheightlevels patch and Owen has fixed the deleting signals and clicking on tiles without rail crashes.

Edit:
The same probem exist in yesterdays nightly.
Looking at Flyspray it does not seem to be reported yet.
I will try a few older versions and see if I can figure out when the bug was introduced.
Maybe it is time I get me a Flyspray account.

Edit2:
Fixed in r19683.
Thank you Smatz.

r19683 | smatz | 2010-04-20 17:49:11 +0000 (Tue, 20 Apr 2010) | 1 line

-Fix (r19654): towns with 3x3 and 2x2 road layouts couldn't expand



is there any chance to include the copy&paste patch?

ColdIce wrote: is there any chance to include the copy&paste patch?

It is included in my test build but I find it to easy to crash.
When clicking the button to open the gui or when trying to save templates crashes the game.
The gui opens with CTRL+v.
Maybe somewhere else it has problems too but I did not test it enough yet.

If you want you can patch the latest trunk version(not the 1.0.0 version) on top of the patchpack. There is only one conflict to solve in window.type.h. Maybe I will make it part of the patchpack after having tested it more.


I am currently testing the changes in the programmable signals patch.
If all goes as it should, I will port the changes form my test build to my patchpack folder and post the new diff.
I was having some issues with the signals gui after doing the changes made by Owen. I have solved those but have not yet tested the rest yet.

Copy & paste patch, revision 19692, works with chillcore patch pack r19599, but only if you download trunk r19600

ColdIce wrote: Copy & paste patch, revision 19692, works with chillcore patch pack r19599, but only if you download trunk r19600

Thanks for the info.

I have been testing v6 but there is still a few crashes with it when using copypaste.
Do you see these errors also with r19600?
- NOT_REACHED triggered at line 146 of copypaste/src/strings.cpp
-> trying to load an ?unloadable? old template.
- Assertion failed at line 53 of copypaste/src/core/pool_type.hpp: index < this->first_unused
-> old template loaded but failed to paste.

Saving and loading new templates seem to work fine.
I could ofcourse post v6 and tell people not to load old templates but it would be better if I could fix it first.

4>console.cpp
4>..\src\copy_paste.cpp(284) : warning C4805: '|' : unsafe mix of type 'bool' and type 'int' in operation
4>..\src\copy_paste.cpp(716) : warning C4258: 'tile' : definition from the for loop is ignored; the definition from the enclosing scope is used
4> ..\src\copy_paste.cpp(697) : definition of 'tile' ignored
4> ..\src\copy_paste.cpp(514) : definition of 'tile' used
4>command_queue.cpp

with r19600, but works just fine. no crashes untill now

ColdIce

any chance for the new binary?

wtfspiff wrote: ColdIce

any chance for the new binary?

May as well be a against a newer trunk revision then.
I am still testing a few things and adding some, there will be a newer version soon ...

Added:
Copy_paste: http://www.tt-forums.net/viewtopic.php? ... 59&start=0

Updated:
- Progsigs to r19677
- Moreheightlevels to v25_2_r19692
- Cargodist to r19733

Needed grf
- copypaste.grf in the data folder NOT in the newgrf folder
get it here: http://www.tt-forums.net/viewtopic.php?p=440743#p440743

New files:
In the src folder:
command_queue.h
command_queue.cpp
copy_paste.h
copy_patste_gui.cpp
copy_paste

in the docs folder:
copy_paste_array.txt



Copypaste has some issues.
First post will be updated with the next version.

Thank you ChillCore!

I was playing r 19600

I will come back with an edit to tell you if save game r19600 is compatible with this one. LE: NO. r19736 doesnt support r19600 save game

here is the WIN32 BUILD.
some warnings http://www.heypasteit.com/clip/JER