Which CAL3D version?

[trollson]

In a recent bug report (el 130 on Debian Sarge), it mentions that the new client is linked against 'libcal3d.so.11'.

 

I thought we where still limited to CAL3D 0.10 due to API changes in 0.11. Has this changed?

 

The Gentoo ebuild still requires "=media-libs/cal3d-0.10", as in previous versions.

 

Although, from the Gentoo pov, the later version is still masked, it is required by some other applications, and unfortunately we cannot have both versions (it is not slotted).

[ttlanhil]

in a thread from a while before that, someone said that debian had skipped a version number for some reason, hence they have an 11 in the name when it's really 10.

yes, it sounds odd...I dunno if it's the case. but it might be why

AFAIK, we still need what's properly cal3d v 1.10

[trollson]

OK, so Debian have become a bit numerically challenged with the library

 

I see that Cal3D 0.11 is now the stable release (as of 2006-06-29). It would be worth re-evaluating an upgrade? I recall there where issues with API changes.

[UberLord]

Checkout Gentoo bug #139230 for a cal3d-0.11.0 ebuild.

 

I've put this on my local system and eternal-lands-1.3.0 builds against it 100% - and it worked for 30 seconds! Not that it crashed, it's just that I'm at work and couldn't really be seen playing a game - lol.

 

I'll see if I can get that into Gentoo soon

[trollson]

Just been looking at the Cal3D 0.11 code against the cal files in elc:

 

It looks like the cal3d_wrapper.* files have been copied over from the cal3d source. The header appears to be a direct copy apart from include changes, and the C++ source file maybe a cut down of the original.

 

So, there could be problems if the internal workings used by the C++ file have changed. Plus, the C wrapper functions should be in the cal3d library already, defined in its copy of cal3d_wrapper.h.

 

The only functions defined in EL's copy of cal3d_wrapper.cpp which are missing from from that in the CAL3D 0.11 baseline are:

CalMesh*	 CalModel_GetAttachedMesh	(CalModel* self,int i);
enum Boolean CalMixer_ExecuteAction_Stop (CalMixer* self, int id, float delayIn, float delayOut);

I think that these can be replaced by:

struct CalMesh* CalModel_GetMesh	   (struct CalModel* self, int coreMeshId);
enum Boolean	CalMixer_ExecuteAction (struct CalMixer* self, int id, float delayIn, float delayOut, enum Boolean autoLock);

with autoLock=True. Though the internals of CalModel_GetAttachedMesh and CalModel_GetMesh are different; which may be a problem if they are not equivalent operations.

 

Both functions are only used or referenced in the cal.c and cal.h files, the latter also includes the local copy of cal3d_wrapper.h.

 

I don't know why the wrapper API was copied from the Cal3d library (maybe it wasn't stable at the time?), but it would seem safer to remove EL's copies of cal3d_wrapper.h and cal3d_wrapper.cpp, and use those provided with the library instead (adjusting for the two API differences)?

 

[crusadingknight]

Though the internals of CalModel_GetAttachedMesh and CalModel_GetMesh are different; which may be a problem if they are not equivalent operations.

 

They don't seem to be - getMesh just finds m_vectorMesh[meshId] where m_vectorMesh[meshId]->getCoreMesh() is equal to m_pCoreModel->getCoreMesh(arg1). On the other hand, CalModel_GetAttachedMesh just returns m_vectorMesh[arg1]. We may need to keep that one wrapper function, since it seems important we be able to access a given meshid, rather than searching for an attached mesh with the given core mesh ID.

 

