Show Posts


Messages - volutar

Pages: [1] 2 3 ... 24
Offtopic / Goodbye
« on: October 08, 2015, 05:06:46 pm »
Just few last words before leaving.

When I found this project, it was late 2010, and it was version 0.1 on SourceForge. Daiky joined a bit earlier and made his battlescape, and started his walking tests, enjoing "ultimate A* pathfinder" (which was kinda bad, frankly speaking, because unit shouldn't be able to route through black "unknown" areas). There were no projectile sprites, and Daiky didn't even know how does it work in vanilla.
UFO: The Two Sides at this point have been using point-sprites instead of projectiles, and it looked really lame. I remember I thought OXC really should be using original looking projectile sprites.

At this point I was on my "active" phase of reversing vanilla exe, figuring lots of the game mechanics, and searching for the good use for what I found.

For OpenXcom there was no any reliable information source on the inners of the vanilla. The only source was Which happen to has really lots of "blind spots" and even misinformation. I start filling these blind spots and correcting
the misinformation, but it was just some bits of info - there was much much more which I didn't put into ufopeadia, just because I stop seeing any reason for that. I thought it would be much more profitable to put this information into actual project, so I started providing OpenXcom with information on vanilla mechanics.
First thing, of course, was projectile sprites, and of course, taken from reversed vanilla.

The "clarification" on title(and "about") pages stated that "The code is completely written from scratch, no reverse-engineering" ;). It was true at that moment of time, but. Later this statement was removed. Because without reliable real reversed source the project most probably would end up with ugly "something" that just only resembles the look of vanilla game (as it was in the beginning). It would end up like lots of other "clones" which barely touches the fame of the vanilla. And I thought, that it would be really shame. And other developers may not agree (so excuse me), but I *actually* took a role of the "accurate vanilla" game designer of OXC. Because was (and is) really poor "map and compass" on many of vanilla aspects.

During this long run I supplied some of OXC contributors with vanilla info.

- SupSuper. Started everything, made ALL of UI things, and the engine "skeleton". Always avoided maths and ingame mechanics programming, like, globe, or battlescape. UI - is just what he's good at. I didn't really provide him with anything important, can recall "nice" great circle flying formula for geoscape and later - dos/adlib music player, which was added just couple of months pre 1.0 release. And what's the good - he continue making fix-commits (mainly gathering community PRs, and some other current fixes).
  Ah yes, he "integrated" radar range circles I made. Cheers, chief.

- Daiky. Started battlescape stage. With the idea "will go my own way" he didn't manage to go too far. I gave him projectile sprites, pathfinding/MCD info, and tried to turn him into more vanilla direction. I think in current codebase there are only few bits of his code left. Mostly it has been rewritten number of times.

- hmaon. The guy who added classic intro sequence video, nice scaler/shaders, and later - some AI logic. I provided him with SFX channel info for intro and some AI concepts from vanilla.

- Karvanit. Added alien missions/flight mechanics, that SupSuper mistakenly called Geoscape "AI". No wonder because there was almost 0 info about that in, and people could have illusion that it actually has AI. No. It's just scripted without any signs of "dynamic difficulty" that Julian Gollop mention.

- l2uriel. With my help and information provided he has implemented dogfights with nice and vanilla looking blob animation and dogfight mechanics itself.

- Warboy. Without him and my help I really doubt the project would hit 1.0 by now or in any close future. I gave him tons on vanilla information, starting from unit sprite drawing, and bunch of fixes of battlescape mechanics (but still PR+committed by Warboy - I never got to use git). He made this project this far as we see it. Map scripting was entirely my idea and concept, and Warboy implemented it quite well (without these "scripting" concepts TFTD support wouldn't happen, because it was initially hardcoded). I actually gave him reversed vanilla sources of XCOM1 and TFTD, and spent hours on explaining of numerous of the vanilla mechanic elements, and function logics. Mission scripting tho is entirely his child, so cudos are entirely his.

All in all it was pretty productive cooperation of Warboy's coding enthusiasm and github access, and my reversing/logic skills, patience and persistence, and of course, the learned vanilla reversed source which I was making and improving from 2010 up to 2014 (including TFTD). But due to his uni stuff, or some elements of laziness, or maybe it's something personal, or both, he rejected number of my offerings (including actual code snippets). I can't get to work with git/PRs, I don't want to get into the situation when my potential huge PRs gonna be "rejected", and obviously I didn't want to start my own project fork like Yankes, with all the "autobuild" and stuff support. (Sidenote: Yankes, you're really stubborn sonovabitch, you're doing freaking great job fighting for your own game engine vision, which I couldn't afford).
So I stop giving Warboy code snippets and fixes, and stop doing anything for OXC at all. Assume that as like I got tired of hitting the wall trying to lobby any progress.

