Dgunning enemy's com in 1v1, ffa and last com in teams kills it instead of the dgunner.

Floris has done some work in the past on making Chobby work with BAR

It makes it easier to get the game on any distribution and keep it up-to-date.

when there is something on a hill, they stay too far with fight command, and wont shoot or move.
Not sure it's only for fidos...

smurf : lol mercury are so fucked
L0v3 : lol yeh

The broad stroaks:

• Build a heavily streamlined lobby
• React, Redux, React Router for the UI
• SCSS for CSS
  • Less.js is a bit old now
  • PostCSS seems new and muddles JS and CSS, it might be cool to be able to use Tailwind, but it's a higher bar to entry, I want the project to be maintainable and SCSS is straight forward to learn
  • I like Bulma, it has a nice grid system, some basic components for things like buttons and typography, doesn't overextend itself
• Use Neutralino JS to host the application
  • electron bundles chromium giving it a large footprint in memory and file size. I have misgivings about chromiums performance
  • NW.js seems better than electron but not as lightweight as Neutralino
  • Neutralino has a simple API and smaller footprint
  • There was another option that was very lightweight but provided just a webview, it would need to have been forked to provide an API to launch spring or read files
• Completely abandon the existing server infrastructure
  • Battles will be retrieved from a REST API endpoint, no login necessary
  • Debuggable using standard REST API tooling, such as POSTMAN
  • Players will make changes to the battle using the same endpoint and POST requests
  • OAuth 2 based authentication
  • No channels DMs or chat, players can use Discord servers, Slack, Skype, etc
  • Player identity to be managed via the REST API and a federated login, preferably Discord
    • I'm in favour of using WP to manage login and REST API, with no WP frontend or WP interface for users. Headless, purely internal
    • any $1 webhost can be setup to act as a game server in minutes, multisites can be used to partition games/battles, object caching with Redis should make things stupid fast with the right data structure
    • a lot of it can be partitioned into separate projects, Discord login is a highly desirable plugin that others would want who have nothing to do with BAR or Spring, free testers and maintainers ftw
  • Autohosts would just be instances of dedicated spring that are told "go to /wp-json/lobby/v1/bar/1234 and start an instance, then POST to that endpoint to say you've started, let us know at the end who won/lost.
    • A heroku dynamo could be spun up for each battle using the Heroku API and a github repo to auto-scale.
    • Alternatively a docker container that takes an environment variable containing the battle ID and a shared secret for API auth
    • The command should be runnable via npx, e.g. npx spring-start --engine=".." --map=".." --game="..." etc should download the relevant engine if it's not already, then start up a headless spring. Anybody with node could spin it up with ease
    • Autohosts won't manage the battle itself, they're dumb launchers for the spring executable
    • No voting controls
    • The first player in a battle is nominated the host. They can hand the host to another player. If they leave, the first person in the list gets passed the host. They don't necessarily have to literally host the game on their computer. Look at the way Zoom has a person who controls the meeting called the Host, but that person is just the admin of the zoom meeting, the hosting is done by servers elsewhere
  • PRDownloader etc, I'd really like it if that part of spring-launcher was hived off into its own package so that mutual maintenance could happen. I don't fancy rebuilding basic stuff like this from scratch, better to share and improve alike. There should be a lot of small utility packages at the end of this, nice building blocks everybody can use, be they javascript or typescript
• Ranks are going in the bin. The current system of arbitrary medal tiers for time ingame is silly. Supernoob got a stupid high rank without playing a single game by spectating. Just bin ranks, and have none.
  • When the time is right to do it properly, introduce a ranked ladder for competitive play, define how long a season lasts, etc
• Nuke flags. When the community is large enough, just ask players if they want the american server or the european server, otherwise they're super unreliable, expose personal information, and add unnecessary information to the UI
• Singleplayer is more important than multiplayer, multiplayer users are just deafeningly loud in comparison
• For maintenance and Documentation
  • markdown document in each folder for documentation
  • I want to use jest for testing, in particular snapshots
  • A fetch polyfill for API requests
  • I like the idea of using https://sentry.io/ for automated bug reporting

I've identified these projects will be needed:

