project-navigation
Personal tools

Author Topic: App crash on bloodspider kill/stun etc  (Read 5549 times)

s300pmu1

  • Guest
App crash on bloodspider kill/stun etc
« on: March 15, 2009, 06:27:05 am »
Currently testing Destructivator's ufoai_2_3Dev_r23515_m23327 which is indeed very stable. However, whenever I try doing anything to bloodspider - stun it or kill it - the moment it flips over the app crashes and gives assertion failed error: http://i063.radikal.ru/0903/22/5fdbceeb1c6d.jpg

Not anymore. Installed ufoai-2.3-dev-win32-23542. Once i kill/stun a bloodspider, the game no longer crashes to desktop, but the tactical mission terminates immediately and you're kicked into geoscape, where you can play it again just like the first time... until you try killing\stunning bloodspiders again, when it kicks you out again just the same.


Minor stuff, most likely known:
- Laser pistol and stun rod images oversized in production/ufopedia, they just don't fit in (same in all prev versions)
- The image of shotgun ammo in equip soldier screen - sometimes it is big, and sometimes it is small (visually only - it occupies 2 squares in any case).
- Some mails in mailclient are displayed without a green border: http://i037.radikal.ru/0903/23/ed07fd3f1973.jpg

Humble feature requests:

0) It might be logical to rework Transfer screen to be more like buy/sell, showing all bases so that transfer can take place to multiple bases from the same screen. I find it often necessary to move stuff from base X to more than one base at the same time, and something tells me I am not unique. It might look as follows:
This way there will be no need for the box listing the transfers http://i062.radikal.ru/0903/68/4fa74a4782b1.jpg - as they will be obvious per se. It might look like this: http://i036.radikal.ru/0903/75/1ab7af75dcc4.jpg

1) Adding scientists/workers not by checking 'em one by one, but rather like buying/selling stuff, i.e. using an up-down control. I guess, unlike with soldiers, nobody cares much about their names anyway, and if they do, the can still rename 'em all they want.

2) Speaking of scientist names, would it not be logical to have the emails signed by scientists actually hired? I.e. when first hired, some scientists are marked "chief" and become authors of all future research letters. This one, unlike the first request here, is not big on my personal list.

3) Still asking to have focus on installation name whenever build installation dialog appears, 'cuz the first thing many do is rename it.

4) In the Base\Buildings screen, the number of buildings already existing in the base should be displayed next to each corresponding building button, not in the floating window. This is because sometimes you want to know which building are there and how much of them, and to learn this you have to click each building button consequtively, which takes a lot of time and clicks.

5) BTW, the floating window is very uncool. Yes, it's semitransparent, but you have to move it to put anything in the place it's hovering over. Better to have a fixed pane of some sort, like in buy/sell/production screens

6) Alien craft tracked by radar should be highlighted in a more contrasting way, particularly in 2D geoscape. It sometimes takes too much looking into the screen to pick out a pale green craft over a background of same color. A high-contrast marker and an option to auto-center on new UFO would be helpful.

7) I suggest that with the development of Advanced radar, the player had an option to draw estimated course lines for UFOs that leave radar coverage. These could be turned on and off with a button like the one used to turn on and off showing radar coverage on geoscape. This way, instead of estimating the course of the UFO and guessing where it might reemerge once it enters radar covered area agian, the user will have the track already. Of course, it must be based on the in-the-radar-history of UFOs movement, and noone would guarantee the UFO would not turn 90 degrees after leaving radar coverage  ;D

8) After alien aircraft is shot down, displaying the line "alien activity detected in..." appears to me to be somewhat misleading. Technically, they are indeed active, those bloody LGM, but in the context of the UFO series I got accustomed to separating "enemy activity", i.e. their land-based missions, and "mopping up", i.e. removing any remaining threat after a successful UFO splash.

9) Can anyone tell me what is the purpose of this screen: http://s42.radikal.ru/i095/0903/9b/5656ab5e303e.jpg? And why is it closed by a _checkbox_? Why not by an optionbutton?  :-X I'd suggest to cut that one out, it's very disturbing when you zoom in and suddenly pop into it, and can't zoom back out, and the worst thing is, as I said, there is no apparent purpose for the screen in the first place, other than to play a nice music.

10) Science - it is perfectly logical that studying a live alien, or a plasma grenade, or some other artefact should be conducted by the scientists of the base where the object is located. Some research is, however, general in nature, and does not require any specific base to be conducted, i.e. can be done in any base. One would assume logical that scientists from _multiple_ bases could be assigned to such projects. They do have email, after all, to coordinate activity.

