How to delete NPRs with step by step guide?

[Steve Walmsley]

Since I'm speaking with the dev might I at this point also ask what are your plans of dealing with aurora performance/how does it look for you and what pc you play on?

My observation is that the game runs super smooth as long as you're alone out there, but once you're not then all the performance can quickly get to unplayed rates.

I am currently playing with 5 NPRs and plenty of combat and it is running fine with sub-second turns, so I personally am very happy with the performance. The improvement in performance vs VB6 is huge, so any VB6 players are probably happy, but it depends on your perspective. If you want instant turns, then this isn't the game for you.

I have no plans to add multi-threading. I've addressed that many times in the past and the main issue is that the areas that are slowest cannot be run concurrently. Its a lot of effort for minimal gain and adds huge scope for hard to find bugs.  There are plenty of past posts on this so I don't want to rehash it again. Based on tests, 32 bit runs slightly faster than 64 bit, so while I can compile it right now in 64 bit, I don't see the benefit.

This is a hobby that occupies a portion of my limited free time, not a professional game. I am not going to spend that time squeezing a few percent in terms of performance, as I would not find that interesting (and if it isn't interesting, it generally doesn't get coded). I would rather add new features or play the game. If the game doesn't provide the required level of instant gratification, then I completely understand if you prefer to move on to something faster. Aurora is definitely not for everyone (or even for most people).

My current PC is (appropriately) an Alienware Aurora.

[Droll]

I have no plans to add multi-threading. I've addressed that many times in the past and the main issue is that the areas that are slowest cannot be run concurrently. Its a lot of effort for minimal gain and adds huge scope for hard to find bugs.  There are plenty of past posts on this so I don't want to rehash it again. Based on tests, 32 bit runs slightly faster than 64 bit, so while I can compile it right now in 64 bit, I don't see the benefit.

I'm legitimately curious - what methods do you use to compare the performance of 64-bit aurora to 32-bit?

[vorpal+5]

I believe wet finger is enough. Steve has played dozen of games in VB6 and a lot in C#. 

I'm playing with 14 NPR (8 Earth nations blocks and 6 NPR within 10 LY) and this is fine. Not super fast, but fast enough.

[Steve Walmsley]

I have no plans to add multi-threading. I've addressed that many times in the past and the main issue is that the areas that are slowest cannot be run concurrently. Its a lot of effort for minimal gain and adds huge scope for hard to find bugs.  There are plenty of past posts on this so I don't want to rehash it again. Based on tests, 32 bit runs slightly faster than 64 bit, so while I can compile it right now in 64 bit, I don't see the benefit.

I'm legitimately curious - what methods do you use to compare the performance of 64-bit aurora to 32-bit?

I have an internal time variable in the sequence of play that checks the beginning and end of each increment in real time. I compiled the code in both 32 and 64 and tried both. I think it is because 64bit is superior when you use lots of memory, but if that is not a factor it has a slightly larger overhead.

[Stormtrooper (OP)]

May I have a suggestion that'd potentially both greatly improve performance when nprs are involved and lessened the amount of work you have to do?

The tl;dr: would be: cut out the simulation that is not needed.

This game already has auto detection without player presence. Why not move further? Cut alien battles out completely - instead, if two hostile fleets are in the system, just compare their stats and use some very simplistic, stupid algorithm to determine winner and remove ships accordingly rather than have the player waste time for the battle that has no effect on gameplay extend "loading screens". Don't care whether the result will accurately represent what would happen in a particular battle, the player won't be able to tell the difference.

And while we're at it, why simulate npr economy and expansion properly as well? Instead of it making colonies, mining, building, researching etc etc make it just spawn ships and ground forces and teleport them around based on criteria like minerals in the system etc etc so more minerals means more ships get spawned etc etc. Then generate all the remaining infrastructure only when needed, so mineral stockpiles and infrastructure built only when player conquers a planet, tracking stations only when player discovers the system (the only infrastructure that is needed before player conquest since it affects combat), simulate proper fleet movement only if player in the system (could make a jump delay for nprs based on their speed or something so that it can't immediately arrive in player system from neigbouring star as this would actually affect gameplay when evacuating your forces, for example, but that's it).

