0.4.8 linux package does not run

[andrewj]

I thought I'd try the 0.4.8 linux package and see how far along you guys were. Unfortunately the game does not run at all.

My system: Debian Linux, stable release ("wheezy"), 64-bit.

I installed some libraries that were needed (shown by ldd), like libxt, and some more libraries that OGRE wanted, like libxrandr, and I think all the dependencies are met. The game starts running, various messages appear on the terminal, and then just stops -- nothing happening at all (but not dead, and no error).

Ran it in the gdb debugger, seems that OGRE is trying to show a config dialog with libXt (an ancient X toolkit, heh) -- but for some reason no window is appearing.

Backtrace (and some game messages) :

{l Code}: {l Select All Code}

Added resource location './DeferredShadingMedia' of type 'FileSystem' to resource group 'General' with recursive option
Added resource location './PCZAppMedia' of type 'FileSystem' to resource group 'General' with recursive option
Creating resource group Music
Added resource location './music' of type 'FileSystem' to resource group 'Music' with recursive option
Creating resource group Sound
Added resource location './sounds' of type 'FileSystem' to resource group 'Sound' with recursive option
^C
Program received signal SIGINT, Interrupt.
0xf751c426 in poll () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt
#0  0xf751c426 in poll () from /lib/i386-linux-gnu/libc.so.6
#1  0xf7231149 in _XtWaitForSomething () from /usr/lib/i386-linux-gnu/libXt.so.6
#2  0xf7232900 in XtAppProcessEvent () from /usr/lib/i386-linux-gnu/libXt.so.6
#3  0xf7226a88 in XtAppMainLoop () from /usr/lib/i386-linux-gnu/libXt.so.6
#4  0xf7ebdd2b in Ogre::ConfigDialog::display() () from ./lib/libOgreMain.so.1.7.2
#5  0xf7daca9b in Ogre::Root::showConfigDialog() () from ./lib/libOgreMain.so.1.7.2
#6  0x080ff15c in ODApplication::ODApplication() ()
#7  0x080f8885 in main ()


I'm not too fussed if you can figure out the problem or not, but thought you may want to know about it. I might try the windows 0.4.9 package later.

[oln]

The 0.4.8 package is very outdated, so I don't know if there is any good way of getting it to run on a newer distro. If you want to check out the progress you will have to try to build it or try the windows releases.

EDIT: Moved the package after posting this.

[Bertram]

Hi there,

@andrewj:
I'd even say outdated is an understatement. I couldn't beg you enough to try to compile the development branch instead of trying the 0.4.8 linux antic release.

@oln:
May I insist to make this oldie move to old releases?

Regards,

[andrewj]

Ahh I didn't know it was so outdated, the date shown on the SourceForge files area was 2014/08/24 so I assumed it was a recent snapshot.

I'm still curious to try this out sometime. Cheers.

[Akien]

This makes me wonder, is there any reason why we call the next milestone 0.4.9, apart from the fact that the previous release was 0.4.8? There has been so much development between those two, that it might make sense to give it a version number that better conveys how much the game changed. What about using 0.5.0 for the next milestone?

[Bertram]

Hi,

I must say I made the milestone named 0.4.9 by respect to the former team which strove a lot to make it happen already.
As for me, I'd rather name the release 0.5.0 once we have a even basic fog of war implemented. (Now you know the evil plan, I'll need to make you disappear on our next lan. ;])

But we can rename the milestone, it's just a name after all.

What is the consensus here?

Regards,

[hwoarangmy]

For me, when we name a release X.Y.Z,
Z = minor modification : when we have a release candidate that fails and we need to change something to make it work
Y = major modification : we add new functionnalities
X = Different version. When changes are so huge that backward compatibility is broken.

For me we should name a release 1.0.X when we will have a functional playable game : creatures fighting, proper winnable levels, ...
If we lack models/spells/traps/functionnalities/campaign, it's not a problem.

As stated, we have worked well on the release lately and we can consider that there are major changes (full server paradigm could justify that by himself IMHO).

