Spring RTS Engine

Well, I'll probably open a flame for this, but eh, who gives a rip.

First off, I got a suggestion about syncing. I know we all played games were we lost sync with players and they ended up dropping. Is there a way to regain sync again once your in game? Maybe the host can pause and do a .sync command and the clients try to resync with the host?

That leads me to a 2nd suggestion, pausing in game. Can you make it so that when the host pauses the game, nobody else can unpause? There were a few times I had to pause due to a really long no/delay sync and people kept unpausing it.

Lasty, I have a few . commands that I would like to see implemented.

1. I like how .setmin/max speed works. But can you make it as easy as it was on the TA demo recorder? Maybe like .setspeed <min#> <max#>

2. In the current spring, to share res, we have to adjust the slider and anything in access of that point will be shared. Personally, I hate having to re-adjust the slider for when I get new cons, or make storage. I suggest making a . command that will put the slider at a user specified number for the remainder of the game, or until the user changes it. Maybe .setshare <#> for both metal and energy, or .setsharemetal <#> and .setshareenergy <#> for metal and energy respectivly. This will also move the slider to the corresponding position.

3. This is the last suggestion. In OTA, the demo recorder allowed us to see, in the minimap, where our allies were focusing their attention (ie. there would be a box on the minimap that showed the allies where exactly their ally was looking at on their screen). I was wondering if this could be done in spring as well? It doesn't have to be a big box, just like a 1x1 or 2x2 colored box that showed where he was focusing his/her attention. It might help the allies see what the heck he is doing (or not doing) Maybe a .mappos or something?

Well, let the flames begin.

Asking for features from the demo recorder is hardly going to cause a flame war.

And 2 should be a percentage.

<insert random flame here>

when are people going to realise there are enough suggestions for now?

The day you realise you're not working hard enough.

and also the day when you look out the window and realize that WE, your loyal fans, outnumber you...imensly.

Then you break out in a cold sweat, and work even harder!!!

Zaphod wrote:<insert random flame here>

when are people going to realise there are enough suggestions for now?

There's enough suggestions for a LONG LONG time

Well, I know your guys are already knee deep. But "most" of the stuff I suggested has already been coded, some of which are already in the demo recorder. So it shouldn't be too hard to implement when you already have the code. That, and the .setspeed should be a simple change in a line of code. Just combining 2 commands into one.

But yes, I do appreciate all the work you guys do. Just trying to suggesting a few things to try to fix some of the commen, annoying problems.

Push me hard with NTAI and I'll crash and burn. Considering zaphods position, he's udner much much mroe strain than I am.

I may be in the middle of a pincer of school work NTAI, but I'm ntot he project leader of Spring, and I'm not being harassed for hundreds of features.

If you want your features go out and fidn Zaphod new programmers, maybe then your features will be implemented before you thik fo them adn we'll get much much mroe fo them faster.

Otherwise lay off him before he goes haywire.

Well, I dunno Zaph knows about the demo recorder but a lot of this is something the SY already did.

ie. .syncon 1 1 would set max and min speed of the game
the demo recorder also showed on the minimap where ur ally's were looking.

The only "new" thing that I suggested was the resyncing, everything else has already been done by SJ and the SY's. (heck, spring already has a lot of the ta demo recorder functions built into it)

Hmm...maybe they didn't like the showing the map pos.

I know its hard being a lead coder. I hate coding myself so I know how daunting it is. But if nobody ever suggests anything, how will spring grow and become better?[/url]

resyncing?

Spring makes a set fo hashes that are unique, they are made from the positions and descriptions of the untis on th battlefield.

Then spring sends these fof tot he host and the host comapres all the hashes. If the hashes dont match, then that means the information on one machien isnt the same as another, so an out of sync message is outputted.

resyncing is crazy but additional replay features such as a box where the player u selecteds view is or be able to see his cursor would REALLY help us all learn about micro and macro a lot quicker

Resyncing would technically be possible. It would just take a while. What would need to happen i think would be that the host pauses, types in .resync or whatever, and the host then sends the location/state of every unit and other object on the map, and the map deformation data. It would take a while because of the amount of information being sent, but it would technically be possible. However, this would be quite a bit of information, possibly going up into the megabytes, because of the amount of information. Because of this, while it would be a handy feature, I dont really think it is viable.

Resyncing is also one of the major requirements for a good port to linux/other platforms... this will definitely be implemented but it's a fairly big thing.

Min3mat wrote:resyncing is crazy but additional replay features such as a box where the player u selecteds view is or be able to see his cursor would REALLY help us all learn about micro and macro a lot quicker

The cursor thing would be a major pain in the ass to implement. It would also make the size of replays a lot larger. The thing I really want for replays is the ability to select the units of any player. Also it would be nice to have something like .showqueue where it automatically shows the buildings/actions that are queued.

Maelstrom: I don't think it would require as much data transfer as you suggest. Considering the size of most replays that is; and that is the data from the whole length of the game. And if/when it is implemented, I don't think the host would have to type .resync it will probably be automatically done in the background.

Replays are different than sending the state of every unit in game. Replays are basicly a whole bunch of orders and stuff. The game then calculates, using this data, how the game was played. Therefore, it is impossible to get the location of a unit or bullet or the state of the terrain without running through the whole replay data. So just sending the replay as you suggested would not work. Unless there was a way to speed through replays at about 1000 speed, doing it that way would take longer than just sending the state of every unit.

My map GUI I'm working on could show you where the allied players are looking and where their cursors are.

It could also tell you what units they have selected, what their commands are visually, custom flares etc.

Otherwise if you need it so badly, I could write you a GroupAI for tomorrow...

u can see queues in replays...

Well, having that screen show on the replay is nice, but having it in-game is good too.

But anyway, with all the talk of replays, I guess I have 1 final suggestion.... There needs to be a way to fast forward a replay. ie. if I only want to know what happened during the final half or 3/4 of a game and not the beginning of it. I know the ta demo recorder had this command in it, but it was a risk using it. It could have caused a crash and crashed the demo recorder and TA. It worked sometimes.

So I'm wondering (since spring has most of the ta demo recorder functions built into it) if this will make it into spring as well? like a .demopos <#> where # represents a %. like 50 would represent 50% and then spring would jump to halfway point in the demo.

"+"

"-" to slow it