Cutting out all that complex simulation should make the game run faster since it'll have far less things to process in case of nprs without any impact on gameplay since the player doesn't know what's going on in npr systems unless the player is in them.

For players it hopefully means better performance. And even if you don't care since I know you make it for yourself basically etc etc, for you it means far less work on AI and less AI-related bugs.

P.S. Why do you log all the events into FCT_GameLog table even if they can't be accessed in-game anymore due to limits set for max events? Heard log in the db impacts the performance, so why not clear them so the table stays small rather than forcing me to periodically run cleanups? Also, why log npr events at all?

[Froggiest1982]

Also, why log npr events at all?

That would pretty much get rid of the only clue we have when things go south and get stuck into 5 seconds intervals or such. So this will be a no for me.

I won't comment on the rest of the post because it is obvious that you just need a bit more experience with the game and haven't fully grasped the basic notions around it; which is understandable, I am knocking my head around it for more than 10 years and some things I still cannot master yet and when I finally do, Steve changes them.

 

[Droll]

P.S. Why do you log all the events into FCT_GameLog table even if they can't be accessed in-game anymore due to limits set for max events? Heard log in the db impacts the performance, so why not clear them so the table stays small rather than forcing me to periodically run cleanups? Also, why log npr events at all?

Although it would be nice the cleanups are really easy to do. I don't mind having to vaccum the DB after every play session.

Literally do this:

Code: [Select]

DELETE FROM FTC_GameLog
WHERE GameID = "YourGameID";
This will completely empty the Gamelogs from your game, hell you could just have the condition be 1=1 and completely flush the table and then just run vacuum on the DB. Takes less than 2 seconds.

[Stormtrooper (OP)]

