OpenXcom Forum
Contributions => Programming => Topic started by: d2uriel on March 08, 2012, 11:05:55 am
-
Last update: 2012-10-26
- Added multi-interceptions and fixed some bugs found during their tests.
Below a list of bugs that are still present within (multi)interceptions:
Dogfights will not close when minimized and craft is low on fuel and returning to base - fixed.
Same as above but with UFO tracking lost - fixed.
There's a glitch with starting a dogfight: if there's a zoom in effect running the time is stopped, but as soon as it ends and the dogfight is about to start the time will be advanced by whatever was chosen before. That means if you have set it to 1 day it will go one day forward. Very nasty bug. - this one should be fixed though a small slowdown can be experienced.
Geoscape buttons are clickable during dogfights - fixed.
---------------------------------------------------------------------
Update: 2012-10-12
- Rewritten drawing mechanism for radar waves, UFO hit, UFO crash landing, projectiles and beams
- Projectiles will not go over their maximum range anymore,
- Added interceptor damage animation.
---------------------------------------------------------------------
Update: 2012-03-26
UFO's are now proper blobs (like in the original game) and they "bling" when radar wave comes across them.
---------------------------------------------------------------------
Update: 2012-03-08
I will update this post with what's going on with the dogfights development.
So first of all, things to be done (it will be updated often):
Adjust score after UFO's been shot down/destroyed or X-Com craft is lost (destroyed as well).- Find out what weapon UFO's are using (in UFOPaedia).
What I've done so far to the existing code (v0.3):
- UFO's are retaliating. They're using Plasma Beams sound and reload time with a 10% chance of actually firing and 50% of chance of hitting the target.
- Since they're doing the above X-Com crafts can be destroyed.
- Projectile weapons and beam weapons look different when they shoot - no more plasma missiles ;-).
- UFO's have simple AI - there's a timer running as soon as an attack is launched (on of three buttons pressed - Standard, Cautious, Aggressive). As soon as it reaches 0 UFO will try to break off.
- UFO's look "almost" (according to Volutar) the same way as in the original. They're not circles anymore.
- Make UFO's shoot in proper intervals with proper chance of hitting.
- Make the UFO "bling" with light green color when the animated radar waves (or however you may call them) reach it.
- Multi-interceptions - I have no idea if they work or not, need to be tested.
- Take care of damaged interceptor graphic - make it red when it's damaged, etc.
Below is the original message:
---
Hey guys,
I've been on the IRC channel and I was told that one of the things that require attention is the DogfightState class. I've decided I can help out with that. I just have a few questions:
- Is there a list of resources (sounds) from the original game? I don't know which should should be played when the interceptor gets hit, which sound to use for UFO fire, etc.
- How often should the UFO fire? Right now I've added another rule for UFO's named Reload (as for craft weapons). But as far as I remember UFO's don't fire very often. I've set it to 12 (*75) and there's also a 10% chance that the UFO will actually fire on when the timer gets triggered. Is that okay?
Thank you in advance for your reply.
Ooh, BTW:
Since I'm new to this project I should introduce myself. I'm Daniel, 28 years old, a service engineer, IT graduate and an IT geek since 20 years ;-). I've done a couple of projects during my studies and some more at work. Nothing special. But since I'm a very big fan of X-Com series I'd like to help out with this project. My first contact with UFO - Enemy Unknown was back in 1995-6 (can't remember exactly) on my Amiga 600HD. Game was extremely entertaining (and still is!). Couple of years later I wrote a save game editor for the PC version - never released it though (no internet connection back then ;-) ). Now, thanks to this project, I actually bought the original version on Steam (never thought it's gonna be possible) and I'm really eager to help! Already done some coding within the above class and couple of related ones.
-
There are some pretty good resource-related articles on Ufopaedia (https://www.ufopaedia.org/index.php?title=Main_Page). Maybe this (https://www.ufopaedia.org/index.php?title=SOUND) will help.
You may also want to take a look at this page (https://www.ufopaedia.org/index.php?title=Saved_Game_Files).
-
Welcome.
I bet Volutar probably has figured out the exact values of each UFO's rate of fire and has put this on ufopaedia somewhere.
Sounds are there for sure. hmm battlescape sounds are (I'd beter keep my mouth shut on geoscape stuff)
Oh and certainly check with SupSuper before throwing one whole big chunck of selfmade code at him out of nowhere, better start with small things (small pull requests I mean) ;)
-
Welcome.
I bet Volutar probably has figured out the exact values of each UFO's rate of fire and has put this on ufopaedia somewhere.
Sounds are there for sure.
Oh and certainly check with SupSuper before throwing one whole big chunck of selfmade code at him out of nowhere, better start with small things (small pull requests I mean) ;)
It's cool, he checked with me on IRC. :P
Hey guys,
I've been on the IRC channel and I was told that one of the things that require attention is the DogfightState class. I've decided I can help out with that. I just have a few questions:
- Is there a list of resources (sounds) from the original game? I don't know which should should be played when the interceptor gets hit, which sound to use for UFO fire, etc.
- How often should the UFO fire? Right now I've added another rule for UFO's named Reload (as for craft weapons). But as far as I remember UFO's don't fire very often. I've set it to 12 (*75) and there's also a 10% chance that the UFO will actually fire on when the timer gets triggered. Is that okay?
Thank you in advance for your reply.
1. You pretty much have to guess which sound corresponds to which event. There are only 14 sounds (0-13), here's a log from the last time they were discussed:
[22:19] bramcor: think 10 is crash & 11 is destroy
[22:19] bramcor: 5 is laser, 8 is missiles
[22:19] bramcor: 8 is stingray & avalanche
[22:20] bramcor: 4 is cannon fire (you got that already ?)
[22:20] bramcor: 5 is laser beam
[22:20] bramcor: 9 is plasma beam
[22:20] bramcor: 12 is weapon hit
[22:21] bramcor: 7 is probably fusion missile launch (havent tried it yet)
[23:18] bramcor: 13 is x-com craft destroyed
[23:18] bramcor: there simply has to be an extra sound for the xcom-craft-hit event
[23:18] bramcor: no10 has no resemblence to what I get ingame
If you wanna guess them yourself, I've attached a ZIP.
2. Again, without reversing the EXE or tons of testing, there's no exact details on how the UFOs operate (part of the reason I didn't get far in implementing dogfights :P). Each UFO type has different parameters so you will probably have to add some stuff to RuleUfo (beware that the rulesets are being externalized so you might have to revise your changes later). These pages might help:
https://www.ufopaedia.org/index.php?title=Craft_Combat_Mechanics
https://www.ufopaedia.org/index.php?title=UFO_Interception
-
Thank you for your replies guys! I'll try to post updates in this thread regarding the development of DogfightState and all related stuff. I'll update the first post.
Update:
Regarding 0x12 field in GEOSCAPE.EXE - in UFOPaedia it's stated that:
00000012 ufoEscapeTime dw ?
This value x100%-200% = time before UFO attempts escape (on Beginner) - Volutar. Values: SS=200 MS=250 LS=300 A=500 H=500 TS=2000 BS=4000 SS=3000 -spikeAnd a little lower:
Builtin craft field 0x12 (ufoUnknown) actually works as craft parameter of how much time before alien craft tries to escape from pursue. The formula of this time is
UfoCraft->EscapeTimer_Field_28 = craftbuiltin->ufoManeuverability_Field_12
+ RAND(0,craftbuiltin->ufoManeuverability_Field_12) - 30*difficulty_level;
Are these values game seconds? If not, then it needs to be multiplied by 75, right? If so, the calculated values are extremely high, i.e. Large Scout on Beginner level will have break off time from 22500 up to 45000 which makes it nearly impossible to actually start to break off. On the other hand, if they are game seconds, then UFO would break off almost immediately after interception starts :P. Hmm... any suggestions?
-
In this (https://openxcom.org/forum/index.php/topic,104.msg941.html#msg941) post Volutar posted blobs of UFO's and projectiles that were hard coded into the game. How do you think we should proceed with using those in OpenXcom? Right now I've created a Gfx directory inside the main game app and I've put all blobs inside (each UFO and projectile blob is one file). Do you think we can leave it like that or should this be changed somehow?
-
Don't hardcode the paths, so they can be changed in the future easily, should the need arise.
-
In this (https://openxcom.org/forum/index.php/topic,104.msg941.html#msg941) post Volutar posted blobs of UFO's and projectiles that were hard coded into the game. How do you think we should proceed with using those in OpenXcom? Right now I've created a Gfx directory inside the main game app and I've put all blobs inside (each UFO and projectile blob is one file). Do you think we can leave it like that or should this be changed somehow?
Hardcoded executable graphics are a sick nasty grey area of doom. :P Technically hardcoded executable graphics are still copyrighted content so we can't just directly include them but ripping them off the original is a royal pain in the ass. So our only options are:
- Load the graphics directly off the original executable (really ugly)
- Copy the graphics into our own external files (really risky)
- Hardcode the graphics into our code (kinda risly but only kinda ugly)
So... don't worry about it and pick whichever you prefer, we'll sort it out later. Personally we've been using the last option (see for eg. Battlescape\Projectile.cpp).
-
Alright then, they will be hardcoded ;).
Edit: Alright, it's hardcoded as static const int array. Same will be done for projectiles tomorrow ;-).
-
Never mind. Volutar found lot's of bugs... need to fix em first.
Sorry for double posting but I wanted to bump this thread.
@SupSuper: do you think we could merge what I've done until now with the main source?
A small list of changes is below:
- UFO's drawing on radar screen fixed.
- Projectiles drawing on radar screen fixed.
- UFO hit animation added.
- UFO crash land animation added.
- UFO's are retaliating so interceptors can get destroyed.
- UFO's can break off the interception.
To be done:
- Make interceptor red in the interception window if it's damaged.
- Multi-interceptions.
- Minimizing interceptions.
- Fix bugs that show up in the current code :P
-
Personally I'm holding off merging any major stuff until 0.4 is out, if that's ok with you, I just really wanna get it done. :P Plus you haven't actually posted where your code is.
Btw I remember reading somewhere in Ufopaedia.org that UFOs can only break off if their current speed is faster than the X-Com craft, though dunno how accurate this is.
-
PR
https://github.com/SupSuper/OpenXcom/pull/102
Probably it could be nice features to include in 0.4, but maybe it would be better to wait.
-
As of July 25 I can't seem to compile from source with cmake (using debian linux) and the error given has something to do with a missing CraftWeaponProjectile.h in DogfightState.cpp. Tough upon inspection there is such a file in the folder, and it also appears in the included part of the DogfightState.cpp. So I really don't know what happened, but my c++ skill are kind of lame.
/home/hobbit/Downloads/SupSuper-OpenXcom-78cf109/src/Geoscape/DogfightState.cpp:45:47: fatal error: ../SaveGame/CraftWeaponProjectile.h: No such file or directory
compilation terminated.
make[2]: *** [src/CMakeFiles/openxcom.dir/Geoscape/DogfightState.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/openxcom.dir/all] Error 2
make: *** [all] Error 2
-
Oops, sorry for that. I didn't add the new files into CMakeList file. A new PR has been sent by Shugyousha with updated file. As soon as it get's merged everything should be okay!
Once again, I apologize. My first PR and already messed up :-|.
Edit: Okay, as far as I've seen, SupSuper merged the PR. You should be able to compile the game now.
Edit2: I hope I won't get thrown outta here for such a crappy buggy PR... FFS. I'll make it better next time.
-
Oops, sorry for that. I didn't add the new files into CMakeList file. A new PR has been sent by Shugyousha with updated file. As soon as it get's merged everything should be okay!
Once again, I apologize. My first PR and already messed up :-|.
Thanks and no problem, ' cause you know, practice makes it perfect!
-
Once again, I apologize. My first PR and already messed up :-|.
Don't worry, it's easy to broke linux when you're working on Visual - it happened a lot before ;) Daiky had such problems too - AFAIK he started using some linux under virtualization to check if it still works.
Bright side is that such issues are quickly discovered and can be fixed.
-
Yeah, that's a good idea. I'll install a Linux distro under a VM and I'll check my changes there as well before making a PR ;-).
-
PR
https://github.com/SupSuper/OpenXcom/pull/102
Probably it could be nice features to include in 0.4, but maybe it would be better to wait.
I ended up changing my mind and adding this to 0.4, as it's a nice addition and doesn't make much sense to have Very Large UFOs that can't kick your ass. :P
Btw a bug I noticed is that shots fired from the Cannon always seem to go through the UFO and out of the screen. In the original game any shot would always stop at the UFO, even if it missed.
-
actually, I'd keep the "missed shots going
through past the UFO" as a feature :)
although, perhaps, it would make sense to have them "fade out" after reaching their maximum (read: maximum effective) range?
-
I'm gonna fix that today in the evening. Been busy lately but this is going to take less than 5 minutes ;-).
-
actually, I'd keep the "missed shots going through past the UFO" as a feature :)
although, perhaps, it would make sense to have them "fade out" after reaching their maximum (read: maximum effective) range?
I think the only problem with that is with such a fast-firing gun like the Cannon, it makes your pilot look like it has really lousy aim (or really wasteful with ammo). :P
-
and how do we suppose to determine if missile hit target if it's at exact missile range? when missile either way disappears at max distance.. only by ufo flash? okay
-
and how do we suppose to determine if missile hit target if it's at exact missile range? when missile either way disappears at max distance.. only by ufo flash? okay
Well in the original X-Com the sprite, sound and messages at the bottom were enough to indicate whether the shot hit or miss.
Don't get me wrong, I think having missed shots bypass the UFO makes sense, but it just doesn't work right with the original dogfight design, you'd need a new design like Xenonauts (https://www.xenonauts.com/wp-content/uploads/2011/11/aircombat_current.jpg) or XCOM Enemy Unknown (https://www.strategycore.co.uk/site/assets/files/5158/xcom_eu_intrcpt_bnr.jpg). If you try it out yourself, all the shots going up to the top of the screen look really out of place.
-
i'm not saying about going to the top of radar screen, just little bit farther than ufo - for example 2 pixels out.
-
I think the only problem with that is with such a fast-firing gun like the Cannon, it makes your pilot look like it has really lousy aim (or really wasteful with ammo). :P
which is not far from the truth. the cannon has a terrible hit-to-miss-ratio, after all :)
I'd opt for having the "projectile" pixels fade out after reaching maximum range. to me it makes no sense to have them always continue to the top of the screen, but neither does it make sense to have them disappear immediately when reaching the maximum range.
if we want to add a little more eye candy, we could even make the "projectile" pixels go off-course after reaching the "maximum range", in a random direction (maximum 15°), although it would probably only really be visible when using the cannon (but who uses the cannon anyway...?)
-
noticed another thing that's not right, although rather rare: I was chasing a small scout, and it had just gotten into the range of my Stingray Launcher. The moment the missile was fired, the UFO started outrunning my interceptor, and was almost getting away (and therefore way beyond the range of the sidewinder) when the missile caught up with it and destroyed it.
I'm okay with missiles catching "outrunning" UFOs, but only inside their operational range. so either the missile has to disappear completely at the range limit, or at least it needs to be "disabled" in some way, which should then be marked by some visual change, in order to avoid confusion.
I guess the easiest way is to have it disappear at the range limit.
(My preferred way would be to have it fade and deviate from the original course, though :) )
-
missile/ufo hit condition doesn't include distance check. that's the reason.
-
The above issue has been fixed (not submitted yet).
I have a free evening/night today so I'd like to fix all issues found in dogfights. Volutar, some time ago when we were talking on IRC you mentioned 8 points that need to be fixed:
1. crash animation 2x slower
2. hit animation 2x brighter for 3 frames
3. hit animation starts with size+3 and ends with size+0 and lasts for 3 frames
4. crash animation 2x brighter for 8 frames (all the time until blob disappears)
5. crash animation starts with size+3 and ends with disappearing (shrinked under size 0)
6. radar animation must not include palette manipulation
7. blaster ray drawn without paying attention on radar wave. ie instead of +16/+8/+4/+2/+1 of intensivity, it replaces radar colors with one value
8. missile projectiles drawn as ordinary sprites replacing radar colors too
Since I wanna do some stuff today here's my comments:
- Done.
- What do you mean by saying 2 times brighter? I'm using the brightest green color in the 7th group found here (https://www.ufopaedia.org/index.php?title=PALETTES.DAT).
- Done.
- As point no. 2 - please explain what do you mean by brighter?
- Done.
- Done.
- You mean I should draw it and take into account radar waves?
- Same as above?
Apart from that, any other issues found?
-
2. it means direct blob values should be multiplied by 2, before adding to wave (background) color (with saturation cap).
4. see 2
6. actually it doesn't matter. it shouldn't affect final picture.
7. sure. see for yourself (attached).
8. see 7.
-
2. Done.
4. Done.
6. You asked for it ;-).
7. Done. Actually I haven't noticed that until your screen shot. Hehe ;-).
8. Done.
I should start coding "minimizing" the interception window and doing synchronous interceptions. Don't think I'll finish today, though.
I'll send another PR with the current changes so everyone can check if they are good or not.
Edit: Actually I should create Interceptor damage visible. This is what I'll do!
-
Sorry for double posting but I need some info regarding craft damage animation. What's the interval between color changes from light red to dark red and the opposite?
-
2. Done.
4. Done.
6. You asked for it ;-).
7. Done. Actually I haven't noticed that until your screen shot. Hehe ;-).
8. Done.
I should start coding "minimizing" the interception window and doing synchronous interceptions. Don't think I'll finish today, though.
I'll send another PR with the current changes so everyone can check if they are good or not.
Edit: Actually I should create Interceptor damage visible. This is what I'll do!
Make sure to send me a PR just with the fixes since I wanna put them in 0.4.5. Stuff like minimizing can come after.
And visible damage is specially important since you made UFOs fight back! :P
Sorry for double posting but I need some info regarding craft damage animation. What's the interval between color changes from light red to dark red and the opposite?
From obversation (hard to tell since game speed varies with CPU), the red damage flashes at regular intervals of around 1/4 second (250ms), just try whatever looks good.
-
btw, I'm not sure if I remember correctly, but I think I had a dogfight in which my interceptor got shot several times, and when it was back at the base, it did not have any damage. can anybody confirm this? I have had several interceptors destroyed, so the basic damage system with "dogfight ended because interceptor is destroyed -> interceptor is removed from game" appears to be working, but maybe partial damage isn't transferred to the global setting correctly?
-
Make sure to send me a PR just with the fixes since I wanna put them in 0.4.5. Stuff like minimizing can come after.
And visible damage is specially important since you made UFOs fight back! :P
From obversation (hard to tell since game speed varies with CPU), the red damage flashes at regular intervals of around 1/4 second (250ms), just try whatever looks good.
Yeah, I've sent a PR which you already pulled ;-). I hope everything's gonna be alright with that one.
-
btw, I'm not sure if I remember correctly, but I think I had a dogfight in which my interceptor got shot several times, and when it was back at the base, it did not have any damage. can anybody confirm this? I have had several interceptors destroyed, so the basic damage system with "dogfight ended because interceptor is destroyed -> interceptor is removed from game" appears to be working, but maybe partial damage isn't transferred to the global setting correctly?
I'll check that. Dunno what happens after the dogfight ends - didn't look at it yet ;-).
-
BTW: when you minimize the interception window there's an icon being show over the Geoscape. Do you know where's this one taken from?
-
BTW: when you minimize the interception window there's an icon being show over the Geoscape. Do you know where's this one taken from?
It's in INTICON.PCK (https://www.ufopaedia.org/index.php?title=INTICON.PCK).
-
Aaah, perfect. Thank you SupSuper.
I was looking for some details regarding multi-interceptions but I haven't found anything relevant. Therefore they may not work the exact same way as in the original. As soon as I'll finish those (should be tonight) I'd like everyone to look for bugs and issues as well as behaviors different than in the original.
-
Can you add a evasive button that says "Do a barrel roll"? :D
-
Aaah, perfect. Thank you SupSuper.
I was looking for some details regarding multi-interceptions but I haven't found anything relevant. Therefore they may not work the exact same way as in the original. As soon as I'll finish those (should be tonight) I'd like everyone to look for bugs and issues as well as behaviors different than in the original.
Multi-interceptions are extremely simple (in fact I'm pretty sure they were an afterthought by the developers :P). As far as interaction goes, they just work as multiple "parallel" interceptions referring to the same UFO with absolutely no interaction between one another, so you could just create a "parent state" that can run up to 4 DogfightStates inside it and rearrange the windows appropriately.
The minimizing is probably the trickier part, as you will need to change more behavior and keep track of more stuff in the saved game:
- You can only minimize interceptions at "standoff range", so you don't have to worry about running combat logic in the background.
- The Geoscape time is "paused" as long as at least one interception is up. If all interceptions are minimized, the game resumes.
- While an interception is minimized, the craft will continue chasing the UFO around the globe without engaging.
- A UFO can still outrun a craft while the interception is minimized (eg. changes speed during flight), in which case the interception is automatically removed.
- This all has to be preserved in case the game is saved with minimized interceptions.
You might find more details here: https://www.ufopaedia.org/index.php?title=UFO_Interception
-
Multi-interceptions are extremely simple (in fact I'm pretty sure they were an afterthought by the developers :P). As far as interaction goes, they just work as multiple "parallel" interceptions referring to the same UFO with absolutely no interaction between one another, so you could just create a "parent state" that can run up to 4 DogfightStates inside it and rearrange the windows appropriately.
The minimizing is probably the trickier part, as you will need to change more behavior and keep track of more stuff in the saved game:
- You can only minimize interceptions at "standoff range", so you don't have to worry about running combat logic in the background.
- The Geoscape time is "paused" as long as at least one interception is up. If all interceptions are minimized, the game resumes.
- While an interception is minimized, the craft will continue chasing the UFO around the globe without engaging.
- A UFO can still outrun a craft while the interception is minimized (eg. changes speed during flight), in which case the interception is automatically removed.
- This all has to be preserved in case the game is saved with minimized interceptions.
You might find more details here: https://www.ufopaedia.org/index.php?title=UFO_Interception
What I've done until now is I transferred dogfights into GeoscapeState class. Meaning it's not being pushed to _states stack of Game class but to a vector inside Geoscape. During every think() of Geoscape all dogfights are thinking as well. Depending on their state (minimized/maximized) different things happen. Can I leave it this way?
Regarding your points:
- done,
- done,
- done (nothing had to be done as it actually worked without any modifications ;-) ),
- gotta test that,
- this is gonna be done at the very end ;-).
I have some questions though:
- If I have one interception minimized and an interceptor will catch up with a different UFO I'll get two separate interceptions, right? They both can be visible at the same time?
- What will happen if I have 4 interception windows already opened and minimized and another craft will catch a UFO?
- Let's suppose I have 1 interception window and I'm gonna minimize it. I'll get an icon with #1. Then another craft is gonna catch a UFO, dogfight is gonna be opened, I minimize it and get a second icon with #2. If I now maximize #1, will #2 change to #1? This is kind of important ;-).
I could really use a saved game for the original game where 4 crafts are chasing a UFO ;-).
-
1. Yes- You can have two interception windows open at the same time (at least on the original). I'm not sure about what Sup saying they are independent, I thought the UFO would only shoot one of the craft's attacking it. I could be wrong though, I can't find any information on that.
2. Don't let them minimise? or maybe this is where OpenXCOM expands on the original and let's you have more?
3. I'm pretty sure they remain in their "slot" when minimised. I think it works like this:
Window A is minimised - called #1
Window B is minimised - called #2
Window A is restored - B is still #2
Window B is restored - No minimised windows
Window B is minimise - called #1
Window A is minimised - called #2
Edit:
Do you think it might be possible to "drag" the window when clicking on the border? I'm not sure if this might get complicated with Z-ordering, and maybe you'd need an "Alt+Tab" to cycle through.
-
Can you add a evasive button that says "Do a barrel roll"? :D
LOL! Yes, that can be done but it won't be visualized in any way ;-).
Regarding them points:
- I know you can. You can even have 4 of them opened. But can they be interceptions of different UFO's?
- First we need the original behavior. So we need to forbid entering a dogfight when 4 are already running? Should the craft follow the UFO until there's a chance to enter the dogfight/it runs out of fuel?
- Does the minimized icon of window B moves to the slot where minimized icon of window A was?
Yes, it would be possible to drag the windows (everything's possible to be exact :P).
-
1. I didn't even know you were allowed 4 (I thought it was limited to 2), but yes, I'm pretty sure you can intercept multiple UFOs
2. I've never had more than 2 in battle (I don't think, can't remember now), so I don't really know the original behaviour, I would expect crafts to follow until able to intercept. Set it up as a Ruleset option as Max Interceptions or something
3. Yes, it should go in the first "available" slot, numerically ordered. Take this example:
# You send 5 craft to attack a UFO
# You minimise 1, 2, and 3 until the 4th arrives, the 5th just follows without engaging
# Craft 2 takes heavy damage, so you minimise return that to base
# You'll want Craft 5 to enter "Slot 2", so you can continue with a 4 craft assault
-
I could really use a saved game for the original game where 4 crafts are chasing a UFO ;-).
You could try the saves from xcomufo.com (https://www.xcomufo.com/x1save.html), they have a ton of stuff set up and everything unlocked so they're very handy for testing stuff out.
-
Believe it or not, but I've been playing the original for the past few days just to have a saved game to work with ;-). I've made some progress with multi-interceptions but there's still some things to fix. As soon as it will be playable and bug free I'll send a PR.
-
Can't wait for minimization to be implemented :'(
I can play DOS version, to provide save with 5 aircrafts chasing an ufo (or maybe another situation). If this still can help - just let me know ;)
-
Okay. The beta version of multi-interceptions is implemented. I've sent a PR but it will be merged after release of v0.4.5. As soon as it is, please test this new feature. It's probably buggy because a lot of things had to be added/re-written/changed. I've done a couple of tests and it seems to work but you know how it goes. If you are really eager to test it now, you can pull the source from here (https://github.com/d2uriel/OpenXcom) and compile it yourself. I've merged the current build into mine so everything should be the same (except for dogfights of course).
Awaiting feedback.
-
I've pulled your changes into my repo, will hopefully have a play with it tonight :)
Edit: SupSuper - I sent you a PM - This now shows in my PR as well as d2uriel's. I'll try and fix it when I get home
-
One more thing that came into my mind a while ago which I always forget to ask.
In DogfightState class there's a lot of surfaces being instantiated with the new operator but they are not deleted within the destructor (only the timers are deleted there). Since I'm not really experienced with SDL - is this being taken care of by SDL itself or was it forgotten straight from the beginning and needs to be fixed?
-
One more thing that came into my mind a while ago which I always forget to ask.
In DogfightState class there's a lot of surfaces being instantiated with the new operator but they are not deleted within the destructor (only the timers are deleted there). Since I'm not really experienced with SDL - is this being taken care of by SDL itself or was it forgotten straight from the beginning and needs to be fixed?
Any surfaces that are rendered on-screen by the State (through the add() function) are automatically cleaned up by the base State destructor. The idea is that once you connect a Surface to a State, the State takes over so you don't have to worry about it (I'm hoping to expand this to timers and such too eventually). This is all part of the OpenXcom engine. ;)
However if you crate any surfaces with new that are not added to the State (eg. temp surfaces), you'll have to clean those up yourself.
-
Alright, good to know that. I didn't really want to dig into the code too much cause this could as well be hidden somewhere in the SDL libs ;-). I really thought it's gonna be faster to ask this question. Hope you don't mind ;-).
-
Alright, good to know that. I didn't really want to dig into the code too much cause this could as well be hidden somewhere in the SDL libs ;-). I really thought it's gonna be faster to ask this question. Hope you don't mind ;-).
That's fine, I imagine OpenXcom engine is quite the mystery for most people and they just roll with. ;) I might eventually give an overview of the inner engine functionality for the more curious programmers.
-
Some notes:
- If you launch both interceptors at the same time, only one combat box pops up - but at the top, as if waiting to draw the other screen
- Minimising that box shows "1", but time does not resume (presuming because of the 2nd interception)
- Restoring window "1" and selecting "Disengage" shows the 2nd interceptor box
- Select the 1st interceptor, and set him to re-engage, once it gets back to the fight, time stops, but no interception windows show
- Restoring window "2" removes the box, but you see no interception windows at all
- You can however, click the geoscape (time still not moving), and however, interceptors don't respond to "Return to base"
Also
- Select an interceptor to attack a UFO
- Miminise, then restore the window and disengage
- Set the interceptor to reengage and minimise
- Craft is now showing as "2" despite being the only craft in combat
-
Umm, how are you able to launch two interceptors at the same time?
Also
- Select an interceptor to attack a UFO
- Miminise, then restore the window and disengage
- Set the interceptor to reengage and minimise
- Craft is now showing as "2" despite being the only craft in combat
Okay, that should be fixed now. Pushed to my repo.
-
When I UFO appears, you click "Intercept" in geoscape, select the first interceptor, click on the UFO, then click Intercept again, pick the 2nd interceptor and click the same UFO :)
-
Right after targeting the UFO for the first interceptor, the Intercept window disappears. Umm... maybe my sources aren't that up to date at all. Lemme check that.
Edit: Well, it says my sources are already up to date when I'm trying to pull from SupSuper/OpenXcom... hmmmm....
Edit2: Till I figure out what's wrong... test it with sending interceptors within a short interval of time of each other ;-).
Edit3: I found a simple way of dealing with this issue. Committed and pushed to my repo.
Edit4: I read your post carefully again. You're not sending them at the exact same time. Unless you're that fast and the time is not able to advance between you targeting the UFO for the first interceptor and clicking Intercept again ;-).
Edit5: I closed my PR. Please comment within my repo only now.
-
Still having problems, thought it'd be easier to record what I'm doing...
https://youtu.be/IRYHufVLsPE
https://youtu.be/asjyNwlzjcE
-
This is weird. Are you using the latest sources of mine? Does it happen every time you do it?
-
I did a pull request about 10 minutes before that post, and yes. I take it that it doesn't happen to you then?
-
No, it doesn't. Can you try to fork my code to a seperate repo instead of pulling it to yours? Maybe there's a different issue here.
There are other bugs found but it does work for me pretty well.
Edit: Have a look: https://www.youtube.com/watch?v=-rI6VkDLzo8&feature=youtu.be
-
I downloaded your Git, compiled it, and it did exactly the same as what it did from my repo!? I have no idea why it works different for you than me.
I'm compiling with VS2008 BTW, not that that should make any difference...
-
I'm using 2010 but it shouldn't make any difference IMO. So it does happen every time you start a new game and launch two interceptions?
I know radius75 also tried it - you haven't had this kind of issues, right? You had others, though :P.
What the heck? Every time I try it - it works without any problems. Umm... weird.
Edit: can you set a breakpoint at line 385 in GeoscapeState.cpp file and run the game again in debug mode? Ooh... are you running debug or release version?
-
Still having problems, thought it'd be easier to record what I'm doing...
https://youtu.be/IRYHufVLsPE
https://youtu.be/asjyNwlzjcE
Confirm this, on vc2010. tested on commit [ec7e92412e13959f84287bab702b7ccc626cc45d]
-
Yes, does it every time
Release. The game won't start if I run the Debug mode (not figured out why).
Anyhoo... I found this little gem:
_dogfights[0]._x = 80
_dogfights[0]._y = 304
_dogfights[1]._x = 80
_dogfights[1]._y = 0
Edit:
Could this be a scaling issue?
Edit 2:
Call me n00b, but where the frigg does _y get set? there's a _y(0) suffixed on the constructor, but I don't understand where it gets set?!
-
Yes, does it every time
Release. The game won't start if I run the Debug mode (not figured out why).
Anyhoo... I found this little gem:
_dogfights[0]._x = 80
_dogfights[0]._y = 304
_dogfights[1]._x = 80
_dogfights[1]._y = 0
Edit:
Could this be a scaling issue?
Edit 2:
Call me n00b, but where the frigg does _y get set? there's a _y(0) suffixed on the constructor, but I don't understand where it gets set?!
Aah, I know what's wrong! Thanks for this piece of information. Try the newest build.
AFAIR, when I used screen resolution for calculating window positions it wasn't working. I guess we still work with 320 x 200 and then the image is up-scaled to whatever resolution you have chosen in the settings, right?
-
Yep, works fine now! Good job!
-
Not really fine, but it works ;-).
I'll update the first post with bugs that are still present. Check it please before posting a bug you find ;-).
-
Does someone have save with four interceptors in Base? He necessary is to tests :-[
Edit
OK, I already have him :)
https://www.speedshare.org/download.php?id=4086F13A1
(https://img411.imageshack.us/img411/4382/screen007g.png)
-
I'm experiencing a different issue now. Creating a new DogfightState object takes about 200ms in debug mode (a little less in release). Because of that you can see a small slowdown when a dogfight is about to be started (just before the zoom in effect).
Does someone have save with four interceptors in Base? He necessary is to tests :-[
Edit
OK, I already have him :)
https://www.speedshare.org/download.php?id=4086F13A1
Haha, good one ;-). Fixed.
Edit: Don't use that saved game for testing now though. It has the wrong values saved. Well, you can do it but you need to return all crafts to the base and make them intercept again.
Edit2: New build available. Cosmetic changes to code... which may break stuff ;-).
Edit3: Regarding the creation time issue - I'm wondering if the dogfight handling shouldn't be a bit different. Maybe I should create 4 instances of DogfightState class when the game starts and then just use them when necessary without deleting them? That would make this issue disappear. What do you think? Is the slowdown really frustrating?
-
Geoscape buttons are enable if the dogfight window is open ;)
[661cec6f3e395601...]
(https://img443.imageshack.us/img443/48/screen008x.png)
-
Geoscape buttons are enable if the dogfight window is open ;)
[661cec6f3e395601...]
Fixed.
The other one with changing interceptors target while it's interception window is minimized is also fixed.
-
Save 5vs1 for testing;)
https://www.speedshare.org/download.php?id=F7B0EA6F1
-
Aah, I know what's wrong! Thanks for this piece of information. Try the newest build.
AFAIR, when I used screen resolution for calculating window positions it wasn't working. I guess we still work with 320 x 200 and then the image is up-scaled to whatever resolution you have chosen in the settings, right?
Yes, internally the game is all 320x200 and scaled in post, makes it a lot easier to manage. :P The only time you need to account for the real screen resolution is when doing advanced stuff like handling the mouse cursor position.
-
Yes, internally the game is all 320x200 and scaled in post, makes it a lot easier to manage. :P The only time you need to account for the real screen resolution is when doing advanced stuff like handling the mouse cursor position.
That explains a lot. Well, next time I'm not gonna make the same mistake again (hopefully) ;).
Anyway... how's the testing going?
-
Anyway... how's the testing going?
Testing in progress...
(https://t3.gstatic.com/images?q=tbn:ANd9GcROc1FYcXIjaayi7TokrnR8jCa4axTXP8K1B0Xh_CovudzZjvNg)
-
LOL! ;D
-
I just realised that I started making all the Snakeman changes in my master branch - which also has your dogfighting code merged. Guess I won't be pull requesting the snakemen any time soon!
-
Well, dogfights should be finished soon. I mean everything that I could think of and what was found should've been fixed by now. If anything gets found I'll try to fix it ASAP. They're playable now and as soon as I won't have any bug reports for a week or two I will fill in a PR for this.
-
[a40d891...]
Geoscape Buttons not work (or Crash) - after intercept and shutdown UFO
(https://img23.imageshack.us/img23/6053/beztytuuuwa.png)
-load sav.
-attack by first interceptor
Sav. 6vsX
https://www.speedshare.org/download.php?id=8FA6FFC41
-
Should be fixed in new build. I also fixed the bug where the music did not go back to the Geoscape music after interception is finished. Not committed yet, though.
radius75 noticed some problems while he was trying to pull my latest build (some conflicts). I tried fixing those and it seems to be okay. Any testers willing to try out the dogfights?
-
Thanks to radius75 I was able to fix everything.
@SupSuper: can I send a Pull Request now?
-
i've been testing out your dogfight code for some time now in my mod, and for the most part it's pretty solid.
the only problem i've encountered is when you have a dogfight minimized, select the craft in question and send it back to base (ie: don't maximize the window and click disengage, select the craft in flight and give it orders from the menu popup) the cursor gets locked out because the dogfight doesn't get cleared from the queue properly. not sure if you fixed this or not yet.
also, good work on this.
-
I'm not sure how this is handled in the original game, but I think the most logical solution for this would be to catch the geoscape clicks for "craft engaged in a dogfight" and have them re-open the appropriate dogfight window instead of the "new orders for craft" window.
-
it's an easy fix, all you have to do is put something like "if(inDogfight) cancelDogfight" (only with actual code and real function calls) in the "return to base" and "select new waypoint" buttons
-
i would like to merge this branch, it works exactly how it should.
i've made a small alteration/fix for the bug i described above, if this meets with your approval (LINK HERE (https://github.com/Warboy1982/OpenXcom/commit/e436493d7228c16b4c0494ed91baa4656fdca979)) please let me know and i'll see about merging it.
-
unless anyone objects, i think we should merge this now.
i've tested the hell out of it and can't break it.
-
Trust your feelings, Luke
-
the handful of remaining bugs (thanks radius) have been addressed and this contribution has been added to the master.
thank you d2uriel for your work, we are now that much closer to 1.0