Spring RTS Engine

Use this thread to post any questions regarding the Wiki as well as to report any issues you think it has.
The discussion system on the wiki is bad and likely won't get you any answers, so a wiki thread is preferred - and usually one is enough.
I'll be a lot more tolerant of off-topicness here, but still common sense rules apply:
"X is ambiguous/incomplete", "Y is wrong because of Z", and similar is better than "Q should be better".

And of course, a thank you to all the contributors so far, developing in Spring would be hell without you.

To start with, the pastebin linked in https://springrts.com/wiki/Springsettings.cfg#Example : http://paste.springfiles.com/view/648280bc seems to have outdated sections, such as LogFlush instead of the new LogFlushLevel.
So, should we remove, manually update it each time settings are changed or create a way to automatically add it much like the section above?

The text of UI commands are not visible if too long:
https://springrts.com/wiki/UI_commands
I assume this is wiki system issue, but can we provide a way to at
Also is there an option to automate that output, like in the https://springrts.com/wiki/Springsettings.cfg page?
PS: https://springrts.com/wiki/Springsettings.cfg doesn't seem to have any issues with long lines.

gajop wrote:To start with, the pastebin linked in https://springrts.com/wiki/Springsettings.cfg#Example : http://paste.springfiles.com/view/648280bc seems to have outdated sections, such as LogFlush instead of the new LogFlushLevel.
So, should we remove, manually update it each time settings are changed or create a way to automatically add it much like the section above?

/me casts 'summon FLOZi'
my opinion is that we remove it

gajop wrote:The text of UI commands are not visible if too long:
https://springrts.com/wiki/UI_commands
I assume this is wiki system issue, but can we provide a way to at
Also is there an option to automate that output, like in the https://springrts.com/wiki/Springsettings.cfg page?
PS: https://springrts.com/wiki/Springsettings.cfg doesn't seem to have any issues with long lines.

its just a formatting issue with <code><pre> blah blah.

http://en.wikipedia.org/wiki/Help:Wiki_markup#Pre

enetheru wrote:

gajop wrote:To start with, the pastebin linked in https://springrts.com/wiki/Springsettings.cfg#Example : http://paste.springfiles.com/view/648280bc seems to have outdated sections, such as LogFlush instead of the new LogFlushLevel.
So, should we remove, manually update it each time settings are changed or create a way to automatically add it much like the section above?

/me casts 'summon FLOZi'
my opinion is that we remove it

*materializes out of the ether*

My opinion is also to remove it. RE: UI_Commands, jK is the automagical updater, so ask him

Imo also that pastebinned "example" should go (the rest of that page, though, is very useful).

Oki, killed the example.

Split out discussion of (dead) links to widget database to here viewtopic.php?f=23&t=33373

Split out discussion of custom commands to here viewtopic.php?f=1&t=33386

Silentwings wrote:Another area: I have never been able to get much out of the AI wiki stuff, although I tried to more than once in the past. I always ended up linked to development threads that were too time consuming to pick info out of, e.g. https://springrts.com/wiki/AI:Development:Lang:Cpp.

The C++ side is pretty bad, and what is more bad is the fact that you also need to compile Spring to build your AI. Talk about a steep learning curve.
The Java AI documentation is much better, and there's also a reference documentation site hosted by abma, which helps a lot.
Fixing this might be pretty hard, as there's no active C++ AI dev and no engine dev is dealing with the AI side.

Silentwings wrote: Imo it would be good to do something about the old resource subforums, they are barely used but they contain plenty of stuff that I wouldn't want to see lost, and there is always the argument that people might get old projects going again from old threads. So, I guess options are that we just lock them, or that we put a sticky/announce of "it's usually better to use the wiki" on them.

I don't think it should be deleted. Maybe locking stuff that is obviously old is the way to go though, but I really don't think it's such an issue...
A sticky would be best, but I assume that the vast majority first go to https://springrts.com/wiki/Engine_Development page from the "Development" top link.

Split out discussion of wiki & resource subforums to viewtopic.php?f=1&t=33438 (Silentwings).

PS: https://springrts.com/wiki/Engine_Development page should probably not be called "Engine_Development" as it covers more than the Engine. Can this be fixed by just renaming or are we going to mess up a bunch of links?

