project-navigation
Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - FWishbringer

Pages: 1 2 3 [4]
46
ufoai-2.4-dev-1301086950-Debug-pentium3-O1-sse-7z-full-win32

Lets say you set your volume controls next to mute, with speakers set high. Then enter into a mission where the mission has a background sound track. The sounds of the mission will be blaring out the speakers, when the music and interface is still nearly muted. This is not any more mission specific than needing a background track, it has happened to me on many missions.

Perhaps audio rendering of maps should follow with the music control, or a 'backgound' audio control could be added?

47
Feature Requests / Re: UFO information on store/sell?
« on: May 27, 2011, 08:59:00 am »
In that window the UFO type is displayed, if you know it. So you have to research the UFO before you get the display.

Part of the problem is it doesn't always display. If you don't wish to show the type until its researched, then the message stating the type has been transferred to yard is inconsistent. In a worst case scenario, perhaps referring to them as Small, Medium, Large... and so on until after their type is researched? There's a LOT of places it would need changed to remain consistent throughout if that were the option chosen, but it doesn't make sense...

Now, as a counter argument, the 'agency' that was developed to fight the incoming aliens has probably already come up with the names for the crafts (with alien names like Xyhsd Su Shoudldf, I doubt the term 'Scout', 'Fighter', or 'Harvester' came from their language as a ship type...) so it would still adhere to the immersion to allow the name to be known prior to researching. Just can't DO anything to it, other than shoot it, sell it, or store it.. until researched.

On the same window, it wouldn't hurt to add a multiline display of the 6 slots of each yard (sort of like the ufopedia does with headers and entries), listing the type and percentage of each in storage already. If this was pursued, it would even offer a simple temporary fix to full yards... if you made a line highlightable with an option to replace. Obviously, a more robust system that incorporated selling them, transferring them, etc would be better, but just the ability to replace them would be a temporary boon.


48
Feature Requests / UFO information on store/sell?
« on: May 26, 2011, 01:41:52 pm »
Quick search and didn't find it, perhaps I don't know the correct search terms.

In a single player campaign (not sure how well it pertains to other formats), when you secure a UFO after a mission and have a yard for storage, it would be nice to have a description on the window given where your options are to sell or to store the craft. Presently, there's a large amount of empty space in the top of the window, and I'm thinking something along the lines of UFO Scout (30%), UFO Harvester (no % if its collected intact), etc.

ufoai-2.4-dev-1301086950-Debug-pentium3-O1-sse-7z-full-win32
(And for the love of all that is holy, put in a 'please wait' after killing the last alien, so I stop crashing unless I wait)


49
Bugs prior to release 2.3 / Re: Crash at end of mission
« on: January 08, 2010, 10:09:14 pm »
Ok, couldn't figure out how to get a stack trace (nothing I switched on or off was giving a stack).

In addition to that error, if I ignore it, it causes the same error (assertation failed) on another line...

Code: [Select]
/**
 * @brief Write an item to the network buffer
 * @param[in,out] item @c item_t being send through net.
 * @param[in,out] container Container which is being updated with item sent.
 * @param[in] x Position of item in given container.
 * @param[in] y Position of item in given container.
 * @sa CL_NetReceiveItem
 * @sa EV_INV_TRANSFER
 */
void G_WriteItem (item_t item, const invDef_t *container, int x, int y)
{
[color=red]assert(item.t);[/color]
gi.WriteFormat("sbsbbbbs", item.t->idx, item.a, item.m ? item.m->idx : NONE, container->id, x, y, item.rotated, item.amount);
}

Ignoring that fault throws a sig fault.

Think I'm at about my limit here, will await ideas.

50
Bugs prior to release 2.3 / Re: Crash at end of mission
« on: January 08, 2010, 08:47:28 pm »
Ok, it does still occur in R27889, but didn't on the mission I saved it before. I had to go 4 more missions to get it again.

