Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Duke

Pages: 1 2 3 [4]
Bugs prior to release 2.3 / rev 24266 can't start any battle
« on: April 28, 2009, 10:08:51 pm »
When trying to start any battle, I get the screenshot screen, then the game exits to desktop.
The log looks like the game isn't aware of a problem:
Code: [Select]
Created AI player (team 0)
Created AI player (team 7)
Connecting to localhost...
load material file: 'materials/estate.mat'
Shutdown gametype 'Skirmish mode'
Shutdown server: Quitting server.

Happens with both freshly compiled maps and older compiles ie. before Mike's and my latest fixes.

Discussion / Split bugs & features ?
« on: April 16, 2009, 01:08:36 am »
I was wondering if it would help us to split the 'bugs & feature request' forum into something like
- 2.2.1 support (no more bug-reports, please)
- 2.3 support (+ potential bugs)
- feature requests

Imho this could save us from the omnipresent question 'which version do you use ?'.

Coding / C::B *.cbp ?
« on: April 16, 2009, 12:28:36 am »
It seems that whenever some dev who does NOT use C::B creates/deletes files, the *.cbp files remain unchanged, which can be quite annoying to the C::B users.

Q: Is there a *single* dev who feels responsible for the contents of the *.cbp files or are we *all* encouraged to update them as necessary ?

Discussion / What about an 'Announcements'-forum ?
« on: February 19, 2009, 01:53:56 am »
Most communities I know have a 'News' or 'Announcements'-forum where only a few members (mods, devs and VIPs) have write access.

So they can put messages there like
"Destructavator has created a new package for Windows based an rev 23456" or
"WARNING: Duke has committed some code to the SVN, so it's considered pre-pre-alpha" or even
"BTAxis is on a 2-week vacation. Don't expect any answers until xx.xx.xx"

Does the forum SW support such restricted write access ?
Shouldn't we have such a forum ??

Coding / Stairway bug solution found ?
« on: December 13, 2008, 10:52:11 pm »
After spending many evenings analyzing, debugging and suspecting innocent functions, I finally could make stairways work again. As often, the solution is very simple.
In fact, it is so obvious that I could also imagine that it has already been considered but declined for some reason. That's why I'm asking here instead of posting a patch.

I tested with the fighter_crash map, the stairway in the 2-story building next to the dropship. It has 8 stairs and is 3 cells long. IIRC from playing 2.2.1 pretty much all the stairways in UFO-maps look like that.

Question 1: is it true that most stairways look like that ?

The routing/pathfinding code uses two constants
Code: [Select]
/* Minimum height for an opening to be an opening in step units (model units/QUANT)
 * Must be larger than PATHFINDING_MIN_STEPUP!!
/* common/routing.c */
They are given in QUANT units, which is 4. Thus the maximum amount of model units an actor can climb per move evaluates to 20. The delta between two floors is 64. So getting up to the 2nd floor with 3 moves of 20 each is impossible.

So I increased those two constants by one and it works nicely :)
If you want to test it, remember to recompile ufo2map as well and rebuild the map(s) you want to test with !

However, this solution may have sideeffects. Things may become climbable that are not supposed to be. Like
- small crates on the floor
- low railings of a bridge
- mild slopes

Question 2: Can any of the experienced modelers think of places in the maps where a height of >= 21 was used to inhibit climbability ?

Discussion / Adding .bsp files to the svn ??
« on: December 10, 2008, 12:09:31 am »
Forum search revealed a lot of "&nbsp"s for "map .bsp svn".

It just took me some 25 minutes to compile the alone (on an outdated 2.6 GHz single-core machine). Downloading the resulting 7.5 MB file would be much faster for me.

Just a thought:
Would it be a good idea to add the .bsp files to the svn ??

Discussion / Unimplemented Game Features FAQ
« on: December 04, 2008, 11:08:01 pm »
That reminds me that I volunteered to write an article about it. As the reaction on my proposal wasn't too enthusiastic, that slided down my priority list...

Ok, here is a 1st draft...

Destructible terrain
I found a paragraph in the Manual/FAQ section of the wiki that could be reused here.

Saves in battlescape:
First, it's a thoughtful design decision of the devs that are in the lead of the project. They simpy do not *want* it, and that is enough reason.
The idea is, that being able to restore after a bad move would take a lot of the tension away, making it a different game.
No reasoning brought up in the past did change their mind. Among the reasons were:

- after playing successfully, my favourite soldier is killed by the last alien remaining.
  Solution: keep up you concentration and caution until the mission is really done.
