Page 1 of 2

About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 4:00 am
by marzo
Just to give a warning: I made a truck-load of commits last night. The 1.4.05cvs snapshot will most likely be buggy. But it will have many cool things. We would appreciate the bug reports, so keep them coming!

Among the new and interesting things: loads of new things can be edited in ES now, and loads of previously hard-coded data is now editable too. A good chunk of data from the originals has been decoded, and now you will see some foes that can actually see invisible beings or weapons that always hit. Combat will be much deadlier, particularly against foes that have high hit points and the tournament flag set (such as the banes, the Fiend).

There is some important things, though: since a lot of new information has been decoded ("lot" as in "many *bits*"), and older versions of ES did *not* save this information, there is much that has been lost in weapon, ammo and monster data. This would affect all current mods except for SI Fixes. There is a tool in ES to fix this, though.

All in all, I just wanted to give a warning.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 4:39 am
by MeddlingMonk
I can't seem to build exult in etiher Leopard or Fedora 9.

For Leopard, it craps out in configuring, ending with:
checking whether to build the GIMP plugin... no
configure: error: conditional "AMDEP" was never defined.
Usually this means the macro was only invoked conditionally.
For Fedora, it configures apparently fine when when I try 'make' I get (in it's entirety):
make all-recursive
make[1]: Entering directory `/home/meddlingmonk/Desktop/exult'
Making all in files
make[2]: Entering directory `/home/meddlingmonk/Desktop/exult/files'
Making all in zip
make[3]: Entering directory `/home/meddlingmonk/Desktop/exult/files/zip'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -Wall -MT zip.lo -MD -MP -MF .deps/zip.Tpo -c -o zip.lo zip.c
gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -Wall -MT zip.lo -MD -MP -MF .deps/zip.Tpo -c zip.c -o zip.o
zip.c:172: warning: 'free_linkedlist' defined but not used
zip.c:231: warning: 'write_datablock' defined but not used
mv -f .deps/zip.Tpo .deps/zip.Plo
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -Wall -MT unzip.lo -MD -MP -MF .deps/unzip.Tpo -c -o unzip.lo unzip.c
gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -Wall -MT unzip.lo -MD -MP -MF .deps/unzip.Tpo -c unzip.c -o unzip.o
mv -f .deps/unzip.Tpo .deps/unzip.Plo
/bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -o libminizip.la zip.lo unzip.lo -lasound
mkdir .libs
ar cru .libs/libminizip.a zip.o unzip.o
ranlib .libs/libminizip.a
creating libminizip.la
(cd .libs && rm -f libminizip.la && ln -s ../libminizip.la libminizip.la)
make[3]: Leaving directory `/home/meddlingmonk/Desktop/exult/files/zip'
make[3]: Entering directory `/home/meddlingmonk/Desktop/exult/files'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flat.lo -MD -MP -MF .deps/Flat.Tpo -c -o Flat.lo Flat.cc
g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flat.lo -MD -MP -MF .deps/Flat.Tpo -c Flat.cc -o Flat.o
In file included from Flat.cc:32:
utils.h: In function 'std::string ReadStr(char*&, int)':
utils.h:258: error: 'strchr' was not declared in this scope
utils.h:260: error: 'strncpy' was not declared in this scope

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 6:03 am
by marzo
utils.h: In function 'std::string ReadStr(char*&, int)':
utils.h:258: error: 'strchr' was not declared in this scope
utils.h:260: error: 'strncpy' was not declared in this scope
Add this line below "#include "common_types.h"":

Code: Select all

#include "string.h"
and see if it compiles.
configure: error: conditional "AMDEP" was never defined.
Hm. Try removing the line with "AC_PATH_XTRA" and see if it configures.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 9:20 am
by MeddlingMonk
OK, I think I'm more confused than usual.

When you say
Try removing the line with "AC_PATH_XTRA" and see if it configures.
about the Mac error, I would have assumed that I need to edit the file 'configure' but I can't find that line in 'configure'.

At the same time, you say
Add this line below "#include "common_types.h"":

#include "string.h"
in response to my Fedora error and given the context I would have assumed that 'makefile' needed to be edited...but I can't find the necessary line in that, either.

Either I need to be editing files that aren't obvious to me (which wouldn't be surprising because I might be naive in thinking that if it fails to configure, edit 'configure', if it fails to make, edit 'makefile') or something is very wrong.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 9:33 am
by marzo
about the Mac error, I would have assumed that I need to edit the file 'configure' but I can't find that line in 'configure'.
Sorry, it is in configure.ac; you will have to run ./autogen.sh again.
I would have assumed that 'makefile' needed to be edited...
Again, sorry; it is at the utils.h file itself.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 4:14 pm
by monotremata
Removing the AC_PATH_XTRA line gets past the Gimp error but it returns a problem Ive been having since about the end of April compiling it from source on 10.5..

checking whether to build Exult Studio... no
checking whether to build the GIMP plugin... no
configure: creating ./config.status
config.status: creating exult.spec
config.status: creating Info.plist
config.status: error: cannot find input file: Makefile.in

and it ends there.

My macs drive died a couple months ago and even though I recovered my old Exult folder it wouldnt let me update it via CVS anymore so I had to start over. That old folder is from March 18 and was the last time I updated and compiled it.
When I started trying again maybe last week in April or so it started giving me problems.. Although I think before I updated the source and tried this today, the Makefile it was stopping on was in the /gamemgr directory.

A curious thing I noticed when running ./autogen.sh is this line that appears now:
configure.ac:160: required file `./ltmain.sh' not found
You are now ready to run ./configure

Looking in my old March exult folder, which luckily is still playable, ltmain.sh is there.. Now though no matter how many times I start from scratch or update that file never shows up. For kicks a couple of weeks ago I copied it from my old source to the newer one and tried it again. Got a little farther but I cant remember where it stopped up at that time..

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 4:58 pm
by marzo
Removing the AC_PATH_XTRA line gets past the Gimp error
The AC_PATH_XTRA is not related to Gimp at all; it is for X libraries -- compilation/linking is failing on X11 without it (at least on Ubuntu).
configure.ac:160: required file `./ltmain.sh' not found
config.status: error: cannot find input file: Makefile.in
Both of those files should be generated by ./autogen.sh and ./configure. What version of libtool, libtoolize, automake and autoconf are you using? Also, in ./configure.ac, try replacing "AM_PROG_LIBTOOL" by "AC_PROG_LIBTOOL" and see if ./ltmain.sh gets generated.

Meanwhile, I will look and see if there is anything unusual in /gamemgr that can be preventing the generation of makefile.in.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:06 pm
by monotremata
Same result changing AM_PROG_LIBTOOL to AC_PROG_LIBTOOL..

How would I find the version numbers of those tools?
Im using whatever comes installed with Mac OS X/X-Code, Im up to 10.5.3 now..

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:33 pm
by marzo
In a command shell, type the lines

Code: Select all

$ libtool --version
$ libtoolize --version
$ automake --version
$ autoconf --version
(and this is just a shot in the dark)
As for the MacOSX: you may want to ask help from our resident expert, Fingolfin; he is sometimes on #exult on IRC.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:42 pm
by monotremata
automake - 1.10
autoconf - 2.61

libtool keeps telling me 'libtool: unknown option character `-' in: --version'

and libtoolize is apparently not even installed on the system?
Im going to go check up on that. Perhaps I just dont remember doing that on my previous system and need to grab it with Fink.. Maybe I just solved my own problem..

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:46 pm
by monotremata
Ok quick note.. There is no libtoolize on Mac OS X.
Its called glibtoolize here. Its 1.5.22.

I seem to remember once compiling something that had me make a symlink that made glibtoolize appear as libtoolize to stuff.
Now I just have to find out what i did...

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:54 pm
by marzo
You can try doing that symlink and see if it works. Something like the following might work:

Code: Select all

$ whereis glibtoolize                       # to find where it is
$ ln -s -T path/to/glibtoolize path/to/libtoolize

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:54 pm
by monotremata
Ok one last redundant post (there doesnt seem to be any way to just edit the one before??)..

In autogen.sh I changed the following line:

libtoolize --force --copy

and just made it

glibtoolize --force --copy

and ./autogen.sh ran fine, ./configure ran fine.
Compiling now.. We'll see if it finishes hehe.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:55 pm
by marzo
In autogen.sh I changed the following line:
Yeah, that works too :-)

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:56 pm
by monotremata
AHH thanks!! Thats what Ive been googling for the past few minutes was how to do that haha.