But again, it's just a name. And until we have a 1.X.X, it doesn't matter much

[Bertram]

I'll be honest, I think we've moved from 0.4.8 to 0.7.1 already.

More seriously, I wouldn't change the version now we're becoming close to a release, as everybody is used to call it 0.4.9, and because we lack normal support (it's plainly my fault, I'll take the blame on the next lan. ;])

Here is what i have in mind, just tell me whether I'm wrong somewhere:

- 0.4.x: Basic but functional gaming experience.
--> Scope more or less defined, we have ~15 issues left before release.
--> The most annoying thing left is to sort out the cmake stuff + make OD packageable.

- 0.5.x: Start on polishing the base.
--> starting addition on evil paths.
--> Basic fog of war: My proposal: Only the tiles that have been seen once by your creatures are visible. You can drop creatures only on visible tiles. Enemy creatures are visible only when on a visible tile.
--> Models are using normals
--> Creature mood system to make the game more strategical.
--> Creature class sounds.

- 0.6.x: Maturing
--> Spells and traps.
--> Doors?
--> Evil paths more or less implemented.
--> A lot more is configurable through ... configuration files.
--> Editor much more functional.
--> A server lobby system?

- 0.7.x: Let's make a full game
--> Basic campaign support
--> Angel script support reboot.
--> Finish/Review how culling is done.
...

Let's not go too far. There is already a lot to do. From what I see, 0.5 and 0.6 tasks could be exchanged without any counter-thought. But I'd request we don't start on campaign without quite some good base gameplay or the campaign will be a boring suite of alike-looking scenarii.

Lan is so cool already as it's making the game playable an replayable with friends.

Best regards,

[hwoarangmy]

I will add at least in 0.5 fixing creatures fighting behaviour. We have to define what we want and implement it. The discussion has been started on github by Danimal but I think it deserves a forum thread.

Concerning fog of war, I think we could implement a real one based on what creatures and claimed tiles see, not showing what happens on non claimed tiles or outside creatures line of sight. For now, every event is sent so every client but we don't have to show everything. Of course, in the end, it would be much better if we don't send events that a player do not see. The complex thing will be to try to relate every event to tiles so that the server knows what to send to a player or not. But this can be done later.
BTW, this is a nice discussion that would also deserve its own thread (for later search purposes)

[Akien]

BTW, this is a nice discussion that would also deserve its own thread (for later search purposes)

Agreed. Maybe a moderator could split the thread at Bertram's comment into a "Development roadmap" thread?

[Bertram]

BTW, this is a nice discussion that would also deserve its own thread (for later search purposes)

Yeah, we tend to discuss stuff everywhere and this should be split. But I like the freedom in this, somehow.

[hwoarangmy]

Yeah, we tend to discuss stuff everywhere and this should be split. But I like the freedom in this, somehow.

Yes, I agree and I'm not giving orders. I was just thinking that in a few weeks, if I was to check what we decide, I think I would not search for the roadmap in a thread called "Linux package doesn't run"

[Danimal]

Split and made sticky:
viewtopic.php?f=35&t=5821

[andrewj]

Well I feel a bit foolish now, the 0.4.8 linux version does actually run, the OGRE config window was sitting _behind_ my fullscreen terminal and only now did I have the sense to unfullscreen the terminal and look behind it. It didn't help that ALT-TAB doesn't show the OGRE window either, probably because the Xt toolkit is so old and does not participate in modern window manager protocols.

I managed to compile OD today, but it segfaults when starting a new game (or Edit map).

Also there is a problem in the CMakeLists.txt -- apparently CMAKE_COMPILER_IS_GNUCXX is not defined, so the CXX_FLAGS never get the proper flags, especially -std=c++11

The following is not a fix, just shows what I did to get it to compile:

{l Code}: {l Select All Code}

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -37,7 +37,7 @@ if (BORLAND)
   set ( CMAKE_CXX_FLAGS_RELEASE  "/RELEASE_FLAGS_GO_HERE" )
 endif ()
 