- after playing successfully for several hours and 30++ rounds, it's 4 am and I need to go to bed.
  Solution: start to play earlier in the evening. With some experience gained, you will also play faster.
- restrict the saving somehow so it can't be exploited. Attempts included: only autosave every 5th round, allow reload not before 12 RL hours have passed,...
  Result: each and every restriction suggested could be proven to be exploitable.
- make it a configurable option at campaign start.
  There would be no reason to disable that option.
There is also a technical reason. Adding that feature is not just like two more function calls somewhere in the battlescape code.
There is quite some additional data in battle which the current code doesn't have load/save routines for, including position and morale of the soldiers, aliens and civilians, dropped items and corpses on the ground etc.
So in addition to being unwanted, this feature would also require quite an amount of work.

Engine change
coming up later...

Discussion / Regarding the locked thread from 'shockwave'
« on: November 18, 2008, 06:13:27 pm »
Uhmm...I fail to see any rudeness in your response...

I think it could save you (and others) quite some work if we had an article in the wiki or FAQ about things that are NOT going to happen and especially *why not* for both coders and non-coders. So every time such a topic is brought up again you could simply post an RTFM-link ;)

I would volunteer to write such an article if that's appreciated.

Coding / reproducable battlescape situations ?
« on: November 04, 2008, 01:31:05 am »
Let's assume I wanted to test/debug a certain situation near the end a of a mission (like 'alien in panic' or 'stun alien').

I guess you don't want me to spend an hour or two to play that mission and *hopefully* recreate that situation.

I assume that this can be done by using the 'commands'. It that correct ?

Feature Requests / 'Continue' button is fubar in retry menu
« on: October 31, 2008, 09:29:04 pm »
Campaign. Start mission. Abort mission.
In the menu that comes up then, the 'Try again'- button looks and works fine, but the 'continue'-button does not.
It's been like that for at least a couple of days.
Running rev 19934 on Window$.

Coding / Updating the project files ?
« on: October 25, 2008, 08:49:10 pm »
What is the suggested way to keep my C::B project file up to date ?

I updated to latest svn and got 'unresolved externals'. I managed to get rid of most of them by adding some m_node_* files to the project. But that gave me 'multiple definition' errors. So I assume I also have to remove some files from the project, but which ? 'search in files' brought up only *one* definition of such a function in error. I'm a bit clueless atm.

So how do you guys do it ??

Windows / A call for testing help
« on: October 19, 2008, 12:45:40 am »
Could anyone who runs ufo 2.3 on Window$ please do a quick test for me :

Check if you can switch to a language different from your machine's default setting.
Hint: chose a language that you can understand a bit, or switching back might be a challenge ;)

That worked fine in 2.2.1, but doesn't work for me in 2.3.

If the test fails, plz report here.
If you should succeed, plz report the type of Window$ you use (W2k, XP, Vista ?)


Coding / partially switching to C++ ?
« on: October 13, 2008, 12:57:00 am »
I bet this topic has been discussed before, but unfortunately the forum search function doesn't let me search for 'C++', it only comes up with occurrences of 'C', which is quite A LOT :(

I haven't seen much of the UFO code, but what I have seen seems to be 'well structured' and could be easily converted into C++ classes.
A prominent example is dbuffer.c, which is kinda 'C++ done manually in C'. Which is not very efficient, both source- and runtime-wise :(

So could anybody plz
- come up with a link to a former discussion on that OR
- tell me why UFO is not moving to C++ ?

Coding / MSVC ?
« on: October 02, 2008, 12:43:27 am »
I loved to play X-COM back then.

It's August 2nd in my 2.2.1 game at std level and I'm running out of things to research. I only noticed a handfull of minor bugs so far (and a lot of missing/uncompleted features, of course). So I have to say:
Great job, guys. THANK YOU very much for giving us this game :)

I guess the next step for me should be to dive into the 2.3 SVN version and help to fix the remaining bugs by reporting them (at least).
To do so, I need to compile SVN src. And sure enough, I'd like to use the debugger before reporting ;)
Problem is, my favourite IDE is MSVC 6.0 SP 5. Allthough the original engine seems to have been developed with MSVC, forum search revealed that none of the devs here seems to use MSVC.
So here are my first questions:

1) Is there anybody around who uses MSVC to compile it ?

2) Are there some docs I missed about how to set up MSVC to compile it (like required switches eg. /J etc.) ?

3) Is there some architectural overview for the src ? eg. which dir contains what and how it all works together ? (I'm not talking about the calltree).


Pages: 1 2 3 [4]