controling the direction of player shadows
- Thread starter inio
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
After reading through the EULA, I've come to two conclusions:
1. such a clause in the license would be a violation of the EULA (they really should have called the group "Editors", not "UnrealEd" as UnrealEd is a part of that group), and
2. HTF does MSU work with the restrictions in the EULA?
1. such a clause in the license would be a violation of the EULA (they really should have called the group "Editors", not "UnrealEd" as UnrealEd is a part of that group), and
2. HTF does MSU work with the restrictions in the EULA?
![-=[MAD]=-Hmpf](/data/avatars/s/33/33783.jpg?1424422844){kind=avatar}
Well it's simple...
The teams don't sell their mods, they're just rewarded because they made sth. cool.
If you download a mod and you like it, then you can send the team some money of course...
but they don't have the right to sell the mod.
just add a readme telling that you want to be mentioned in the Credits or something...
you should also remember, that as soon as you release sth. with your code, everyone can use it.
(since there's no code encryption)
The teams don't sell their mods, they're just rewarded because they made sth. cool.
If you download a mod and you like it, then you can send the team some money of course...
but they don't have the right to sell the mod.
just add a readme telling that you want to be mentioned in the Credits or something...
you should also remember, that as soon as you release sth. with your code, everyone can use it.
(since there's no code encryption)
Last edited:
![[SAS]Solid Snake](/data/avatars/s/30/30541.jpg?1424422840){kind=avatar}
Then someone else would fill the gap. A few of us had already done this technique, thus if you don't release it, then someone or even I will. You can't sue us or me because you can't claim that our code used the same algorithum or methods of yours, simply because we may have just thought along the same lines. With a surface level code level such as this, there is limited ways you can do something. Heck, I might even just release my own sourced lighting code [technically I already have since it's included in my Karmaed code] for mappers to use at NO cost, with the exception of my name in a text files which probably costs the author about 4 calories from their diet to type.
With my own mod, Karmaed, I have even bundled MY original source code for other people to use, learn and to create from and all I expect is just creditation and that's about it.
inio said:
WOTgreal isn't based on epic's code. It's a third party tool that can be used for coding in unreal engine based games.
Pretty much all the code I've written for UT2003 that other people may find handy in their own mods I've released for others to use... I don't do it because I think I'll earn something out of it, I do it because I like seeing what I can do with the engine provided, and if I download a mod, export the .u files and see something based off code I gave to someone a few months ago, it does actually give a warm fuzzy feeling. Which means if Snake, or anyone else who's used my mouse code, or NPC code, or hitbox detection code etc wins something in the contest, good on them. They made the code that I produced into something that was worth winning a prize; what I produced on it's own could have never won on it's own right. A credit in a readme or in their endgame credits is more than enough... even without that I'm not fussed. If it didn't cost me anything to write (except maybe a few hours of sleep) then it doesn't cost anyone to use it.
Much like these dynamic shadows... on their own they wouldn't win a prize, only if they're used properly by the right person in the right map. If you're going to make them pay for it to include in a map, you better make everyone who downloads that map pay for it as well. Then see how far it goes. It's like that saying... someone invented oil paints, but Da Vinci turned them into the Mona Lisa.
BTW snake, I want at LEAST 90% of any money you may get from anything to do with any sort of code you may have that might be in some way based off any code I may have written ever. I looked at your www link and realised you're a kiwi, you sheep ****ing ****er!
Last edited:
Lol, oh well, at least I have fun and get a s@x education earlier than all of you!
Do you accept pocket lint? I am a uni student too so my money that I thought I had is already in to paying my debts.
Do you accept pocket lint? I am a uni student too so my money that I thought I had is already in to paying my debts.
Pocket lint
There is no better legal tender than pocket lint... or perhaps leaves, of the general sort. (Though pocket lint takes the cake).
Just to wrap up this debate here (which actually was a good read without turning into a flame war!):
Its very very hard to produce something surface level that is acceptable to sell; possible, but you sort of need to throw in a unreal - liscense, etc and go from there. Thus, the general concensus is that if you recieve $ for you work, its from the goodness of the user's heart; if I won $1000 US for a map that relied on this shadow system, I might very well throw in a couple of bucks, but thats about it. Otherwise, the best you can do is ask for credit, hope its recieved, and slowly build up a portfolio of all these projects: to get into the game industry, this sort of work is worth almost as much as a 4 year university degree, though the latter is a written requirement. Thats sort of how I see this tiny corner of the world working, and any sort of anomoly is likely to be removed or forgotten.
On the subject of code stealing: to do so blatently is disgusting. Anyone who does so should ideally be shot, or at least frowned upon and robbed of all pocket lint. But as for looking into code, esspecially that shared in the open - source sentiment, is what this community is based up: how many of us would there be if there was never any open source to pick apart, epic released or otherwise.
And on that note, I'm off. This was a good little discussion: an interesting topic and a good adult-response; thanks!
There is no better legal tender than pocket lint... or perhaps leaves, of the general sort. (Though pocket lint takes the cake).
Just to wrap up this debate here (which actually was a good read without turning into a flame war!):
Its very very hard to produce something surface level that is acceptable to sell; possible, but you sort of need to throw in a unreal - liscense, etc and go from there. Thus, the general concensus is that if you recieve $ for you work, its from the goodness of the user's heart; if I won $1000 US for a map that relied on this shadow system, I might very well throw in a couple of bucks, but thats about it. Otherwise, the best you can do is ask for credit, hope its recieved, and slowly build up a portfolio of all these projects: to get into the game industry, this sort of work is worth almost as much as a 4 year university degree, though the latter is a written requirement. Thats sort of how I see this tiny corner of the world working, and any sort of anomoly is likely to be removed or forgotten.
On the subject of code stealing: to do so blatently is disgusting. Anyone who does so should ideally be shot, or at least frowned upon and robbed of all pocket lint. But as for looking into code, esspecially that shared in the open - source sentiment, is what this community is based up: how many of us would there be if there was never any open source to pick apart, epic released or otherwise.
And on that note, I'm off. This was a good little discussion: an interesting topic and a good adult-response; thanks!
Last edited:
(this was also posted to the Wiki)
OK, so I pretty much have it working, but there are some issues still I'd like to resolve. As such I'm reluctant to release yet as "upgrading" a map to a future version could be difficult if there are changes in the configurable variables.
The other issue is, what level of configurability should I provide? There are lots of options that an advanced mapper might use, but that a newbie is bound to try to use and just get confused. For example, right now I have an option ShadowDesaturate that controls how gray the shadow is if it's sourced from a colored light. This defaults to 1.0 as colored shadows aren't working for regular (non-blob) shadows. However, if you turn on bUseBlobShadows then it's safe to turn ShadowDesatureate down to 0 (though you probably want it around .3-.5).
I'm also wondering how much self checking code I should put in. There's so many ways that the code will appear to not work, and the causes of most of them are confusing. For example, should I have ShadowCasters check at startup to make sure they get added to a volume and complain if they don't? How loudly should I complain? A console message? Bright yellow text across the screen?
Another issue is namespace. Right now all my classes are kinda randomly named. There's a few class names I use that have a nominal chance of conflicting with other people's modules. Should I clean it up so they have nice class names all starting with some prefix: 'LS' (Live Shadows), 'IFR'(my initials), or something like that?
Finally, and I'm expecting this to get a similar reaction to the profit sharing concept: What if I bundled and used a mechanism for 64x32 "credit" icons to be displayed on the endgame scoreboard in otherwise unused screen space? There would be an easy way for the mapper to add his/her own, and other coders could would be free use the system in their modules. I'd need to come up with a way for outside packages to interface with the myLevel-based components so they don't draw on top of each other, but I think I could figure out something.
OK, so I pretty much have it working, but there are some issues still I'd like to resolve. As such I'm reluctant to release yet as "upgrading" a map to a future version could be difficult if there are changes in the configurable variables.
The other issue is, what level of configurability should I provide? There are lots of options that an advanced mapper might use, but that a newbie is bound to try to use and just get confused. For example, right now I have an option ShadowDesaturate that controls how gray the shadow is if it's sourced from a colored light. This defaults to 1.0 as colored shadows aren't working for regular (non-blob) shadows. However, if you turn on bUseBlobShadows then it's safe to turn ShadowDesatureate down to 0 (though you probably want it around .3-.5).
I'm also wondering how much self checking code I should put in. There's so many ways that the code will appear to not work, and the causes of most of them are confusing. For example, should I have ShadowCasters check at startup to make sure they get added to a volume and complain if they don't? How loudly should I complain? A console message? Bright yellow text across the screen?
Another issue is namespace. Right now all my classes are kinda randomly named. There's a few class names I use that have a nominal chance of conflicting with other people's modules. Should I clean it up so they have nice class names all starting with some prefix: 'LS' (Live Shadows), 'IFR'(my initials), or something like that?
Finally, and I'm expecting this to get a similar reaction to the profit sharing concept: What if I bundled and used a mechanism for 64x32 "credit" icons to be displayed on the endgame scoreboard in otherwise unused screen space? There would be an easy way for the mapper to add his/her own, and other coders could would be free use the system in their modules. I'd need to come up with a way for outside packages to interface with the myLevel-based components so they don't draw on top of each other, but I think I could figure out something.
Last edited:
inio said:
Why not expose "simple" and "advanced" properties in different sections of the UnrealEd property sheet? As long as the "advanced" options have useful defaults, people can just ignore them.
Namespacing isn't a technical issue, more an aesthetic one; your entire package is a namespace. Classes with the same name in different packages don't conflict as they can always be referenced by their fully qualified name including the package name.
However, it's good form to create an artificial namespace by prefixing your classes with something. Given that you might be working on other projects in future as well, a functional prefix like "LS" strikes me as more fitting than your initials.
Probably annoyance on the parts of the mappers and players. Again... imagine what'd happen if every custom component author added their vanity vignette to the end scores screen.
Well, the code is designed to be embedded into myLevel to keep people from having to deal with additional files. Also, it prevents people from worrying about multiple versions etc as the map file always has the right version for the map.Mychaeel said:
Yep, I agree, just wasn't sure if someone had started a standard I wasn't aware of. The initials idea came from a distributed development project I was involved in a while back where we were supposed to prefix all global identifiers with the three-letter initials of the author.
BlackHornet
Global Warzone Project Leader
heres my example
http://mirror.centauri-dev.net/movies/shadow2.avi (DivX 5.0.3)
its without any new actors, but in fact implemented into our mod. so i added it into pawn + some new actors.
The mapper doesnt need to place special volumes or lights.....he can use standart UT2k3 lights.
The amount of shadows is variable and without a given maximum. it works with up to 20 bots each with 5-6 shadows on a P3 900 / 384 MB Ram with a loss of 10 frames.
http://mirror.centauri-dev.net/movies/shadow2.avi (DivX 5.0.3)
its without any new actors, but in fact implemented into our mod. so i added it into pawn + some new actors.
The mapper doesnt need to place special volumes or lights.....he can use standart UT2k3 lights.
The amount of shadows is variable and without a given maximum. it works with up to 20 bots each with 5-6 shadows on a P3 900 / 384 MB Ram with a loss of 10 frames.
Last edited: