Messages

151

Feature Requests / Re: Production time

« on: July 10, 2009, 06:02:49 am »

I like this idea too, and it sounds like something I could do easily. Should I try to do this?

My proposal on this matter is to break it down to the minute, so it will be 60 times an hour. Now, while you can still waste some engineers, 60 items per hour may be more reasonable. I'm sure someone can think of some reasons why (like transferring them to storage or something). So, this will be the only change I will attempt..

Basically, I'll try to find the code that checks production completion, have it check every minute rather than every hour, and divide the work done by 60. I don't want to over tax the cpu by checking 10,000 times an hour or something...

152

Discussion / Re: Power Plant

« on: June 26, 2009, 04:12:59 am »

Oh yeah, it is. XD Hehe. Positrons, only heard of those from Data's brain. >.>

I wonder how they contain the explosive power.. Granted, they have an extra few hundred years on us.

I actually have no idea how much explosive power anti-matter can produce. Nor do I know how much explosive power 1 kiloton of anything produces. I figure if you make the shielding strong enough to withstand an anti-matter explosion, the aliens aren't going to destroy it by randomly shooting it anyway.. Not even if they throw anti-matter grenades at it...

153

Discussion / Re: Power Plant

« on: June 25, 2009, 09:48:05 am »

I think the best idea I have is destroy the anti-matter by using it. You can do whatever you want with the energy. If you want it to be controlled, it can't be instantaneous, but we could calculate how long it would take to safely consume the amount of anti-matter we have stored, and then during the mission, we start the countdown from when the order to consume the anti-matter is given.

If the anti-matter storage gets destroyed before the timer is up, we can then calculate the explosive power that remains, and.. err... I'm making this too complicated, aren't I?

154

Discussion / Re: Power Plant

« on: June 25, 2009, 09:27:57 am »

I'm not a physics person or anything, but I thought nothing we know could stop a proton anti-proton or electron negatron reaction, which is probably what the antimatter is, a bunch of anti-protons and negatrons.

So, if whatever energy barrier we're using to try to keep antimatter from contacting any matter fails, we probably lose a lot more than just the base.. I don't know how foam could stop it, or anything else.. like burying the thing.. An AM storage would probably always be running on its own (internal) power, so I think we can leave out any connection between the power plant and AM storage. Or, uh, is it something we're creating that we say can stop it? Which I guess is ok now that I think about it.. Who knows what the future will bring... but right now, as far as I've ever heard, there's no way to stop it, not even theories. anti-matter will basically react with any matter, of any type... I think.

I guess, if we really would to figure this out, we can find the explosive power generated by a single anti-proton proton reaction, we know the exact weight of the anti-proton, and we can simply calculate if there is enough power there to destroy the base. If there isn't, we simply destroy whatever percentage of the base the reaction would destroy, and place the center of the explosion on the anti-matter storage. Well, it will be quick to look up all this information anyway, and quick to calculate the damage.. I guess the only long part would be to calculate how much hp a base would have...

155

Feature Requests / Re: Alien Reinforcements

« on: June 25, 2009, 05:36:17 am »

I remember several X-Com crashed ufo missions where all the aliens died in the crash. In UFO: Alien Invasion, this never seems to happen..

Also, in this game, the aliens always seem placed in the same positions for crashed ufos. Always 1 standing just down the ramp that dies first round, and the rest inside the ufo. I guess that can make sense from a hive mind perspective too, but, uh...

Are the aliens in a crashed ufo coded at a certain number always, or are they somewhat random?

156

Windows / Re: Do UGVs work or not?

« on: June 20, 2009, 11:00:12 am »

I am currently working on the goggles and smoke grenades. It will be a long time coming though. I request these items not be removed until I fail miserably.

Also, I need someone to go through each team file and determine how hot each alien and human is, and, preferably, modify the team files (and post a copy) so I can make use of the values. I have no idea how hard this will be, but it's not something I plan to do on my own.

157

Design / Re: Medikits

« on: June 18, 2009, 08:50:47 am »