-if (CMAKE_COMPILER_IS_GNUCXX)
+if (TRUE)
   set ( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall -Wunused -Wno-deprecated -fno-strict-al
   list( APPEND CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS}   -g -O2")
   set ( CMAKE_CXX_FLAGS_RELEASE  "${CMAKE_CXX_FLAGS}   -O3 " )


[Akien]

Also there is a problem in the CMakeLists.txt -- apparently CMAKE_COMPILER_IS_GNUCXX is not defined, so the CXX_FLAGS never get the proper flags, especially -std=c++11

The following is not a fix, just shows what I did to get it to compile:

{l Code}: {l Select All Code}

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -37,7 +37,7 @@ if (BORLAND)
   set ( CMAKE_CXX_FLAGS_RELEASE  "/RELEASE_FLAGS_GO_HERE" )
 endif ()
 
-if (CMAKE_COMPILER_IS_GNUCXX)
+if (TRUE)
   set ( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall -Wunused -Wno-deprecated -fno-strict-al
   list( APPEND CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS}   -g -O2")
   set ( CMAKE_CXX_FLAGS_RELEASE  "${CMAKE_CXX_FLAGS}   -O3 " )


Hi andrewj, this was indeed a problem but it has been fixed recently in the development branch. You should make sure you are using the latest revision of the development branch; we did create a stable branch a while ago but we haven't kept it in sync with the development one (which is quite stable actually).

[Bertram]

Hi there,

@andrewj
I do really hope you'll be able to compile the latest development branch, you might love it.

@Akien
Once the Christian cross bug, and the hidden ones uncovered thanks to latest hwoarangmy's patch, I think I should merge it all back to stable.
I'll also redo a rolling release at that moment.

[Akien]

@Akien
Once the Christian cross bug, and the hidden ones uncovered thanks to latest hwoarangmy's patch, I think I should merge it all back to stable.
I'll also redo a rolling release at that moment.

Yes I was thinking too that Danimal deserves to get to play with the awesome improvements that we've got lately, both to the GUI and the gameplay.

I'm a bit unsure about how to best use the stable branch, since our pull request reviewing system already ensures a respectable stability in the development branch. Should we consider that the stable branch is the one that curious players/developers should try to compile to enjoy OD in the best way? How do you envision the task to keep it in sync with the stable changes on the dev branch?

[Danimal]

I can see in github you are implementing pretty nice things

[Bertram]

Yes I was thinking too that Danimal deserves to get to play with the awesome improvements that we've got lately, both to the GUI and the gameplay.

Yes, somehow we're all working for him.

I'm a bit unsure about how to best use the stable branch, since our pull request reviewing system already ensures a respectable stability in the development branch. Should we consider that the stable branch is the one that curious players/developers should try to compile to enjoy OD in the best way? How do you envision the task to keep it in sync with the stable changes on the dev branch?

Rather simply. We add features, we notice bugs and we're a following cycles where either features get added and more bugs are there, and where bugs get fixed and there are less of them.
I won't enter the technical theory of testing and quality assurance according to design goals but simply put, when we think the game has reached a state where it's stable enough and has reached a correct subset of features, and feels like to reach a loop in term of usability, we should talk about merging to stable.

For instance, I wouldn't do it just right now, since we have small bugs we can flag as obvious flaws in the gameplay. But once, we have fixed the obvious stuff, then yeah, let's merge to stable.

Also, I don't want to patronize here. I mean I never meant I had the most skills of the clearest vision. You guys may have better skills or diploma in some area than me but what counts to me is that we are a bunch of guys just trying to bring a game out of this code and we help each others in that attempt.

Best regards,

[Danimal]

Yes, somehow we're all working for him.

Darn, you discovered my subliminal orders, now ill have to resort to mood drugs, you better dont force me to use the lobotomy on you all...

Somehow we have made a stable team, get to agree with each other and put this concept piece of code to work, thats not something to take ligthly

[Bertram]

Eh eh.