No idea how easy it is to rename, but the actual engine development page, which is linked to as "Engine Development" from that page and the main wiki page https://springrts.com/wiki/Main_Page, is https://springrts.com/wiki/Development:Getting_Started.

iirc I moved the wiki page itself but kept a redirect for what the site points at

#1 Remove the authors page

It's out of date and a maintenance hassle. Instead, lets link to the GitHub contributor page instead.

I'd make the case that the roflcopter attribution in the footer should be changed instead to "Site built by the community" and linking to the website contributor page

#2 System Requirements

Why do we list system requirements on the about page, when we have an entire page dedicated to system requirements?Is there any objection to simply linking off to this?

# 3 What the engine doesn't do

We should devise a list of commonly requested or desired things that can't be done, and things that are halfway there, that are relevant to potential users of the engine, e.g.:

- Mesh deformation
- Out of the box save/loading
- Inverse Kinematics and ragdoll physics

All of which can be implemented but it should be noted that they're not in a well documented and fully fledged form at the moment, are there others?

I recently made a number of other changes:

- Rejigged the layout of the game page to fix a number of quirks and bugs
- Removed the boxes with the broken styling on help and development and replaced them with normal text under a quick links title
- Added the GitHub project to the dev page, it's frustrating that an open source project hides their source so deeply inside their wiki, it should really be on the front page
- The developer column of the main wiki page now has 2 sub sections, Engine & native dev, and Content dev
- Spelling errors

AF wrote:#1 Remove the authors page

It's out of date and a maintenance hassle. Instead, lets link to the GitHub contributor page instead.

You should note that Github contribution page isn't fully accurate (the core developers aren't shown as they mostly don't use a GitHub-registered email).

AF wrote: # 3 What the engine doesn't do

- Out of the box save/loading

I wouldn't mention this one, as it might mislead people into thinking Save/Load is not possible to implement through Lua.

Which is why you list it separately, either way they'll make their way into the forums and be told exactly that, so lets save them the hassle and tell them the situation

AF wrote:Which is why you list it separately, either way they'll make their way into the forums and be told exactly that, so lets save them the hassle and tell them the situation

(Assuming you're talking about the Save/Load) -> That's mostly wrong. There's a nearly complete implementation that can be obtained from ZK.
It serves no purpose to point out to things that are obtainable and implemented in Lua. There's also no builtin UI library, but that doesn't make sense mentioning as there's Chili and some other Lua frameworks/libs.

what would be an in-between road that would satisfy both parties?

couldn't a FAQ with good answers be a viable solution?

is there a valuable distinction between 'native'/'zero cost' features that work as intended, and possibilities, workarounds and hacks.

..bridges comes to mind.. water height

enetheru wrote:what would be an in-between road that would satisfy both parties?

I am happy with the two other issues. Those are things that simply can't be implemented satisfiably in Lua.

enetheru wrote: couldn't a FAQ with good answers be a viable solution?

It could! Needs to be a complete answer in that case, but if you just make a list of things Spring doesn't do, save/load shouldn't be there!

enetheru wrote: is there a valuable distinction between 'native'/'zero cost' features that work as intended, and possibilities, workarounds and hacks.

I think so. Bridges are sorta possible depending on how you define them, but Spring doesn't have fluid physics for example -> important distinction on "doability".

Then they should go under a 3rd party implementation part elsewhere in the wiki, but there's still plenty to list, e.g. waterfalls and flooding dynamics, multiple water heights, model rigging, etc

As for stuff like Chilli etc, sometimes when prospecting things it's useful to know that something exists but isn't in the engine itself, it helps figure out how much work it'll be for you.

E.g. if you're in the market for a house, you'll probably say no if someone called Gajop shows you around and says things like "But next door has a full implementation of Windows and doors", or "Our warehouse has a good selection of floors but we don't advertise missing floors in this house, you can just install them if you want them"

Just remember, everything you say makes perfect sense to people in this community, but this kind of content is not for people in the community, the whole point is the people reading it know nothing of the community, so what you're saying won't make sense to them without additional knowledge they don't have.