If you keep the stun damage separate, it means injured people can not be stunned more easily than healthy people (assuming you don't decrease the size of the endurance bar based on damage, which is added complexity).

On the other hand, if you are adding an endurance bar, it might make more sense to get tired as people run around swinging swords and shooting guns. Would that make them more easily stunned?

158

Design / Re: Medikits

« on: June 16, 2009, 05:00:04 am »

Just a note, Domein's suggestion is what UFO: Aftershock's (and possibly with other UFO After games) currently does.

In UFO: Aftershock
Max hp is what is damaged slowly each hit. It requires a treatment facility to restore. If you are unconscious, all damage is done directly to Max hp, and if this max hp reaches 0, you're dead. While you are unconscious, your max hp slowly decreases until you are revived by a medikit, or completely dead.
Current hp is the amount of hp you have that keeps you conscious. It is damaged by every hit, explosion, and whatnot a lot faster than max hp. If current hp reaches 0, you are unconscious.
Stun reduces current hp only, and has no effect on max hp.
Acid and fire and other things rapidly reduce both current and max hp (current still faster though). This is sorta like bleeding while still conscious.
You can't bleed while conscious though, only when you fall unconscious do you bleed to death.
Medikits can't raise your current hp above your max hp.


Just thought I'd mention where this idea has already been implemented..
One other note is, if the mission ends, and any of your soldiers are stunned or bleeding, they are considered lost. I didn't like this idea so much, but that's how it was implemented. Unconscious soldier = dead soldier, whether the mission was a success or failure.

159

Discussion / Re: Communication strategy

« on: June 02, 2009, 10:14:11 pm »

Criusmac had more determination (time?) than I did to actually get involved, but reading his post it seemed like he was fighting obstacles to try and help.  I think you are losing a lot of potential help. 

Woo hoo! I got mentioned! Err, really fast that. I'm not sure I'm involved even yet. I'll consider myself involved if I successfully manage to create a patch. What I did though was see an obvious, but somewhat complicated problem that needed to be fixed, get some additional info from the person who wrote the accepted proposal (of visibility), and then hunted around the source for other code that did what I wanted to do. A few copy/paste later, and I've at least started, though it sure isn't pretty. I still suspect this is beyond my abilities, but I suspect the worst that can happen is I fail, and nothing gets done. At least the ideas posted seem better than they originally were, in my opinion anyway, which means time wasn't really wasted.

- Pretty much everything a player will see is focused on 2.2.1 which is over a year old.  Its pretty obvious once you hit the forums that 2.2.1 is barely a memory in anyone's mind, but if you don't look at the forums you will hit up an incomplete manual and fiddle around with 2.2.1 and thats it.

If a dev release works decently well maybe make a note of it on the wiki with some comments on where it will break so people can try a dev version without trying to figure out which ones could potentially be playable.

My attempts to generate a patch are a bit different than the requested method of grab the latest dev version, and apply the changes directly to it. I decided to do my work on the stable version directly. I decided this since my changes (visibility) do not exist, in part or whole (as far as I know) in the latest dev version. It's a bit riskier since the code is a good year old, but I don't have to worry about any of the latest bugs that may have cropped up, or been fixed. I don't have to download dev versions and test my code against them (yet). Since I know where in the branch I got my files from (2.2.1), a merge patch is possible which means it should be easy to merge my code into the latest development version when I'm done (free tools exist to do this). Once that's done, I can see if my code still works. So, for me, having a stable release is all I need since if something goes wrong, it's probably a bug introduced via my code, and will be easier to locate and fix. There's a lot of assumptions I'm making here and there, but for the most part, any assumptions I make don't actually change anything. For example, if it turns out I can't merge my changes into the latest development release, I'll just download the dev release later, and manually merge my finished changes in. Still a lot simpler than developing on the dev release itself. Maybe this would work for you as well?

- The technical area of the wiki looks like my personal wiki.  Stuff is all over, linked to all over.  Its completely unclear what is current and what isn't and most of it has a large amount of assumed knowledge associated with (its not wikified).  This works fine for my personal wiki, the directory is password protected and no one other than myself should ever see it.  It probably works fine for most of the developers here, but it is a heck of a hurdle for someone trying to learn.

I gave up with trying to learn anything general about what people want done. I picked a task that I felt was needed in the game, and I'm concentrating on it alone. I saw the wiki, but I don't think I did anything with it. The proposals page (http://ufoai.ninex.info/wiki/index.php/Proposals) is a great place to find something you want to do, and I'm really lucky what I wanted to do happens to have an entry.

- I don't know about a CMS, I mean the monthy updates are great but what else are you going to put there?  The daily SVN logs?  Forums are fickle, information gets lost and few new people read anything but the stickies (if that) unless they are searching out something specific.  I would try and make the wiki the focal point, make the main page updated with current notes and have at least all the pages that link from the main page be well designed and up to date.  There doesn't seem to be a whole lot of activity on there though.

The forums are absolutely horrible to search through here. Things I saw by randomly reading I can't find again even with a few keywords to help. The wiki does seem like a good focal point, but it should be accessible from the forum page somehow via a link. It would have saved me a lot of time if I had known it was so connected to the forum's ideas. As for updating things, it might be possible, but I can't imagine a quick and easy way.

Anyways I am trying to be constructive I hope no one gets offended; I am probably not saying anything that is new or that anyone doesn't already know, but thought it might help.  I am software engineer and am just finishing up two months of documentation work and just about want to kill myself (which is why I was hoping to jump in and start coding something neat), I know the pain of trying to write junk to explain complex things to people who know nothing.  If I can motivate myself maybe I will try and start doing a 2.3 user manual on the wiki or trying to figure out what needs to be update and how it might better be organized, it would be a good project for learning to code and figure out how things work and what needs to be done...

I personally don't see how a 2.3 user manual will help until 2.3 is a stable release. This user manual you suggest is for people new to the game, right? If this is true, then they should be playing the 2.2.1 stable release anyway. Playing a dev release is, well, ugh? (ugh = bug ridden, crash prone, unbalanced, and who knows what else). What drew me to this project is the eye candy, game play, complexity, and probably a few other things, like todos. I like complex things, as can probably be seen in my own terrifying posts. It is tough to pick a starting point, but mine I saw from within the game itself (and it bugged me), so it was easier for me. Whether or not I can do it, only time and luck will tell. My suggestion is similar to others here though. Download Code::Blocks and use it since that's all people seem to use here. Once you have successfully compiled the code, you can start changing it, and hopefully it'll be improved when it's done. Doesn't have to be big, doesn't have to be complex, I'm sure anything you do will help out, as long as it works properly. I like to keep a d20 (20 sided die) around to help me make decisions like this.

160

Coding / Re: Visibility plans

« on: May 28, 2009, 04:18:43 pm »

Did we want a way for the players to know exactly which squares are visible to their soldiers? For example, by colouring every square they can clearly see a different colour or something?

Also, a random thought led me to believe there are some circumstances where you can't see an individual, but you know they are there via sight. For example, if someone is too far for you to see, but there is a light shining on a wall behind them some distance. Your vision of that part of the wall would be obscured by the individual. Not sure how to handle such a situation, any suggestions?

Under my current proposal, it would have been completely ignored and you wouldn't have seen them.

Unfortunately, if we allow people to see them, it creates almost a cheat where since eyes are above ground and most creatures are standing on the ground, an individual could see things that are out of range just via the light hitting the ground alone. We could raytrace lines through every target to see if they obscure a light source hitting something behind them, so, uh... What should I do?

This also creates an imbalance in multiplayer since 2 different players can be staring at each other, and only 1 of them might be visible via the light behind them. Let me know how you want this handled.

Lastly, I have decided to place all the visibility parsing data into CL_ParseClientData. This means any visibility changes related to equipment or tech will need to be added to the tech or equipment directly, since the cl_visibility.c will have no knowledge of what equipment or tech exists.

161

Coding / Re: Visibility plans

« on: May 17, 2009, 06:46:43 am »

Maybe we can drop that part then. Give everyone the same detection range and impose an artificial bonus to CPU teams? The main thing to consider here is multiplayer, where players can pick an alien team.

Hmmm. Multiplayer. Since you seem to want it to be identical for each player, perhaps I should add another section to visibility.ufo to handle multiplayer exclusively. <Trying hard to not say any assumptions>..... <failed> I take it the server sends the .ufo configuration to each client then?

I don't understand this part. How do you arrive from 25/50 vision and 20% light to 30 squares?

25 range vision at night.
50 range vision at day.
20% light, so I take 50 (day) - 25 (night) = 25 (total difference). 25 (total range difference between day and night) * 20% (effective light) = 5 (range difference at 20% light). 25 (night visibility range) + 5 (range difference at 20% light) = 30 (range at 20% light).

During my stable version game, I observed light in different squares had different strengths. This proposal allows people in low light to hide better than people in bright light. This proposal also means people in low light hide worse than people in total darkness.
No randomness involved, and a (I believe) simple calculation assuming there is no light brighter than the sun, or darker than pitch black... Which may not actually be true in this game.

162

Coding / Re: Visibility plans

« on: May 17, 2009, 02:11:06 am »

I have created cl_visibility.h and .c in the ufo client code, and modified the stable version of cl_main.c's CL_ParseClientData to parse the new visibility.ufo in the 0ufos.pk3 package. I'll assume you can merge patch these changes when they are complete.
The visibility proposal lists an example indicating the visibility values for a Hovernet. Since this creature does not exist in the stable version, I'll assume it is an odd translation of Bloodspider, and go from there.

Re: Stealth
The stealth section of the visibility proposal does not make sense to me.

  Stealth

A target's visibility (though, given the counter-intuitive values in this section, a better term would be "stealth factor") should be influenced by:

    * The lighting of the space the target is on. A square in full daylight will have stealth factor 0, and a square right underneath a street light will have a stealth factor of -10 (since these squares are especially noticeable in the darkness), while a square in a deep shadow at night could have stealth factor 20.
    * The stance of the target. See partial obscurity.
    * Any stealth bonuses the target receives from camouflage or other cloaking methods, such as smoke screens.
    * Aliens could get small stealth bonuses or maluses as a result of the difficulty setting.

If the unit's visibility is equal to or less than the actor's detection value at that range, and the conditions mentioned at the start of this article are met, the target is spotted. Otherwise, the target remains hidden.

I am assuming this stealth factor is written from a human's point of view, instead of from, for example, a Taman's point of view.
Because Taman can see better in darkness as compared to light (for some reason, possibly due to infraseeing, but no idea) a human standing under a street light would be harder for a Taman to see in the night. Due to the example given in the visibility proposal, since every other alien creature can see as well in the day or night, standing under a street light would make no difference for them. Therefore, it is better for humans to stand under a street light whenever they can since it will make them harder to spot for Taman, and make no difference for other aliens.
For humans though, an alien will be easier to spot under a street light because it simulates day, which is when humans can see better (according to the proposal). I don't see why there should be a bonus or detriment for this however.

What I plan is only the target square's lighting has any impact on the visibility of the target. This means, standing under a street light means the target square is more or less day, and thus can be seen from further away using day vision. Night vision would not have any effect on a target in a day square.

Night vision will only have an effect if the square is darkened, or in shadow. Day vision will have no effect on a square that is pitch black.

Re: Light strength
I will find the light value of the square, and placing night vision value at 0%, and day vision value at 100%, the ability to see the target in a certain strength of light will be strength % of the light in that square, and where the actual value of said percentage falls.
So, for example, humans have 25 night range vision, and 50 day range vision, and the target they are looking at is in say, 20% light as compared to daytime. 25 (30) 35 40 45 50. They could see the target from 30 feet away.
If a Taman were looking, 75 (65) 55 45 35 25, a Taman could see the target from 65 feet away.

At present, I'm unsure of how to handle technologies and items.

(From research.ufo)

Code: [Select]

tech rs_irgoggles
{
type weapon
mdl_top weap_irgoggles

up_chapter equipment
description {
default "_irgoggles_txt"
}
// pre_description "_irgoggles_pre_txt"

require_AND
{
tech rs_skill_mind
}
provides irgoggles
time 0
producetime 80
}

Due to the provides line, I will try to add a modifier as seen in the following visibility.ufo.

I propose we modify the visibility of humans so that humans can see 0 feet in absolute darkness since that seems to be how well we see (unmodified) today. I don't know if this holds true in the future as depicted in the game, so you'll have to let me know.

Due to the way infravision is explained in the tech description (being able to see through walls), I have to assume it is a different type of sight altogether, and not based on day or night vision. Since I am considering infravision as separate from night vision, we may need to look at some of the alien races, like the Taman, and ensure the values are entered correctly, or we need to rethink how night vision works by assuming night vision can always see through walls, and day vision can not. Please let me know how you want that to be.

With the currently planned visibility.ufo, there is room to add new methods of detection as time goes on, like a type of motion detector like some of the XCom games had (if I recall right). For now, the only value required for any new detection type is how easily it can penetrate a wall. There may need to be others if, for example, someone invents a device that scans the x axis better than it scans the y axis (like radar might).

Warning: This post was rapidly typed and may not have been thought through very well. Please let me know of any problems you see with it.

I am basing visibility.ufo on the team name files, so the visibility.ufo file will look something like this (subject to random changes):

Code: [Select]

//========================================================================
// VISIBILITY - List of visibility and modifiers
//========================================================================
// Description:
// TEAM DESCRIPTIONS
// day Team's unmodified ability to see using day structure
// night Team's unmodified ability to see using night structure
// infra Team's unmodified ability to see using infravision structure
// psionic Team's unmodified ability to see using psionic structure
//========================================================================
// STRUCTURE DESCRIPTIONS
// wall How many feet are added to range for each foot of wall. 0 = infinite
//========================================================================

team human
{
day 50
night 25
infra 0
psionic 0
}

team taman
{
day 25
night 75
infra 0
psionic 0
}

team ortnok
{
day 60
night 60
infra 0
psionic 0
}

team shevaar
{
day 50
night 50
infra 0
psionic 0
}

team bloodspider
{
day 75
night 75
infra 0
psionic 0
}

day
{
wall 0
}

night
{
wall 0
}

infra
{
wall 5
}

psionic
{
wall 1
}

tech irgoggles
{
day -15
night 0
infra 25
psionic 0
}


163

Coding / Re: Visibility plans

« on: May 15, 2009, 06:27:59 pm »

I'm not sure exactly what you want here - the TODO lists are general, as you said. If you want detailed concepts of features to be implemented, they're either on this wiki page, or we don't have any yet. In the latter case, you should discuss it in the IRC channel. It may be that there is some general idea of how to do things, but nothing that has been fleshed out yet.

Thank you! Numerous searches could not find the Proposals page for some reason, but that contains the information I wanted!

The important thing is that these values should be scripted so we can tweak them later for balancing. That way all you have to worry about is the basic system, and if something is off it can easily be corrected.

I've only given it a quick look-over, but my first impression is that it's very complicated, both in terms of abstract rules and codewise. I'd prefer a simple system, as with everything. Especially the randomness is a problem for me - the more random something is, the less predictable, and in case of visibility I think it pays to be predictable because then the player can more reliably make it part of his tactics.

I'm unsure what you mean by scripted. Do you mean to create definitions in the source code so you can change the values more easily? Or do you mean it should read the values from an external file somehow?

As for randomness, Hmm. You do make a good point. It feels like you are saying given any set of circumstances, you will either always see the alien, or never see them, with no random possibilities of maybe seeing them. If this is indeed what you mean, it means you will need a lot more balance testing until you get it just right. That is another way to go about this, just not one I'm used to. I will give the visibility proposal a look over, and see what I can come up with then, thank you.

164

Coding / Visibility plans

« on: May 15, 2009, 04:04:44 pm »

Ok, without any suggestions forthcoming from the "Searching C++ Programmers" post, I'll assume I'm supposed to do whatever as I see fit. Maybe this is the way open source projects are supposed to work? I have no idea really.

Is there any way to see what features have been agreed upon as "need to do" at least?

It took me a long time to refind the todo lists, but they are rather uninformative, and general for me to do anything about.

I did not find the UFORadiant code, only gktRadiant, so I'll assume UFORadiant got canned due to its problems, and no longer exists. In that case, I'll assume nothing needs to be done about this C++ code then. These posts are obviously too old now.

I looked at some of the translation information, but there doesn't appear to be enough of a concept of what people want to have said. From what I can tell, what is wanted is someone to invent a story or piece of one and type it up. I'm not a storyteller, so this is beyond me.

Since the Feature Requests do not contain information on whether or not the feature requested was accepted, I'll assume they are in the discussion phase until they appear on the todo list, at which point somewhere, somehow, the information is kept, just not where I can see it.

I have been unable to find any information on how people want visibility to be implemented.

I will try to implement visibility without any outside information, even though it isn't on the todo list since I feel this game should have it. Since I have no information written down anywhere, I will come up with arbitrary random numbers and ideas, and tweak them until it works somewhat. Since I don't have any information on the alien's capabilities except for the text in the research panels, I will go completely off the research information, and try to set their powers of sight based on that. This basis will be as if all aliens are humans with today's level of technology for whatever detection methods they have. IE: Aliens with infrared sight will act as if they are humans with infra goggles permanently attached to their eyes.

It's a poor way of doing it, but with no information or knowledge on what is wanted, it's the best I can come up with. Without any raytrace information suggested that I can find, I will assume I don't know what is wanted about this, and will thus not do it.

In short, if you want me to try to do it a certain way, post a link to what you want, or how you want it done, otherwise I'll assume it's up to me, and just do it however I see fit (which may not be a bad thing really, just not a well thought out one).

So, here is what I plan to do currently:
1) During debug mode, enemies will be completely visible as they currently are, but their popup will include your chance of seeing them in your current positions. There will be 1 row for each living soldier to indicate his/her chance of seeing the alien. This chance will be 0% if there is no line of sight.
2) During any movement by an alien, each soldier will roll a random number to indicate their percentage chance of noticing the alien. I will not deal with decimals in the percentage currently, so everything will have a 0-100% chance of detection.
3) Once an alien is detected, it will not become undetected until it leaves *all* soldier's line of sights at the same time.
4) During any movement or facing changes by a soldier, that soldier will get a chance to see any of the aliens he or she has line of sight to. This means standing in 1 place and constantly changing facing is a good way to pick up on any aliens that you may not have spotted initially. I'm assuming the soldier is taking the time to look around.
5) If a soldier is fired upon either via melee or ranged attack, and they get hit by the shot, they will not have an increased chance of detecting where the alien is since they will be in pain/unconscious/panicky/whatever happens when you get hit by serious firepower. They will still have their normal base chance of seeing the alien if they are not dead though.
6) If they are not hit by the alien, they will be granted some random number bonus to detecting the enemy. For now, I will assume this random number is based on mind, and I will go with (mind-25) (that can not become negative, since 25 seems to be average mind) increased detection chance since that seems like a good starting point. This means if you have a soldier with 124 mind, they will have a 100% chance of detecting any enemy they have line of sight to assuming they have at least a 1% base detection chance.
7) This means any alien that has a 0% detection chance can not be seen no matter what they do. They can scream and shout, poke people, stab people, shoot people, and there's no way to detect them. Chances are this will only happen in very dark places, or with cloaking technology, or no line of sight, or at least, I'll tweak it until it only happens for those times. (assuming no infra goggles or other detection methods that might make it possible anyways)
There will be a -10% chance of detecting any enemy (can not decrease below 1% if it started at higher than 0%) for each 5 foot level difference between the observer and the observee. This makes stairs very dangerous since you have very little chance of seeing anyone above or below you, even if they are generally right in front of you. This level disadvantage does not apply if they are shooting at you, whether or not they hit. I'm not going to make an exception for stairs or areas being narrow since I have no idea how one might want to come up with those rules, so I'll just assume they are no matter what. Feel free to change the code if I actually manage to get this working though.

I've forgotten a lot of what I planned since this post is long, so I'll just modify this post as I come up with them, or people give me suggestions I decide to try to implement too.
By the way, this won't actually happen for a long while since I haven't look at any of the code yet, and have no idea if these things are doable without other major changes. I'll assume it'll be fairly easy though since there is already line of sight detection somewhere, and all I'm doing is modifying that function to roll random numbers based on my own criteria for detection.

Sound good?


1st Edit:
On my first initial look at the code, I have identified int G_CheckVisTeam (int team, edict_t * check, qboolean perish) as the likely place to implement this code.
I have confirmed this function is already called in static int G_DoTurn (edict_t * ent, byte toDV), and int G_CheckVis (edict_t * check, qboolean perish), so assuming these functions aren't spammed a lot constantly, this seems like a good place to start.

165

Feature Requests / Re: Alien using human weapons?

« on: May 15, 2009, 06:23:49 am »

Oh, I had forgotten about that. I went with Standard on my first try. Never tried any other levels though. That's probably my problem then.