Insta-build, insta-cost. Gimme AoE/DoW/SC.
Moderator: Moderators
The problem is that the gadgetHandler is under GPL and it isn't part of the engine itself (you have to include it in your mod). So it is part of your mod -> your mod uses GPL code -> your (whole) mod has to be under GPL.
PS: external code can be none GPL (see linux kernel and commercial products), but internal code that contain GPL has to be under GPL, too.
That's why ppl dislike the nvidia kernel module, cause nobody can say if it is external or internal code.
And btw, as long as you don't want to earn money with your work, GPL isn't a problem. Except you don't want to share your work, but after the spring devs shared all their work this would be selfish ..
PS: external code can be none GPL (see linux kernel and commercial products), but internal code that contain GPL has to be under GPL, too.
That's why ppl dislike the nvidia kernel module, cause nobody can say if it is external or internal code.
And btw, as long as you don't want to earn money with your work, GPL isn't a problem. Except you don't want to share your work, but after the spring devs shared all their work this would be selfish ..
This kind of bullshit is retarded, People wonder why I hate gpl... for one gpl fails for art work, the other reason Is I have to go and rewrite the fucking thing or the gpl tards will piss and moan. Why do I have to fucking bother with that crap? I refuse to believe that lua would require the complete and total GPL of the project that is using it. The LUA code I can understand but THE WHOLE project... if that is true expect a shit storm from me about it.So it is part of your mod -> your mod uses GPL code -> your (whole) mod has to be under GPL.
Clarify please? I am not sure what you mean? are you saying that if a project goes standalone and uses it's own version of the engine it needs to be completely GPL-ed or are you saying that the projects since they are external to spring do not need gpl.PS: external code can be none GPL (see linux kernel and commercial products), but internal code that contain GPL has to be under GPL, too.
That's why ppl dislike the nvidia kernel module, cause nobody can say if it is external or internal code.
*sighs* jk sharing has not been a problem but I prefer CC as it has less strings attached. as if I don't share... to even suggest that sort of thing... it is insulting.And btw, as long as you don't want to earn money with your work, GPL isn't a problem. Except you don't want to share your work, but after the spring devs shared all their work this would be selfish ..
One thing you need to notice is that is simply not true. Only the parts that link to (ie. require) GPL'd code are subject to GPL infection. Your art *and* code that doesn't use GPL'd code is safe. In practice, this means that you can put a GPL widget in your mod and not worry.smoth wrote:This kind of bullshit is retarded, People wonder why I hate gpl... for one gpl fails for art work, the other reason Is I have to go and rewrite the fucking thing or the gpl tards will piss and moan. Why do I have to fucking bother with that crap? I refuse to believe that lua would require the complete and total GPL of the project that is using it. The LUA code I can understand but THE WHOLE project... if that is true expect a shit storm from me about it.So it is part of your mod -> your mod uses GPL code -> your (whole) mod has to be under GPL.
Ok, took a look, Mael.
Here are the major bugs remaining:
1. The status of the ground (i.e., open or closed ground) needs to be taken into account. Can't drop buildings on closed ground (or close-able ground, in Factories- I don't even see anything in the LUA callouts that addresses that, so it may require a patch from Trepan or other parties to Spring). I'm not sure if LUA can read Spring.SetBlocking status on ground that is already occupied, or not- I'll test that.
2. Teams need to be set correctly. This results in the wrong team getting the object.
3. It needs to check for, and either obliterate Trees / Wreckage, or halt with an appropriate message. I'd rather that it obliterated Trees / Wreckage, as otherwise it will hose AIs.
4. It needs to take into account Units within the area. If users attempt to build on top of another Unit, it needs to halt, or (even better yet) give orders to all mobile Units to move outside the area, wait for 10 seconds for them to get clear, then complete.
Here are the features I think it should have, as opposed to bugs:
1. It needs a visual depiction of the size of the build area, and (ultimately of course) some sort of visual depicting where the final "landing spot" will be.
2. It should (in my opinion) use the BuildDistance specified for the Unit, unless overridden, for backwards-compatibility (i.e., if somebody wants to play Gundam with this thing as a mutator, well... let 'em).
3. It should respect orientation, i.e., we should be able to rotate the buildings if we want. Tricky, I know- you might have to have a hook into the part of the core GUI, frankly, to "see" those keys being used, dunno.
4. It should refer to a config, so that we can impose a flat time-delay, or (in the future) require costs that aren't Metal or Energy, with minimal re-coding required.
I'm going to poke a bit more at this stuff and see if I can get anywhere. The issue of a visual depiction of the landing area is currently beyond my skill level, as I have no idea how to track the cursor position X,Z in Spring...
Here are the major bugs remaining:
1. The status of the ground (i.e., open or closed ground) needs to be taken into account. Can't drop buildings on closed ground (or close-able ground, in Factories- I don't even see anything in the LUA callouts that addresses that, so it may require a patch from Trepan or other parties to Spring). I'm not sure if LUA can read Spring.SetBlocking status on ground that is already occupied, or not- I'll test that.
2. Teams need to be set correctly. This results in the wrong team getting the object.
3. It needs to check for, and either obliterate Trees / Wreckage, or halt with an appropriate message. I'd rather that it obliterated Trees / Wreckage, as otherwise it will hose AIs.
4. It needs to take into account Units within the area. If users attempt to build on top of another Unit, it needs to halt, or (even better yet) give orders to all mobile Units to move outside the area, wait for 10 seconds for them to get clear, then complete.
Here are the features I think it should have, as opposed to bugs:
1. It needs a visual depiction of the size of the build area, and (ultimately of course) some sort of visual depicting where the final "landing spot" will be.
2. It should (in my opinion) use the BuildDistance specified for the Unit, unless overridden, for backwards-compatibility (i.e., if somebody wants to play Gundam with this thing as a mutator, well... let 'em).
3. It should respect orientation, i.e., we should be able to rotate the buildings if we want. Tricky, I know- you might have to have a hook into the part of the core GUI, frankly, to "see" those keys being used, dunno.
4. It should refer to a config, so that we can impose a flat time-delay, or (in the future) require costs that aren't Metal or Energy, with minimal re-coding required.
I'm going to poke a bit more at this stuff and see if I can get anywhere. The issue of a visual depiction of the landing area is currently beyond my skill level, as I have no idea how to track the cursor position X,Z in Spring...
Look, people... for the love of Dog, do not derail this thread with GPL stuff.
Argue it elsewhere, if you need to rehash all of this stuff. There are many unresolved issues here, for people who are scared of the GPL, which I am not, nor do I want your arguments derailing a thread about making something that provides something as important as a wholly new gameplay model within Spring
[edit]
And imbaczek's argument was what I stated was my belief on this matter, months ago when we had our last major fight about this. I have not revised the NanoBlobs license, which mixes GPL and CC, because I believe it is legal to do so, and PURE will probably be licensed as GPL, (C), and CC (variants), depending on what content is being used. In short, I think that Spring games can include multiple Licenses without major legal problems, and I fully intend to release a game that could (potentially, if somebody has enough money and motivation) be legally challenged and create a precedent (not that I'm all that worried about it, frankly- who would be the "injured party"- Trepan?).
Argue it elsewhere, if you need to rehash all of this stuff. There are many unresolved issues here, for people who are scared of the GPL, which I am not, nor do I want your arguments derailing a thread about making something that provides something as important as a wholly new gameplay model within Spring
[edit]
And imbaczek's argument was what I stated was my belief on this matter, months ago when we had our last major fight about this. I have not revised the NanoBlobs license, which mixes GPL and CC, because I believe it is legal to do so, and PURE will probably be licensed as GPL, (C), and CC (variants), depending on what content is being used. In short, I think that Spring games can include multiple Licenses without major legal problems, and I fully intend to release a game that could (potentially, if somebody has enough money and motivation) be legally challenged and create a precedent (not that I'm all that worried about it, frankly- who would be the "injured party"- Trepan?).
Last edited by Argh on 04 Sep 2007, 21:52, edited 1 time in total.
I don't know. Maybe they interpret it differently, there's some room for that (it goes by this reasoning: if GPL'd code is required for the whole thing to run even if it isn't included explicitly, GPL infects everything anyway. I don't like that interpretation and in spring mods, there aren't many things that you cannot cut out without breaking everything.)
edit: sorry, argh, me no mean to
edit: sorry, argh, me no mean to
The problem is that the guys who wrote the GPL were of the oppinion that their way is superior to all others and should be forced upon people as much as possible. It wouldn't surprise me if they'd actually want you to opensource the whole mod as a result and possibly even complain about your use of non-GPL IP (Gundam, in this case).
OTOH I think the law allows only the copyright holder to sue you so only if the person who wrote the gadgethandler disagrees with your handling of the license you can actually get in trouble.
Nonetheless, if this is ambiguous I'd request that the copyright holder relicense the gadgethandler under a license like BSD or LGPL since the idea of the gadgethandler is pretty much considered an essential engine feature and being part of the mod isn't really necessary and putting legal uncertainities on mod devs for simply using standard features is a horrible idea.
OTOH I think the law allows only the copyright holder to sue you so only if the person who wrote the gadgethandler disagrees with your handling of the license you can actually get in trouble.
Nonetheless, if this is ambiguous I'd request that the copyright holder relicense the gadgethandler under a license like BSD or LGPL since the idea of the gadgethandler is pretty much considered an essential engine feature and being part of the mod isn't really necessary and putting legal uncertainities on mod devs for simply using standard features is a horrible idea.
argh we are not rehashing that argument. This is an important discussion and one that needs an answer immediately.
This is the CRUX of it.since the idea of the gadgethandler is pretty much considered an essential engine feature and being part of the mod isn't really necessary and putting legal uncertainities on mod devs for simply using standard features is a horrible idea.
Yes. Since it is somewhat ambiguous, why not use LGPL?since the idea of the gadgethandler is pretty much considered an essential engine feature and being part of the mod isn't really necessary and putting legal uncertainities on mod devs for simply using standard features is a horrible idea.
And what's the license of springcontent.sdz?
Ummm.... I never release a copy of the Lua code. How did you test it for bugs if I didnt even release it?Argh wrote:Ok, took a look, Mael.
Here are the major bugs remaining:
1. The status of the ground (i.e., open or closed ground) needs to be taken into account. Can't drop buildings on closed ground (or close-able ground, in Factories- I don't even see anything in the LUA callouts that addresses that, so it may require a patch from Trepan or other parties to Spring). I'm not sure if LUA can read Spring.SetBlocking status on ground that is already occupied, or not- I'll test that.
2. Teams need to be set correctly. This results in the wrong team getting the object.
3. It needs to check for, and either obliterate Trees / Wreckage, or halt with an appropriate message. I'd rather that it obliterated Trees / Wreckage, as otherwise it will hose AIs.
4. It needs to take into account Units within the area. If users attempt to build on top of another Unit, it needs to halt, or (even better yet) give orders to all mobile Units to move outside the area, wait for 10 seconds for them to get clear, then complete.
Unless you mean the file I uploaded for the bug report. Which I might add has a horrid CRASH BUG in it, so i kinda know its buggy and not finished
Code: Select all
Spring.GetGroundBlocked(x1, z1, x2, z2) ->
nil | false | "unit", unitID | "feature", featureID