Compiling TTDPatch under Lubuntu

[WWTBAM]

You need to do svn checkout svn://svn.ttdpatch.net/trunk/, rather than http. Possibly I can detect the Subversion client and redirect it to svn://svn.ttdpatch.net/trunk/ though.

EDIT: Done, the command line svn client at least will show the correct URL if you try to access svn.ttdpatch.net via HTTP.

I got redirected when I tried with http://. Off to fix the lock bug I found.

[orudge]

Yes, but you should be redirected to the right place now.

[WWTBAM]

I was just testing it to see if it worked. I am of course now using the correct URI.

[WWTBAM]

If or when you start producing patches, I can give you commit access to the SVN repository.

That would be nice once I start producing patches that aren't merely TextID changes

[planetmaker]

If or when you start producing patches, I can give you commit access to the SVN repository.

That would be nice once I start producing patches that aren't merely TextID changes

Do you think that the TextID changes make no sense? Or why don't you consider them worthy a commit?

[WWTBAM]

I see them as not being worthy of commit access alone but if others (name orudge) see it differently, then I am happy to have the rights.

[planetmaker]

I see them as not being worthy of commit access alone but if others (name orudge) see it differently, then I am happy to have the rights.

While I understand that, I think you're too modest, given it would be the first commit in about two years. Though... lakie seems to have pushed your suggestion already
http://projects.tt-forums.net/projects/ ... repository

[WWTBAM]

Ok. Well I have a patch that he maw not have. In that I changed a misleading error for lock construction. It would be nice to commit that as myself.

[WWTBAM]

I checked the betas, and they display the same object in the way error when trying to build lock in the wron spot. Should I back port my patch from trunk to the 2.5 branch when I get commit access? If so how do I go about back porting?

[Lord Aro]

personally, i think you're caring too much about the old stuff. I say just start again at 2.8(?) or even 3.0

[WWTBAM]

personally, i think you're caring too much about the old stuff. I say just start again at 2.8(?) or even 3.0

Why? TtDPatch has trunk aka 2.6 and a 2.5 branch. Most people that have been using TTDP for a long time want to see a stable released. I personally want to see a 2.5 stable released and can't relay care what the next stable is called but that's the future.

[OzTrans]

I wouldn't worry about the 2.5 branch. Almost none of the Canadian graphics files work with it anyway (due to features only available in v2.6 alpha); that is why I'm no longer using it. Back-porting features and fixes from 2.6 to 2.5 would be a waste of time.

I would release TTDPatch v2.6 alpha r2366 as the new stable or beta version, even if there are some minor issues, if that is possible. Then continue the 'alphas' with v2.6 r2367 (maybe as v2.7).

[Lord Aro]

personally, i think you're caring too much about the old stuff. I say just start again at 2.8(?) or even 3.0

Why? TtDPatch has trunk aka 2.6 and a 2.5 branch. Most people that have been using TTDP for a long time want to see a stable released. I personally want to see a 2.5 stable released and can't relay care what the next stable is called but that's the future.

Because it's all ancient, and no one sensible actually uses it anymore. 2.5 beta 9 is from 2006!

[wallyweb]

2.5 beta 9 is from 2006!

The dates have absolutely nothing to do with anything other than a convenient way to organize the files on your hard drive. What IS important is the versioning of the releases.
In TTDPatch there are three current releases:
STABLE: TTDPatch Version 2.0 rev1
- No bugs, no crashes
- Does NOT support newer features
BETA: TTDPatch Version 2.5 beta 9
- Several outstanding bugs
- Does not support newer features
ALPHA (nightly): TTDPatch Version 2.6 alpha 0 r2366
- Many outstanding bugs including those from 2.5
- Includes latest features.

My personal experience is that the current alpha (r2366) is very stable.
I have had NO crashes.
Although there are many outstanding bug reports, I have not encountered any of them.
I do not consider the current inavailabilty of newobject tool tips to be a bug, but rather a desirable feature.
I do not consider the current inavailabilty of a newobject tool in the scenario editor to be a bug, but rather a desirable feature.

Unless someone can confirm the bugs attributed to beta 2.5, I suggest moving it to STABLE.
Unless someone can confirm the bugs attributed to alpha 2.6, I suggest moving it to BETA.
These steps should "clear the decks".
Any new bug reports should be attributed to 2.6 beta 0 and resolved before moving on the next version.
A new ALPHA 2.7 should be started for NEW FEATURE developement.and resolution of bugs only attributable to those new 2.7 features.

On bug reports: In the past Just about anybody has been able to log a bug report, often without veryfying repeatability or previous reports. This has led to a lot of spurious reports and a stuffed bug report file. To resolve this, I suggest that the general public be encouraged to post their reports in these forums and that only developers be able to log the reports after proper validation.

As roboboy has taken the innitiative ( ) he should have the final say in any of this.

These are just my random thoughts.

[WWTBAM]

2.5 beta 9 is from 2006!

The dates have absolutely nothing to do with anything other than a convenient way to organize
As roboboy has taken the innitiative ( ) he should have the final say in any of this.

These are just my random thoughts.

Well I think patchman should have the FINAL say.

re the main toolbar newobjects tooltip, that was a bug as it displayed a tooltip before Lakies fix showing incorrect text. Any further tooltips are definitely features. I think 2.5 should be moved to either release candidate or stable. 2.6 should probably stay at alpha but be moved to Alpha 1 rather than alpha 0.

[WWTBAM]

So I have made my first commit. Now I can't seem to build TTDPatch with version information any more Will keep looking to work out what's happening. I put the .ver file in the versions directory but after a build, it's back to a noversion version of the file.

[WWTBAM]

I have been trying to get compiling working for the DOS version. My owsetenv.sh for Open Watcom 1.9 contains:

Code: Select all

#!/bin/sh
echo Open Watcom Build Environment
export TERMINFO=/lib/terminfo
export WATCOM=/home/user/watcom
export PATH=/home/user/watcom/binl:$PATH
export INCLUDE=/home/user/watcom/h/:$INCLUDE
export EDPATH=/home/user/watcom/eddat
export WIPFC=/home/user/watcom/wipfc

My PATH is set to:

Code: Select all

$PATH:/usr/local/games:/home/user/Documents/TTDPatch/TTDPatch-nightly-r2366/NASM:/etc/:/home/user/Documents/TTDPatch/TTDPatch-nightly-r2366/BIN/:/home/user/watcom/binl/

and I get:

Code: Select all

[CCD] ttdpatch.obj
ttdpatch.c(11): Error! E1055: Unable to open 'stdio.h'
ttdpatch.c(12): Error! E1055: Unable to open 'stdlib.h'
ttdpatch.c(13): Error! E1055: Unable to open 'string.h'
ttdpatch.c(14): Error! E1055: Unable to open 'ctype.h'
types.h(15): Error! E1055: Unable to open 'limits.h'
types.h(18): Error! E1091: Cannot compile in this environment (bad char type)
types.h(54): Error! E1091: 16-bit integer type required to compile. Sorry.
types.h(66): Error! E1147: Too many errors: compilation aborted
make: *** [ttdpatch.obj] Error 1

when running make alld from my source dir. stdio.h and stdlib.h are in /home/user/watcom/h/ .

everything is set up the same as before.

Edit: It seems the environment variables are not being set correctly or not being imported properly when I run owsetenv.sh. echo $INCLUDE returns an empty line after I have run owsetenv.sh.

Edit 2: All fixed. I wasn't running owsetenv with the correct syntax.