Cataclysm: Dark Days Ahead version 0.8 Romero released

HRose · 2013-09-24T10:49:19.000Z

Uff, this is annoying.

Since I saw some work being done on the tiles in the source that could have helped fixing things in my own tiles, I then tried to compile this thing myself.

And obviously it doesn’t work. The makefile mentions:

handle #include “SDL/SDL.h” and “SDL.h”

Nope. It doesn’t work. I had to relocate all the .h files so that the path was correct. Then I managed to compile it, but I wonder if it works since I have no idea what kinds of version it needs for the bunch of libraries it depends on, like libpng, freetype and so on.

Anyway, it compiled, but now it demands a bunch of .dlls. Like SDL_image.dll

So the question: Why the F it can’t link statically all that mess? The package you distribute doesn’t need any .dll littering the directory, so why the makefile isn’t ALREADY SET UP to work like the thing you actually distribute? And what I need to edit to make it behave like that?

And yes, I moved all the .dlls into the game dir so that I could run and… yes. It opens, waits a while, then it closes without any message. FAIL.

It’s never a smooth ride.

HRose · 2013-09-24T11:29:04.000Z

More:
I tried to download this: http://ci.narc.ro/job/Cataclysm-Win32-SDL/lastSuccessfulBuild/artifact/cataclysmdda-0.8.zip

And tile mode is screwed with vehicles. They show up as a bunch of #### (unknown) currently. So either the code needs fixing, or the tiles.

i2amroy · 2013-09-24T15:07:59.000Z

[quote=“HRose, post:120, topic:3053”]Oh, and another thing I wanted to rant about:

a few versions back I found a working vehicle, but I was disappointed by the collision system. Imho, it’s not very realistic, and so way too immersion breaking, that one can easily drive right through buildings without suffering much damage. This stuff should at least use some basic damage model that considers the frame resistance and speed, and then make also a check against the stuff you’re colliding with. A crash with a car against a wall could take down the wall, but the car would likely explode or at least not move ever again.

