Page 2 of 3

Re: Spring Modules?

Posted: 13 Sep 2013, 10:37
by Forboding Angel
CarRepairer wrote:
Forboding Angel wrote:Unfortunately, the stuff in ZK for chili is mostly hardcoded and made only to really work for ZK.
What are you referring to here? Chili itself is unmodified in ZK. It could be used by any game. The widgets however are very tailored to ZK, so I agree that those should not be a module. So...
Don't be silly. Anytime we are discussing chili in ZK you can safely assume that we are talking about he widgets. The only time anyone gives a solid crap about the chili framework is if it doesn't work.

And things like KB menu, integral, etc SHOULD DEFINITELY be modules, WITH CONFIGS.

Those configs should also control default sizing and placement as well. The point of a config is that you make every single portion of item in question open to ease of editing. Unfortunately, people who work on zk chili widgets love to just hardcode everything.

Re: Spring Modules?

Posted: 13 Sep 2013, 11:55
by PepeAmpere
Forboding Angel wrote:... Unfortunately, people who work on zk chili widgets love to just hardcode everything.
bad bad people! :twisted:

Re: Spring Modules?

Posted: 13 Sep 2013, 12:09
by gajop
Forboding Angel wrote: Don't be silly. Anytime we are discussing chili in ZK you can safely assume that we are talking about he widgets. The only time anyone gives a solid crap about the chili framework is if it doesn't work.
There was a time a while back when ZK's chili framework diverged from jk's quite a lot, and the way I see it some things of the framework itself (such as custom controls or themes) could be changed for each game, so it should be designed with that in mind.

While I agree with the rest of your text, it's also true that the things that should be made into modules first are the ones that Flozi mentioned, and I'd extend that list with a lobby API (lua library) if it ever gets made.

Re: Spring Modules?

Posted: 13 Sep 2013, 16:29
by knorke
Modules might seem like a good idea but imo it is not feasible.
One question is always: Who would maintain this module?

module "chili framework"
This one makes maybe the most sense.
But with http://springrts.com/wiki/Chili it is now easier to set up and not so much about copying random things anymore.
chili is under active development, it changes, and some mods might prefer to use an older version for whatever reasons. Then you either have "chili_module-V4.6.sdz" or mods again include their own version. Also what if modA does an update to chili? Then modB who includes the same chili-module might break because modB was not adjusted.

module "commonly used widgets" (chili or normal)
What if you only want the playerlist and healthbars but not the resource bar?
There is maybe some way to disable unwanted widgets but is that really an improvement?
Configs of widgets:
Simply not feasible to make every number/constant in widget configurable. Some changes are also not possible via configs: Say you want healthbars to be pie graphs instead of bars, that is a small change, but how to do such things as config without blowing everything to elephant size.

spring features
For such module to be maintainable it would have to be different:
Similiar features should share a .lua file, like all trees, rocks,etc that only differ in what model they use. See http://springrts.com/phpbb/viewtopic.php?f=14&t=28123
Otherwise annoying to edit a dozen files just to change some values.
Defs are bad: unused tags, featureDead or "featurereclamate" referencing to not existing features etc, hitvolumes,..
Filenames and no folders in unittextures\ make it confusing which textures goes with which model.
Atm imo better to have the features you actually want included in map or mod.
Having lots of "strange" defs in mod/maps can lead to problems such as:
http://springrts.com/phpbb/viewtopic.ph ... 23#p525623
Same textures are way too large, some are even 1024x1024 and 2 are 1600x1600
In addition to the benefits mentioned before I think this may allow for new developers to get started with their new game faster by including (cherry-picking) commonly used modules they want, and later extending them as their game progresses if needs be.

Re: Spring Modules?

Posted: 13 Sep 2013, 21:03
by zwzsg
I don't think introducing library dependency hell into Spring game would make life easier for anyone.

Re: Spring Modules?

Posted: 14 Sep 2013, 01:04
by smoth
I am back from driving as far as all the flooded highways in colorado will let me.

Here is the deal:

are you going to re-re-re use a few pieces? sure? make it a module.

are you working on a *A project? yeah? want to use all the same models and unit defs they used as a base? maybe a file called TACONTENT.sdz or whatever too late.

want to work on something new for use in other projects? is it luaoo, if not do you not care about people telling you what to do? DO IT!

Seriously, on my project and code structure, I have 0 cares available for all the mandates and ridiculous demands of this community. I have been told to use 2 spaces instead of a single tab for my code spacing... I use tabs still. Want to tell my variable names suck? sure go ahead, suggest a better one, if I think it is not verbose enough, hang on while I ignore your suggestion.

