Latest trunk build

[peteran]

• Realtime lightning doesn't really work for me. I mean, works ok until combat (when it's used) and then it eats up enough cpu to make navigating to options with a mouse interesting. I don't really know if it's my system (Pentium M 2.13 GHz, 2 GB memory and GeForce FX 5600) or the game.

well, a fx5600 is maybe not enough to execute the glsl shaders we are using.

True on the fx5600. I have a Sapphire Radeon X1950 Pro with 512 MB waiting to get a new fan, but that got put on hold as I need to fabricate a vrm heat spreader from copper and other stuff (life) got in the way. Now it feels like I should get that card up and running. Then again, graphics isn't the most important thing.

The navigating with mouse could be made easier, maybe. I mean, it's easy enough to hit the big button to get to the options screen, but hitting the small checkboxes when the system is under heavy load requires a good deal of patience.

As the slowdown is most noticeable in battle, I will not be the only one experiencing it.

Would it be possible to suspend some thread when the options menu pops up?

[Mattn]

ufo is not threaded (well, there is a thread for the bsp walking)

if you plan to optimize things, the ai is rather slow, too (might also be related to the pathfinding)

[TrashMan]

Just got a new build 15 minutes ago. Got this while compiling:



Compiling: ..\..\src\tools\ufo2map\brushbsp.c
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\ufo2map\brushbsp.c: In function `SelectSplitSide':
C:\Documents and Settings\Toni\Desktop\UFO_AI\src\tools\ufo2map\brushbsp.c:618: error: invalid type argument of `->'
Process terminated with status 1 (0 minutes, 6 seconds)
1 errors, 0 warnings
 

[DuKe2112]

Jeah and abot 20 mins ago I got A syntax error in a related file.
Seems as if someone is programming directly on the svn trunk...
Not a wise Idea I'd say.

[BTAxis]

ALL programming happens on SVN trunk. It's been that way ever since the (re)start of the project.

[DuKe2112]

Oh, I have seen it on other projects, that trunk is mainly kept for testing. And therefore should be kept at least compileable and startable.

Thats the reason I was confused when I got a version that I couldn't even compile due to syntax errors.

Developement is usually done on a private copy that is only synchronized with the svn after at least some validation.
Sometimes there are even extra versions for experimental developements (eg that are not to get anywhere stable soon)

But It's yours to decide what has which advantages and disadvantages for you.

[Valis]

I think what BTAxis wanted to say is that the trunk is a continuous development branch so every change is committed directly under that branch. Other branches are made for example for the release candidates and the final versioned releases.

Therefore the trunk should always be compilable. If there are any syntax errors then...well, errors happen and somebody has committed an uncompilable code.

Correct me if I am wrong, I am just getting started with this project and its structure [compiled it today for the first time, code was checked out one day before, no errors during compilation, game runs]

[BTAxis]

Some revisions actually don't compile for that reason (especially radiant). Trunk is *supposed* to be compilable at all times (i.e. half-finished work that breaks compilation or execution should not be committed), but especially platform-specific issues tend to pop up from time to time.

[bayo]

At the moment users of Mac PPC are welcome to test thrunk ; if the game compile and work. They can test the open/close of the message system; is spinner and checkbox work; is there anyproblem on the aircraft GUI. Imho part of the game where we can have more platform-specific problems. I change some code about menus allocation (r22963 r22970)

We also have many warnings, because we are refactoring many code. It should not make problems for compilation; and will be fixed soon.

[Duke]

Running 23247 on XP (plus some pathfinding patch)

- starting a new single campaign, auto-build a base,  save

- load that game, open console
- devmap fighter_crash
=> map loads fine, but without soldiers.

That procedure still worked for me about a week ago, sooo questions:
Is it just me ? Or did the devmap behaviour change ?

[Duke]

I removed all patches and tried with plain trunk code (rev 23274). Same problem
Also tried 'map' and a different map. No soldiers.
I could enter a mission from the campaign (from that same saved game) and had soldiers though.

Even if nobody can fix it or knows a workaround, it would be nice if somone could at least confirm or disconfirm this problem.
t.i.a.

[bayo]

Hello.

No body talk about a bug like that right now.

If all your files are up to date (map compiled with last ufo2map, game library compiled (so/dll), game compiled, new save game), an helpfull information is to find the first revision creating this problem. Your computer/OS can also be helpfull.

[Mattn]

please try to start a map via the skirmish game mode - don't try to start them manually

i still have to fix some stuff around the handling of map spawning.

[Duke]

Thx, bayo, a good hint. So I created a fresh savegame, but it didn't work either

@Mattn:
Already tried skirmish mode and it works. But it's not very helpful if I want to test pathfinding.
Wilminator has just created a new patch for routing and it looks very promising
As the 'stairway bug' has prio 9 in the tracker, may I suggest that fixing devmap spawning is considered prio 10 ?
Do you already know what needs to be done or is there still some bughunting to do ? I tried to venture into that area of the code but couldn't even find the point where the spawning should happen.

[Duke]

When pressing ctrl-g, I get "vid_grabmouse is write protected." in my log (rev 23378, XP)
 along with the inability to test in windowed mode.

Yesterday's trunk did work.