(Still, one private API function in our wrapper is an improvement over the present - though, it took a little modification to their SConstruct file to start the build, which didn't happen in the last release.)

 

EDIT: OK, now the SConscript file is missing some dependencies. This release may have been shipped in a hurry...

 

EDIT2: Following some tweaking (had to add OS path import, and two dependencies), the library built. If anyone wants, I can see if trollson's proposed changes will work on windows.

Edited July 5, 2006 by crusadingknight

[UberLord]

EDIT2: Following some tweaking (had to add OS path import, and two dependencies), the library built. If anyone wants, I can see if trollson's proposed changes will work on windows.

 

Would be a good idea.

It's a shame that EL isn't auto-tooled so we can detect cal3d version as it maybe of benefit to support both 0.10 and 0.11.

 

While you're on windows, could you test this patch for me or portability?

 

http://www.eternal-lands.com/forum/index.php?showtopic=26532

 

If it fails it's probably because the sys/*.h files aren't included for Windows.

[Roja]

do any of you know cal3d enough to fix some annoying bugs we have?

 

such as:

-making the animals that sleep, sleep longer than 2 seconds

-synchronising the fighting properly

(these may be server involved..if so then oh well )

 

Also some additions we'd like to have:

-making the playable characters able to wear things like scarves & medallions

-texture masking

(check the programming client pinned post for more info)

[UberLord]

do any of you know cal3d enough to fix some annoying bugs we have?

 

Graphics programming is not my forté, so no.

[crusadingknight]

While you're on windows, could you test this patch for me or portability?

 

http://www.eternal-lands.com/forum/index.php?showtopic=26532

 

If it fails it's probably because the sys/*.h files aren't included for Windows.

You may want to talk to somebody who uses VC++ about that; I'm using MinGW, so I have the sys/* hierarchy, and pretty much every POSIX function which can be emulated on windows...

 

 

do any of you know cal3d enough to fix some annoying bugs we have?

 

such as:

-making the animals that sleep, sleep longer than 2 seconds

-synchronising the fighting properly

(these may be server involved..if so then oh well )

Yeah, those would appear to be server side (personally, I think the best way for the fighting might be to introduce some sort of fight orchestration protocol, so both enter combat at the same time - that way the animation lengths will be all that matter.)

 

Also some additions we'd like to have:

-making the playable characters able to wear things like scarves & medallions

-texture masking

(check the programming client pinned post for more info)

For the first, can't that just be done by attaching a mesh, the same way as ie. the capes work? Creating a new handler for another mesh isn't all that hard at all (ie. I had to work with that stuff before, when we wanted the legs/body meshes to possibly change with the armors worn. Doesn't take very long to implement if there's a server protocol to send the information.)

Edited July 6, 2006 by crusadingknight

[UberLord]

You may want to talk to somebody who uses VC++ about that; I'm using MinGW, so I have the sys/* hierarchy, and pretty much every POSIX function which can be emulated on windows...

 

I got VS Studio 2003 here and the headers are fine - however I cannot test EL on the work machine.

It does need the headers though, but someone updated update.c to only include them if not Windows and I cannot work out why for the life of me!

 

Oh well.

[icerogue]

I suppose i could always pull out my laptop and try it on there, though i think the newest version of VS is 6.0 =/

[crusadingknight]

-making the animals that sleep, sleep longer than 2 seconds

 

On that note, this must already be done - I timed one snake today, who slept for over three minutes. (I was harvesting at the time, so I had little else to do. )

[mikeman]

I don't know why the wrapper API was copied from the Cal3d library (maybe it wasn't stable at the time?), but it would seem safer to remove EL's copies of cal3d_wrapper.h and cal3d_wrapper.cpp, and use those provided with the library instead (adjusting for the two API differences)?

 

When I wrote the initial Cal3D implementation, the cal3d_wrapper just didn't expose some necessary functions as CalModel_GetMesh. As for CalModel_ExecuteAction there *was* such a function, but it didn't expose the autoLock parameter at all. Internally, the wrapper was always setting it to false. Since I couldn't done any overloading in C, I had to write a function with a different name(CalModel_ExecuteAction_Stop) which was always setting autoLock to true. So, I had to edit the .h and .cpp files so we could access those functions correctly from C.

 

I don't know in what state the wrapper of Cal3D is now since I'm done using C, but if it at lasts wraps all functions and classes, yeah replace my modified versions with the official ones(and of course make some changes to the code).

Edited July 9, 2006 by mikeman

[Torg]

On that note, this must already be done - I timed one snake today, who slept for over three minutes. (I was harvesting at the time, so I had little else to do. )

Snakes have always slept for ages (iirc). Bears however only sleep for a couple of seconds.

[Roja]

hm that's weird. so this is something in the server code?

[Learner]

hm that's weird. so this is something in the server code?

Some of the animals sleep, others dont (only 5 do sleep), but there is nothing in the code for a minimum amount of sleep time, so sometimes they go to sleep and wake up right away, other times they sleep for a long time. The chance of waking up also varies per animal.

[Roja]

But they should NEVER sleep for < 30 seconds...it's just really stupid looking to see an animal lay down for 2 seconds and get right back up. If they wake up earlier than that they should wake up because you attacked them.