This is the reality of all development here. Everyone is an expert on how you should do everything. SOMETIMES they know what they are talking about and you will just have to sift through all the bullshit. That being said.

Here is what happened for me:
gundam rts was and still is my baby. It is alive somewhere should I ever have an opportunity to flail around in front of bandai to try and get hired. LOOK AT ME I LOVE GUNDAM HIRE ME!

so I realized i needed a core rts system that would always work with spring and support my super projects. HOWEVER, since I am no longer working on gundam... there was all this stuff I wanted to do! so I realized taking several key elements and placing them within a core file would be advantageous.

so I split gundam into Gundam and Green Bean Sandwiches. I can use GBS to speed up any development carrying over all my bits and bobs into future projects. it is WONDERFULLY easy to disable/enable things based on what is available. Also I am a config junkie, I love having them, as many as possible. so I continue to split all this code out.

I don't think you should do this. you have 1 project with some specific directions you want to take. You are over engineering your codebase. There are people*strikeout that* I mean idiots who will tell you to do all this. Unless you have a REALLY good reason I say you don't.

here is my current favorite reason:
content module(contains all art/ip related stufff) + game module (contains all gpl compliant stuff.

mod file references both. Since your artwork is just art, your sounds are just sound etc... gpl can go EFF it's self. They are not and cannot by nature run against/linkto/whatever, the gpl'd spring code or lua you have. So your games identity is safe, just the code you use has to be gpl compatible.

Just a fun thought for sowing a bit of fun around here.

anyway. No for a small project, you are adding a great deal of complexity for no good reason. If you ever do develop something like lups/chili you can break it out later.. once we get the new gadget/widget handler a long time ago in a galaxy far far away.
FLOZi wrote: All game logic gadgets should be game specific, or you end up with monstrosities (i.e. unit_morph.lua) that are impossible to maintain anyway.
unit morph is a dated trainwreck and needs better configs. I started walking through redoing it a while back and I was amazed at how sloppy it was. Either some things were not available when it was written or it is just that the origonal author didn't care.
knorke wrote: spring features
For such module to be maintainable it would have to be different:
Similiar features should share a .lua file, like all trees, rocks,etc that only differ in what model they use. See http://springrts.com/phpbb/viewtopic.php?f=14&t=28123
ha ha ha nope I 100% disagree. no 1 file is bad. I hate scrolling through 9001 lines to find the feature I want to update.

as far as flozi's oo code.. that isn't really oo the parent class is unavailable outside of the file which takes away the ability to inherit it in future files. no knocking flozis code 1 bit just saying I don't think you should use it as an example. if he had a dir filled with parent classes and there after any weapon loaded could inherit any parent and there could possibly even be an inheritence chain. but there isn't currently. At last last that I recall and maybe my memory is rough and I should go verify but I am pretty sure.

Re: Spring Modules?

Posted: 14 Sep 2013, 03:44
by knorke
I have 0 cares available for all the mandates and ridiculous demands of this community.
Ok. But then why post in a thread that is about the mandates and "ridiculous" demands of this community.
I hate scrolling through 9001 lines to find the feature I want to update.
I did not say to create such 9001 line files.

Re: Spring Modules?

Posted: 14 Sep 2013, 03:49
by NeonStorm
The hardest thing is balance.
Unless you want a kernel-panic remake.

Unit models and textures could be packaged, because they are very big and rarely changed
But scripts and unit definitions can't get packaged - they are too different.

Re: Spring Modules?

Posted: 14 Sep 2013, 03:51
by smoth
knorke wrote:
I have 0 cares available for all the mandates and ridiculous demands of this community.
Ok. But then why post in a thread that is about the mandates and "ridiculous" demands of this community.
because I am telling him, he shouldn't. Tons of people around here love to make ridiculous gameplay demands due to the who fan entitlement behavior which has become common among gamers these days. However, I also see a great deal of ultra-nerd elitism where people act like if it isn't fully OO it is crap... while that is an exageration, the example is fair enough I feel. of course reading this you may assume I am saying ignore all feedback as that is also the common issue around here.. people read and think black and white. As I said earlier, it is OK to say, no, that is ridiculous and I am not doing it!
knorke wrote:
I hate scrolling through 9001 lines to find the feature I want to update.
I did not say to create such 9001 line files.
for all trees etc yeah that would result in huge unmaintainable files. As it stands now, the maintainer of the features file just has to place them in a folder under the author unless forb altered that structure... I don't think he did. I don't see anyone around here really making any new features outside of myself so I think the very idea is silly because I will not do it to begin with and I don't think forb should have to and to EVEN suggest OO for DEFS.. REALLY?

Re: Spring Modules?

Posted: 14 Sep 2013, 04:38
by knorke
Tons of people around here love to make ridiculous gameplay demands due to the who fan entitlement behavior which has become common among gamers these days.
There is no point to bring up things like this, that happend nowhere in this thread.
for all trees etc yeah that would result in huge unmaintainable files.
Currently: tree1.lua,tree2.lua,...tree10.lua
The files all have the ~20 identical lines, only a few are different.
For example "model=tree1.s3o" becomes "model=tree2.s3o" and so on.
Idea:
Use anything so that you do not have the same files copypasted multiple times with only 2 lines changed.
Dont like OO then maybe do like this http://springrts.com/phpbb/viewtopic.php?f=14&t=26888 or whatever else.
I don't see anyone around here really making any new features outside of myself
I do. http://springrts.com/phpbb/viewtopic.php?f=13&t=30776 1st page of mapping forum

Re: Spring Modules?

Posted: 14 Sep 2013, 05:02
by smoth
because he wanted to ask about it and I personally don't think it is a good way to go. Others want him to because they like the way the structure sounds cool or whatevers.

that's nice, they are mostly identical because I went through and built out all the files out several years ago giving zero shits about whether or not I had it all 100%. Because not everything is tree2.s3o, because not all artists want to call it tree2.s3o because they want to name it christmastreeA.s3o, because they are NOT all trees, because you are assuming this is a concerted effort. When artists can get prissy over the dumbest alterations of their models so it is best to just leave the file the hell alone. I understand your points and think they A: don't belong in this thread. B: have LESS to do with his modularization questions than my point about telling the community get lost is ok.

This must be a language bit lost in translation.
I don't see anyone around here REALLY
the really means they are not often doing it and while you might be able to cite them as an example they are outliers.

Re: Spring Modules?

Posted: 14 Sep 2013, 05:18
by Forboding Angel
knorke wrote: spring features
For such module to be maintainable it would have to be different:
Similiar features should share a .lua file, like all trees, rocks,etc that only differ in what model they use. See http://springrts.com/phpbb/viewtopic.php?f=14&t=28123
Otherwise annoying to edit a dozen files just to change some values.
Defs are bad: unused tags, featureDead or "featurereclamate" referencing to not existing features etc, hitvolumes,..
Filenames and no folders in unittextures\ make it confusing which textures goes with which model.
Atm imo better to have the features you actually want included in map or mod.
Having lots of "strange" defs in mod/maps can lead to problems such as:
http://springrts.com/phpbb/viewtopic.ph ... 23#p525623
Same textures are way too large, some are even 1024x1024 and 2 are 1600x1600
https://code.google.com/p/spring-features/

Knorke, I suggest you learn to use grep (and paragraphs).

Re: Spring Modules?

Posted: 14 Sep 2013, 05:52
by knorke
Because not everything is tree2.s3o
Look at the feature/file names in springfeatures and you will see there are lots of features using the "tree1,tree2,tree3" naming scheme.
When artists can get prissy over the dumbest alterations of their models so it is best to just leave the file the hell alone.
I was talking about the .lua defs files not about the models.
Springfeatures does not include the original license files, so it is a bit hard to check but iirc most models are free to be edited, too.
Knorke, I suggest you learn to use grep (and paragraphs).
I prefer to keep files somewhat neat so it does not need tools to handle the chaos. For example search & replace over multiple files to edit the same thing in several places seems fail to me. Just have the thing in one place only.

Re: Spring Modules?

Posted: 14 Sep 2013, 16:45
by AF
Before I comment:
Seriously, on my project and code structure, I have 0 cares available for all the mandates and ridiculous demands of this community. I have been told to use 2 spaces instead of a single tab for my code spacing... I use tabs still. Want to tell my variable names suck? sure go ahead, suggest a better one, if I think it is not verbose enough, hang on while I ignore your suggestion.
+1000, if you use 2 spaces and I like 4 spaces I have to reformat the entire code base. If you use tabs, and you use 2 spaces, but I like 4, I flick a switch in my editor and hey presto, I get 4 and you still get 2. Tab is a dedicated indenting character, using spaces is ludicrous, as it enforces your style on everybody else.

On to modules

I think you're all working off of some basic assumptions, most of you anyway. Namely that a module == an sdz/archive, mod dependency, something that the lobby can download, something that would be in a separate file on the end users machine or merged in auto-magically.

This isn't the only way.

Instead, try looking at PHPs composer, or javascripts Bower, or Nodes npm.

Instead of having a final product dependency, simply declare your dependencies, and the desired versions, and have a tool grab them for you. Use it as a development tool that assembles a single package rather than auxillary packages you declare as dependencies.

For example, here I have a composer.json that tells composer my plugin needs pimple, doctrine 2+ and PHP 5.3 or higher:

https://github.com/Tarendai/wordpress-d ... poser.json

I can then distill it down to this:

Code: Select all

{
	"name"        : "tomjn/doctrine_boilerplate",
	"require"     : {
		"composer/installers"          : "~1.0",
		"php"                          : ">=5.3",
		"pimple/pimple"                : "~1.0",
		"doctrine/orm"                 : "*"
	}
}
I then run:

Code: Select all

composer install
And it goes and grabs the appropriate versions of those libraries and bundles and puts them in my projects vendor folder, or wherever I demand it. Doctine will have it's own depencies that are pulled in too

Now imagine a package.lua that went something like this:

Code: Select all

return {
	name='Balanced Annihilation',
	description='Balanced Annihilation',
	version='7.81',
	require={
		zk_chilli = "~1.0",
		widget_playerlist = ">2.0",
		spring_engine = "95.0"
	}
}
Then we did something such as this:

Code: Select all

springpackager install
And all of those parts were downloaded and installed in the appropriate places inside your games development folder ready for use

We could then do something similar to composer and do:

Code: Select all

springpackager archive --format=sdz
and hey presto we now have a means of packaging things up too, and we get for example Balanced_Annihilation_7.81.sdz. One single archive, no dependent archives, no faffing around downloading multiple dependencies, no install instructions saying put this here and that there.

Now say we did this:

Code: Select all

return {
	name='Balanced Annihilation',
	description='Balanced Annihilation',
	version='7.81',
	require={
		ba_units = "7.8",
		ba_gadgets = "7.8",
		ba_textures = "7.8",
		ba_sounds = "7.8",
		zk_chilli = "~1.0",
		widget_playerlist = ">2.0",
		spring_engine = "95.0"
	}
}
Suddenly that lua file is all thats needed to cart around the entire game. An sdz or an svn checkout with various dependencies is now a 1/2kb lua file. Each component can be managed and updated independently with alternate versions. Maybe someone bumped sounds to 7.9, and units stayed at 7.8, or units moved to 8.0 for balancing reasons, you could mix and match dependencies, and they'd be specific to that archive.

While typing that, widget_playerlist updated to v3.0, what happens? We can run:

Code: Select all

springpackager update
And the dependency is upgraded. If we decide v3 is bad or it breaks things, we change the requirement from >2.0 to 2.0 using the standard semantic versioning used in hundreds of other packaging systems.

Now lets say I'm bored with BA, and have decided to build a mutator:

Code: Select all

return {
	name='AF Aliens Godzilla',
	description='OMG GODZILLA',
	version='1.00',
	require={
		balanced_annihilation = "7.8",
		spring_engine = "95.0"
	}
}
Now my mutator can pull in all of BA, specifically BA 7.8, and be completely self contained. Perhaps I may want an option to use dependencies in separate archives to save space, who knows, but this lets me rapidly prototype things, and encourage modularity in packages, as well as diverge ownership and maintenance of separate components.

Ofcourse this suggests some central packaging point that lists and maintains package details, but that isn't necessary. Packagers such as composer allow you to specify URLs to zip files for package versions, and Git and SVN repositories to export, or to define your own personal package repository

Re: Spring Modules?

Posted: 15 Sep 2013, 03:09
by smoth
AF wrote: Now say we did this:

Code: Select all

return {
	name='Balanced Annihilation',
	description='Balanced Annihilation',
	version='7.81',
	require={
		ba_units = "7.8",
		ba_gadgets = "7.8",
		ba_textures = "7.8",
		ba_sounds = "7.8",
		zk_chilli = "~1.0",
		widget_playerlist = ">2.0",
		spring_engine = "95.0"
	}
}
Suddenly that lua file is all thats needed to cart around the entire game. An sdz or an svn checkout with various dependencies is now a 1/2kb lua file. Each component can be managed and updated independently with alternate versions. Maybe someone bumped sounds to 7.9, and units stayed at 7.8, or units moved to 8.0 for balancing reasons, you could mix and match dependencies, and they'd be specific to that archive.
but it can be a maintenance nightmare and have a potential to cause a lot of issues. + you are adding tons more sdds to the spring archive. What will manage and PACKAGE all these files into their respective sdzs etc? it seems more trouble than it is is worth when the project is able to be updated only where necessary through rapid. It feels like a lot of excess management and work for little benifit.

AF wrote:While typing that, widget_playerlist updated to v3.0, what happens? We can run:

Code: Select all

springpackager update
And the dependency is upgraded. If we decide v3 is bad or it breaks things, we change the requirement from >2.0 to 2.0 using the standard semantic versioning used in hundreds of other packaging systems.
where do I get this springpacker? what does it do?

Re: Spring Modules?

Posted: 15 Sep 2013, 07:32
by KDR_11k
I don't see too much value in modules like that as verbatim reuse is pretty rare. Then there's the general issue with dynamic linking that your dependencies may release new versions and might break compatibility with your game. When you link to a specific version you might as well include it in the game's archive directly, there's not much gain when every game needs a different version anyway (or even uses custom forks).

In terms of verbatim reuse that was a large part of The Cuberor's Finest (which was heavily based on reusing existing gadgets) but even then the squad gadget needed some changes to support the reinforce mechanic.

You'd need a well specified API to allow interacting with module code and I'm not sure people would really maintain that carefully enough.

Re: Spring Modules?

Posted: 15 Sep 2013, 08:21
by FLOZi
FLOZi wrote: The only things I'd see being made into dependencies (and I've mentioned it before) are;

