Bjarni opened the ticket and wrote:

this is a test newgrf bug report. Just checking if newGRF is set up correctly

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/4

bociusz opened the ticket and wrote:

MSVC projectfile & documentation update

1. Removed lithuanian.lng from the MSVC6 & MSVC.NET
   projectfile, because it was moved to unfinished, and
   the compile failed.

2. Updated the MSVC6 doc to the newest Wiki version,
   too many things changed since the last synch.

Attachments

• lang-msvc.diff (6.13 KiB)

Reported version: trunk
Operating system: Windows

This issue was imported from FlySpray: https://bugs.openttd.org/task/27

peter1138 opened the ticket and wrote:

The call to this function needs to be moved to after custom graphics have been loaded, during AfterLoadGame, after GfxLoadSprites() is called but before AfterLoadVehicles().

Currently it works fine for games using only the default graphics.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/21

Bjarni opened the ticket and wrote:

changing the autoreplace array into a pool is needed to get rid of the fixed max number of engines

it is important to get into svn before next release as it will invalidate the saved array and clear all replace settings on load. The current replace array have never been in a release and it is coomplex to transfer the data to the pool

Attachments

• replacepool3.diff (8.50 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/3

Darkvater opened the ticket and wrote:

The problem is obvious, game crashes.
To reproduce: "bridge_crash.sav": any time any part of the train is under the bridge.
To reproduce: "bridge_crash2.sav" (with patch): only at that exact moment.

The original problem (been there for ages, in 0.4.0.1 as well) is that EnsureNoVehicleProcZ() is called and the tile is released as free-to-demolish when the v->z_pos and ti->z don't match. This is incomplete, as a train on a slope will have z values ranging from the bottom to the top. Eg from 8 to 16 if it goes from level 1 to 2. The patch fixes that.
The second problem (bridge_crash2.sav) still occurs however. This is because at the exact moment the train enters the tile, it's 'Z'-value is still 8; no change made. Currently there is no way to fix this without an overhaul of UP/DOWN detection (which is XXX-d and is crap), as there is not a single variable that tells us if the train is going up/down. These variables are cleared just a few lines before in AfterSetTrainPos:2603 in train_cmd.c.

A note: bridge_crash2.sav, while it does happen, does this VERY sporadically. To reproduce it faithfully I had to breakpoint the game at the exact moment the train enters the tile and pause it programmatically. Nevertheless it can happen.

Any thoughts on the patch? I think it is sufficient for the time (using > instead of >= will break deleting tracks under bridges); any better fixes need a lot more work. Also noted that the hash is totally braindead and doesn't really work as required.

Please test and give thoughs.

Attachments

• bridge_crash.diff (0.70 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/40

TrueBrain opened the ticket and wrote:

Here I will post all patches that I send to OpenTTD.GPMI, of which I feel OpenTTD will benifit too. You should think about things like bugs fixes, small code rewrites and stuff like that.

1. http://devs.openttd.org/~truelight/patches/regular/network_gamesettings.patch
   This patch holds the game from loading autosave, kilometers and currency when loading a network game as client.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/37

Meush opened the ticket and wrote:

The bug is described at http://www.tt-forums.net/viewtopic.php?t=22441

This patch calls InitializeGame with one more argument "mode"
If "mode" is 2 (creating random land), date will not be re-set.

It's been tested succesfully

Attachments

• editor_keep_date.patch (1.95 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/30

egladil opened the ticket and wrote:

When building or cloning a train, it can't be made longer than a certain length. However, when combining trains when dragging them in the depot window, only the length of the target train is checked. Neither the source train length or the combined train length is checked. Thus, by dragging the trains the right way, one can make trains many times longer than normally possible.
I can't say if the limit should be what it is now, or unlimited. Just that I think the limit should be the same everywhere.

An example on how to build a 700 wagon train can be found here: http://emil.djupfeldt.se/ottd/longtrain/

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/36

Rubidium opened the ticket and wrote:

town_cmd.c at about row 815 has the following statements:
...
// Only work with plain land that not already has a house with map5=0
if (ti.tileh == 0 && (ti.type != MP_HOUSE || ti.map5 != 0)) {
if (!CmdFailed(DoCommandByTile(tile, 0, 0, DC_AUTO, CMD_LANDSCAPE_CLEAR))) {
DoCommandByTile(tile, GenRandomRoadBits(), t->index, DC_EXEC | DC_AUTO, CMD_BUILD_ROAD);
...

The problem is that 'ti.map5 != 0' part of the if-statements makes no sense.
What it means is that it only allows destroying houses when they are in some, but not all, stages of construction and it allows destroying finished houses with a lift.

The original meaning probably was that it only may destroy houses when they are in development. On the other hand, http://svn.openttd.org/cgi-bin/trac.cgi/browser/branch/map completly removes the part.

So I've created two patches, one that changes the 'ti.map5 != 0' to 'building not finished', meaning that no finished house will be replaced by a road, and the other removes the complete part, meaning that no house will be replaced by a road.

Attachments

• town_cmd_change_statement.diff (0.76 KiB)
• town_cmd_remove_statement.diff (0.72 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/49

peter1138 opened the ticket and wrote:

Started a game with UKRS from 1921, and it didn't advertise. Found the cause of this, and also the cause of the duplicate advertisements.

http://195.112.37.102/ottd/advertise.diff

Testers appreciated.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/39

matthijs opened the ticket and wrote:

The memory pool code needs a rewrite. I have written a replacement in two parts: One malloc() like pool which just allocates (fixed-size) blocks of memory, and another one built on top of it which also gives every drop of memory a unique index (as the current pool does).

Reported version: 0.4.0.1
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/13

Bjarni opened the ticket and wrote:

ability to check refit mask for a engine type even before building the vehicle

right now we need to have a vehicle of the given type to do the actual check. It would be nice to have the option to check a type before building a vehicle

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/7

Rubidium opened the ticket and wrote:

As the summary says, some if, for, switch and while statements miss a space before the (.

The attached patch fixes about 87 'if('s, 186 'for('s, 111 'switch(es and 17 'while('s.

Attachments

• if_for_switch_while_whitespace_fixes.diff (100.27 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/46

julik opened the ticket and wrote:

When clicking on the station construction button before any track has been laid down in a new game the program crashes with assertion:

GetAcceptanceAroundTiles in station_cmd.c (line 591)
"w > 0"

After any track has been laid down the station construction is possible. Reported as of build 3419.

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/44

matthijs opened the ticket and wrote:

I've been experiencing crashes when saving with latest SVN (r3260). When run normally, everything is fine, but when run inside gdb, it crashes when saving:

Steps to reproduce: Clean compilation (though DEBUG or configuration doesn't seem to affect it). Start OpenTTD, new random game, save game. Bang.

===
matthijs@katherina:~/public_html/openttd/openttd-clean2$ gdb ./openttd
GNU gdb 6.3.90_20051119-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) r
Starting program: /home/matthijs/public_html/openttd/openttd-clean2/openttd
[Thread debugging using libthread_db enabled]
[New Thread -1212086592 (LWP 4147)]
[New Thread -1219277904 (LWP 4241)]
[Thread -1219277904 (LWP 4241) exited]
thread_db_get_info: cannot get thread info: generic error
(gdb)

Can somebody confirm this?

Reported version: trunk
Operating system: Linux

This issue was imported from FlySpray: https://bugs.openttd.org/task/20

tokai opened the ticket and wrote:

game crashes on start when no TCP/IP stack is loaded (some network related function is used before the network is initialized, aka OpenLibrary("bsdsocket.library",4UL); is executed).

There are 2 workarounds for this: open bsdsocket.library manually before the network function (which has to be found ;) is called or use new libnix constructor handling (which initializes bsdsocket.library before main() ), so it can fail gracefully w/o crash. Constructor handling is maybe a bit problematic with the crosscompiled nightly builds.

Reported version: 0.4.0.1
Operating system: MorphOS

This issue was imported from FlySpray: https://bugs.openttd.org/task/8

vlassarev opened the ticket and wrote:

1. Station cargo rating is currently formed based on the age of the last train car as opposed to the engine age, which can be annoying in multiplayer games.
2. The second of two competing trains transporting the same goods to arrive at its station seems to get an unfair advantage when it catches up with the rating of the train already at the station. Assuming that the maximum rating of the two trains is the same. Also annoying in small multiplayer games where people use this to their advantage (i.e. hold the train until the competition is already at the station and then arrive)

I realize these are small problems but when playing TTD head to head they can be major issues.

Reported version: 0.4.0.1
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/47

Meush opened the ticket and wrote:

This patch lets users sort theirs vehicles by model, just like in vehicle buying window.
Very small and safe patch, tested on road vehicles, ships, planes, standard trains, monorails and maglevs. Everything works fine :) Just merge it

Thank you for your time
Meush

Attachments

• sort_by_model.patch (2.14 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/35

Bjarni opened the ticket and wrote:

I was just told that the nightly build didn't show the error window when a grf file was missing. A quick test showed that it's true for the nightly build. However I haven't got time right now to tell if it is an issue for the crosscompiler or cocoa
We should have this working before releasing or the guys, who do not include the TTD files will not get an error about it (read: a lot of bug reports)

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/29

Bjarni opened the ticket and wrote:

OpenTTD crashes with a lazy pointer not found on exit
This only happens when linking statically to SDL

this is more like annoying than a real problem as it crashes after the game have saved openttd.cfg and no data is lost. It's quitting anyway, but it is annoying to get the crash window on exit

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/2

Qball opened the ticket and wrote:

a "--version" (or --revision) option would be the nicest solution, but it looks like MyGetOpt doesn't like it and '-v'/'-r' is allready in use.

I've attached a patch that appends the revition number to the help output.
Like this:

List of music drivers:
extmidi: External MIDI Driver
null: Null Music Driver

OpenTTD Revision: r3257M

I hope it aint a duplicate from sf.

Qball

Attachments

• append_version_to_help.patch (0.86 KiB)

Reported version: 0.4.0.1
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/15

thepizzaking opened the ticket and wrote:

At the moment, when playing a game in a later year eg. 2030 and you are building Maglev's, then you abandon the game and start a new game in an early year like 1930 and press the build rail button once, the Maglev toolbar will appear.
This patch fixes the problem, when ToolbarBuildRailClick is called, a loop is started to check if the last built railtype is available, if it is, that bar is opened, if it isn't, the next best railtype will be selected.
I hope that made sence, so here's the patch.

Attachments

• check_if_rail_available.patch (0.66 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/42

egladil opened the ticket and wrote:

The NORETURN macro is declared as nothing for gcc in stdafx.h. Instead it should be declared as __attribute((noreturn)).

Attachments

• noreturn.diff (0.34 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/45

peter1138 opened the ticket and wrote:

Splitting NewGRF related code out of engine.c, if desired...

Deleted attachment -- a new version will feature an svn copy :)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/31

Qball opened the ticket and wrote:

During playing openttd random (but very rare, just once every x day's) asserts with the following error:
------------------------------------------------------------------------------------
| openttd: gfx.c:142: GfxFillRect: Assertion `bottom > 0' failed.
| Aborted
------------------------------------------------------------------------------------
It happens when doing something, haven't noticed the problem when openttd is just running in the background.

I've been having this problem for almost a year now.
I am running openttd on linux (ubuntu), the problem occurs on x86 and ppc.

libsdl version: 1.2.7+1.2.8cvs20041007-5.3ubuntu2

Sorry for the vague description + summary.

Qball

Reported version: trunk
Operating system: Linux

This issue was imported from FlySpray: https://bugs.openttd.org/task/12

Bjarni opened the ticket and wrote:

we really need a cocoa video driver due to SDL being fucked up

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/17

peter1138 opened the ticket and wrote:

A few times I've been irritated by the train details view being fixed in size. So I scratched my itch, and this is the result...

Testers appreciated.

Attachments

• resizedetails.diff (4.96 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/38

Darkvater opened the ticket and wrote:

See http://bugs.openttd.org/task/40 in its extreme case. Fixing this requires rewriting slope-detection and handling. Also fixing the vehicle-hash table would be a nice addition

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/43

Bjarni opened the ticket and wrote:

refit each train vehicle individually so it's no longer needed to be refitted from the front engine

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/6

Darkvater opened the ticket and wrote:

As you know I won't be here for the coming days, but if you guys by some wonder finish all impending tasks for the release (as it is REALLY about TIME) and want to do a release, here are some points to take into account when doing the windows release:

1. Zipped version.
   - changelog, copyright, known-bugs, readme.txt (data, executable, language files, scenarios, strgen.exe)
   - make SURE you do the zip that it uncompresses into the same directory, not in OpenTTD-0.4.5-win32 or some similar one. This should also hold for the windows nightlies if possible, but that's another issue
2. Installer version.
   - update the windows installer file (os/win32/installer/install.nsi), Give it new version 0.4.5 and set INSTALLERVERSION to the next number; which will be 16 or 17 I think
   - opdate openttd.rc. FILEVERSION, PRODUCTVERSION 0, 4, 5, 0, other FileVersion in string-form

That should be about it. Good luck!

General tasks for a release:
- update changelog
- update known-bugs file (C&P from SourceForge / Flyspray)
- update readme

Reported version: trunk
Operating system: Windows

This issue was imported from FlySpray: https://bugs.openttd.org/task/14

tokai opened the ticket and wrote:

openttd does a write to NULL when the user clicks "parent" and he reaches the device root.

Details: Under MorphOS paths looks like: volume:dir/subdir and OpenTTD is not aware of that. Since we compile using libnix (MorphOS libc) and not ixemul (alternative more unix-alike libc, but with certain limitations in 'nativiness') there is no automatical unix<->morphos path conversion and it has to be done manually. Prolly nothing problematic. :-)

Reported version: 0.4.0.1
Operating system: MorphOS

This issue was imported from FlySpray: https://bugs.openttd.org/task/9

Bjarni opened the ticket and wrote:

Allow autoreplacing to replace train wagons as well as engines

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/5

egladil opened the ticket and wrote:

The makefile uses both CUSTOM_LANG_DIR and
CUSTOM_LANG_PATH with the same meaning at different
places. This gives problems when trying to set the lang
dir manually.

Attachments

• makefile_fix.diff (0.66 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/25

StarLite opened the ticket and wrote:

If a way is blocked for a train, and it has to choose a way, it will CHOOSE the free way even it find 2 1-way signals, but ONLY in the direction of it's target. aka: it will never go to a north 1-way of the target is south of it.
This behaviour only accurs when there is a PRE-SIGNAL in front of it, in case of a normal signal it will behave as normal.
Attached are 5 screenshots of a test where the bug occured.

Attachments

• bug1.png (201.01 KiB)
• bug2.png (203.19 KiB)
• bug3.png (204.34 KiB)
• bug4.png (203.54 KiB)
• bug5.png (204.95 KiB)

Reported version: 0.4.5
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/50

Bjarni opened the ticket and wrote:

we really need a native sound driver as SDL really fucks up now

the code is working, but might need a minor change to make it work on x86 too. It's not committed yet

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/16

peter1138 opened the ticket and wrote:

The X in the window close box is not centred. This patch separates the WWT_TEXTBTN and WWT_CLOSEBOX widgets, and draws the close box (slightly) differently.

This is really important, apparently ;-)

Attachments

• closebox2.diff (1.66 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/23

peter1138 opened the ticket and wrote:

Upon loading a game, each player's available railtypes are reset according to data from railvehicleinfo. However, it is possible that all engines of a certain type have been made obsolete, and thus the railtype is no longer available. This will mean that the track for the obsolete rail type cannot be built, even if obsolete engines are still running.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/33

egladil opened the ticket and wrote:

Sacro said something on irc about wanting nick tab completion so I made a little patch that autocompletes player names at the start of the chat message.

Attachments

• NickAutoCompletion.diff (1.47 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/28

Rubidium opened the ticket and wrote:

Both ai/default/default.c and viewport.c contain code that is not used since rev. 1.

The ai code makes one tile unconditionally height 1 and unconditionally a single tile of a HQ. Making a single tile of a HQ makes no sense at all, and because the code is # if 0'ed since rev 1 I think it can be removed safely.

The viewport code is also not used since rev. 1. It furthermore does not compile when DEBUG_HILIGHT_MARKED_TILES is defined. It is furthermore inconsequent in using the extra bits -> it writes 4 bits, but only reads 1 back. The non-static functions in de # ifdef are not used anywhere in the code.

Attachments

• rip_out_useless_debug.diff (2.10 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/48

peter1138 opened the ticket and wrote:

Exiting the game with double size enabled saves wrong window size. When the game is next started, it will still be in double size mode, but the window size will be half what it was before.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/22

LordOfThePigs opened the ticket and wrote:

[EDIT by TrueLight]
All this work is now done in a branch in the OpenTTD.GPMI Repos. You can find it here:
svn://svn.libgpmi.org/openttd/branch/tfc_newmap
They will communicate via this task. If you want to see their progress, make a diff between regular OpenTTD Repos and this branch. They will try to keep the branch as up to date as possible.
[/EDIT]

This patch replaces all access to m1 of the current map array by accessor functions. The functions are designed to abstract the code from the underlying data structure, making it easy to change the data structure without breaking the code. Ultimately (ie: once all the fields of the old map array have been rewritten) this will allow switching to a better structure without breaking any code.

Attachments

• map.r3261.diff (25.31 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/19

Graphite opened the ticket and wrote:

This patch fixes two issues:

- In the detailed performance rating, the min. profit would be set to the required value for the min. profit (10000) instead of 0 if the player had no vehicles yet.

- If all vehicles profits are higher than the min. profit value, it shows the maximum minimum profit instead of just the required min. profit value (so for example 25000/10000 instead of 10000/10000). This to make the profit window a bit more consistent as the others already do this.

Attachments

• minprofitfix3285.diff (0.67 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/24

peter1138 opened the ticket and wrote:

If a depot is positioned facing away from a piece of track, an engine will half at the end of the line such that it intrudes into the depot.

This can be fixed by making TrainCheckIfLineEnds() check for a depot facing away from the line -- then the train can stop and turn around before it reaches the tile edge.

This patch implements this check.

Attachments

• depotcrash2.diff (0.78 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/41

Bjarni opened the ticket and wrote:

A vehicle will lose its custom name if it is autoreplaced

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/11

Graphite opened the ticket and wrote:

The current inline function for BIGMULS casts two numbers to 64-bit, then casts the result to 32-bit, only to then return a 64-bit value. This patch fixes that so it returns a 64-bit result without casting it to 32-bit.

Priority is very low since it currently causes no problems (it's only used in inflation calculations and those numbers stay small enough). However it is a bug worth fixing to avoid future problems if someone were to use BIGMULS with big numbers.

Attachments

• BIGMULSfix3285.diff (0.34 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/26

admin opened the ticket and wrote:

This isn't a real task. You should close it and start opening some real tasks.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/1

oteek opened the ticket and wrote:

Adds FPS counter, cleans-up texteff.c (split to texteff.c, animated_tiles.c and textmessagebox.c)
generalization of network chat messages -> textmessagebox system (used both for network chat and info window)
(infobox is enabled only for DEBUG_)

Attachments

• fps.diff (39.13 KiB)

Reported version: 0.4.0.1
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/34

Bjarni opened the ticket and wrote:

===> Linking openttd
/usr/bin/ld: Undefined symbols:
std::__default_alloc_template<true, 0>::deallocate(void*, unsigned long)
std::__default_alloc_template<true, 0>::_S_force_new
std::__default_alloc_template<true, 0>::_S_free_list
std::__default_alloc_template<true, 0>::_S_node_allocator_lock
std::__default_alloc_template<true, 0>::allocate(unsigned long)
std::__default_alloc_template<true, 0>::_S_refill(unsigned long)

this bug appears if you link statically to SDL 1.2.8. This appears to be an issue to SDL and not OpenTTD as other projects got this issue too

workaround until a solution is found: link dynamically or use SDL 1.2.7

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/10

Bjarni opened the ticket and wrote:

for PPC we need to support all the way back to OSX 10.2 if possible, so dynamic linking is out of the question (they don't like opening libs in non-standard locations)
OpenTTD can't link statically to anything newer than SDL 1.2.7
I can't crosscompile SDL 1.2.7 for x86 OSX, but 1.2.9 can compile, so x86 needs to be dynamically linked to SDL. Luckily x86 is at least OSX 10.4 (developer edition, that is not for public release) or 10.5 (public release), so adding a dynamic lib to the release is possible

The result of this is that the universal binaries have to be static linked PPC code and static linked x86 code except for SDL, which will then be dynamically linked. This is NOT nice, so we better get rid of SDL. Specially since it causes so many issues, not just this one

Reported version: trunk
Operating system: Mac OS X

This issue was imported from FlySpray: https://bugs.openttd.org/task/18

egladil opened the ticket and wrote:

This patch takes the common parts of FiosGetSavegameList and FiosGetScenarioList, and replace them with FiosGetFileList which uses a callback to determine which files to add to the list. This removes the duplicated code, and also makes it easier to add new file formats to list. (Like the tutorials im working on.)
It needs testing on win32 and os2, since I don't have access to any of those.

Summary of changes:
* Moved arch independet fios functions to new file fios.c
* Added FiosGetFileList to os2.c, unix.c and win32.c
* Removed FiosGetSavegameList and FiosGetScenarioList from os2.c, unix.c and win32.c
* Created new FiosGetSavegameList and FiosGetScenarioList in fios.c
* Updated makefile and vc projects.

Attachments

• fios.diff (24.29 KiB)

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/32