What directly was done by me:
- Radar lines (floating point line draw functions are also used for craft trajectories).
- Adlib music player (working for both xcom1 and tftd).
- First-person look aka "F10" (useful for finding holes and "missing" reason) and full voxel dump with "F11" (for debug only). Started because of "Jade's skyranger hole".
- Terrain damage mechanics and spreading of explosion (considering advanced bigwalls).
- Vanilla-like throw trajectory limitation (for standing and sitting, for the ceil blockage).
- Holeless LOF (covering diagonal jumps found in lots of vanilla crafts and buildings).
- Spacial correct projectile shadow (considering slopes and stuff under).
- Geoscape "astronomically correct" Earth tilt and shade gradients.
- MCD Editor - started as simple MCD viewer after I got into Win7x64, and found that Koralt's version (I used to) doesn't work anymore.
- WORLD.DAT editor - not really worth mentioning, but still.
- Smoother/slower bubble trails are also under my responsibility. With vanilla speed it was too fast and you just can't enjoy the look.
- Projectile "sprites", implemented by Daiky.
- Great circle formula for globe trajectories, implemented by SupSuper.
- Alien mission/trajectories/loadouts, implemented by Karvanit.
- Detailed information on bubble trails, palette, and other stuff from TFTD, implemented by Warboy.
- "Advanced" pathfinding through bigwall proof of concept, later implemented by Warboy.
- Map scripting concept (with proof of viability for both xcom1 and tftd and potentially any other mod), later entirely implemented by Warboy.
- Accurate information on map generation, trajectories, races/ranks/loadouts for TFTD, implemented by Warboy.
- Accurate information on special terror mission spawning for TFTD (which doesn't have anything in common with UFO:EU), also, Warboy.
And lots of other tiny things I don't even remember.

And just gonna list few things that I was working on, some of them were WIP, but some were actually finished but nevertheless they were rejected.

- Smooth globe. - rejected
I've tried couple of different approaches and found the best one. But still, it hasn't been approved. So I guess you'll never see it. A video of it.
- FPS independent window popup animation. - rejected
Really quick and smooth in any CPU/GPU configs. It was just ignored. So if you're unlucky - you know why animation is slow: it's FPS dependent.
- List highlight line misposition bug fix - rejected
- Optimized "over globe polygon" function - rejected
It meant to allow of automatic dogfight window opening after "can't intercept over the land" popup.
- New version of GLOBE.DAT editor.
Was already finished, can load/save trajectories, areas, cities (from yaml ruleset), and visually edit all of them. Just cancelled.
- MCD Editor updates.
The version 1.17i gonna be the final, despite any bugs or anything else.
- Natural targeting.
You know the thing. It's just something that was simply aborted. So get your 50% "obstacle hit" chance even with 110% accuracy aimed shot.

And more of other quality of life things, that were planned (some were even drafted), but actually never gonna happen (like "particle engine" easing flamethrower animation implementation, like multiple projectiles for shotguns, fire/throw preview, and more from here).

I'm really glad that project got to this point, so lots of people could enjoy playing good old XCOM and TFTD. I'm glad that lots of people are making mods of their dreams, using the OXC concept of externalized game assets, and even some of my tools. And I'm glad that some of developers earned lots of cudos and moments of fame.
But personally I feel being exchausted, feel being used, and feel that I didn't really gain anything. I just feel I spent part of my life for almost nothing, which I could spend on something better, like doing my own stuff, and hitting no walls.

So... Goodbye, OpenXcom community.

Playthroughs / Re: Are you sure you wanna fight this?
« on: April 11, 2015, 10:14:55 am »
Please, care about sizes of screenshot and no black areas.

Suggestions / Re: Smarter Civilian AI?
« on: April 08, 2015, 10:37:53 pm »
For not wanting any enhancements, you surely enable an awful lot of them.
They are optional. And they've been made during xcom1 replication. And now it's another story, when no features aside of tftd in mind are added. And the AI thing is too complicated to be "fixed" or modified the way you might expect. AI is easier to re-implement, than to figure out current and refactor. But it's like 6 months of hard work, without any distractions. Really poor chances of that to be done. So better to forget it.

Suggestions / Re: Smarter Civilian AI?
« on: April 08, 2015, 02:43:55 pm »
Even though there already is a number of changes that do not fall under bugfixing, like improved alien AI, which certainly have more impact on the game than civilian behaviour.
There is no "AI enhancement" in OpenXcom. Since there's no way to replicate vanilla by 100% it's just went into something SIMILAR to vanilla. In some respect it might seem "smarter" in other respect - dumb. But it's what it is. Until there are some obvious bugs like stuck, crash, hang,etc, nobody will touch that beast. It's a rabbit hole __noone__ wants to dive into.

I think if OpenXCom was meant to be only a 100% faithful recreation of the original, half of this forum would be pointless. And I don't mean mods.
Frankly, quite a bit of forum messages are pointless indeed (as always  :-\).
Bad thing about that - they are often going over the "trolling" line. Not just trolling each other, but devs as well. Like this turn3 thing, which became a huge raw spot. And by constant annoying about this can simply cause project stop.

Suggestions / Re: Smarter Civilian AI?
« on: April 08, 2015, 01:39:10 pm »
Frankly, following this reasoning, there's no point in the OpenXCom at all.
So leave it.
OpenXcom doesn't want to please all your ideas. It meant to give non bugged and scalable REPLICA of the vanilla. Vanilla gameplay modifying "enhancements" are not really welcome.

You may create your fork, and do whatever you want, or ask Yankes for his "extended" version to spend months of hardwork on this thing (but more changes of the first way).

Suggestions / Re: Smarter Civilian AI?
« on: April 07, 2015, 09:16:03 pm »
There will be no change for civilian AI.

Suggestions / Re: Smarter Civilian AI?
« on: April 07, 2015, 09:42:42 am »
Forget about controlling civilians without using MC. Thankfully they don't turn aliens, as in vanilla, after losing control (because it was a bug).
And surely, as living beings they are recovering from stun. Tho you can add some more stun.
You may want not to have civilians at terror missions at all, like, to make it easier to complete with positive score? You can make a MOD with no civilians.
But this kind of mission meant to cause almost 100% casualities.
Civilians can't control lines of fire. It's simply impossible. Why should they ease your life?

Suggestions / Re: Smarter Civilian AI?
« on: April 07, 2015, 07:44:00 am »
Civilians are panicking, they faced terror and unnatural aliens, they simply can't think "smart" (at least 85% of them). Obviously they act chaotic way.
The most they can do, is to run away from the danger. And I think that kind of behaviour is already there.

If we will make "mapDataSets" list overritable by similar values section INSIDE of particular mapBlock, it could make that happen without even changing map edit (I guess).
Code: [Select]
  - name: DESERT
      - BLANKS
      - DESERT
    script: DESERT
      - name: DESERT00
          - BLANKS
          - DESERT
          - JUNGLE
        width: 10
        length: 10
        groups: [0, 1]
      - name: DESERT01
        width: 10
        length: 10
        groups: [0, 1]
In this case we will have 255 MCD limit per block, not per map. Which is way better, than it is now.

It's pretty feasible, comparing to 16bit map switch, or 8.8bit (mcdsetID.tileID) way. Just for notice - straight 16bit way is worse than 8.8, at least because removing/adding new MCDsets to map would be less destructive, and won't make that much mess.

Tools / Re: MCD Edit by volutar
« on: April 06, 2015, 10:13:23 am »
1.17g uploaded.
PNG spacing/margins (for import/export) and sprites per row (for export) through the Edit->Settings.

Please check it and report if anything wrong.

Tools / Re: MCD Edit by volutar
« on: April 04, 2015, 08:02:16 pm »
davide, first thing, you made your sheets with 1 pixels between neighbours. Sheets used by MCDedit are not using any spaces.
Second thing, you're using RGB with alpha, the format, which haven't been used for sheets before. So it can't import sheets of this RGBA format properly.

I've reuploaded fixed exe.
But as for "pixel space", and number of tiles per row - it's the thing which I believe would require for some "settings" menu. And for now, you have to change your sheets by removing any spaces, and using exact grid 32x40 pixels.

It's definately a subject to resolve.
But only after TFTD.

Tools / Re: MCD Edit by volutar
« on: April 03, 2015, 02:11:42 pm »
Well, theoretically I could make this value (sprites per row) externalized (in the config). I just didn't see important reason for that. Yet.
Hobbes, can you confirm working PCK insert now?

Suggestions / Re: In-game manufacturing profitability view
« on: April 03, 2015, 01:54:55 pm »
I agree, this kind of modification is pretty delicate (just single line), doesn't clutter screen (as initial proposal) and still pretty useful.

Tools / Re: MCD Edit by volutar
« on: April 01, 2015, 07:01:24 am »
1) Is it possible to copy .mcds between tilesets, with all the properties? I'm guessing no, judging from the thread. It would be enormously helpful when moving tiles between tilesets.
You can copy MCDs (number of) into clipboard (they are copied as text), and then paste them into another mcdset, if you want, or even in text file. I guess you didn't read the thread properly. :P
2) How do you pick a colour when editing? Using the colour pick highlights all instances of that colour, but doesn't make it active colour.
Please refer this
In short - either from the palette just with rmb/lmb, or in draw mode with "alt" and rmb/lmb (besides highlighting it also switches to colorpick mode).

Quote from: Hobbes
Just a little thing: Insert PCK doesn't seem to be working
Confirmed. Weird thing. Guess it's some unfinished version, just recompiled and it became fine. Reuploaded.

Pages: [1] 2 3 ... 24