• Discord WP plugin
• Battle API WP plugin
• Lobby repo
• autohost repo ( also on https://www.npmjs.com/ )
• PRDownloader library repo ( also on https://www.npmjs.com/ )
• unitsync equivalent library repo ( also on https://www.npmjs.com/ )
  • for this it shouldn't assume unitsync and just provide an interface for maps and games with options, then a default implementation that does spring. I expect other game engines would find this helpful, and that would help enormously with maintenance

Don nott know where they got it from or if it is an original, but it helps to see radar coverage in sight coverage mode very nicely.

Specially since you do not see the radar shadows cast by terrain otherwise

Hey, I'm using the appimage on Linux, but the openal library is missing from the image.

Is there any script that builds the appimage? I would like to contribute the required changes to add the missing library.

I think the most realistic approach to any kind of cooperation between the various JS lobbies and launchers is to make npm packages that do most of the hard stuff.

I've written a list of what I plan to produce from spring-launcher.

• gajop/spring-launcher#37

Luckily I've already written most of this functionality with spring-launcher, it "just" needs to be made into packages other people could use.

I hope someone will write a package for the communication with various lobby servers, (most importantly Uber, and if really bored a ZK one as well and whatever else new comes along).

Would like to hear what everyone has in mind regarding this. I will only be creating these packages if I see there's strong desire for such a thing and if I think this will be mutually beneficial.

I know it's an engine thing, but i would really like to see transparant smoke-shadows, if smoke particle also get more transparent.

Due to passive builders and metal converters behaving passively, you have no idea how much you "could" consume vs what is actually being consumed, while build processes are idling in the background.

Before running into choosing an implementation, I think we should first describe the current situation and what we like or dislike about it - only then can work be sensibly directed.

I would like to split this into two parts: User Experience and Technical Concerns, as knowing where the issue is will be critical in determining tech stacks and problem areas.
So without further ado:

User Experience

Chobby + spring-launcher:

• TODO: Write key pros & cons

SpringLobby:

• TODO: Write key pros & cons

uberserver & other existing infra stuff:

• TODO: Write key pros & cons

Technical Concerns

Chobby + spring-launcher:

• TODO: Write key pros & cons

SpringLobby:

• TODO: Write key pros & cons

uberserver & other existing infra stuff:

• TODO: Write key pros & cons

Additional candidate to consider for removal is "You are wasting metal"

BA9 solved this issue

Basically we need to add to the passive builders widget the condition that constructors shouldn't stop if building something that requires 0 resources, in this case energy.

It comes as a natural consequence of #60

It centers the camera itself directly above the unit, which can have the unit completely off-screen if you're looking too diagonally.

And construction units too?

http://logs.springrts.com/logfiles/605/

Pressing esc currently tells me to press shift-esc - not very useful

The copyright and licensing story is currently not good enough.

Not sure how to recreate, but it seems to happen often with a queue done with the initial queue widget.

Attached a screenshot

the ghost disappears after a while, eg. when something is built next to that building.

Let's add a Ready button as well when startpostype=fixed or random.

It is annoying that the game loads and starts immediately, sometimes you get bored with looking at the loading screen and want to do other stuff, but it forces you to pay attention as the game may start any time. Another big issue connected to it is that you are not able to chose a faction in-game, so ppl using current lobby will always default to ARM, since no lobby-side faction picker either.

This renders them pretty much useless while left on auto attack

lets make fighters aa online. hundreds of fighters shooting missiles to the ground doing relatively low damage each can be quite performance heavy for a relatively small gain. sure hundred fighters do some damage in the end but the price for this is high and imo unnecessary also in term of consisteny when thinking seperating task for unit. fighter is already very powerful in his role and and multirole units should be generally less effective. its only for lazyness keeping ag missiles for fighters but its not even fitting the rest of the game mechanics

as a return for the air-ground balance i would increase hp of gunships a bit for not making everything even more ground dominant. they are still rarely used in general and giving them a small incentive for loosing fighter ground attack ability (having the whole picture in mind) would be probably a plus for the whole game mechanics

cheers, Flaka (if anyone wonders who fruehling76 is)

Are those to go away for ever? They where incredibly nice.

Hi,

I'm on byar-14688 and I've got a problem with the mouse cam control:
The mouse can't move the camera, the option is not enabled by default on the config. When I enabled it and restart a session (not the full game), the camera work.
But when I do a full restart of the game, the config is overriden and the camera is lock again.

Maybe byar-chobby rewrite the config file with default value everytime it's launch?

Should they do it the other way around?

Realism oriented TA has a WIP lobby:

https://github.com/Realism-Oriented-Total-Annihilation/spring-launcher

• typescript + electron
• eschews UI libraries and frameworks such as React or Vue in favour of vanilla JS/TS

This would make skirmishing a lot richer and realistic. At the same time it would have bigger impact on gameplay for which I would like to have your tentative approval first. @Ruwetuin @icexuick (sorry if I'm missing anyone else on the sign-off list).

I managed to get it working on the stumpy already and know my way around.

• Get approval
• Make listing of all tanks in question

some feedback based on yesterdays games:

AI too late on t2
ai does very good on t1 but suck from the moment it has to go t2. there it gets surpassed by human. only 2 of 5 ai ver going to t2 in a 40min match on delta siege dry. first one around min 23 when human tries to go around min 10-12 there. they already had all over 20 metal income and lots of metal in storage.

solution:

• lower the trigger for t2 or spread it wider

i wonder also if it is possible in multiplayer games to let ai play sometimes with kind of teching ai, which maybe reclaim com to level up very early and then force economy and build t2 cons for other players which they use them too build some t2 mexes before they level up. comleting that task it should force economy again before going early to t3

Activating "Passive builders / cons" does not result in the constructors actually being set to passive upon construction.

Since there is a lot of discussion pertaining new lobbies it might be of use to agree on what the flow and data of "an ideal" backend would look like.

This way lobbies can keep it under consideration regardless of whether they are aiming to support uberserver first or not.

I propose we meet in voice channel one day to talk and create a rough outline we can then hone in on.

Located at GitHub Repository, supersedes #42

The idea behind the whole thing was to create a launcher that offers an interface for mutators for any mod, while standing on the currently existing infrastructure. It has to be;

• Compatible with Uberserver (for better of for worse, it makes no sense to change everything at once, and the main spring lobby server is running Uberserver so...)
• Do not marry the Uberserver in the process, We want to switch that to something cleaner and more performant so it scales to what you would get if you publish for example BAR on Steam.
• Easy to develop and maintain (low entry to contribution barrier)
• Fast to develop and maintain.
• Cross platform, with Linux amongst the first class citizens...
• Reasonably performant (snappy) and not to big in executable size. This point is on purpose at the bottom of this list.

The tooling we went for;

• Electron
• Typescript (makes Javascript orders of magnitude more bearable)
• No frameworking, just plain vanilla ECMA6 and NodeJs in the back

Progress so far;

• Login, Registration and Confirmation
• Player Listing (IRC)
• Battle Listing

Missing;

• Map visualization and handling
• pr-downloader wrapping
• The settings story (not really clear what makes sense here, the experience with SpringLobby is not very good)
• Game room functionality
• Game start

Help needed;

• UI design needs a lot of improvement. Help wanted/needed
• UX needs ideas to further project itself.

Post-parity TODO's;

• Torrent support for download infrastructure (pr-download for seeding, torrent for offloading)
• New backed support for a new lobby server

Up for discussion whether that is intended to happen or not

There is practically no visibility of radar coverage (LOS difference - if any - is insignificant). Radar is very important in BAR and it's going to confuse newbie players if such information is hidden

units with order "maneuver" should always return to there original position after completing a task (hunting/attacking) enemy units that come close

• cordoom: only one light laser (red) shots from right barrel

Hi,

I want to try this game, but I can't install it on my W10. I have not try on Linux.

The updater say: Request Failed: 404

Here is the link to the complete log.
http://logs.springrts.com/logfiles/1251/

Extracted part for the error 404

[error] engine/104.0.1-1553-gd3c0012 maintenance: Failed to download resource: Request Failed.
Status Code: 404

Ps: I've disable my personal DNS before opening this ticket.

Needs to be reproduced and dug in further to narrow down what exactly is happening

Couldnt use reclaim command properly on riverdale, it happenned on other maps, dont know why

The in-game updater will fail on Fedora 33 with error on initial run. [Error] ../../tools/pr-downloader/src/Downloader/Http/HttpDownloader.cpp:487:processMessages():CURL error(1:77): Problem with the SSL CA cert (path? access rights?) 0 (https://repos.springrts.com/repos.gz)

Enterprise Linux distros (CentOS, Fedora, Oracle Linux, RHEL) place CA certs in /etc/ssl/certs/ca-bundle.crt and /etc/ssl/certs/ca-bundle.trust.crt (for extended validation certs). The updater should look for these paths in addition to /etc/ssl/certs/ca-certificates.crt. Symlinking /etc/ssl/certs/ca-bundle.crt -> /etc/ssl/certs/ca-certificates.crt fixes this issue on Fedora 33. I did not test on the other flavours of Enterprise Linux, but it likely affects all of them.