11) Science - http://s45.radikal.ru/i109/0903/2d/4596b08cce5d.jpg - "Unresearchable collected itmes" - it would be helpful if it were more descriptive, i.e specified under the title of the base where it is researchable (in my case this base is Greenfield, so it should sit right there). That way the user would not have to guess which base is the right one to research the thing at. Number two, the text in description is not word-wrapped, while it should be.

12) An autosave feature saving geoscape every minute or two to a single slot (or perhaps even keep a history of the game for the last half-hour or so at 1 minute intervals) would be REALLY helpful in testing the Dev version. This way the testers could stop bothering about saving after each f*rt they make under different names in different slots and concentrate on testing instead.

13) Status messages appearing in the top line of geoscape are not at all helpful. It is almost always unclear WHERE the events happen. In some cases, the line is not word-wrapped, and not all text can bee seen.

« Last Edit: March 18, 2009, 10:56:26 pm by s300pmu1 »

Offline Destructavator

  • Combination Multiple Specialty Developer
  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 1908
  • Creater of Scorchcrafter, knows the zarakites...
    • View Profile
Re: App crash on bloodspider kill/stun etc
« Reply #1 on: March 15, 2009, 01:39:42 pm »
Regarding your feature requests, I'm really not one of the developers but as I understand it a good number of these things are already being worked on.  I don't have time at this moment to specifically address every single one of your points, but some areas have more on the TODO list than others (like point #9, the zoom-in which is where interactive air combat will take place, allowing the player to control what happens when interceptors fight UFOs, for example - which as can be seen in that build is a section of the game that has barely been started in development).

2.3 isn't finished and is a work in progress.

I do see a few good ideas that haven't been brought up before though...

s300pmu1

  • Guest
Re: App crash on bloodspider kill/stun etc
« Reply #2 on: March 15, 2009, 04:21:51 pm »
Well I'm not really asking anything and I did assume you are not a dev )
Thank you and the dev team for the greatest UFO experience so far.
I just hope I'm being somewhat useful with my comments here.

Offline bayo

  • Professional loser
  • Project Coder
  • Captain
  • ***
  • Posts: 733
    • View Profile
Re: App crash on bloodspider kill/stun etc
« Reply #3 on: March 15, 2009, 07:52:17 pm »
Hello, i will only talk about the transfer screen.

If i am right, what we (want to) have (and its maybe the same for the market) is to have a delay between the request and the arrival of items. I dont know where is the work about that, but i dont think your proposal will help to see this point, but with some changes, it's maybe possible. That's right the current transfer GUI is not easy to use; but the market too should not look like the current one.

I think, before any improvment of this screens, we should check the feasibility of the merge of the market and the transfer into and "inventory" screen. Before knowing if you want to transfer/buy/sell/produce/destroy... things, you every time check your items; and then you know what you want/can do. Maybe we should improve this way.

Offline BTAxis

  • Administrator
  • PHALANX Commander
  • *******
  • Posts: 2607
    • View Profile
Re: App crash on bloodspider kill/stun etc
« Reply #4 on: March 15, 2009, 08:07:46 pm »
(and its maybe the same for the market)

Yes.

odie

  • Guest
Re: App crash on bloodspider kill/stun etc
« Reply #5 on: March 18, 2009, 03:15:43 am »
11) Science - http://s45.radikal.ru/i109/0903/2d/4596b08cce5d.jpg - "Unresearchable collected itmes" - it would be helpful if it were more descriptive, i.e specified under the title of the base where it is researchable (in my case this base is Greenfield, so it should sit right there). That way the user would not have to guess which base is the right one to research the thing at. Number two, the text in description is not word-wrapped, while it should be.
Hi sp300pmu1,

I think that this kinda info should be retained on the items that are not complete with the items required for research.

Let me clarify: For one, when u r dealing with something unknown, i believe in real life, you would not know what else to try researching in order to reach it right?

The same way. In game, let say you found a UFO harvester, and w/o prior knowledge of smaller crafts, or perhaps even how to open the door, you would not be able to 'research' it.

A good scene of this would be the movie, Independence Day. Remember that lead actor who went to area 51? The scientists showed him that the UFO could float, and thats abt all they could do. Then that silly actor took a gun, and fired at it the next day? Yar, it takes discovery by trial and error.

I believe the developers here are doing this kinda thing : add a level of suspence..... if u dun like it, go download the roadmap for research in wiki. :P


12) An autosave feature saving geoscape every minute or two to a single slot (or perhaps even keep a history of the game for the last half-hour or so at 1 minute intervals) would be REALLY helpful in testing the Dev version. This way the testers could stop bothering about saving after each f*rt they make under different names in different slots and concentrate on testing instead.

Well, you might want to try the editors for maps and stuff. I thnk you might get better chances there. I believe the rework of a save in combat would be distracting and not worth the developer's time. Afterall, i have played hundreds of battle, (well planned) and not having so far, any single soldier killed. (Yes, they are shot, some heavily injured, but they all survived and put into hosp for rehab).

