1
Fan-Stuff / Re: YAML based Savegames = Win.
« on: October 17, 2011, 10:49:00 pm »
I am wondering whether it goes beyond 255 in OpenXcom 
Welcome, Guest. Please login or register.
Did you miss your activation email? January 15, 2025, 07:51:40 am
Did you miss your activation email? January 15, 2025, 07:51:40 am
News: If you can't login, please contact us with your username and e-mail so we can fix it.
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.
2
Programming / Re: Globe improvements
« on: September 27, 2011, 07:30:36 pm »For example, research mission. They've scripted 3 levels of progression.Code: [Select]<ct_SmallScout, 1, 0, 300>
<ct_MediumScout, 1, 2, 260>
<ct_LargeScout, 2, 4, 300>
Values are: CraftType, NumberOfUFOs, Trajectory_Type, Timeout.
So they're using trajectory_types 0,2 and 4.Code: [Select]0:
dw 5 ; UFO_Waypoint_count
dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
dw 4, 3, 1, 1, 2, 0, 0, 0; UFO_Waypoint_Altitude
dw 100, 74, 28, 47, 100, 0, 0, 0; UFO_Waypoint_Speed
dw 3000 ; Ground_Timer
2:
dw 5 ; UFO_Waypoint_count
dw 5, 0, 0, 1, 5, -1, -1, -1; UFO_Waypoint_Site
dw 4, 3, 2, 1, 0, 0, 0, 0; UFO_Waypoint_Altitude
dw 100, 57, 26, 50, 100, 0, 0, 0; UFO_Waypoint_Speed
dw 5000 ; Ground_Timer
4:
dw 8 ; UFO_Waypoint_count
dw 5, 0, 0, 2, 0, 0, 2, 5; UFO_Waypoint_Site
dw 4, 2, 2, 1, 0, 2, 1, 0; UFO_Waypoint_Altitude
dw 100, 67, 52, 40, 30, 20, 30, 100; UFO_Waypoint_Speed
dw 7000 ; Ground_Timer
Found the numbers interesting, so I thought I'd help make them a tiny bit more reable
Keep up the good work!
3
Programming / Re: Research developement
« on: September 21, 2011, 12:54:09 am »Don't worry I'll be sure to drag it out until everyone comes to my house with torches and pitchforks.
.. or maybe they bring champagne for the release party?
4
Offtopic / Re: X@Com - Xcom as roguelike
« on: August 23, 2011, 10:41:46 pm »
Awesome particle system btw! I was "blown away"
5
Offtopic / Re: X@Com - Xcom as roguelike
« on: July 14, 2011, 07:24:48 pm »
I guess the OpenXcom code could be modded to show ASCII instead of sprites - there you have you near-instant XCOMRL in a neat package
6
Fan-Stuff / Re: Soldier names
« on: April 02, 2011, 01:50:48 am »
Just grabbed the 20 most used names and surnames from Statistics Denmark.
Now lets get those vikings into OpenXcom
Now lets get those vikings into OpenXcom
7
Fan-Stuff / Re: Soldier names
« on: March 31, 2011, 06:45:37 pm »
I was wondering if the ratio of 3:1 of male and female names is used for any particular reason?
Maybe in UFO:EU it directly affect how many male and female soldiers are generated when hiring soldiers in-game?
Maybe in UFO:EU it directly affect how many male and female soldiers are generated when hiring soldiers in-game?
8
Suggestions / Re: The weapon upgrade idea.
« on: February 17, 2011, 11:25:02 pm »Oh, so it is also related to fx. fire and smoke animations "stalling" while walking around or firing bullets?Well, the way I was going to implement it, it IS a technical limit: there always can be just one action on the battlescape at a time: whether it is an explosion busy with exploding, a soldier walking, a ufo door opening or a bullet flying. Only when the previous action has finished, the next one can start.Actually the speed of the auto-cannon was a result of the technical limit of not more than 1 bullet that can be flying at the same time.I think of this as more of a design decision to ensure that the player knows what he has hit, by having the screen follow each shot until it "terminates". Only then can you fire another shot and have the screen follow that. Whether this is an absolutely critical feature for "good" tactical gameplay I am not sure though...
The next bullet could only be fired when the previous one hit something (or went out of the map).
9
Suggestions / Re: The weapon upgrade idea.
« on: February 17, 2011, 06:24:46 pm »Actually the speed of the auto-cannon was a result of the technical limit of not more than 1 bullet that can be flying at the same time.I think of this as more of a design decision to ensure that the player knows what he has hit, by having the screen follow each shot until it "terminates". Only then can you fire another shot and have the screen follow that. Whether this is an absolutely critical feature for "good" tactical gameplay I am not sure though...
The next bullet could only be fired when the previous one hit something (or went out of the map).
10
Suggestions / Re: The weapon upgrade idea.
« on: February 15, 2011, 09:40:59 pm »
I know you weren't talking about changing the default game form - your ideas just got me thinking about what one need to keep in mind to ensure a "good" mod
11
Suggestions / Re: The weapon upgrade idea.
« on: February 15, 2011, 05:24:31 pm »
There are many different problems and opportunities in this field:
Simplicity
As michal mentioned, the simplicity or elimination of choice in the core game could very well come from not wanting to burden the player and make it clear which way to go to win the game. One can only speculate whether at the time of development, the game was targeted less at hardcore gamers and more at "casual" ones (if there were such a thing at the time...). Most fans today are hardcore strategic and tactical aficionados who like the challenge of figuring out which weapon is best and under what circumstances it is best used. Shortly put: Core gameplay might benefit from sticking with the original formula to draw in and entertain new players, while extensions/modifications could be the way to goto keep the more hardcore fanbase challenged in the long run.
New feature vs. numerical upgrade:
With weapon development/upgrading you often have two possibilities: Add new feature (fx. toxic gas grenade) or make more powerful (increase range, power, ammo etc.). New features are more interesting to hardcore players because they open up the space of possibilities by creating more complexity which motivates the development of more advanced tactics among players. This is a good thing because many are motivated by the exploration of possibilities in play and experiences of success once a more efficient tactic has been identified. However, new features are also usually much more costly to implement than "powerups".
Balancing
When changing the rules of a game, you always have to keep the balance in mind - otherwise the flow of the game is likely to be changed significantly (of course this can be a positive thing, if that was what motivated the change in the first place). Apart from being more costly than upgrades, new features are also notoriously more difficult to balance, because they interact with existing features in new and unexpected ways. Hence a new type of weapon may turn out to be a super-weapon even though it wasn't meant to be, because fx. the AI was not prepared for its impact on tactics in the game.
These points are not meant to criticize changes to the game - on the contrary I am looking very much forward to modding a bit myself. I am just making the point that it takes a fair bit of caution not to ruin the play-value of a game with new stuff! Also, keep in mind that there are probably more things to be aware of than what I came up with off the top of my head...
Simplicity
As michal mentioned, the simplicity or elimination of choice in the core game could very well come from not wanting to burden the player and make it clear which way to go to win the game. One can only speculate whether at the time of development, the game was targeted less at hardcore gamers and more at "casual" ones (if there were such a thing at the time...). Most fans today are hardcore strategic and tactical aficionados who like the challenge of figuring out which weapon is best and under what circumstances it is best used. Shortly put: Core gameplay might benefit from sticking with the original formula to draw in and entertain new players, while extensions/modifications could be the way to goto keep the more hardcore fanbase challenged in the long run.
New feature vs. numerical upgrade:
With weapon development/upgrading you often have two possibilities: Add new feature (fx. toxic gas grenade) or make more powerful (increase range, power, ammo etc.). New features are more interesting to hardcore players because they open up the space of possibilities by creating more complexity which motivates the development of more advanced tactics among players. This is a good thing because many are motivated by the exploration of possibilities in play and experiences of success once a more efficient tactic has been identified. However, new features are also usually much more costly to implement than "powerups".
Balancing
When changing the rules of a game, you always have to keep the balance in mind - otherwise the flow of the game is likely to be changed significantly (of course this can be a positive thing, if that was what motivated the change in the first place). Apart from being more costly than upgrades, new features are also notoriously more difficult to balance, because they interact with existing features in new and unexpected ways. Hence a new type of weapon may turn out to be a super-weapon even though it wasn't meant to be, because fx. the AI was not prepared for its impact on tactics in the game.
These points are not meant to criticize changes to the game - on the contrary I am looking very much forward to modding a bit myself. I am just making the point that it takes a fair bit of caution not to ruin the play-value of a game with new stuff! Also, keep in mind that there are probably more things to be aware of than what I came up with off the top of my head...
12
Translations / Soldier names
« on: February 09, 2011, 06:36:38 pm »I noticed that in LNG files not presented names/surnames of X-COM soldiers. What about original name generator?
I actually did an experiment with adding my own SoldierNamePool to XcomRuleset at some point and it worked pretty well in conjunction with the existing ones.
However, I don't think it is as much a translation issue as a content issue
Maybe you can make an unofficial unsupported mod for OpenXcom with more names?
13
Translations / Re: Czech translation
« on: January 26, 2011, 11:09:44 pm »SupSuper:
Just wanted to point out one thing. As you may be aware, there are a number of differences between Czech (among other similar languages) and English language, one of which is that Czech language tends to use a number of different words where there is one in English. I noticed it when I spotted that you're using some of the string identifiers in multiple locations in game, such as with VERY HIGH/HIGH/MEDIUM/LOW/VERY LOW describing strength as well as altitude. Unfortunately, if we were to use the same word in Czech it would look unnatural. Example:Quote
In English:
Strength: High
Altitude: High
In Czech:
S
14
Translations / Danish Translation
« on: January 26, 2011, 08:14:25 pm »
I guess I'll be managing the Danish translation then
15
Programming / Re: Ocean colouring - Version 2
« on: December 25, 2010, 04:19:29 pm »but it is only slightly worse than beforeI beg to differ - just updated a bug report with a video
Just saw the video - that is pretty bad.
I have only experienced the right-side error, with gradient lines being spaced apart by strange intervals.
The left-side flickering of dark areas I have not seen before, hence the "only slightly worse than before" comment
I will have to figure out how to replicate it!