Re: About the new (next?) snapshot...

Posted: Wed Jun 04, 2008 5:58 pm
by marzo
(That was about the first thing I made a point of learning in Linux and not forgetting: how to create sym/hard links. I have been using hardlinks in XP -- and would use symlinks too, if XP had them -- for a while, and they are incredibly handy.)

Re: About the new (next?) snapshot...

Posted: Thu Jun 05, 2008 9:12 am
by MeddlingMonk
My turn, now. :)

Starting on the Mac side...removing AC_PATH_XTRA from configure.ac didn't help at all. But changing libtoolize --force --copy to glibtoolize --force --copy in autogen.sh did (apparently since 'make' is still running, so far without errors). And that's very interesting, maybe, because unlike Monotremata, I haven't been having ANY trouble building on 10.5 since late last year when patches were made to take 10.5 into account. It's only this very latest snapshot that's caused me trouble on the Mac since then and I've never had to edit autogen.sh before now.

Now, on the Fedora 9 side, I added the suggested line to utils.h and now am back to an error I've been getting since upgrading from 8 to 9:
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flex.lo -MD -MP -MF .deps/Flex.Tpo -c -o Flex.lo Flex.cc
g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flex.lo -MD -MP -MF .deps/Flex.Tpo -c Flex.cc -o Flex.o
In file included from Flex.cc:28:
Flex.h: In copy constructor 'Flex::Flex(const Flex&)':
Flex.h:58: error: 'memcpy' is not a member of 'std'
Flex.h:59: error: 'memcpy' is not a member of 'std'
Flex.h: In member function 'Flex& Flex::operator=(const Flex&)':
Flex.h:66: error: 'memcpy' is not a member of 'std'
Flex.h:67: error: 'memcpy' is not a member of 'std'
make[3]: *** [Flex.lo] Error 1
I'm not sure what to make of that except that there are usually teething troubles after an upgrade. Possibly there's a bug in the build tools that will be corrected eventually. Maybe it's because something is a newer version (Fedora often includes newer versions of things, even betas, than other distros). Would you need any info other than how make terminates?