s300pmu1

  • Guest
Re: App crash on bloodspider kill/stun etc
« Reply #6 on: March 18, 2009, 10:44:14 pm »
Quote
(re 11) I think that this kinda info should be retained on the items that are not complete with the items required for research.
Let me clarify: For one, when u r dealing with something unknown, i believe in real life, you would not know what else to try researching in order to reach it right?

I'm not sure I was sufficiently clear on that one. What I meant is that the item is specified as unresearchable only because the player has selected in the research screen the base which does not have the object to be researched in it.

That is:

Base A has object X (e.g. a Harvester)
Base B has no such object

When I have base B selected, the "Unresearchable item" appears, as it is not here to be researched.
When I select base A, the previously Unresearchable item becomes researchable indeed, which is logical, as it is here and it can be researched by local scientists.

What I was arguing is that having the player (who has other things to worry about and spend time one) to guess which base the item is in, in order to click it and to start researching, is superfluous and has no point in it.What I do in such cases is just click each base successively until I hit the one which has the object to be researched in its storage/UFO hangar, and initiate research. Once you have more than two bases, it gets really dull, and surely does not add any suspense whatsoever. I do believe that placing the unresearchable item under the base name which can research it is logical, therefore, so that the user could switch to this base without checking on other bases directly.

Quote
Well, you might want to try the editors for maps and stuff.
I don'r really need 'em, as you can easily edit the armor stats to make personnel invincible.

Quote
After all, i have played hundreds of battle, (well planned) and not having so far, any single soldier killed. (Yes, they are shot, some heavily injured, but they all survived and put into hosp for rehab).

Again, I fear you misread me. I was speaking of _geoscape_, not tactical. And the point of autosave would be not to make the game easier to play, but to allow the tester to concentrate on testing and simplify error reproduction.

For example, I play the game, do something which causes an error, the game crashes. This means the following, see the algorithm below :)

SELECT CASE
   CASE i was lazy and did not save often
            open last saved game
            play it trying to do just the same that eventually led to the error
            in the meantime, save every minute or so in different slots in case the error happens earlier lest you'll have to start all over again
   CASE i was not lazy and have a numbered save I can tell apart from the others by name/number/date/time
            // whew I was lucky to save a minute ago!
            load save game
            continue testing, saving every minute of progress or so, just like before
END SELECT

Now in any case this takes a lot of time. Not every situation is reproducible, so some errors may not reoccur if you saved long time prior to them and didn't reproduce your actions exactly right. Whereas if we had this time-machine feature - we could just say - load the game as it was a minute ago, or as it was five minutes ago.

Considering the saves happen virtually instantly, this would not impede playing, while being a real time-saver. And I do not believe that implementing this feature would be time-consuming. Just activate the game-saving subroutine every <n> minutes if in geoscape screen, and perhaps just prior to a tactical mission (e.g. upon display of dialog "enter/automission/cancel"). Save game under a simple incremental number with date and time  stamp. Allow user to keep say 30 saves of this kind, and allow him to load any of his choosing. Keep the usual savegame slots for manual saving. That simple.
« Last Edit: March 18, 2009, 10:51:05 pm by s300pmu1 »

Offline Mattn

  • Administrator
  • PHALANX Commander
  • *****
  • Posts: 4831
  • https://github.com/mgerhardy/vengi
    • View Profile
    • Vengi Voxel Tools
Re: App crash on bloodspider kill/stun etc
« Reply #7 on: March 19, 2009, 07:18:06 am »
Again, I fear you misread me. I was speaking of _geoscape_, not tactical. And the point of autosave would be not to make the game easier to play, but to allow the tester to concentrate on testing and simplify error reproduction.

I haven't followed the whole thread - but we have a quicksave feature that saves your game before you enter a battle. We even have shortcuts for this - F1 is the saving, F2 is the loading.

s300pmu1

  • Guest
Re: App crash on bloodspider kill/stun etc
« Reply #8 on: March 19, 2009, 10:08:57 pm »
I haven't followed the whole thread - but we have a quicksave feature that saves your game before you enter a battle. We even have shortcuts for this - F1 is the saving, F2 is the loading.

I understand the you people have lots of stuff to do, so no problem with that. You're making my life better with every build, and thank you for that.
The problem with quicksave/load is that every time you do it, you're overwriting the last quicksave.
What I was suggesting is a "time-machine" feature - the quicksaves not replacing old ones, but queing up so that you can load, if necesary, not only the last quicksave, but also any of the preceding ones as well.

Considering the small size of save files and quickness of the saving process, that would not present any problems, IMHO. As for the resons to do this - well, read my above post.