On the client yes, but there is also a server-side limit. 

I put a temp fix for this in trunk HEAD (it did allow a max of 20000 objects, now it's 200000 -- I have quite a lot more arches than are in the SVNs).

But regardless, the test server is using (essentially) the same code as the main server so it has the same small limit and many more arches (well actually not that many more ATM, but more).

Plus people connect to test with the pre-built client, which isn't fixed (in fact, the fixed client can not connect to test), so the client-side limit is still there.

Innit fun?

Oy.... and people thought things were hard to keep track of when i was the one explaining the SVN .

Ok, i'll test the things... If i test these, will it be good?:
HEAD 0.9 server (0.9 + daiserv)
HEAD Test server (trunk + daiserv + mapwiz)
r3286 Test server (r3286 trunk + HEAD daiserv + HEAD mapwiz)

Yes?

Cheers,
Unislash

Yes, and you should connect to the 3 servers with the following clients:
Download binary
HEAD trunk
Download binary

TBH if the 3rd setup works, you should have no problems with the other two, but better safe than a n00000000b!!!!!!

(I was discussing with MT the possibility of having 3 arms of SVN -- test, main, and trunk (AKA development) -- to prevent this sort of confusion in future.)

It all works like a charm. Green light.

Cheers,
Unislash

Kewl. Don't forget to commit to trunk as well then (for one thing, this will put the images on the test server too -- following collection anyway).

Almost. On trunk (r3896) you updated the arc to refer to lots of new image, but then didn't commit the images. This also means that the collection committed to mapserv is broken. (Also, a collection should be committed to SF trunk),

Didn't commit the images? I had to--how would it work otherwise? Also, a collection to SF trunk won't do any good; it gets rewritten by daiserv as well as mapwiz...

Cheers,
Unislash

http://daimonin.svn.sourceforge.net/viewvc/daimonin?view=rev&revision=3896

See? Extended .arc but no new images.

The collection to SF (and more than that, the correct raw arches to SF), especially for trunk, are in some ways more important than committing to daiserv or mapserv.

The reasons are that SF trunk is our statement to new devs, as well as our stomping ground for existing devs and other interested parties. It is also the basis for the mapmaker package. Therefore it is very important that it works as well as we can manage at all times.

Re lightning images: Ah, i see. Yea... oopsies, my fault . Forgot to add before i committed. (thanks for the copy-over)

How should i collect the archs for a commit to the trunk?

Cheers,
Unislash

Just export the trunk arches (only), collect with gridarta, then commit arch/* (or do what you did with branches, but with trunk).

Then you will also need to recollect mapserv (so trunk+daiserv+mapserv).

I like the new Lightning gfx thay look alot better.
Now make new flame animation!

Heh... flames actually look quite nice as they are. Plus, they are really, really hard to do

I'm working on a meteor spell, though

Cheers,
Unislash

Logged in earlier and tried out your new lightning graphics!  Job well done - excellant work Uni!

Uni, you did good this go-round with the lightning.

@Uni: In response to Xergh's suggestion for new flames, currently frostbolt/icestorm and firebolt/firestorm use the same images, just the bolts travel in a straight line, and the storms in a cone. Also, the bolts use the same images, regardless of direction.

So while storms do IMO look fine, bolts look a bit half-arsed.

The bolt arches are already set up to work properly with directions. All that's needed are the corresponding images.

IMO you'd do better right now to fix up these existing spells before trying to add new ones (which essentially are just variants of the existing spells but with different graphics anyway).