Or at least cars that aren’t specifically engineered to tear down things, and even in that case speed should be severely affected.[/quote]
If you’ve noticed .8 already has come with a rather large vehicle update. Don’t try to drive through buildings now, or at least not in any car you plan to keep using. At this point most vehicle collision bugs are strange quirks of the old system that are just now coming to light due to us replacing a chunk of the system with something that is realistic and not filled with said bugs. (Take the shrubs bug, it’s due to some old code that automatically stopped the car under certain conditions; it’s just that you never noticed it’s effects really before because shrubs didn’t really do any damage to your vehicle.

youtoo · 2013-09-24T22:00:30.000Z

has any work been started on z-levels? i read the developer diary. I dont see it mentioned. Is that on tap for after the mod manager? Or are other people working on it? Not sure if certain things have to be cleaned up first before that can start.

CIB · 2013-09-24T22:13:17.000Z

z-levels will likely come later.

youtoo · 2013-09-24T22:36:19.000Z

thanks guys. how about adding a link to the facebook page on the front page? we have twitter there already.

Treah · 2013-09-26T11:54:45.000Z

i2amroy;

The problem with the mac version of the game I believe is that you have dynamically linked in the libintl.8.dylib instead of statically linking it to the binary. This library is not present on Mac systems ( even when you install xcode and command line tools ) and thus will fail to be found when the game is run. The only reference to the library that I could find was from macports, and asking users to install that just to run a single program is a bit overkill IMHO. So you will either have to distribute a copy of the library with the game and get the compile to dynamically link to it in the game directory ( that’s ugly and hackish IMHO) Or just statically build the lib into the binary. Ill see if I can give compiling it from scratch a go as I have a mac to work on that’s running the latest version of the OS. However I have not had good luck in the past getting it compiled before.

youtoo · 2013-09-26T15:35:47.000Z

by real physicals for cars? what physics engine did you use? is it some physics code from the web? not sure how this works.

i2amroy · 2013-09-26T19:04:26.000Z

[quote=“Treah, post:127, topic:3053”]i2amroy;

The problem with the mac version of the game I believe is that you have dynamically linked in the libintl.8.dylib instead of statically linking it to the binary. This library is not present on Mac systems ( even when you install xcode and command line tools ) and thus will fail to be found when the game is run. The only reference to the library that I could find was from macports, and asking users to install that just to run a single program is a bit overkill IMHO. So you will either have to distribute a copy of the library with the game and get the compile to dynamically link to it in the game directory ( that’s ugly and hackish IMHO) Or just statically build the lib into the binary. Ill see if I can give compiling it from scratch a go as I have a mac to work on that’s running the latest version of the OS. However I have not had good luck in the past getting it compiled before.[/quote]

Feel free. Apple has pretty much gone out of their way to make static linking all but impossible in Xcode, which is why we are having so many problems. If you manage to get a version working without needing dynamic library linking feel free to post it here and we can upload it. This goes double for the SDL version, which takes even more jumping through hoops to get it to work.

kevin.granade · 2013-09-26T19:10:52.000Z

youtoo: It’s just a simple parameterized elastic collision model, the vehicles are still treated as basically point masses, and we ignore angular momentum. But it’s more accurate than the totally ad-hoc thing we had before.

cheeseyb0b · 2013-09-26T19:33:38.000Z

I just started playing the new version and I’ve noticed a bug. Attacking something with a rock-in-a-sock shows the debug message “Tried to get invalid material: cloth” then crashes the game.

i2amroy · 2013-09-26T19:41:01.000Z

cheeseyb0b:

I just started playing the new version and I’ve noticed a bug. Attacking something with a rock-in-a-sock shows the debug message “Tried to get invalid material: cloth” then crashes the game.

It’s already known and fixed in the experimental.

Thanks for reporting all the same, though you might want to consider using the Garage forum in the future for bug reports.

An0n3 · 2013-09-27T18:50:34.000Z

Rock-in-a-sock?

Does the game feature madballs?
That is, a cue ball in the bottom of a sock.

vultures · 2013-09-29T11:03:55.000Z

With the exception of madball not being in an actual sock (think of it - what can you find instead in a pool bar?)

But get this, just an idea:
Tools:
Open Flame
Tongs
Hammer
Materials:
Nails x3 (though, these should be actual building nails, but whatevah)
Chunk of Steel
Chain
Heavy Stick or Pool Cue
Cue Ball x3

Cut the stick in half, shape the steel onto an end; drive searing-hot-rod nails through cue balls, shape ends and connect to sturdy piece of wood&steel with three chain pieces. Smash / Grapple then Stun.

Mrn · 2013-09-29T13:05:27.000Z

Hi, I have a tendency to use “list items” (V) quite a lot in the game, but it didn’t work for me in the tiles version. Trail line wasn’t drawn and there was no way to know where are the items listed. I tried both the 0.8 and Git version to no avail and was somewhat surprised no one complained about it (I’m using Linux, if it’s relevant), so I decided to try and fix it myself.

My solution is probably suboptimal, since I don’t know the code-base at all, but here is what I did:

[code]diff --git a/game.cpp b/game.cpp
index 10f2d2f…f2b72d2 100644
— a/game.cpp
+++ b/game.cpp
@@ -6851,14 +6851,9 @@ void game::draw_trail_to_square(int x, int y)
draw_ter();

 //Draw trail

point center = point(u.posx + u.view_offset_x, u.posy + u.view_offset_y);
std::vector vPoint = line_to(u.posx, u.posy, u.posx + x, u.posy + y, 0);
for (int i = 1; i < vPoint.size(); i++)
{

   m.drawsq(w_terrain, u, vPoint[i-1].x, vPoint[i-1].y, true, true, center.x, center.y);

}

draw_line(x, y, vPoint);
mvwputch(w_terrain, vPoint[vPoint.size()-1].y + VIEWY - u.posy - u.view_offset_y,
vPoint[vPoint.size()-1].x + VIEWX - u.posx - u.view_offset_x, c_white, ‘X’);[/code]

It works and is finally playable for me. I also checked both the curses version and SDL version with tiles turned off and it doesn’t seem I’ve broken anything. Is this correct? Or should the original code work as well?

i2amroy · 2013-10-06T19:23:17.000Z

Kaet:

Any update on the vehicle tileset situation? Able to make not just frames yet?

We don’t handle anything for tile sets other then support, and I’m pretty sure that this problem is just that the tile set owners haven’t gotten around to making vehicle tiles yet for their respective tilesets. You might want to consider posting in their threads if you want an estimated time.

(If I’m wrong forgive me, I don’t really mess with tilesets so I’m not 100% positive on how they work).

GalenEvil · 2013-10-07T09:29:48.000Z

I’m really not sure what the problem is to be honest. I will look at it again and see if I can get it working properly. The code is looks functionally the same for both the GDI and Tiles vehicle drawing. I bet I botched something though with how it picks the tile >.<

xLemor · 2013-10-07T23:58:23.000Z

Maybe a priority on what tile to display on top would work. I dont know if it can be done tho.

HRose · 2013-10-08T09:44:34.000Z

[quote=“Kaet”]Unfortunately you’re wrong there. All the tilesets have been sort of half finished because vehicle frames are shown on top of everything else on the vehicle, so all the cars look like weird unidentifiable heaps that you can’t tell back to front from.
I’m guessing the tileset makers have maybe not voiced their problems enough if nothing has been done to fix it.[/quote]

I’ve opened bugs about this and other things.

Both tiles and standard SDL need a lot more work but it seems pretty low on the priority list of devs.

i2amroy · 2013-10-08T15:10:28.000Z

HRose:

Both tiles and standard SDL need a lot more work but it seems pretty low on the priority list of devs.

Mainly because GalenEvil is the main one who understands and handles that code, and he’s busy doing other kickstarter work.

(I know that personally I don’t use tiles at all [they don’t work on Cygwin] so I won’t be doing any tiles development/bugfixes.)