Chaosforge Forum

  • March 28, 2024, 13:40
  • Welcome, Guest
Please login or register.



Login with username, password and session length
Pages: [1]

Author Topic: dialorl-svn build error  (Read 5184 times)

icelus

  • Private FC
  • *
  • Offline Offline
  • Posts: 6
  • Lost Soul
    • View Profile
dialorl-svn build error
« on: June 01, 2012, 18:36 »

I think the file vlualibrary.pas in fpcvalkyrie is missing; in r387 a bunch of stuff was refactored to use it, and the log message indicates it's the main change.... but there's no file that I can see.

In r984 diablorl gives me errors in rlthing: rlthing.pas(26,42) Error: Unknown class field or method identifier "FPosition" (using the 2.6.0 fpc compiler - it refused to build with anything less).

Stepping back to r983 gives me errors in rlview (probably because I had to step to r386 of fpcvalkyrie to get a build).

First occurrence without that is r946; that has errors in rlui (more missing modules from the library).

First occurrence without those errors is 944. That needs vlualibrary (the same we started off missing).

First occurrence without that is r940. This has overloading errors in rllua/rlplayer (State.Push is an ambiguous overload). I backported the fixes from r984 into 940 and fixed these.

Unfortunately, there's an ifOnHit (undefined flag from TFlags) still outstanding. I wasn't able to work out how to fix this in the time available.

ALl of which is a long way of saying I think svn doesn't build at the moment. I did try though! I really wanted to play this.
Logged

Tavana

  • Local Inquisitor
  • Brigadier General
  • *
  • *
  • Offline Offline
  • Posts: 663
    • View Profile
Re: dialorl-svn build error
« Reply #1 on: June 01, 2012, 20:01 »

The libraries are being rewritten quite often, and sometimes they break syntax. If you really want it to compile, I suggest getting onto IRC on Quakenet, and joining #Chaosforge - epyon is the name you're looking for. Prod him a little bit and he can update the svn files to work, and give a bit of advise on which versions of things to use.

That being said, if you're just wanting to play the game, try this page, as there are downloads which may be of interest to you.
« Last Edit: June 01, 2012, 20:07 by Tavana »
Logged
Common words do not mean common understanding. Language is mercurial. Meanings are never constant.

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4562
    • View Profile
    • http://chaosforge.org/
Re: dialorl-svn build error
« Reply #2 on: June 01, 2012, 22:07 »

It's not missing, you need to add the /lib library to your unit path.
Logged
at your service,
Kornel Kisielewicz

icelus

  • Private FC
  • *
  • Offline Offline
  • Posts: 6
  • Lost Soul
    • View Profile
Re: dialorl-svn build error
« Reply #3 on: June 02, 2012, 08:11 »

Thanks for the help on building this. I wanted to try the latest version.