As if I didn't know how to do it. It's just a matter of the fact that I wait till the performance drops, then have to open dB (alternatively could make it my habit to do so before each session, but then there's the problem of the last events from where I stopped being there to refresh my memory), run the SQL, close dB and reopen game. It's just inconvenient. If the game itself would keep the log clean by removing those events that can't be accessed due to max event setting and not log nprs events at all, then that's a different story.

[Steve Walmsley]

May I have a suggestion that'd potentially both greatly improve performance when nprs are involved and lessened the amount of work you have to do?

The tl;dr: would be: cut out the simulation that is not needed.

This game already has auto detection without player presence. Why not move further? Cut alien battles out completely - instead, if two hostile fleets are in the system, just compare their stats and use some very simplistic, stupid algorithm to determine winner and remove ships accordingly rather than have the player waste time for the battle that has no effect on gameplay extend "loading screens". Don't care whether the result will accurately represent what would happen in a particular battle, the player won't be able to tell the difference.

And while we're at it, why simulate npr economy and expansion properly as well? Instead of it making colonies, mining, building, researching etc etc make it just spawn ships and ground forces and teleport them around based on criteria like minerals in the system etc etc so more minerals means more ships get spawned etc etc. Then generate all the remaining infrastructure only when needed, so mineral stockpiles and infrastructure built only when player conquers a planet, tracking stations only when player discovers the system (the only infrastructure that is needed before player conquest since it affects combat), simulate proper fleet movement only if player in the system (could make a jump delay for nprs based on their speed or something so that it can't immediately arrive in player system from neigbouring star as this would actually affect gameplay when evacuating your forces, for example, but that's it).

Cutting out all that complex simulation should make the game run faster since it'll have far less things to process in case of nprs without any impact on gameplay since the player doesn't know what's going on in npr systems unless the player is in them.

For players it hopefully means better performance. And even if you don't care since I know you make it for yourself basically etc etc, for you it means far less work on AI and less AI-related bugs.

P.S. Why do you log all the events into FCT_GameLog table even if they can't be accessed in-game anymore due to limits set for max events? Heard log in the db impacts the performance, so why not clear them so the table stays small rather than forcing me to periodically run cleanups? Also, why log npr events at all?

I think I will just quietly step away from the thread at this point

[Droll]

As if I didn't know how to do it. It's just a matter of the fact that I wait till the performance drops, then have to open dB (alternatively could make it my habit to do so before each session, but then there's the problem of the last events from where I stopped being there to refresh my memory), run the SQL, close dB and reopen game. It's just inconvenient. If the game itself would keep the log clean by removing those events that can't be accessed due to max event setting and not log nprs events at all, then that's a different story.

I do it after every session and I don't have slowdowns due to logs. Usually its 2-5 MB every 4 hour session and I don't even wipe every log.
You mainly want to get rid of commander related events and NPR combat. I'll edit this post with the queries I use since that probably helps you more than the basic one I posted above.

If thats too inconvenient you can try playing a professionally made game, not that there's any out there like aurora but I don't know that else to tell you since you're the only one that seems to be having this much of a problem with the DB.

Here's the one that I use for commander related events and failed conditionals:

Code: [Select]

delete from FCT_Gamelog
where (EventType = 129 or
       EventType = 90 or
       EventType = 291 or
       EventType = 98 or
       EventType = 83 or
       EventType = 54 or
       EventType = 321 or
       EventType = 290 or
       EventType = 42 or
       EventType = 296 or
       EventType = 291 or
       EventType = 292 or
       EventType = 99 or
       EventType = 256 or
       EventType = 280 or
       EventType = 257) and
       GameID = 39;
Here's the one that handles NPR combat (includes ground combat since those logs are very spamy):

Code: [Select]

delete from FCT_GameLog
where (EventType = 15 or
       EventType = 16 or
       EventType = 28 or
       EventType = 42 or
       EventType = 54 or
       EventType = 83 or
       EventType = 90 or
       EventType = 98 or
       EventType = 99 or
       EventType = 256 or
       EventType = 257 or
       EventType = 280 or
       EventType = 285 or
       EventType = 290 or
       EventType = 291 or
       EventType = 292 or
       EventType = 296 or
       EventType = 321)
       and GameID = 39;

Remember GameID will be different for you but these queries will help you not delete important logs that you might want to keep to know what's been happening in your game recently and over time as you figure out the IDs of other events you can extend them for your own purposes.

You might feel inclined to ask for what each EventType actually stands for, don't bother. I will not catalogue the 300+ IDs for you, but feel free to poke in the DB and look up the various event names. If that proves too inconvenient....... well that's rough I guess.

[Steve Walmsley]

As if I didn't know how to do it. It's just a matter of the fact that I wait till the performance drops, then have to open dB (alternatively could make it my habit to do so before each session, but then there's the problem of the last events from where I stopped being there to refresh my memory), run the SQL, close dB and reopen game. It's just inconvenient. If the game itself would keep the log clean by removing those events that can't be accessed due to max event setting and not log nprs events at all, then that's a different story.

I do it after every session and I don't have slowdowns due to logs. Usually its 2-5 MB every 4 hour session and I don't even wipe every log.
You mainly want to get rid of commander related events and NPR combat. I'll edit this post with the queries I use since that probably helps you more than the basic one I posted above.

If thats too inconvenient you can try playing a professionally made game, not that there's any out there like aurora but I don't know that else to tell you since you're the only one that seems to be having this much of a problem with the DB.

The game log is trimmed during saves, but only for events older than five years. I've been reluctant to cut it back too far because people may want to check events from a year or two ago. If no one has any objections, I could reduce that to a year.

[Iceranger]

As if I didn't know how to do it. It's just a matter of the fact that I wait till the performance drops, then have to open dB (alternatively could make it my habit to do so before each session, but then there's the problem of the last events from where I stopped being there to refresh my memory), run the SQL, close dB and reopen game. It's just inconvenient. If the game itself would keep the log clean by removing those events that can't be accessed due to max event setting and not log nprs events at all, then that's a different story.

I do it after every session and I don't have slowdowns due to logs. Usually its 2-5 MB every 4 hour session and I don't even wipe every log.
You mainly want to get rid of commander related events and NPR combat. I'll edit this post with the queries I use since that probably helps you more than the basic one I posted above.

If thats too inconvenient you can try playing a professionally made game, not that there's any out there like aurora but I don't know that else to tell you since you're the only one that seems to be having this much of a problem with the DB.

The game log is trimmed during saves, but only for events older than five years. I've been reluctant to cut it back too far because people may want to check events from a year or two ago. If no one has any objections, I could reduce that to a year.

If you consider changing that, maybe set it as an option where people can fill in how many years of log to keep?

[Droll]

As if I didn't know how to do it. It's just a matter of the fact that I wait till the performance drops, then have to open dB (alternatively could make it my habit to do so before each session, but then there's the problem of the last events from where I stopped being there to refresh my memory), run the SQL, close dB and reopen game. It's just inconvenient. If the game itself would keep the log clean by removing those events that can't be accessed due to max event setting and not log nprs events at all, then that's a different story.

I do it after every session and I don't have slowdowns due to logs. Usually its 2-5 MB every 4 hour session and I don't even wipe every log.
You mainly want to get rid of commander related events and NPR combat. I'll edit this post with the queries I use since that probably helps you more than the basic one I posted above.

If thats too inconvenient you can try playing a professionally made game, not that there's any out there like aurora but I don't know that else to tell you since you're the only one that seems to be having this much of a problem with the DB.

The game log is trimmed during saves, but only for events older than five years. I've been reluctant to cut it back too far because people may want to check events from a year or two ago. If no one has any objections, I could reduce that to a year.

I don't know how many people will see this Steve as we have somewhat drifted off the topic of deleting NPRs, perhaps better suited as an open question on a separate thread.

The only thing I would ask of you with regards to save size management, when an NPR is fully conquered - it should be deleted (maybe keep their intel screen entry but I personally don't care too much if it also goes). I have done it and seen the absolute mess of "escape route" waypoints that are for some reason unused and undeleted.

This caused massive space savings when I deleted them (like 50mb).

[Steve Walmsley]

The only thing I would ask of you with regards to save size management, when an NPR is fully conquered - it should be deleted (maybe keep their intel screen entry but I personally don't care too much if it also goes). I have done it and seen the absolute mess of "escape route" waypoints that are for some reason unused and undeleted.

This caused massive space savings when I deleted them (like 50mb).

Escape route waypoints should have been deleted after three months, but I have just checked and it wasn't happening. Fixed for v1.13.

[Stormtrooper (OP)]

it is obvious that you just need a bit more experience with the game and haven't fully grasped the basic notions around it

Well, actually looks like it is you who haven't fully grasped the basic notions around something, because how did you see a correlation between amount of experience with the game and npr-related (lack of) performance is beyond me. Whether I downloaded the game half a minute ago or played since the first public release, performance is performance and that'll always be equally important regardless of how much exp with the game I have.

I think I will just quietly step away from the thread at this point

Why? I made this reply you quoted precisely to hear your response on that matter. If you wish me to make other thread or something, just say so, I really want to hear your opinion on this. And if you don't want to tell it for whatever reason, I'd be really grateful if at least you stated so explicitly.

Thanks in advance.

you can try playing a professionally made game

I'd have explained what I think about such replies, but thankfully in the following statement

not that there's any out there like aurora

You've managed to explain this to yourself really well. So please don't bother with similar "suggestions" in the future.

You mainly want to get rid of commander related events and NPR combat. I'll edit this post with the queries I use since that probably helps you more than the basic one I posted above.

I see, you still missed my point completely. I know I can delete the logs and I know how to do it. I told you so already. I was talking about keeping log at bay rather than waiting for performance drop, seeing the performance drop and deleting it. And no, I don't want to get rid of commander events and npr combat. Once I open db to delete the log, after memorizing or taking actions accordingly to the last few events I cared about, there's no reason for me to do anything but delete it all, so I don't see a reason why I'd want to bother with more complex queries to gain less than I'll gain by just running delete from FCT_GameLog