Backtrak's gameplay development poll
Hi All,
Sorry I haven't been around much, it's been one hectic summer. Chainsaws vs trees, Trap shoot nationals, Pigs at the fair, two in highschool, one starting middle school (kids not pigs), a mega vacation to Universal Studios in Orlando, and then... Allegiance!
So, I owe you all a state of the world since April:
1. YP and I got a deathmatch bot thing working on East2, neat!
2. Radulfr made a whole bunch of server changes and tweaks with an eye on evolving those over time.
3. Wasp made some interesting findings on his Joystick / Dx9 / Dx7 issues
3a. Oldest kid jumps on me, busts my shoulder... working is incredibly painful!
4. I modified my laptop to attempt to replicate Wasps findings (Not a smart move looking back on it, I should have used a VM for this) - This may be the cause of why my server builds don't work with the bots anymore.
5. Radulfr made some more fixes in response to community feedback
6. When I tried to build these and deploy the server, the bot host completely quit talking to the game server. It talks to the lobby, it works fine on my laptop, it works fine on my test server, but doesn't work any more on East2.
7. I spend several weeks trying to figure out why. No luck. Final option is to rebuild my laptop, which would mean days of lost work on several other paying projects. (not an option at this time )
8. Summer kicked in (see above)
9. MRI + Cortisone Shot + Physical therapy got my shoulder up and going again!
10. Last month, started working on a new bot system to enable bot commanders. So far I have a two sided bot game running with opening scouting, up to tech con placement. More to come.
So, here we are.
Decision Time!
Do you guys want me to release Radulfr's changes and lose the DM Bots, or do you want to keep the DM bots and roll back to an earlier server build? Or, do nothing and leave everything as is until I finish bot comms (several months away).
Other requests in the todo list: Get Rock's next-release branch up and building so that he can release Betas.
Radulfr, MSDN is running a 750 free Azure hours promotion right now, if you sign up, you can run your own Allegiance Azure server for a year. I would be happy to help you set it up and get it connected to the lobby. Then you can modify / deploy server changes at will. PM me if you would like to try that!
B1S VM - https://azure.microsoft.com/en-us/free/
Poll is above!
Sorry progress has been so slow... Allegiance is very much a project of opportunity for me, I appreciate your patience!
Sorry I haven't been around much, it's been one hectic summer. Chainsaws vs trees, Trap shoot nationals, Pigs at the fair, two in highschool, one starting middle school (kids not pigs), a mega vacation to Universal Studios in Orlando, and then... Allegiance!
So, I owe you all a state of the world since April:
1. YP and I got a deathmatch bot thing working on East2, neat!
2. Radulfr made a whole bunch of server changes and tweaks with an eye on evolving those over time.
3. Wasp made some interesting findings on his Joystick / Dx9 / Dx7 issues
3a. Oldest kid jumps on me, busts my shoulder... working is incredibly painful!
4. I modified my laptop to attempt to replicate Wasps findings (Not a smart move looking back on it, I should have used a VM for this) - This may be the cause of why my server builds don't work with the bots anymore.
5. Radulfr made some more fixes in response to community feedback
6. When I tried to build these and deploy the server, the bot host completely quit talking to the game server. It talks to the lobby, it works fine on my laptop, it works fine on my test server, but doesn't work any more on East2.
7. I spend several weeks trying to figure out why. No luck. Final option is to rebuild my laptop, which would mean days of lost work on several other paying projects. (not an option at this time
)8. Summer kicked in (see above)
9. MRI + Cortisone Shot + Physical therapy got my shoulder up and going again!
10. Last month, started working on a new bot system to enable bot commanders. So far I have a two sided bot game running with opening scouting, up to tech con placement. More to come.
So, here we are.
Decision Time!
Do you guys want me to release Radulfr's changes and lose the DM Bots, or do you want to keep the DM bots and roll back to an earlier server build? Or, do nothing and leave everything as is until I finish bot comms (several months away).
Other requests in the todo list: Get Rock's next-release branch up and building so that he can release Betas.
Radulfr, MSDN is running a 750 free Azure hours promotion right now, if you sign up, you can run your own Allegiance Azure server for a year. I would be happy to help you set it up and get it connected to the lobby. Then you can modify / deploy server changes at will. PM me if you would like to try that!
B1S VM - https://azure.microsoft.com/en-us/free/
Poll is above!
Sorry progress has been so slow... Allegiance is very much a project of opportunity for me, I appreciate your patience!
Last edited by BackTrak on Fri Aug 31, 2018 8:08 pm, edited 1 time in total.
Hi BT!
Finally the cavalry is here to save the day.
Umm I voted for a complete roll back before reading your post BT.
The BOT PIGS server was mainly put up so new players can test out the game when the game servers are empty.
I rarely see them used and the general consensus from most new players it the PIGS are too good, driving them away.
If they could be toned down a LOT I am good with option # 1
But I could wait for the BOT COMS to be completed if you we are looking at a reasonable amount of time.
Finally the cavalry is here to save the day.
Umm I voted for a complete roll back before reading your post BT.
The BOT PIGS server was mainly put up so new players can test out the game when the game servers are empty.
I rarely see them used and the general consensus from most new players it the PIGS are too good, driving them away.
If they could be toned down a LOT I am good with option # 1
But I could wait for the BOT COMS to be completed if you we are looking at a reasonable amount of time.
Nice to see you back BT, sounds like you had fun.. maybe too much if your kid thinks he has to jump on you.
Interesting to hear things from your perspective. I hope you understand though, that it is frustrating for me to have fixed a bug and not seeing any effect for months, while people complain about it. Which is why having a test server which shows the latest state of the code would be great.
Personally I consider having three servers already very much for a game that has either no, or exactly one game running at any time. I don't want to add a fourth server if it can be at all avoided. Especially since I want people to actually play on the test server, to get the logs, which is getting more unlikely the more alternatives there are.
If you want the extra server as backup server in case one goes down - As mentioned, I want people to play on the test server, so I will keep it in a usable state and it should be fine as backup + there is the third server.
If you want the extra server to test things yourself, we could use the same server for that.
The Microsoft Azure server comes with a whole lot of limitations and conditions, for example only 15GB outbound data. I'm not at all sure it will work out for Allegiance without costing anyway in the end. And if I'm going to be paying for a server, it won't be a US one.
Now, regarding decision time: I voted lose DM Bots.
You can't have a new feature, which never worked reliably, blocking fixes and development.
If you roll back the server, you may also have to roll back the client, to keep things in sync and not run into new issues. Then we have old bugs back and can't fix them for months. You should never put yourself in a position where you can't deploy fixes.
Enough of an argument, but personally I also think the very principle of the bot server is flawed and it should be replaced. Why have an external tool pretend to be a human player just to get a ship to shoot at, when you can easily type CreateDrone(x,y,z)!?
With that approach you could easily create 100 light scouts with Gat1 and Nan3, where ever you want, to make for a unique challenge, for example. Try to create 100 players, have them join, chose teams, set up ships, launch, and get into position with your tool..
The only real downside to drones is, that if you mess up, the server will crash, instead of your external tool.
Interesting to hear things from your perspective. I hope you understand though, that it is frustrating for me to have fixed a bug and not seeing any effect for months, while people complain about it. Which is why having a test server which shows the latest state of the code would be great.
Personally I consider having three servers already very much for a game that has either no, or exactly one game running at any time. I don't want to add a fourth server if it can be at all avoided. Especially since I want people to actually play on the test server, to get the logs, which is getting more unlikely the more alternatives there are.
If you want the extra server as backup server in case one goes down - As mentioned, I want people to play on the test server, so I will keep it in a usable state and it should be fine as backup + there is the third server.
If you want the extra server to test things yourself, we could use the same server for that.
The Microsoft Azure server comes with a whole lot of limitations and conditions, for example only 15GB outbound data. I'm not at all sure it will work out for Allegiance without costing anyway in the end. And if I'm going to be paying for a server, it won't be a US one.
Now, regarding decision time: I voted lose DM Bots.
You can't have a new feature, which never worked reliably, blocking fixes and development.
If you roll back the server, you may also have to roll back the client, to keep things in sync and not run into new issues. Then we have old bugs back and can't fix them for months. You should never put yourself in a position where you can't deploy fixes.
Enough of an argument, but personally I also think the very principle of the bot server is flawed and it should be replaced. Why have an external tool pretend to be a human player just to get a ship to shoot at, when you can easily type CreateDrone(x,y,z)!?
With that approach you could easily create 100 light scouts with Gat1 and Nan3, where ever you want, to make for a unique challenge, for example. Try to create 100 players, have them join, chose teams, set up ships, launch, and get into position with your tool..
The only real downside to drones is, that if you mess up, the server will crash, instead of your external tool.
Hi Radulfr,
I completely agree with you on not locking out changes. That is mostly the fault of my lack of time. The bot setup was working fine all the way up to 4/24, which coincides with several things happening at about the same time. The number 1 culprit I'm blaming is my laptop's config, which currently has all VS versions from 2005 to 2017, and several platform targeting packs and a platform selection toolset from some random guy. I think I jacked up my machine's ability to create a server .exe that is compatible with the AGC COM and PigsLib COM modules at the same time, but I don't know enough about it to figure out why.
I don't think anyone will argue without about bug fixes, but there seems to be a lot of argument on what consists of a bug. For instance, does a miner avoiding an enemy sector constitute a bug, or something that a comm must carefully manage until they can get the team to remove the hazard? Game play elements like this will create controversy just because people are used to them over a long period of time. I don't think there is a right answer, it really comes down to preference.
Here is a list of server side changes which I believe are affecting these types of game play elements:
https://docs.google.com/spreadsheets/d/ ... sp=sharing
Rolling back these changes means going through each change set and reverting the key areas leaving the other UI and bug fixes alone. I can see that you put some effort into these, so I hate to lose your work. What would you think about linking your game play changes to the Experimental Game flag that is available in mission parameters? Then comms can easily decide if they want to play with your changes, or if something gets messed up, then it will easy to play without them.
Believe it or not, 15 GB is plenty to run an Allegiance server for a month. The game is after all optimized for a 28.8kbs modem. The game server itself was made to run 20k players on a Pentium III. My Azure servers are snoring 99% of the time.
I will mess around with it today and get the most current server code running on east1/2, that will give us a baseline on where we are at now.
RE: bots and bot servers - Kage made similar points about bot servers in that the bot functionality belongs inside the server and not in a stand alone application. There is some merit to this approach, namely you don't have to play an interop game trying to get Allegiance objects into an external application / alien framework. Native objects stay native, and you can take full advantage of the existing code. However, when it comes to actual testing and test iterations, things get a lot more complicated. In my case, running a lobby, server and several allegiance game clients while testing bots means that a bot logic change in server code requires restarting everything except the lobby. This is very cumbersome for my CABTAB style. I'm not ashamed to admit it.
So, I prefer the benefits that a stand-alone bot client gives which for the way I'm testing lets me spin up 2 full teams of players, and one comm in one go, and then spin up another comm independently. Then I can modify code and comm behavior on the single bot without impacting the running game letting me quickly make changes without restarting the entire game. Considering that it takes 5-6 minutes to hit the opening tech stage, restarting the server every time would be untenable. Under the new model I've been working on, bots work though C++ interop without any COM at all. This makes build cycles a whole lot cleaner and I don't have to worry about funky server installations, while giving me full access to the entire IGC stack and Allegiance event systems (by way of listening directly to the DPlay messages and Allegiance events). By treating bots as game clients, I get all the benefits of clintlib.
Anyway, lots of fun has been had so far, and more to come!
I completely agree with you on not locking out changes. That is mostly the fault of my lack of time. The bot setup was working fine all the way up to 4/24, which coincides with several things happening at about the same time. The number 1 culprit I'm blaming is my laptop's config, which currently has all VS versions from 2005 to 2017, and several platform targeting packs and a platform selection toolset from some random guy. I think I jacked up my machine's ability to create a server .exe that is compatible with the AGC COM and PigsLib COM modules at the same time, but I don't know enough about it to figure out why.
I don't think anyone will argue without about bug fixes, but there seems to be a lot of argument on what consists of a bug. For instance, does a miner avoiding an enemy sector constitute a bug, or something that a comm must carefully manage until they can get the team to remove the hazard? Game play elements like this will create controversy just because people are used to them over a long period of time. I don't think there is a right answer, it really comes down to preference.
Here is a list of server side changes which I believe are affecting these types of game play elements:
https://docs.google.com/spreadsheets/d/ ... sp=sharing
Rolling back these changes means going through each change set and reverting the key areas leaving the other UI and bug fixes alone. I can see that you put some effort into these, so I hate to lose your work. What would you think about linking your game play changes to the Experimental Game flag that is available in mission parameters? Then comms can easily decide if they want to play with your changes, or if something gets messed up, then it will easy to play without them.
Believe it or not, 15 GB is plenty to run an Allegiance server for a month. The game is after all optimized for a 28.8kbs modem. The game server itself was made to run 20k players on a Pentium III. My Azure servers are snoring 99% of the time.
I will mess around with it today and get the most current server code running on east1/2, that will give us a baseline on where we are at now.
RE: bots and bot servers - Kage made similar points about bot servers in that the bot functionality belongs inside the server and not in a stand alone application. There is some merit to this approach, namely you don't have to play an interop game trying to get Allegiance objects into an external application / alien framework. Native objects stay native, and you can take full advantage of the existing code. However, when it comes to actual testing and test iterations, things get a lot more complicated. In my case, running a lobby, server and several allegiance game clients while testing bots means that a bot logic change in server code requires restarting everything except the lobby. This is very cumbersome for my CABTAB style. I'm not ashamed to admit it.
So, I prefer the benefits that a stand-alone bot client gives which for the way I'm testing lets me spin up 2 full teams of players, and one comm in one go, and then spin up another comm independently. Then I can modify code and comm behavior on the single bot without impacting the running game letting me quickly make changes without restarting the entire game. Considering that it takes 5-6 minutes to hit the opening tech stage, restarting the server every time would be untenable. Under the new model I've been working on, bots work though C++ interop without any COM at all. This makes build cycles a whole lot cleaner and I don't have to worry about funky server installations, while giving me full access to the entire IGC stack and Allegiance event systems (by way of listening directly to the DPlay messages and Allegiance events). By treating bots as game clients, I get all the benefits of clintlib. Anyway, lots of fun has been had so far, and more to come!
Last edited by BackTrak on Sat Sep 01, 2018 4:21 pm, edited 1 time in total.
Yes, regrettable, but to be fair, it was only one the one fix we have been missing I believe.BackTrak wrote:QUOTE (BackTrak @ Sep 1 2018, 12:06 PM) I completely agree with you on not locking out changes. That is mostly the fault of my lack of time.
I hope your realize I was talking about locking out changes in the case of choosing another option than #2 though, not in the past.
Very true I was thinking the same thing when Ryujin asked me make a list of my bug fixes. (I haven't actually looked or counted though - kind of hard since many of my changes/fixes are summarized as big bullet points in the patch notes.)BackTrak wrote:QUOTE (BackTrak @ Sep 1 2018, 12:06 PM) I don't think anyone will argue without about bug fixes, but there seems to be a lot of argument on what consists of a bug. For instance, does a miner avoiding an enemy sector constitute a bug, or something that a comm must carefully manage until they can get the team to remove the hazard? Game play elements like this will create controversy just because people are used to them over a long period of time. I don't think there is a right answer, it really comes down to preference.
I'm confused - you are talking about cherry picking specific changes/making more changes. I thought you lost the ability to build a server that works with Bot DM and thus we only have the option of using an old server version as is or go without Bot DM. If it is just a specific change that messes up Bot DM - sure get rid of it.BackTrak wrote:QUOTE (BackTrak @ Sep 1 2018, 12:06 PM) Here is a list of server side changes which I believe are affecting these types of game play elements:
https://docs.google.com/spreadsheets/d/ ... sp=sharing
Rolling back these changes means going through each change set and reverting the key areas leaving the other UI and bug fixes alone. I can see that you put some effort into these, so I hate to lose your work. What would you think about linking your game play changes to the Experimental Game flag that is available in mission parameters? Then comms can easily decide if they want to play with your changes, or if something gets messed up, then it will easy to play without them.
I'll assume you are talking about what to do in case we go with option #2?
In that case I'll have to say, I'd rather spend the time fixing the issues instead of going through everything to duplicate the code with the experimental flag properly. And then fixing the issues without anyone realizing because they just are used to playing with the flag off. If the fixing doesn't work or just takes too long, we could do that though.
In the future, the test server will serve the purpose of the experimental flag for the most part.
Pretty cool, I'll have time to give it a real shot tomorrow and will then probably PM you for helpBackTrak wrote:QUOTE (BackTrak @ Sep 1 2018, 12:06 PM) Believe it or not, 15 GB is plenty to run an Allegiance server for a month. The game is after all optimized for a 28.8kbs modem. The game server itself was made to run 20k players on a Pentium III. My Azure servers are snoring 99% of the time.
There is no confusion as to what constitutes a bug. Some miner/con AI behavior is preferential but we haven't even really gotten as far as addressing any of that (since everyone just wants all those changes reverted entirely anyway) but there's a list of explicit bugs introduced for both cons and miners, and it's not up for debate. It's not preferential. It's not subjective. They are just broken. Miners not staying docked once ordered to, miners not mining once reaching a sector full of he3 and then just idling indefinitely, cons failing to build once ordered, and failing to move once ordered, etc.
He3 visibility bugs are also massively irritating
He3 visibility bugs are also massively irritating
Last edited by Mastametz on Sat Sep 01, 2018 8:25 pm, edited 1 time in total.
There's a new sheriff in town.
QUOTE I'm confused - you are talking about cherry picking specific changes/making more changes. I thought you lost the ability to build a server that works with Bot DM and thus we only have the option of using an old server version as is or go without Bot DM. If it is just a specific change that messes up Bot DM - sure get rid of it.[/quote]
Yes, you are quite right. I have updated the server on both east1 and 2 to the current code version, and I was still unable to get the DM bots working. What's maddening is that they talk to the lobby fine, and even connect to the game server, but they don't get a mission list from the game server. This works fine with the Allegiance client and also the bot server running from my laptop pointed at East2, and also my local test server. It only appears to be an issue with the bot host COM container on East2.
The option is as you say: To retain DM bots we would need to roll way back to the 2/9 server and lose all the bug fixes. Not a great option at all. So, for now, we will have to shelve the DM bots, and focus on fixes.
Now that we have East1/2 servers updated to the latest code, we will need verification on Dome's bug list to see which ones are still an issue:
-HE3 indicator lag bug
-Different HE3 indicator bug that will show a completely empty HE3 rock as full
-Tech Cons sit and stare at tech rocks they've been ordered to build on
-Miners don't run when they're being shot at
-Miner routes are different/suboptimal
-Tech cons will completely stop moving, but still be orderable to an uneyed tech rock they were ordered to build at, but was previously built on by the enemy
Thanks!
Yes, you are quite right. I have updated the server on both east1 and 2 to the current code version, and I was still unable to get the DM bots working. What's maddening is that they talk to the lobby fine, and even connect to the game server, but they don't get a mission list from the game server. This works fine with the Allegiance client and also the bot server running from my laptop pointed at East2, and also my local test server. It only appears to be an issue with the bot host COM container on East2.
The option is as you say: To retain DM bots we would need to roll way back to the 2/9 server and lose all the bug fixes. Not a great option at all. So, for now, we will have to shelve the DM bots, and focus on fixes.
Now that we have East1/2 servers updated to the latest code, we will need verification on Dome's bug list to see which ones are still an issue:
-HE3 indicator lag bug
-Different HE3 indicator bug that will show a completely empty HE3 rock as full
-Tech Cons sit and stare at tech rocks they've been ordered to build on
-Miners don't run when they're being shot at
-Miner routes are different/suboptimal
-Tech cons will completely stop moving, but still be orderable to an uneyed tech rock they were ordered to build at, but was previously built on by the enemy
Thanks!
At the time I started on the miners, we were suffering from a lack of commanders and many things were considered to make commanding more enticing. "Stupid miner AI" is something I could probably find a quote from every one, you consider a good commander, complaining about. So I definitely listened to the community.cashto wrote:QUOTE (cashto @ Aug 31 2018, 02:24 PM) Do you promise not to mess with core gameplay mechanics without community review and consensus?
In hindsight though, yes - I'd rather have done something else than miners, because stupid & predictable miners have their advantages too, even if I could make miners perfectly smart. Namely allowing the players to kill them easier.
So sure, I'll talk to people if I want to mess with something as core as miners again, although I can't think of anything like it that could be changed. Maybe flight mechanics, but we mess with those all the time via .. cores.
But the problem is, Miner AI went from a little stupid, but consistent, to stupider and less consistent. Not trying to offend, but they were less stupid before. And they have driven away old comms more than brought any new comms in. Which is why we really really need to roll back to:Radulfr wrote:QUOTE (Radulfr @ Sep 2 2018, 05:24 AM) At the time I started on the miners, we were suffering from a lack of commanders and many things were considered to make commanding more enticing. "Stupid miner AI" is something I could probably find a quote from every one, you consider a good commander, complaining about. So I definitely listened to the community.
In hindsight though, yes - I'd rather have done something else than miners, because stupid & predictable miners have their advantages too, even if I could make miners perfectly smart. Namely allowing the players to kill them easier.
So sure, I'll talk to people if I want to mess with something as core as miners again, although I can't think of anything like it that could be changed. Maybe flight mechanics, but we mess with those all the time via .. cores.
Old Miners
Old He3 Viewing
Old Con Behavior
(One positive of the new con behavior was the autobuild not building techs in peoples homes though, if this can be re-implemented bug free I think that would be good)
*#$@faced $#@!tard Troll