Page 3 of 3

Re: thread CPU affinity not set

Posted: 16 Jul 2013, 12:53
by zerver
Silentwings wrote:On part of BA, I ask that your project works with the official modfile that we release.
MT needs additional fixes, and there is nothing I can do to prevent that. However, due to the fact that I am (or was) a member of the BA dev team and committed some of these required fixes to your repo earlier, the amount of fixes needed is very small compared to other games.
Silentwings wrote:We want no attempt to hijack/imitate/rebrand/etc or force dependency on some lobby or engine. I have made that clear to you in the past and, amongst other things, it's also clear in the branding policy.
You changed your policy after I asked about the MT stuff, and you lost a bit of my respect by doing so. It is like adapting the legislation after an unwanted act has been committed and then applying retroactive punishment. That said, I may change the name when 7.79 is released. If this really is an issue to you, you can speed up the process by releasing 7.79 fast.
Silentwings wrote:stop your continued attempts to circumvent community rules and licenses.
Unfortunately your policy is just adding to the confusion of users. Why does BA exist under two different names?

Re: thread CPU affinity not set

Posted: 16 Jul 2013, 19:02
by Silentwings
zerver wrote:You changed your policy after I asked about the MT stuff, and you lost a bit of my respect by doing so.
We had never needed to deal with un-official engine forks before, or attempts to lock BA derivatives to them. There is nothing unusual about updating rules to deal with new situations.

Also, the policy was not changed after the event; it was set and appeared on the forum months before you released anything. As you know, you asked us months ago if we would allow what you planned and we gave you a clear no.
Your 'hijacked' release is against the branding policy with or without the sentence on dependencies.
Why does BA exist under two different names?
It does not. And there is currently no confusion.
MT needs additional fixes, and there is nothing I can do to prevent that.
Basically all that you've done is renamed function calls with a find-replace search that forces dependency on your engine.

If you actually need fixes, and if your engine becomes accepted by the devs/moderators, I've got nothing against it; provided they don't cause incompatibilities etc etc.

Re: thread CPU affinity not set

Posted: 16 Jul 2013, 21:08
by zerver
At least one gadget and a few widgets were fixed in Balanced 7.78 MT, but it can indeed be difficult to find due to the large bulk changes you pointed out.

Maybe there is only one BA, but to me something that is indistinguishable from BA is equivalent to BA.

Re: thread CPU affinity not set

Posted: 18 Jul 2013, 00:18
by Satirik
zerver wrote:At least one gadget and a few widgets were fixed in Balanced 7.78 MT, but it can indeed be difficult to find due to the large bulk changes you pointed out.

Maybe there is only one BA, but to me something that is indistinguishable from BA is equivalent to BA.
seriously, stop fighting, just give up, you can't win, I know it's hard to give up on something you spent a lot of time on, but you're just wasting your time, find another project, spring is dying anyway

Re: thread CPU affinity not set

Posted: 18 Jul 2013, 07:09
by hoijui
i would kind of suggest you to stop it too, but not cause spring is dying, but just cause this is no healthy way of living. start your own little engine project from scratch, implement stuff the way you like it too and be satisfied by that. less time, no problems, more satisfaction, no stress. you will likely not have any users other then yourself, but ... do you really need them?
after a few weeks, you will be done, and you can move on to the next thing, and you will have sucked out the same amount of good energy from that project that you optimally could have gotten from spring, over many years.

Re: thread CPU affinity not set

Posted: 19 Jul 2013, 00:07
by zerver
Haha, well said.

Re: thread CPU affinity not set

Posted: 19 Jul 2013, 10:18
by Anarchid
Better option: join pyrogenesis. They are also in desperate need of speedups, but their compartmentalized engine architecture might be easier to work with :)

Also, they have much less coders than artists, a rare sight in open source.

Re: thread CPU affinity not set

Posted: 20 Jul 2013, 09:33
by hoijui
i doubt that this is a better idea. they might have the same problems spring has, and as a new dev, one would probably be even less valued then here, as veteran. the spring engine also has much less coders then the community has artists (when not counting lua coders).

Re: thread CPU affinity not set

Posted: 24 Jul 2013, 03:40
by Cheesecan
Pyrogenesis is much worse off. That game is unplayable even in 1v1 after years and years of development. Pity cause aoe was charming and deserved a solid OS revival.

Re: thread CPU affinity not set

Posted: 24 Jul 2013, 11:11
by Anarchid
the spring engine also has much less coders then the community has artists
That's because of engine/content separation. In that other project, there is no such thing as different project teams for Engine and Game. Engine doesn't need artwork. :)
Pyrogenesis is much worse off
And that is why i suggested trying to speed it up. Especially due to their highly compartmentalized engine seemingly having a great potential for stuff like multithread.

Re: thread CPU affinity not set

Posted: 24 Jul 2013, 21:37
by Cheesecan
Anarchid wrote: Especially due to their highly compartmentalized engine seemingly having a great potential for stuff like multithread.
Dunno about zerver, but I would run like the wind if I heard somebody talking about compartmentalized code. I think the word you are looking for is modular. :wink: