Wiki Update

[FLOZi]

105.0 might require a team effort,

need to trawl through https://github.com/spring/spring/compare/104.0...105.0 and compare to everything labelled as 106.0 in https://github.com/spring/spring/blob/7 ... ngelog.txt

Can probably ignore all the mantis fixes for the purpose of updating the wiki - is there a way to filter the comparison on github?

[PicassoCT]

https://github.com/spring/spring/network ?

[FLOZi]

Just realised some mantis reports are feature requests too like https://springrts.com/mantis/view.php?id=6357

So guess the most robust way is just to suck it up and go through all 1500+ commits.

[ivand]

A significant amount of new functionality was added between 104 and 105, but I'm not sure I have extra capacity to fill up the wiki too.

On the Lua side the most reliable way would be to see the history of changes of each cpp file here https://github.com/spring/spring/tree/105.0/rts/Lua and see if the change added something new.

[FLOZi]

I will do the wiki updates, as I have since 90.0 , but it will take me longer this time due to work commitments and the issues with some commits being only on develop and not maintenance.

It may be quicker to go through the 290 lines of changelog checking for relevant changes in my usual manner (will thin it out some more) then check if those particular changes are present in master 105.0. (Rather than going through commits themselves - though this relies on people having touched changelog.txt but I have traditionally just worked from there)

Thanks for the suggestion re: lua, can do the same in sim too and that ought to cover everything for the wiki.

[ivand]

Good, thanks! I wasn't following Sim changes much, but I mostly expect bugfixes and minor changes e.g. different numbering of weapon indices (or did it happen before 104?).

[FLOZi]

Index changes were before 104 I think. There are some new modrules and unitdef tags in 105.0.

[saturnV]

opinions on viewtopic.php?f=14&t=42239 ?

[FLOZi]

More than likely the lua const page is outdated as you surmised.

The 'more efficient with lua' bit I think pica wrote and I don't entirely agree with it. The base documentation itself should be correct.

[saturnV]

To me it looks completly rubbish.
the only part where I even understand what the described problem is, is this one:

In some cases, only the first category listed will be obeyed. At other times in that same list, all will be obeyed.

The text wants to say that units are not put into a category despite being listed in the armorDefs table?
I found this to work normal in BA.
But I do not understand what "at other times" means? Each run of the game gives different result? Unlikely?

For the rest I do not understand at all what is "kludgy" , "messy" or "inefficient".
Picasso?

[FLOZi]

I was wrong, knorke added it. I have removed it.

[Master-Athmos]

I'd like to help if possible. I dug through the Game Development and Lua Scripting pages for the last 2 months to LUAfy Maximum Annihilation and in order to start writing some custom LUA scripts / edit existing ones to my liking. That's also where I noticed the ArmorDefs page and created the topic about it which also was mentioned here while also noticing things like that the example projects are outdated in several respects (now deprecated LUA function names etc.). When I need a break from working on MA (~500 units with the need to update every unit definition, weapon definition and whatnot is tedious) I might even create a new example game. Might as well use my future trials with Blender, Substance Painter and the PBR shader in Spring to do just that...

But for now just tell me when I can be of any service concerning the Wiki. I understand how scripting works and could even have a look at the source code as long as I don't have to backtrack countless instances of classes and their virtual functions to understand what's happening in general. I have so say though that I already had a look at quite some cpps and the code seems to be quite readable (got no flashbacks of me fighting OpenFOAM ).

I'd just need some directions on what to check based on where the current implementation in the source code is or what has to be checked in general...

EDIT:
I just checked: I still can login to the Wiki - my account still must exist from my work on it in 2009...

[Beherith]

Whenever I look for something and dont find it in the wiki or dont understand and have to look up engine source, I try to just update the wiki to clarify things. Thats usually the best bet.

[FLOZi]

Most of the const pages of the lua API need review .

I would like to template-ize callouts as I did to callins so that each entry is an anchor e.g. https://springrts.com/wiki/Lua:Callins#GetTooltip

Many callins themselves are still undocumented as to what they actually do.

I did some experimentation on the above years ago https://springrts.com/wiki/User:Flozi#T ... I_proposal the problem is replicating hte pseudo BNF as | is a reserved char in mediawiki too, so I made a template {{pipe}} though {{OR}} might be better syntactic sugar.

[Master-Athmos]

I started by adapting the LuaCallout template to what I think works comfortably when editing the wiki code. I then started to adapt the Lua System category as you can see here:

Original: https://springrts.com/wiki/Lua_System
Adapted: https://springrts.com/wiki/User:Master-athmos

Apart from missing information like descriptions and a few cases where I'd need to look up if the given wiki information is correct - is everyone ok with me adapting the remaining wiki Lua pages in this style?

[DmitryProfessional]

Please reduce red to at least dark red because it hits the eye
Look "Post Reply" button below for reference, or darker

[Master-Athmos]

Allright - I can change that. I took the color from existing wiki pages where this color was used for remarks. In the end it's not meant to be present that often though as it's more of an indicator that a proper description still has to be written (even if it just states the obvious). But yeah - I can make the color less "striking"...

[FLOZi]

Looks good, how well does it cope with something like

Code: Select all

Spring.SetUnitBlocking
 number unitID,
 boolean isBlocking,
 boolean isSolidObjectCollidable,
 boolean isProjectileCollidable,
 boolean isRaySegmentCollidable,
 boolean crushable,
 boolean blockEnemyPushing,
 boolean blockHeightChanges

or

Code: Select all

Spring.SetUnitBuildSpeed

 ( number builderID,
   number buildSpeed, [ number repairSpeed [, number reclaimSpeed
 [,number resurrectSpeed [, number captureSpeed [, number terraformSpeed ]] ]]] ) -> nil

[Master-Athmos]

Basically yes, but actually no...

I got the brackets to sort of work but in order to make it work reliably I added two additional templates:
{{bracket}}
{{rbracket}}

One creates brackets around a text or just the left bracket, the other creates just a right bracket.
This works fine but I found out that there's a strange behavior for my callout class. I put the functions you mentioned to the top of my wiki page. SetUnitBlocking works just fine, but SetUnitBuildSpeed starts skipping listing the arguments after captureSpeed. I couldn't figure out yet why this happens - the automatic comma placement detects that something should follow but it just isn't shown. The Callout template works fine for all 9 arguments and it's also not about the {{type}} template as it happens there too without those, nor is it about too long strings...

I'll have a look at this issue again and see if I can pin down the problem.

Apart from that a general question:
I don't know if it follows BNF explicitly, but I'd prefer a style where each optional arguments gets its own bracket. I prefer that in contrast to lots of single open brackets followed by a bracket galore at the very end. You can find both styles applied at the top of my wiki page. Would everyone be ok with giving each argument its own brackets?

EDIT:
Found the bug - I messed up one line in the Lua Callout template. It works as intended now and can be previewed on my wiki page...

[FLOZi]

It's not strict BNF, though I'm loathe to change it after years of it being a certain way.