Google_Frog wrote:Do game mechanics fit into this anywhere? My attributes system contains all that is required to multiply unit movement and reload speeds. The raw SetUnitWeaponState and or Set{Type}MoveTypeData functions can be complicated to use (as well as buggy) and special handling is required for 0 movement or reload speed. It is also a system which can multiply speed modifications from many sources. Every game which touches movement speed or reload time should have a gadget like it.
They do, and from what I understood the attribute system is a good example of such a case as it basically provides a wrapper to the engine to simplify some operations.
Other game mechanics could also be a unit ability, leveling(exp) or tech system we built in LD, but such things tend to be hard to design in a way that would be useful to every game. Some work could happen nonetheless.
Google_Frog wrote:
Currently the attributes gadget is 50% ZK-specific because it also handles economy multiplication and sensor disabling. The main update function is a list of all the UnitRulesParams which set various multipliers and the logic for their interaction is within the gadget. I cut down the gadget significantly for LD but the ad hoc interaction coding was still present. Would it be worthwhile to create a general system to be included as a library?
The ZK-specifics would need to be removed so it serves a wider purpose. I don't know what functionalities it offers to judge if it it's worth the time, but it probably is.
Google_Frog wrote:ZK also has the One Click Weapon gadget which is a system for activatable abilities, both aimed and unaimed. There are a lot of quite modular game mechanics and engine fixes in ZK but I don't know if they are within the scope of your initiative.
Maybe, I'm not sure what's there. In general I'm OK even with libraries that are made for TA-like games or anything as specific, as long as it can be easily integrated in such projects. The ideal is to still make it as generic as possible.
(engine workarounds in Lua would definitely be great to have in one place but that may be non-trivial to maintain)
code_man wrote:Are you considering mentioning, non library stuff too some other place?
For example the delay call api gadget is very useful, but really small.
Delay api is useful and has been added.
code_man wrote:
Another example would be, that a chilli ui unit spawner, that i think would be very useful for new gamedevs.
It might be a good idea having these up somewhere too.
UI tools like that unit spawner thing you mention as well as feature placer, boxxy or Scened do not belong here. They're useful and should be mentioned elsewhere, but are not related to this.
Jools wrote:It wouldn't be game-agnostic if it uses chili. Just saying.
I disagree. Chili is a general purpose framework and not tied to any one game. In general I would think that it's best to avoid any dependency, but that's sometimes impossible if the library has UI elements (like the notification library) or is meant to provide chili improvements itself (like chilifx).
AF wrote:The tool I mentioned doesn't exist, but it's basically use a package manager, the same way we have bower/composer/npm etc
...
Seeing as it doesn't exist I don't want to discuss it in huge detail yet, but the first step would probably be to make it work for Lua libraries and Spring dependencies (basically the Lua mod/game/map dev environment).
There's no need to overcomplicate things with arbitrary engine modules and such.
Was actually thinking about this when I wrote it, but I looked at all the other Lua_Scripting pages and they didn't seem to have categories. So I didn't know how to do it in a consistent way. Feel free to move and delete the old page, only admins can delete.
Also would like them breadcrumbs (I noticed Pica's page:
https://springrts.com/wiki/Lua:Libarylinks doesn't have them either)
FLOZi wrote:
Also, custom unit shaders is a biggy you missed?
Correct! Added it. Is there any documentation? (LUPS is also somewhat lacking)
FLOZi wrote:
I think the little 'API' gadgets like delayCall and vectors should probably be in there too; perhaps in their own little subsection?
Agreed. I think it should be added in the second part of the page. Started work on that (not sure what the *best* links are really seeing as a number of projects use them). Still want to be conservative about what gets added there (this mustn't become a widget database).
PS: The delay API could easily be made in to a small library (maybe with some other utilities dealing with time), as you can delay calls for a certain number of frames, seconds, do it in widgets and gadgets and also delay it for the next opengl call (pretty useful as some things can only be executed in opengl).