Discussion in 'Coding' started by Istrebitel, Aug 26, 2016.
Yeah, that worked thanks!
Whoever was implementing game events, if you're still around, could you tell me what's "AgentRearmed" and "UnknownDied" events?
Another question: How do we tr() the briefing text? It has multiple lines but it seems translation is a single line. For example, russian tr file:
"The Aliens have located your base and have launched an attack. Defend the "
"base from costly damage by eliminating all invading forces. If all hostile "
"forces are eliminated X-COM will be saved. If you are defeated then X-COM "
"will be wiped out, leaving the world open to Alien domination. The fate of "
"humanity will be determined by this conflict. Good luck."
msgstr "Пришельцы обнаружили вашу базу и напали на нее. Не дайте им причинить ей значительные повреждения. Если вам удастся уничтожить все вражеские силы, организация X-COM будет спасена. Если же вы потерпите поражение, X-COM будет уничтожена, что оставит мир беззащитным перед инопланетным вторжением. От исхода этого боя зависит судьба человечества. Удачи вам."
So what do I put in code for this breifing to properly work?
I think we should change the 'source' translation to be a single line - I don't see why the newlines should be hard-coded into the string, as if you change the font/ui layout slightly it'll look awful.
If we think it's worth re-generating the translation source files and upload to transifex regularly (IE the number of string changes is decreasing) I think it should be possible to setup one of the autobuilds to do that for us... Until then it's a bit of a manual step that I can't remember how to do... As I said, the translation system is a 'proof of concept' in my mind until it started to settle down, but if that time is starting to arrive it makes sense to clean it up.
Well, yes, battlescape is like almost finished now. We should.
Also, who developed music? We need to implement music in battlescape, but I'm not sure I understand how to do it properly.
We need the following function:
- Start playing random track from the list, only if current playing track is not from the list
I think it was me - the 'plan' was the "Jukebox" class would manage playlists, currently it just plays them in order - are you saying you want a 'shuffle' mode?
I know the "action" music in the original game tended to start when the battlescape decided that something "interesting" is happening - I'm not sure how this is implemented - does it play the "action" track then go back to it's original position in the "calmer" playlist? Or randomize a new "calm" track when it ends?
Well I'm not sure either. I will implement a system that at least somewhat resembles vanilla, and then after people study it we will implement if properly. On topic of the class you developed, the following functions would suffice:
1) Is a track from the specified list of tracks currently playing?
2) Start playing a random track from the specified list immediately, run callback when finished
3) Play a list of tracks on shuffle and repeat.
Do we have them in that class?
Not yet. It "just" plays through a list in-order right now. Maybe add those as tasks under a new "audio" tile in the "General" list on Trello, then you can assign them to me?
I kinda worry my todo list is growing and I've not had time to tick any off recently....
Nah it's not first priority, the music. We need tooltips and agent equipment first.
I've implemented the Skirmish form, which allows selection of battle parameters, and encountered a strange bug. If I set too many enemies (like, 32 spitters, 32 anthropods and 32 sekeletoids) then agent generator will say "probability map was 0xsomething" in agent.cpp:211
It seems for some reason StateRef to AgentType become blank and thus accesing this->something fails. I have no idea why this happens. Looking at memory, it's not really rising way up - starts at 410mb, goes to 412mb and then it crashes.
Can you check JonnyH? I've pushed this to my repo
I had the following error building:
OpenApoc/game/ui/general/skirmish.cpp:462:90: error: could not convert ‘false’ from ‘bool’ to ‘OpenApoc::StateRef<OpenApoc::Base>’
true, loadBattleBuilding(base->building, &state, false, aliens))});
was that 'false' means to be 'base'?
With that fixed I seem to be able to start an assault ship (36 skeletoids, spitters and anthropods) fine.
BTW when trying to start on the 'base' map I get:
OpenApoc/game/state/battle/battle.cpp:372:21: runtime error: division by zero
then a crash - I guess as we don't setup the base map up correctly yet so it has no spawn points?
If it's some other specific map or other option needed to crash let me know and I'll try to look into it when I can.
I uploaded a fix for first bug. Sorry for that. Btw, travis complains about clang 3.9 for some reason https://travis-ci.org/Istrebitel/OpenApoc/jobs/224029479
Bases do not work yet, yes.
Any other map works. I tried on one of the UFOs (no matter which, all fail the same way with lots of aliens)
Now clang 4.0 is released the 'testing' ppa I setup for travis removed 3.9. It should work to update to 4.0 (https://github.com/pmprog/OpenApoc/commit/039f76935c3d594b67251f7979f91ede6a8b5635 does that - it should be picked up next time you merge from pmprog)
The skirmish I tested was a UFO - the 'alien assault ship' - and it seemed to start fine with no errors/crashes. I'll play around later today to see if I'm doing something different or if it's a linux/windows difference or something.
So to confirm, you can start with over 100 aliens with no crash?
Yeah, seems to work OK?
Lots of leaks when quitting though, possibly as I didn't "end skirmish"? But that's not important right now.
Hmm. Will re-build clean and re-check this.
About agent inventory, wanted to note, I've changed stamina to 2000 max value, so the UI should display 2000 as 100, 1000 as 50 etc. That is because game sometimes subtracts like 0.5 or 0.8 stamina, and we don't need floating point here so it's just simpler to multiply it by 10.
Edit: Forgot that we have getDisplayStaminaValue() - that means change should be no problem.
Okay, indeed it works.
We seem to have problems with memory.
Problem one is, when there's not enough memory the game simply ignores it. I think this is because we do loading in tasks and thus thrown exceptions kill tasks and aren't handled anyhow. We should introduce at least catching of exceptions so that user is informed that there's not enough memory and that program will now exit.
Problem two is, when closing game unproperly it leaks memory. It may also leak memory when simply working (my travis complains about some framework stuff leaking memory) but it is obvious closing the game does it for sure. I think modern games are past this - like, if I terminate CS: GO or Dota 2 or World of Warcraft, I don't think it will leak, will it?
And as a side note, we should think about moving a lot of static constants into some moddable file storage. Maybe one or several xml files? Like, we should let the modder change how frequently are alien detections happening, or how frequently aliens move around, how much damage enzyme does to items, or what sound file names are used for certain ingame actions (button presses, alien detected alerts etc.), or what icons are used for waypoints. Right now a LOT of stuff is hardcoded. And it makes sense for it to be moddable.
Also, how is it better to implement squad assignment screen? The part where you can drag unit controls to other squads. Is there an easy way to tie a control to a mouse? Do I use list for the squads?
I fixed the 'no exceptions from threadpools' issue - the exception would never be thrown if you never called .get() on the returned future. I now treat unhandled exceptions that get to the threadpool task call to be fatal (IE LogError())
As for the leaks - you can safely ignore 'small' still-reachable messages in travis about libX11, GLX and SDL. This is a bug in the version of SDL2 that's used in that version of ubuntu, and it's only ever leaking a few kb per run (IE it doesn't increase as you play) - and all this gets cleaned up at process terminate on any remotely modern system (IE not DOS) anyway, so it's not a big deal to me.
As for in-game leaks - I ran in both -fsanitize=address and valgrind 'massif' profilers, and they both agree (Ignoring the small SDL leaks mentioned above):
Start app, 'start new game', get to city, go back to main menu, 'start new game', go back to main menu', quit - no leaks
Start app, 'start new game', get to city', enter skirmish, 'exit battle', go back to main menu, quit - Leaks.
It's not easy to see why the leaks are there, it appears to be a circular sp<> dependency, so there's no obvious 'head' to blame. This may be what you referred to as leaks in the "framework"? As it says stuff like RGBImages have leaked, but as they're only ever used by sp<> references that means they are 'kept around' by something still having a reference, not an issue in the Framework itself.
But it *does* appear to be caused by entering battles?
Separate names with a comma.