Once I got it again, I tested exiting and re-entering game, and it still crashed when I finished the new mission (saved right before transport arrived).

Changed && to || and rebuilt, and... got something worse.

Weapons aren't being 'held'. I can see them, the people appear to have them, but they are not usable. Not in the 'current item' slot, and opening inventory doesn't show anything on anyone.

EDIT

Changed the statement to if (nr == 0) and it appears to work, time to complete the mission and see if it crashes again.

EDIT

Ok, same crash back... going to try the other half... if (ent->type != ET_ITEM)

EDIT

Ok, that brings back the missing weapons and items

Since those tests (since the original binary I had was release) were all done in release mode. Rebuilding in debug, and will see if I can attach to it.

EDIT

Debug fails to build, tons of errors regarding an undefined reference to mcount, and a few others. Going to rebuild in release and try attaching.

EDIT

Debugging from the codeblocks IDE isn't allowed if I didn't build debug, time to figure out what needs fixed.

51
Bugs prior to release 2.3 / Re: Crash at end of mission
« on: January 08, 2010, 04:41:25 pm »
I went to the wiki
Obtained the codeblocks setup
Got it set up
Extracted all the pk3 files in the appropriate place
..and am presently running an svn update on the whole thing

Once its done, I'll double check the function after the svn update and see if anything changes, if not, I'll try building it with ||

I uncompressed saves, and verified that the crash is still occurring, so hopefully the save will be compatible or easily made compatible, so I can test the crash after any code changes.

EDIT:
Dawned on me, I could just browse the source tree while waiting on svn update to finish.
It still reads as posted

I took a look around and I'm not sure if || is appropriate, or if it wouldn't be better off as just
Code: [Select]
if (nr == 0)
EDIT:
SVN finished, building stock now. To test if it still occurs on latest svn, though I expect it will, since it has the same line.

52
Bugs prior to release 2.3 / Crash at end of mission
« on: January 08, 2010, 03:44:01 pm »
I'm using the version from http://ufoai.ninex.info/forum/index.php?topic=2830.msg33021#msg33021

When completing missions, I frequently get the same crash. When it occurs, if I load up a save before the mission, I'm still 100% going to repeat the crash. My only workaround is to auto mission, and try the next after.

The error I get (critical stop popup, with the red X)

Crash popup...
Code: [Select]
Assertation failed!
Program: d:\Games\UFOAI-2.3-dev\ufo.exe
File: D:\UFOai\src\game\g_inventory.c
Line: 249

Expression: ic->item.t

--stuff about debugging--

Relevant code...
Code: [Select]
/**
 * @brief Sends whole inventory through the network buffer.
 * @param[in] playerMask The player mask to determine which clients should receive the event (@c G_VisToPM(ent->visflags)).
 * @param[in] ent Pointer to an actor with inventory to send.
 * @sa G_AppearPerishEvent
 * @sa CL_InvAdd
 */
void G_SendInventory (unsigned int playerMask, edict_t *ent)
{
invList_t *ic;
unsigned short nr = 0;
int j;

/* test for pointless player mask */
if (!playerMask)
return;

for (j = 0; j < gi.csi->numIDs; j++)
for (ic = ent->i.c[j]; ic; ic = ic->next)
nr++;

/* return if no inventory items to send */
if (nr == 0 && ent->type != ET_ITEM)
return;

G_EventInventoryAdd(ent, playerMask, nr);
for (j = 0; j < gi.csi->numIDs; j++)
for (ic = ent->i.c[j]; ic; ic = ic->next) {
/* send a single item */
LINE 249 assert(ic->item.t);
G_WriteItem(ic->item, INVDEF(j), ic->x, ic->y);
}
}

It happens with various loadouts, whether or not I pick up items, etc. I can't find any pattern to say 'this will always repeat it'.

When it does occur, its ALWAYS at the end of the mission. right after the last alien is killed or stunned, and if I saved before it, it will always do it if I load the save back up and replay it.

Pages: 1 2 3 [4]