1. Chili framework (not individual widgets)
2. LUPS framework (not individual gadgets/widgets)
3. CustomUnitShaders

All game logic gadgets should be game specific, or you end up with monstrosities (i.e. unit_morph.lua) that are impossible to maintain anyway.

Re: Spring Modules?

Posted: 15 Sep 2013, 13:07
by Google_Frog
Forboding Angel wrote:And things like KB menu, integral, etc SHOULD DEFINITELY be modules, WITH CONFIGS.
Why? Were they written for you? What justification can you give to their authors for the extra work required in doing this?

Re: Spring Modules?

Posted: 15 Sep 2013, 20:24
by AF
smoth wrote:
AF wrote: Now say we did this:

Code: Select all

return {
	name='Balanced Annihilation',
	description='Balanced Annihilation',
	version='7.81',
	require={
		ba_units = "7.8",
		ba_gadgets = "7.8",
		ba_textures = "7.8",
		ba_sounds = "7.8",
		zk_chilli = "~1.0",
		widget_playerlist = ">2.0",
		spring_engine = "95.0"
	}
}
...
but it can be a maintenance nightmare and have a potential to cause a lot of issues. + you are adding tons more sdds to the spring archive. What will manage and PACKAGE all these files into their respective sdzs etc? it seems more trouble than it is is worth when the project is able to be updated only where necessary through rapid. It feels like a lot of excess management and work for little benifit.
Where are these additional sdz files and sdd folders coming from? I think you misunderstand, the end result of this is not multiple sdd packages, I am not talking about downloading and installing SDZ archives or their SDD equivalents.

Also keep in mind that Rapid does not do semantic versioning, and is not fulfilling the same role. Rapid is aimed at end user deployment, such a packager would be used by content developers, not end users. End users would use the output of this, they would not be the ones doing the assembly on their own machines.


E.g. In my above examples, ba_units would not be a separate SDZ or sdd, it would be downloaded and extracted into, not in addition to, the local game. ba_units is not a dependency of the SDZ, it is an archive of the game.
AF wrote:...
where do I get this springpacker? what does it do?
It would be a tool built or forked from one of the many tools elsewhere that work in the same way.

If we were to use json instead of lua then bower or composer could be taken up wholesale with no additional tools needing to be built. There's already a tool chain for each of them to set up custom package repositories and set target paths in a project

Re: Spring Modules?

Posted: 15 Sep 2013, 22:04
by Funkencool
I think AF has the right idea. If I understand correctly. It would not be a tool for the end user at all but for the developer; as a way of compiling his game archive.

I don't get the naysaying. If people are willing to put in the work its not going to close paths for veterans but open paths for newcomers.

I havent seen one new dev deny it would be nice, and every negative response has been from veterans. I think that says something.