Re: About the new (next?) snapshot...

Posted: Thu Jun 05, 2008 9:33 am
by marzo
Hm. Flex.h hasn't been touched for 3 years, 8 months; so I'd guess Fedora 9 is to blame. At the top of that file (just above "class DataSource;") add the following line and try to compile:

Code: Select all

using std::memcpy;
If it still doesn't compile, replace the line you just added by the line

Code: Select all

#include 
(also, above I told you to use

Code: Select all

#include "strings.h"
in utils.h; replace that instance by the above one too). If this does work (and the one in utils.h too), complain to the Fedora 9 devs for shipping either, a broken compiler or a non-standard standard library ( should be included automatically from ).

Re: About the new (next?) snapshot...

Posted: Thu Jun 05, 2008 9:55 am
by MeddlingMonk
The Mac build is definitely working.

As for F9, I tried both suggestions. The first didn't seem to make any difference. Trying the second gave me
make[3]: Entering directory `/home/meddlingmonk/Desktop/exult/files'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flat.lo -MD -MP -MF .deps/Flat.Tpo -c -o Flat.lo Flat.cc
g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flat.lo -MD -MP -MF .deps/Flat.Tpo -c Flat.cc -o Flat.o
mv -f .deps/Flat.Tpo .deps/Flat.Plo
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flex.lo -MD -MP -MF .deps/Flex.Tpo -c -o Flex.lo Flex.cc
g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Flex.lo -MD -MP -MF .deps/Flex.Tpo -c Flex.cc -o Flex.o
mv -f .deps/Flex.Tpo .deps/Flex.Plo
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Table.lo -MD -MP -MF .deps/Table.Tpo -c -o Table.lo Table.cc
g++ -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../headers -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DXWIN -O2 -Wno-long-long -g -O2 -MT Table.lo -MD -MP -MF .deps/Table.Tpo -c Table.cc -o Table.o
Table.cc: In member function 'void Table::IndexTableFile()':
Table.cc:57: error: 'exit' is not a member of 'std'
which is a little different although it's still griping about flex.

I think the problem is with F9, too. The only thing I've been trying to build on that is ScummVM which has been going just fine but that means less than nothing (other than maybe that the compiler is not simply broken).

Re: About the new (next?) snapshot...

Posted: Thu Jun 05, 2008 11:08 am
by monotremata
Yeah this was the first time I had to change the autogen.sh too.
However with the symlink from glibtoolize to libtoolize in place I built it again from scratch last night and it worked just fine.
But like I said last time I actually updated my original source looked like it was March and I hadnt played my SI game since then.
I do seem to remember quite awhile ago having to make that symlink for something else I was trying to build. I had just forgotten about that part until I had to find the version numbers for Marzo and discovered the glibtoolize situation via google.

I even figured out how to get it into X-Code last night as well and built it fine in that. Now if only I could figure out how to make an .app that you could copy to your Applications folder without breaking hehe.

Re: About the new (next?) snapshot...

Posted: Thu Jun 05, 2008 1:09 pm
by marzo
Table.cc:57: error: 'exit' is not a member of 'std'
Bad, bad F9. Below

Code: Select all

#include 
, add this line:

Code: Select all

#include 
and see if it compiles.

Out of curiosity, what version of GCC/G++ does F9 use?

Re: About the new (next?) snapshot...

Posted: Fri Jun 06, 2008 3:55 am
by MeddlingMonk
Monotremata:
I even figured out how to get it into X-Code last night as well and built it fine in that.
How'd you manage that?


Marzo:
#include

, add this line:

#include
No good.

I misspoke before: I've been trying to build Pentagram and get the same errors.
Out of curiosity, what version of GCC/G++ does F9 use?
4.3.0, which seems to match what Fink is using on the Mac side, so I think it's more likely to be bugs on the F9 end. Still,I wondering if the compatibility libraries might help. At this stage anything is worth trying and it can't do any harm to try.

Re: About the new (next?) snapshot...

Posted: Fri Jun 06, 2008 4:07 am
by MeddlingMonk
Monotremata:

I forgot, I'm not sure of course about building Exult with Xcode, but from terminal after 'make' finishes just do 'make bundle' and you'll have your app. But there's one small problem (and I've submitted a bug report about it): when you do make bundle (at least with 10.5), the command fails to put the file exultmsg.txt into Exult.app/Contents/Resources/data. Without that file there SI won't run but of course it's simple to manually add it.

Re: About the new (next?) snapshot...

Posted: Fri Jun 06, 2008 6:07 am
by marzo
Hm. A bit of googling led me to this. Seems that the fault actually may lie with GCC 4.3 after all. Which seems odd considering that it compiled on the Mac.
No good.
O>o. Did a new error appear or was it the same error? Because std::exit *is* at ; and if adding the include to Table.cc did not fix that, then F9 has broken headers. Can you confirm that there is a file at "/usr/include/c++/" named "cstdlib"?

Re: About the new (next?) snapshot...

Posted: Mon Jun 09, 2008 5:06 pm
by monotremata
To get the code into X-Code I just followed the directions here:
http://developer.apple.com/documentatio ... 9-BBCJABGC

To get it to make the app I just made a New Target and set the build command to make bundle instead of just make.


My .app doesnt have exultmsg.txt in it but SI seems to run just fine regardless.
Although Exult does quit when I exit all the time now but other than that its working..

Re: About the new (next?) snapshot...

Posted: Tue Jun 10, 2008 4:30 am
by marzo
Although Exult does quit when I exit all the time now
Yes, I already bumped into that and fixed it. I have also uploaded the fixes.

Re: About the new (next?) snapshot...

Posted: Tue Jun 10, 2008 8:11 am
by monotremata
Awesome!! Ill have to update and recompile today when I get home!!

A bit of good news...

Ive managed to make a snapshot of the current CVS just like the older 1.2 binary Mac OS X release on the download page.

I was trying my hardest to figure out how to get the app to work in my normal old /Applications/Ultima 7 folder (where my blackgate and serpentisle folders live along with Exult 1.2) and finally got it.
All it took was to copy the contents of the /data folder inside the .app (or the freshly compiled source code directory) into the /data folder thats in the Ultima 7 directory.
Now the app works just fine if I move it out of the source folder.
You just have to leave it in the same directory as the /data folder.

Now if only we could get Exult to use its internal data directory we could have a single standalone .app! Whats wierd is, I noticed while using Console to start it up, that Exult sets its 'dpath' to that internal Data folder, but no matter what, it wont use it and quits saying it cant find exult.flx even though its in the Exult.app itself. Gotta have the seperate external /data folder with the .flx files in it.

I have a .dmg I packaged up last night but didnt have time to get over here and post it up.
Ill update the source when I get home and re-package it, perhaps we can start having regular OS X cvs snapshots once again!

Re: About the new (next?) snapshot...

Posted: Tue Jun 10, 2008 10:40 am
by EarthquakeDamage
What do the Tournament and Zombie flags do, anyway?

Also, I've noticed the "can't die" flag does nothing. The NPC's object type (specifically, the monster data) is the only way to affect that.

Re: About the new (next?) snapshot...

Posted: Tue Jun 10, 2008 11:29 am
by marzo
Tournament: NPC can't take damage or die while the flag is set. If the damage from an attack is equal to the NPC's current hit points, the NPC's usecode function is called with event equal to 7 to signal his "death". In the usecode, certain checks can be done to (for example) determine cause of death and so on and, if needed, clear the flag and kill the NPC.

Zombie: Used in SI to mark certain conditions for alternate dialog or NPC behavior. For example, companions and Cantra after being possessed by the banes.

Can't die and immunities flag can't be set and refer to monster data.

Re: About the new (next?) snapshot...

Posted: Sat Jun 14, 2008 6:38 am
by MeddlingMonk
Seems that the fault actually may lie with GCC 4.3 after all. Which seems odd considering that it compiled on the Mac.
I suppose that's better than it being an OS problem. Maybe. Either way, I have to wait for it to be fixed.

Re: About the new (next?) snapshot...

Posted: Sun Jun 15, 2008 9:23 am
by Philipp
Hello,

first of all let me thank you, Marzo, for the still ongoing work on exult. It's good to know the project lives.

So here's what I experienced with 1.4.05cvs (SI only, with sifixes):

(1) As I started a new game because my old saves proved buggy I encountered the guy in the Knights' Test who appears next to the secret door. He keeps reappearing all the time and was extraordinarily difficult to kill (hey, I'm playing on ''hardest''/+3). Actually I don't think the NPC itself respawns but it's his sprites that got messed up somehow. (And I had to switch off the sound too, can't stand this noise.)

(2) In SS, as usual the first quest for me to complete outside of monitor, I realized that either the avatar isn't willing to fight and has to be forced by repeatedly clicking the target with the mouse, or his companions (Dupre and Shamino so far, Lolo's still idle in his hotel) won't act by themselves and even my hitting the mouse doesn't move them. They won't stand a chance against nagas as pacifists* ...

Playing under this condition is no fun at all, so I quit the game in favor of a bug report. Should I put it in the tracker, too?


* Only a minor note: Conducts would make an excellent addition to the game, at least for people like me who know the intended way of finishing it quite well. Vegetarian, pacifist, no killing knights for cash, atheist (now that it's possible to meditate at shrines in BG), weaponless, armorless, carpetless, illiterate (with some exceptions) etc. -- shouldn't be difficult for exult to keep track of.

Re: About the new (next?) snapshot...

Posted: Sun Jun 15, 2008 12:38 pm
by alagner
To point no.2: Yup, I encountered that also in BG, but - the Avatar gets close to the target, but does not attack, neither does he when targert is dbl clicked. The key was to manually move as close as possible and then double-click on the monster.

There's also a strange bug with dragon that attacks itself (I posted it in a different topic) as well as the fact that gazers and dragons don't attack while they are invisible - and in original they did.

Re: About the new (next?) snapshot...

Posted: Mon Jun 16, 2008 4:46 am
by marzo
Noted; thanks for the reports. (still trying to figure out what is wrong)

Re: About the new (next?) snapshot...

Posted: Mon Jun 16, 2008 12:20 pm
by djolk
I've compiled the newest snap shot with some difficulty using gcc 4.3 and after playing through BG a bit I decided to use 'help' spell which caused the game to lock.
Now, apparerntly that save game is corrupted and locks after I walk around for a bit. Lasts longer when it's light outside.

I've tried a few times, once I got a glibc error with back trace. I will try to post it when I can get that computer online (Stupid satellite internet)

I had to minorly modify several ( a lot actually ) files to get it to compile so this could just be me.

daniel

Re: About the new (next?) snapshot...

Posted: Tue Jun 17, 2008 3:01 pm
by Donfrow
You said:


There is some important things, though: since a lot of new information has been decoded ("lot" as in "many *bits*"), and older versions of ES did *not* save this information, there is much that has been lost in weapon, ammo and monster data. This would affect all current mods except for SI Fixes. There is a tool in ES to fix this, though.

Just to be sure before I install it, and kind of a dumb question, but if I install this and don't use the tool in ES to fix it, can I save the current map and use it later, or does it have to be done early on to avoid messing things up even more.

Also, what is this tool you speak of? :P

Re: About the new (next?) snapshot...

Posted: Tue Jun 17, 2008 7:47 pm
by marzo
The tool is in ES itself (Tools->Fix old shape info). The only things affected (either by old versions of ES or by the tool) are data in weapons.dat, ammo.dat and monster.dat; that is, some weapon, ammo and monster stats and/or abilities. Everything else is untouched.

Re: About the new (next?) snapshot...

Posted: Fri Jun 20, 2008 9:57 am
by Malignant Manor
I finally downloaded it and here are some things I've noticed. Some have been mentioned, but I elaborate a little more.

The problem with not being able to hit enemies seems to stem from larger shape sizes and only with melee weapons. I literally have to teleport in order to be able to swing. It seems more like the center of the object is considered for range instead of any part of the shape. Ranged weapons worked okay. Sometimes the range seemed out of whack and they went right next to someone to use a ranged attack.

Invisible creatures won't attack anymore like previous versions of Exult. One noticable change is that the invisibility of previous versions for nonparty members was the semi transparent white and now it truely is invisible (probably how it is in the original be could be causing a problem)

Creatures of all types seem to sometimes damage themselves or other monsters (a single foe in the same onscreen section seems to stay alive sometimes and other times it will kill itself) even to the point of death. This seems to be more prevailent when the they cannot pathfind. A lot of monsters didn't attack the Avatar or companions at all.

The game name for BG in the Exult menu just says "blackgate" even though FoV is installed. (The Complete Ultima 7)

I had problems with Exult Studio Crashing whenever I double clicked on the many monster type shapes (other than ethereal monster). You could double click on them in game with Exult Studio open and edit them. The upper right corner where object shape would normally be displayed in that menu seems to show only black if the NPC is facing east or west.

Re: About the new (next?) snapshot...

Posted: Fri Jun 20, 2008 10:12 am
by SepiaAndDust
I had problems with Exult Studio Crashing whenever I double clicked on the many monster type shapes
I was having a *fit* trying to get that to work this morning... now I can relax.

Re: About the new (next?) snapshot...

Posted: Sun Jun 22, 2008 5:59 pm
by Malignant Manor
The game name for BG in the Exult menu just says "blackgate" even though FoV is installed. (The Complete Ultima 7)


Nevermind, I had this in my config (probably from a lazy copypaste)



blackgate

Re: About the new (next?) snapshot...

Posted: Sun Jul 06, 2008 3:23 pm
by Malignant Manor
In the "void Combat_schedule::find_opponents" function contained within combat.cc, these line being omitted stops monsters from attacking themselves or others of the same alignment.


Code: Select all

		else if (!in_party)
			{		// Attacking party member?
			Game_object *t = actor->get_target();
			if (t && t->get_flag(Obj_flags::in_party))
				opponents.push_back(actor);
			}
I can't find anything else that changes when removing the line.


I also noticed something unrelated while testing, charmed monsters will attack party members and the Avatar. I think this might be because targets don't change when alignment shifts. It's probably only needed for the charm spells though.

I still have no idea what is causing some larger monsters to be unhittable in melee unless you teleport into them.

Re: About the new (next?) snapshot...

Posted: Sun Jul 06, 2008 3:53 pm
by Malignant Manor
Well, with a two handed sword, I could hit the larger monsters sometimes when my character was extremely close.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 12:23 pm
by drcode
I finally got the latest code, and am seeing the same problems as Malignant Manor, where invisible monsters don't attack, and others, like the Drakes, will attack each other. Slightly more minor, but I notice that when a dragon becomes invisible, it doesn't happen smoothly, but one block at a time.

I'm sorry I haven't been able to look into fixing these, but my development setup at home isn't in very good shape right now.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 1:28 pm
by Malignant Manor
The Avatar isn't being painted when he is invisible. The other party members seem fine.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 1:45 pm
by Malignant Manor
I think removing "else if (!in_party)" might be stopping party members from being attacked. All the headless in the testing area were only focused on the Avatar, and when he was invisible, spark wasn't being attacked even when I spawned several more.

About the invisibility, the Avatar has the "in party" flag set, but if I toggle it off and then back on, he renders properly while invisible (the semitransparent blur).

Dang, I need an edit button. :p

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 1:48 pm
by Malignant Manor
Toggling the Avatar out and in party causes an extra Avatar to appear in the status bar. I had to save and reload for it to go away. Toggling through status bar did nothing to fix it.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 2:24 pm
by drcode
Okay, fixed a couple things:
1. The invisible dragons now attack.
2. There was another problem where if you were just out of range of a dragon, it wouldn't attack, but wouldn't approach to get closer. This is, I think, fixed now.

I think I'm still seeing drakes attack each other, though.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 3:16 pm
by Malignant Manor
Did you notice this earlier post where it narrows down the monsters attacking each other?



In the "void Combat_schedule::find_opponents" function contained within combat.cc, these line being omitted stops monsters from attacking themselves or others of the same alignment.

Code: Select all

		else if (!in_party)
			{		// Attacking party member?
			Game_object *t = actor->get_target();
			if (t && t->get_flag(Obj_flags::in_party))
				opponents.push_back(actor);
			}
I think it has something to do with attacking others in the party besides the Avatar, because party members weren't getting attacked either when it was removed, but it also seems to be causing monsters of the same alignment attacking each other.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 4:43 pm
by marzo
Unless I am wrong about the cause (that I switched missiles to start at the attacker's center tile), I think I got the problem with the dragons attacking themselves (or any other large creature with a missile weapon, for that matter). This should also make enemies stop attacking each other if I am right.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 5:05 pm
by Malignant Manor
Hopefully it does, but small creatures with melee weapons (or none) attacked each other and themselves at times. It probably will at least fix the problem with being able to hit large creatures in melee (due to seeming to have target focused on center of the creature).

When the download section updates, I'll do some more testing.

Re: About the new (next?) snapshot...

Posted: Mon Jul 07, 2008 5:34 pm
by Malignant Manor
Monsters attacking themselves and other same alignment monsters seems fixed. (Kind of weird that it only seemed to happen when they wanted to hit the Avatar before.) Hitting large creatures in melee seems fixed too.

Have you seen this thread? For future reference does updating a tracker item that has no one assigned to it still notify developers? There are two tracker items about it.