This is not so trivial at the moment to build on my system. In case anyone else runs into problems, a rough guide for debian/lenny amd64 is (assuming you followed COMPILING.linux and it didn't work):

cd src
make clean
FPCDIR=/usr/lib/fpc/2.6.0/ fpcmake
make  COMPILER_UNITDIR=../../fpcvalkyrie/libs/ FPCOPT="-k-lm"

This probably builds (it does for me). But before you celebrate, try

cd ../bin
./mpq

If this works, congratulations. If you get "no such file or directory", this is a weird interaction bug with fpc, the linker, and the dynamic linker and your mpq has a bad interpreter. For me at least, ./rl ran fine, and you can use that to find out what your interpreter should be:

readelf -l rl | grep interpreter

This will produce something like:

 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Check your mpq interpreter is bad:

readelf -l mpq | grep interpreter

  [Requesting program interpreter: /lib/ld64.so.1]

Luckily this is fixable.

cd ../src
make clean
make FPCOPT="-k-lm -k--dynamic-linker=/lib64/ld-linux-x86-64.so.2" COMPILER_UNITDIR=../../fpcvalkyrie/libs/

Note the string after --dynamic-linker should be the "good" interpreter you got from /bin/rl (or if not there, any other working exe on your machine).

For me at least, mpq now runs, and rl can be started. However, in the "select name" box, pressing enter sends focus to the shell behind (seems to automatically background rl without redrawing the screen). Be very careful what you type while you're wondering when it's going to load (it isn't going to load).

This got me incrementally further forward anyway.

Best wishes.
Logged

icelus

  • Private FC
  • *
  • Offline Offline
  • Posts: 6
  • Lost Soul
    • View Profile
Re: dialorl-svn build error
« Reply #4 on: June 02, 2012, 11:36 »

The problem I reported before was in fact a hang. It was quite an interesting one. Essentially when Tristram is created, the shops are reloaded. Each of them is looking for items to sell, and there's no limit on the number of times they'll try random generation to get acceptable items. All that makes an item acceptable is a positive price and having no spell on it, which should be no problem because almost all items have prices and most don't have spells. However, the way items are created is to use data from a master lua table. The Delphi code in charge of building an item is very forgiving about fields that might not be present, and simply fills in defaults, including a value of zero for price. The fields are all there in the master table, but the call TLuaTable.TryGetField doesn't set its result value in the case of success. That means that an arbitrary collection of properties on an object are not initialised, they just come from the defaults. So: every single item that the shop refiller tries to generate has a zero price, even though the lua datastructures are being initialised correctly. Loading Tristram therefore hangs.

The following patch fixes that bug and one other less interesting one. On my machine, running the sytem in debug mode segfaults. The culprit is ClearInterrupts which generates a range exception because the iterator is a Word instead of an Integer (I don't know why this should be, but it is reproducible). Now that except occurs in a constructor, and in fact in a naughty constructor which is doing work before its ancestors have been initialised. One of those ancestors has prev and next pointers to a linked list of like objects, and those prev and next pointers always point to something valid (in the case of the single item list, they both point to the object itself). When an attempt is made to Detach the uninitialised ancestor, it tries to shrink the list using its prev and next pointers, but they are null (because that naughty constructor TTextIODriver.Create is doing work before initialising it). The result is crash.

After applying this patch you should find you can walk around Tristram. This is how far forward I am. Hopefully I can sit down and play now!

Index: src/viotypes.pas
===================================================================
--- src/viotypes.pas    (revision 571)
+++ src/viotypes.pas    (working copy)
@@ -125,10 +125,10 @@
 { TIODriver }
 
 procedure TIODriver.ClearInterrupts;
-var iCount : Word;
+var iCount : Integer;
 begin
   FOnQuit := nil;
-  for iCount := 0 to High(FInterrupts) do FInterrupts[iCount] := nil;
+  for iCount := Low(FInterrupts) to High(FInterrupts) do FInterrupts[iCount] := nil;
 end;
 
 procedure TIODriver.RegisterInterrupt ( aCode : TIOKeyCode; aInterrupt : TIOInterrupt );
Index: src/vluatable.pas
===================================================================
--- src/vluatable.pas   (revision 571)
+++ src/vluatable.pas   (working copy)
@@ -892,6 +892,7 @@
 begin
   lua_getfield( FState, -1, PChar( aKey ) );
   if lua_isnil( FState, -1 ) then Exit( False );
+  Result := True;
 end;
 
 procedure TLuaTable.RunGetField ( const aKey : AnsiString; ReqType : Byte ) ;
@@ -904,6 +905,7 @@
 begin
   lua_getfield( FState, -1, PChar( aKey ) );
   if lua_type( FState, -1 ) <> ReqType then Exit( False );
+  Result := True;
 end;
 
 function TLuaTable.IsField ( const aKey : AnsiString; ReqType : Byte ) : Boolean;
Logged

Kornel Kisielewicz

  • God Hand
  • Apostle
  • *
  • *
  • Offline Offline
  • Posts: 4562
    • View Profile
    • http://chaosforge.org/
Re: dialorl-svn build error
« Reply #5 on: June 03, 2012, 17:04 »

First of all, any help on coding DiabloRL is really welcome -- please come to #chaosforge on QuakeNet if interested!

That said, the current SVN status is very volatile - I did a serious refactoring recently, and there was no one to beta test it since then. Moreover, not everything that was there before the refactoring is reimplemented (most notably skills and spells UI's are missing). I or "you" (yep, that's her nick) will reimplement at some moment, but that might take some time.

Also, due to the fact that none of the primary devs uses Linux, compiling on this platform might still be a little rough.
Logged
at your service,
Kornel Kisielewicz

you

  • Programmer
  • Local Inquisitor
  • First Sergeant
  • *
  • *
  • Offline Offline
  • Posts: 109
  • I am You!
    • View Profile
Re: dialorl-svn build error
« Reply #6 on: June 05, 2012, 08:57 »

I really wanted to play this.
JESUS CHRIST IT’S A LIVING DIABLORL COMMUNITY MEMBER! GET IN THE CAR, QUICK!
"you" (yep, that's her nick) will reimplement at some moment, but that might take some time.
OP left me no choice but to do it ASAP.
Logged
Pages: [1]