OpenXcom Forum

Contributions => Programming => Topic started by: Daiky on October 14, 2010, 01:37:59 pm

Title: Battlescape development
Post by: Daiky on October 14, 2010, 01:37:59 pm
Some may know already that I have started battlescape development for openxcom. Independently from SupSuper's geoscape development atm, and not (yet) committing into SVN.
You can always ask me on IRC how this is progressing, but I'm not there all the time, so I decided to post my progress here for these curious people. :)

milestone 1 - done
I started with a design, threw the design far away and started coding.

milestone 2 - done
First new class I created is the BattlescapeState. This is where all the action takes place. It divides in 2 main parts, the "_map" part and the "_icons" part. Map, another new class, is an interactice surface which is the viewport to the battle map. Icons... well, the icons :) And then lots of interactive surfaces, one for each button. The abort button stops the battlescapestate. The battlescape state starts when pressing the ufopaedia button on the geoscape. (just for quickly testing the battlescape state of course)

milestone 3 - todo:
- review code of previous milestone
- create SavedBattleGame class (the pointer is held by SavedGame) which  holds a set of Tiles
- using XcomRuleset certain .MAP files are loaded into the set of tiles, (depending on terrain, mapsize, mission,...)
- proper terrain PCKs (tilesheets) are loaded
- the Map is drawn.
- post a screenshot in this thread
Title: Re: Battlescape development
Post by: Daiky on October 15, 2010, 02:08:36 pm
- created new classes:
Tile
SavedBattleGame
BattleRuleset & XcomBattleRuleset
BattleResourcePack & XcomBattleResourcePack

keeping rulesets, resources and game data for battlescape seperate from geoscape stuff did not seem like a bad idea to me, correct me if I'm wrong.
Title: Re: Battlescape development
Post by: michal on October 15, 2010, 02:14:57 pm
I'm not sure if Tile is good name, isn't it to generic? Are you using namespaces? If not, maybe it should be called BattleMapTile? And maybe Map should be called BattleMap?

Anyway, i think that better solution would be using namespaces and folders for splitting classes (i already suggested it to SupSuper).
Title: Re: Battlescape development
Post by: SupSuper on October 16, 2010, 12:33:13 am
IMHO, as long as there aren't any name conflicts, it should be fine. Appending Battle to every class name would get kinda silly, we can look into organization later.

Mind explaining why you're keeping Geoscape and Battlescape stuff separate though? I can see how the saved game data would differ, but the resource pack and ruleset are kinda generic and I wonder if you misinterpreted their purpose.
Title: Re: Battlescape development
Post by: Daiky on October 16, 2010, 12:59:06 pm
I thought you don't need access to any of the battlescape resources (tilesheets) while in geoscape mode + it seemed logical to have them loaded intelligently at battlescape start anyway.
The XcomResourcePack loads everything in the constructor of the class;
so there's two options here, either I create a function in the XcomResourcePack to load battlescape tilesheets (and unload them at the end) or create a seperate resourcepack with tilesheets, sounds for battlescape and delete the resourcepack when battle ends.
I'm not sure bout the rulesets, it could keep the files at a reasonable length, because they may get big.
Title: Re: Battlescape development
Post by: michal on October 16, 2010, 02:33:53 pm
The XcomResourcePack loads everything in the constructor of the class;
so there's two options here, either I create a function in the XcomResourcePack to load battlescape tilesheets (and unload them at the end) or create a seperate resourcepack with tilesheets, sounds for battlescape and delete the resourcepack when battle ends.

Or just load everything at game start and don't care about memory usage. But on the other side maybe it would be better to keep memory usage lower - for some devices with less memory.
Title: Re: Battlescape development
Post by: Daiky on October 16, 2010, 04:23:53 pm
The XcomResourcePack loads everything in the constructor of the class;
so there's two options here, either I create a function in the XcomResourcePack to load battlescape tilesheets (and unload them at the end) or create a seperate resourcepack with tilesheets, sounds for battlescape and delete the resourcepack when battle ends.

Or just load everything at game start and don't care about memory usage. But on the other side maybe it would be better to keep memory usage lower - for some devices with less memory.
To know what we are talking about I just tested it with one single resourcepack loading at startup. Loading 48 extra battlescape PCK (which is terrain+units) files takes up about 12Mb of extra memory. And maybe 1 second of extra loading time my laptop.
So it is not a big deal after all.
Title: Re: Battlescape development
Post by: SupSuper on October 16, 2010, 08:02:57 pm
Well the point of the ResourcePack class is just a convenient place to check and load up all the resources (anything loaded from an X-Com file is considered a "resource") on startup, so the actual states don't need to worry about them, and can just *expect* them to be there. So there's no need for dynamic loading or problems with missing stuff later down the line. Since the game is extremely lightweight (by today's standards), keeping everything loaded is not an issue. It also makes it easier to later on "externalize" this so people can use their own improved graphics, and there's no telling if the Geoscape won't need Battlescape resources later anyways (eg. pre-soldier equipping).

As for the Ruleset, despite the name, it's not intended to keep any "core X-Com logic" like what defines the AI or map generation or anything like that (for now at least). Instead it just contains all the raw game values and stats for crafts, facilities, items, etc (stuff you typically find buried in the X-Com EXE). The UFOpedia will probably need access to all of this. And again, this can be externalized later so people can make their own X-Com "game modes", ala XcomUtil's improved tanks and weapons. I'll explain this better by v0.2.

In short, I'm lazy. :P
Title: Re: Battlescape development
Post by: Daiky on October 17, 2010, 01:49:09 pm
just want to tease you with a screenshot:
(https://2.bp.blogspot.com/_ZFvuqmKo6Yo/TLrR9AXKtGI/AAAAAAAAAFQ/MoNBuSMKzig/s1600/battlescape_teaser.jpg)
still needs some work before I can post a patch...
Title: Re: Battlescape development
Post by: michal on October 17, 2010, 02:24:51 pm
Awesome :) Looks exactly like original Ufo.
Title: Re: Battlescape development
Post by: SupSuper on October 17, 2010, 03:52:55 pm
Great job. :)
Title: Re: Battlescape development
Post by: Daiky on October 18, 2010, 05:10:49 pm
milestone 3 - done:
- review code of previous milestone
- create SavedBattleGame class (the pointer is held by SavedGame) which  holds a set of Tiles
- using XcomRuleset certain .MAP files are loaded into the set of tiles, (depending on terrain, mapsize, mission,...)
- proper terrain PCKs (tilesheets) are loaded
- the Map is drawn.
- post a screenshot in this thread
- implement edge-of-screen scrolling

I created a svn patch file of the current battlescape code, if you like to have a play with/look at it.

milestone 4 - todo
- review code, bugfix milestone 3
- button: show/hide all map layers
- buttons: map level up/down
- draw battlescape "selector" cursor


edit: patch updated, compilation error fixed
Title: Re: Battlescape development
Post by: michal on October 18, 2010, 07:07:03 pm
I've just compiled OpenXcom with this patch under linux, it's nice too see beginning of battlescape, good job :)
Title: Re: Battlescape development
Post by: bramcor on October 18, 2010, 08:16:04 pm
Battlescape works flawlessly on Ubuntu x64!

Only problem was patching, which caused some hunk fails with vcproj file. Compiled with a few warnings in Tile and XcomRuleset, but they seemed to have no effect on running the game.

Chek out the fails and warnings at https://pastebin.com/iqPGcDKc

Screen edge scrolling is a bit choppy and difficult to control but I am sure that is a WIP ;)
Title: Re: Battlescape development
Post by: Daiky on October 21, 2010, 01:22:21 am
milestone 4 - done
- scrolling fixed
- buttons: map level up/down
- draw battlescape "selector" cursor
- loading of 20x20 maps works
- animated tiles works

I have included a openxcom.exe build for windows that includes the battlescape when you press the Ufopaedia button, it starts a 50x50 jungle map.
Also included a screenshot.

And be prepared for the next big milestone....
milestone 5 - todo
- bugfixes
- base defense map generation
- adding an xcom craft on the map (exciting !!! - no soldiers yet... but they will come)
- minimap button/minimap screen
Title: Re: Battlescape development
Post by: michal on October 21, 2010, 12:21:11 pm
Don't forget about patches for non - window users ;)
Title: Re: Battlescape development
Post by: SupSuper on October 21, 2010, 01:38:25 pm
He's waiting on me to finish wrecking the SVN. :P
Title: Re: Battlescape development
Post by: Daiky on October 23, 2010, 04:15:00 pm
SVN is a bit stable. Battlescape builds. Here is the patch file.
Note that it has rightclickdrag scrolling in it atm (will be optional).
Note2: not all terrain mapblocks are defined, only Farm, Jungle and Forest atm. (Default = Forest)
Title: Re: Battlescape development
Post by: michal on October 23, 2010, 05:06:00 pm
Works great :) Edge scrolling is much better now, rmb scrolling is nice to :)

Keep up good work :)
Title: Re: Battlescape development
Post by: Daiky on October 24, 2010, 12:49:05 pm
Some of the biggest inventions were done by accident...

Because of a coding error, the Skyranger is drawn in a wrong tileset, however this is a really nice example of camouflage of the XCom dropship. Especially useful when doing a UFO Ground Assault mission and you want to land really close to the UFO without them noticing and taking off right away.
(see screenshot attached)
Title: Re: Battlescape development
Post by: SupSuper on October 24, 2010, 02:27:42 pm
How do you get out of the ship though? :P
Title: Re: Battlescape development
Post by: michal on October 24, 2010, 05:28:48 pm
You need to equip your soldiers with axe or chainsaw. Chainsaw uses less tus but it's heavier and requires fuel.
Title: Re: Battlescape development
Post by: Daiky on October 25, 2010, 11:34:46 am
small update on milestone 5:
- functional: XCom Craft placement (done)
- functional: Ufo placement (todo)
- functional: Battlescape starts when landing skyranger at a crash site (todo)
- technical: Move MCD struct to TerrainObject class (in progress)
- technical: review variable names to see they all correspond the conventions
 (conventions: a map origin is on the left side, X-axis runs to bottom right, Y-axis runs to upper right, Z-axis represents the layers, a distance on the X-axis is called width, a distance on the Y-axis is called length, a distance on the Z-axis is called height ) (in progress)
- technical: big code review so this patch can be integrated for the first time in the openxcom SVN repository (in progress)
Expecting patch somewhere this week...
Title: Re: Battlescape development
Post by: liamdawe on October 25, 2010, 11:55:02 am
small update on milestone 5:
- XCom Craft placement (done)
- Ufo placement (todo)
- Battlescape starts when landing skyranger at a crash site (todo)
- big code review so this patch can be integrated for the first time in the openxcom SVN repository (in progress)
Expecting patch somewhere this week...


Flipping awesome work, you are the man!

This should make the project a bit more complete, with all the features from this in - 0.2 release of openxcom?
Title: Re: Battlescape development
Post by: michal on October 25, 2010, 01:26:40 pm
Yeah, i guess we will see Daiky's contribution in 0.2 :)
Title: Re: Battlescape development
Post by: liamdawe on October 25, 2010, 01:28:55 pm
Any idea when you plan to release 0.2 at all? Looking like it will be good with the recent text changes and screen res stuff :D
Title: Re: Battlescape development
Post by: michal on October 25, 2010, 01:31:25 pm
I guess it will take some time. SupSuper wants to rewrite / refactor couple of things.

If you want to check latest releases, it would be best to compile from source code.
Title: Re: Battlescape development
Post by: liamdawe on October 26, 2010, 01:41:45 pm
Scales quite well by the looks of it :D
Title: Re: Battlescape development
Post by: Daiky on October 27, 2010, 12:25:07 am
The doors of the UFO are kinda hyperactive, they keep opening and closing by themselves, probably some emergency procedure.(fixed)
Not a trace of any aliens however... the chickens scared away... seeing the skyranger arrive... with no soldiers  8)

The thing that really bothers me atm are the black floortiles in the insides of the UFO... what is different with them that they are not drawn like the others?
Title: Re: Battlescape development
Post by: michal on October 27, 2010, 12:20:10 pm
Isn't those floors drawn at same tile with grass/dirt? Maybe your floor is overdrawn by blackness from grass/dirt tile?
Title: Re: Battlescape development
Post by: NeFuRii on October 27, 2010, 01:50:28 pm
Its some kind of a mask for the half tile.
If you would draw ufo floor and then the wall, you would see that floor outside the ship.
I think it should be: first draw the grass/dirt, then draw the wall, then draw the ufo floor but only on black part of the tile
Title: Re: Battlescape development
Post by: Daiky on October 27, 2010, 02:52:08 pm
@NeFuRii, thanks for the response.
I kinda get it. But why did they not add the half floor directly to the diagonal wall object? Because I notice that the mask is added to the diagonal wall object. And if I have a look at all the UFO models, it is always the same floor that goes with the diagonal wall. And I don't immediatly see any depth sorting issues that could occur...

I think I would fix it by changing the sprites in memory after U_EXT02.PCK is loaded, adding the half floors to the sprites 5 6 and 7.
Title: Re: Battlescape development
Post by: NeFuRii on October 27, 2010, 03:08:55 pm
It has to do with damages probably. For example if you shot the floor of that 'half tile' you need to change the tile for its damaged version.If this was one connected floor-wall tile you would need to make all possible combinations of damaged/undamaged floor and wall. Even worse, if you damage a floor on the higher level you would need to factor in combinations of not having any floor if it gets destroyed.
Title: Re: Battlescape development
Post by: Daiky on October 27, 2010, 03:53:35 pm
speaking of damages... if you shoot the inside half of the tile it should replace it with the damaged version of that tile, if you shoot the outside half of the tile it should replace it with the damaged version of that one. The damaged version is held in the MCD data, However, the game can only hold 1 MCD index for a floor tile... how can it hold the MCD indexes of both "floors"?
Title: Re: Battlescape development
Post by: NeFuRii on October 27, 2010, 08:21:31 pm
I'm not familiar with ufo's file types.  No idea how its stored.
Title: Re: Battlescape development
Post by: Daiky on October 29, 2010, 12:48:15 am
as promised a patch this week for milestone 5:
- functional: XCom Craft placement (done)
- functional: Ufo placement (done)
- functional: Battlescape starts when landing skyranger at a crash site (done)
- technical: Move MCD struct to TerrainObject class (somewhat done)
- technical: review variable names to see they all correspond the conventions (done, I hope)
 (conventions: a map origin is on the left side, X-axis runs to bottom right, Y-axis runs to upper right, Z-axis represents the layers, a distance on the X-axis is called width, a distance on the Y-axis is called length, a distance on the Z-axis is called height ) (done)
- technical: big code review so this patch can be integrated for the first time in the openxcom SVN repository (somewhat done)

there is still a little issue with diagonal ufo walls, the floor is not blitted correctly (it's not using the black mask, got to find out how to use masks with the SDL blit).

So, SupSuper, as for me this patch can go in SVN. I don't know what you think.
Anyway, I keep implementing battlescape stuff:
milestone 6:
- load waypoints/spawnpoints
- add units /soldiers

Title: Re: Battlescape development
Post by: bramcor on October 29, 2010, 01:35:52 am
Great job with the patch Daiky! It is great to have a use for that Skyranger ;)

From what I can tell, your terrain detection is spot on. I tried out farm, forest, jungle, desert, mountains and polar. All of them corresponded to the correct globe surfaces.

Only thing that caught my eye was a few warnings during compilation. I pasted them here: https://pastebin.com/rNjy5jbK
Title: Re: Battlescape development
Post by: Daiky on October 29, 2010, 11:47:31 pm
THE MISTERY OF THE DIAGONAL WALL / FLOOR TILE SOLVED :)
I opened up the good old map editor, and behold.... the floortile next to the diagonal wall tile has a small part attached which is a half floor tile.

The reason why it showed black is, that I was drawing all floor tiles first, and then the rest. Which is maybe not a good idea I see now.
Title: Re: Battlescape development
Post by: NeFuRii on October 30, 2010, 02:55:25 pm
Interesting :).
But how does it work? There are no such tiles in the U_EXT02.PCK, so it can't be a single tile. It still seems to be some kind of graphics manipulation on the fly done by the engine. Or is it stored in some other file? I haven't seen it anywhere.
Title: Re: Battlescape development
Post by: Daiky on October 30, 2010, 02:59:58 pm
those special tiles are in U_BITS.PCK
Title: Re: Battlescape development
Post by: SupSuper on October 31, 2010, 03:21:00 pm
Daiky has earned SVN access, so there's no more need for constantly creating/adding patches. Hopefully he won't go mad with power. ;)
Title: Re: Battlescape development
Post by: Daiky on November 01, 2010, 12:57:29 pm
If you just heard a loud bang, don't be afraid, it was just me committing the battlescape code into the openxcom repository :o
Title: Re: Battlescape development
Post by: SupSuper on November 01, 2010, 10:18:30 pm
THE HORROR! :P
Title: Re: Battlescape development
Post by: liamdawe on November 02, 2010, 01:01:34 am
Can't wait to see the .2 release with all of this included :D
Title: Re: Battlescape development
Post by: Daiky on November 02, 2010, 07:10:23 pm
I committed a cleanup, and renamed some of the classes, so they are clearer what they do.
Title: Re: Battlescape development
Post by: Daiky on November 07, 2010, 06:51:38 pm
I'm happy to anounce first visible results of the unit drawing code I have been working on lately.
As you can see, it is currently only drawing the heads of the soldiers.
The drawing routine works 100% on a rule-based parameters system, so it's as flexible as it gets, nothing hardcoded. This means in the future easy implementation of other units, or more advanced unit animation, etc without code changes.
The downside is, for every unit you have currently 63 parameters to configure, which can become even more later on.

Other stuff I have been working on:
- reading of RMP files = spawnpoints of aliens on the map, and later on for AI pathfinding
- moved MAP and RMP file loading to ResourcePack
- Soldiers are positioned on the proper tiles inside the skyranger
and in between I'll get that soldier summary panel on the bottom look right.
Title: Re: Battlescape development
Post by: Daiky on November 14, 2010, 01:44:25 pm
Rene: "I can't believe X-Com send us out here without any equipment at all... a scouting mission they said. But what if there is really some alien activity over here?"
Sarah: "Well, then I run as fast as I can back to the Skyranger. By the way, I'm catching a cold walking around on this ice and snow."
Rene: "Come over here, let me warm you up."

revision 206 to play with basic pathfinding
Title: Re: Battlescape development
Post by: Daiky on November 19, 2010, 07:26:57 pm
I'd like to announce that battlescape milestone 6 has been reached.
- XCom soldiers inside the skyranger spawn on the battlescape
- Soldiers can be selected either clicking them or with the "next soldier" button, selection is indicated with yellow arrow.
- Basic soldier stats are shown in the small info area
- Pathfinding is implemented: soldiers walk around avoiding obstacles (most of the time :p)
- Right click - look at functionality.
- Center-on-soldier button.

Milestone 7: (todo)
- Fix pathfinding bugs.
- Add battlescape sounds.
- Add laser rifles.
- Add floaters to test your laser rifles on.
Title: Re: Battlescape development
Post by: pmprog on November 19, 2010, 11:55:38 pm
Wow, you've seriously put some effort into this! Makes me feel like I've been away too long.
Title: Re: Battlescape development
Post by: liamdawe on November 21, 2010, 04:24:51 pm
Some fantastic work going on and i sure do appreciate it, cannot wait to fire it up on Linux and play it natively when this is all done :D
Title: Re: Battlescape development
Post by: Daiky on November 22, 2010, 12:06:45 am
Thanks, I'm happy to contribute to the project.
Title: Re: Battlescape development
Post by: liamdawe on December 02, 2010, 01:47:27 pm
How's the work going? :)
Title: Re: Battlescape development
Post by: Daiky on December 02, 2010, 10:51:00 pm
Okay, little slower lately due to other projects, social activities and sickness. But this weekend is totally empty, so expect an update on sunday evening :) Either involving items in the battlescape or sounds in the battlescape - don't know which one yet  ;)
Title: Re: Battlescape development
Post by: Daiky on December 03, 2010, 01:08:20 pm
BTW, I still found a terrain render bug...  I can't believe no tester has reported it yet :)
Title: Re: Battlescape development
Post by: bramcor on December 03, 2010, 02:25:35 pm
I have a backlog of battlescape bugs that I just haven't gotten around to posting yet .. been a bit busy lately, you see ;)

I have also observed the rendering problem for corners where wooden fences meet! Which make me think that it is likely to be the same for all other tiles that meet in a corner in the same manner (walls in houses, hedges and whatnot)
Title: Re: Battlescape development
Post by: Daiky on December 07, 2010, 09:12:52 pm
I thought I just commit the stuff I have at the moment.
So rev.219:

- added Soldier footstep sounds
(- added BattleItem class )
- fixed automatic view level position when walking
- fixed rendering issue of two walls in a corner
Title: Re: Battlescape development
Post by: liamdawe on December 10, 2010, 01:22:09 pm
As always I appreciate the work you are doing, please keep it coming :D

I will get around to some testing over the festive period :)
Title: Re: Battlescape development
Post by: Daiky on December 15, 2010, 04:53:49 pm
just an update for the latest stuff I've been working on:
- bug in pathfinding when walking down the stairs in a barn is fixed
- added the feature where you click behind the stairs to go up the stairs to the next level (reported by bramcor)
- added opening doors feature + ufo door animation + their sounds
- under-the-hood change: The BattleSoldier class (which was a descendant of BattleUnit) is going to be removed and the BattleUnit class gets a "faction" attribute (player,hostile,neutral). This makes more sense, especially when things like mind control (should be as easy as setting the faction attribute to another value) are coming into play.

I see you already thinking: hey, what happens if you start a battlescape mission with all aliens set to faction "player" and all xcom soldiers set to faction "hostile"? Yeah, then you can play the aliens side.
And yes, there is also an (un-used, un-implemented) faction "friendly", which are non playable characters that will attack hostile units :p (I'm thinking of civilians that pick up a shotgun and try to defend their home from aliens).

edit: more under-the-hood battlescape changes (if anyone is interested in this, I don't know :p). Procedures like map generation and placement of units in the SavedBattleGame class are moved to a new utility class BattlescapeGenerator.
Title: Re: Battlescape development
Post by: Daiky on December 17, 2010, 04:34:36 pm
First aliens sighted in openXcom !

I have done a commit. But for people who are not compiling themselves, I have uploaded a little video:
https://www.youtube.com/watch?v=Spn3DbrrEKE
Title: Re: Battlescape development
Post by: SupSuper on December 17, 2010, 06:12:35 pm
Yay, more frontpage material! :D
Title: Re: Battlescape development
Post by: Daiky on December 17, 2010, 10:24:09 pm
Since the Items section is undergoing a major overhaul in release 0.3, I wanted to wait to implement items/weapons in battlescape as well.
So I have put some less exciting stuff on my todo list for the coming weeks:
- battlescape lighting (night missions yay!)
- fog of war (the excitement of not knowing what to expect at every step...)
(not necessarily in that order)
Title: Re: Battlescape development
Post by: Daiky on December 19, 2010, 11:15:35 pm
Not a very exciting feature that I implemented today, probably nobody ever notices it, but nevertheless: I call it "sun shading". This is the shade under the skyranger, inside buildings, inside ufo's,...
Title: Re: Battlescape development
Post by: Daiky on December 21, 2010, 01:22:53 am
Very first try at soldier personal light. Still needs lots of work.
Title: Re: Battlescape development
Post by: michal on December 21, 2010, 08:33:32 am
You're fast :) Good work :) Looks great  ;D
Title: Re: Battlescape development
Post by: Daiky on December 21, 2010, 12:35:17 pm
Well, it depends what you call fast :) The lighting code up until now is maybe just 40 lines, but it took me about 10 hours to write. I have implemented these features before already in my own project, some concepts are carried over from there.
BUT.... and here it comes... in my project the minimum requirement was hardware acceleration (OpenGL or DirectX driven).
It is unplayable without hardware acceleration, because of how I handled the tile drawing. I pumped all sprites into the GPU as textured polygons. The GPU can render tiles this way very fast, including applying shaders to the textures while drawing them.

But in OpenXcom there is no HW acceleration. (...yet. But not let us start the discussion here :p)
I did a first try implementing it like I was used to. But no go: less than 5fps... I had to rethink the whole concept.

The issue was in the fact I had to create a temporary copy of the original sprite, this means creating/allocating a new Surface object and then applying the shading to every one of it pixels, and then blit it. This whole process takes up to 2 milliseconds, which is forever in the world of graphics rendering. That's only 500 sprites per second. Before shading I could blit about 100.000 sprites per second. And as a reference: old/slow GPUs could already shade and blit 10 million sprites per second. FYI the current battlescape viewport contains 400 sprites on average.

So I had to take out the shading process out of the drawing loop. This is from gameplay standpoint no issue, because the shading only changes every now and then. At the start of the battlescape I copy every tile to a "cache". If the shading of a tile changes, I update the cache with the correct shading of the tile. The shading update is done asap for tiles within the viewport and a little later for tiles outside the viewport. In the drawing loop I just blit the cached/pre-shaded tiles.
Title: Re: Battlescape development
Post by: Daiky on December 22, 2010, 06:30:37 pm
Interesting to see the Japanese gaming website seems to follow the progress, they even promoted the donation.
https://translate.google.be/translate?js=n&prev=_t&hl=nl&ie=UTF-8&layout=2&eotf=1&sl=ja&tl=en&u=http%3A%2F%2Fwww.game-damashi.com%2Fdatabase%2F%3Fp%3D7382&act=url
Title: Re: Battlescape development
Post by: Daiky on December 25, 2010, 05:18:21 pm
I made a little christmas present for the fans:
Wiiiii another videoooo :)
https://www.youtube.com/watch?v=t2ME1IhWFLk
Title: Re: Battlescape development
Post by: Daiky on December 30, 2010, 02:44:13 pm
You can play with lighting too now, if you update your SVN build. Or wait until v0.2.
SVN 227:
- Basic per-tile-lighting implemented. Lighting/shade is depending on the landing site.
- Basic fog-of-war implemented.
- Caching of tiles and units implemented. This was needed for faster shading, despite some increase of RAM usage.
- Added terror site map rules.

I'm going to party some, and then go on holiday, so it might be quiet for a few weeksdays.
Title: Re: Battlescape development
Post by: michal on January 04, 2011, 08:56:17 am
If you want to try latest battlescape stuff and can't compile openxcom by yourself, you can download svn builds for windows. More details here:

https://openxcom.ninex.info/forum/index.php?topic=140.0
Title: Re: Battlescape development
Post by: liamdawe on January 08, 2011, 01:58:01 pm
Loving the active development here, hope you had a good new year, seems we are getting close to a really playable release now :D
Title: Re: Battlescape development
Post by: Yankes on January 10, 2011, 02:15:07 am
Daiky i think that is small bug in battlescape, in mission during night source of light under solder is too big. its made 4 squares bright not only one under solder.
Title: Re: Battlescape development
Post by: Daiky on January 10, 2011, 02:56:59 pm
Daiky i think that is small bug in battlescape, in mission during night source of light under solder is too big. its made 4 squares bright not only one under solder.
Hi Yankes,
I have seen this problem too, it's some kind of rounding error. Problem is the tile coordinates have a very low resolution (if you see every tile as a pixel with it's own brightness) and this easely causes this kind of rounding errors.
Title: Re: Battlescape development
Post by: Daiky on January 18, 2011, 12:28:03 pm
Just an update on what is happening on battlescape development these days.
- First of all the battlescape savegame is on it's way. Yaml-cpp hasn't yet all the base64 encoded binary reading/writing functions in place, so currently I will work with my own base64 encoding functions.

Why binary? Well, the map file will be huge otherwise, so I try to make it as compact as possible.
It is made up by 3 bytes per object, 1 byte for the datafile the object is in, 2 bytes for the index in the datafile.
A tile has 4 object on it, so 12 bytes per tile.
- Empty tiles are saved as a 0xFF byte followed by a two byte number indicating how many empties.
- Fog of war is stored as a bitmap with 0 or 1 when a tile is discovered(1) or not(0). This bitmap is also base64 encoded.
- Lighting level per tile is not stored but calculated.
- Smoke and fire is not yet implemented. But these will probably be stored as a list.

- Secondly, I discovered a spot in my design that really needed refactoring. I don't know what I was thinking when I initially did it this way.
Currently we have the following classes:

Resource/TerrainObject
Resource/TerrainObjectSet
Ruleset/MapDataFile

But a terrainobjectset and mapdatafile are actually the same thing (both refer to the .MCD file).
So I decided to merge them both into MapDataFile, and remove TerrainObjectSet.
And TerrainObject will be moved from the Resource map to the Ruleset map and renamed to MapData.
The set of MapData is then MapDataSet, following the syntax of Surface/SurfaceSet
So after refactoring we have:

Ruleset/MapDataSet
Ruleset/MapData

- Thirdly, lighting implemented like in the original game (light not blocked by objects). With the option to switch back to the solution I made.
Title: Re: Battlescape development
Post by: Daiky on January 22, 2011, 07:48:04 pm
Daiky i think that is small bug in battlescape, in mission during night source of light under solder is too big. its made 4 squares bright not only one under solder.
It's fixed now.
Title: Re: Battlescape development
Post by: Daiky on January 30, 2011, 04:51:02 pm
This is how the night mission now looks at the start. The battlescape terrain is not completly blocking light, but also it isn't completly "transparent".
Title: Re: Battlescape development
Post by: SupSuper on January 30, 2011, 05:39:22 pm
Looks better, although there's still the whole "uneven light shades" on the front of the craft, probably because the light stops at the front wall but the rest of the tile is still lighted, since tiles are lighted equally all over (this isn't as noticeable on typical walls). If you can't smooth it out, you could probably just add some light sources to the craft.

Another thing I noticed is units can't move behind the back walls of a UFO, though I don't remember if this also happened in the original or not.
Title: Re: Battlescape development
Post by: Daiky on January 30, 2011, 06:44:18 pm
it would surprise me if you could move behind the back bits of a ufo wall in the original, because those walls are no walls, they are objects that are not walkable.


and the uneven shades at the front of the plane is again the data that is doing this :) each one of those objects have a light block value of 10. I now divide it by 2 already, so they have a light block value of 5.
There is 4 tiles between the front wall and the closest soldier. So the light hits the first object in the front wall with a power of 11 (15-4). The first object is nicely lit. Then it substracts 5, the second object is lit with a power of 6. Almost half as dark. And the nose of the plan only gets 1. Almost black.

The way I see it, if this specific issue is only present in the skyranger nose, it is kinda silly to code a special routine just for the skyranger nose... The data (in PLANE.MCD) can be modified to fix the issue. Remember that this lightblock data was added, but never used in game and therefore maybe not tested.

Below a screenshot with a fixed PLANE.MCD (I cheated : if (_name == "PLANE")   mcd.Light_Block = 0;) :p

Any suggestions? :)
Title: Re: Battlescape development
Post by: Daiky on February 01, 2011, 05:00:52 pm
I decided to drop the light blocking idea for now, and do it like it was in the original x-com. I need to focus back on more gameplay stuff getting implemeted.
Title: Re: Battlescape development
Post by: Daiky on February 02, 2011, 11:34:50 pm
SVN r265:
- fixed walking animation.
- lighting and vision calculation reworked.
- right-click aborts walking.
- first unit is now selected at start instead of last one.
- units are properly shaded and properly cached.
Title: Re: Battlescape development
Post by: liamdawe on February 06, 2011, 12:26:46 pm
Still lurking watching your progress man, grand work!
Title: Re: Battlescape development
Post by: Daiky on February 11, 2011, 10:07:15 am
Thanks!  :D
I hope to post a new video soon.
Featuring: Explosions, Fire and Smoke...  :o
Title: Re: Battlescape development
Post by: michal on February 11, 2011, 10:19:45 am
And i will make new svn ( git? ;) ) build for windows, when you will commit your new stuff ;)
Title: Re: Battlescape development
Post by: Daiky on February 11, 2011, 01:28:10 pm
Isn't it when I "push" my new stuff? :) gah... it will take a while to get use to git, after using CVS and SVN for 10 years :) And I still have to use CVS/SVN at work, so I can not just forget all about it :p I'll start posting diff files on the forum again :p
Title: Re: Battlescape development
Post by: michal on February 11, 2011, 01:47:51 pm
But look at other side - instead of knowing two version control systems, you will know three ;)
Title: Re: Battlescape development
Post by: Zyxpsilon on February 11, 2011, 06:28:06 pm
Hey Daiky... like i said -- i'm now IN!
Graphics in HD has been officially revived from its basic roots.
I sure do hope we'll get some stuff made from whatever everyone already has.
Title: Re: Battlescape development
Post by: Daiky on February 14, 2011, 12:47:53 pm
Hi Zyxpsilon, I see it that you are "IN", but -like I said already a few times- I'm not IN (think that's the first time I use bold or underline) :) at least not while I'm working on the battlescape (which is what this thread is about btw).

So about battlescape:
- items in soldiers hands displayed on the information pane
- items in soldiers hands displayed on the unit
- items on the ground displayed

is what I'm working on.

EDIT: to make it clear: I'm talking about coding, not the graphics , the original X-Com graphics are used to play OpenXCom.  ;)
Title: Re: Battlescape development
Post by: michal on February 14, 2011, 01:40:40 pm
- items in soldiers hands displayed on the unit

You probably again will have lot of "fun" with proper drawing of weapons / hands for various units ;)
Title: Re: Battlescape development
Post by: Daiky on February 15, 2011, 12:31:44 am
Don't try this at home kids. Dry hay is flammable!
Title: Re: Battlescape development
Post by: michal on February 15, 2011, 08:56:27 am
Yeah, burn those crops !

Btw, does fire emit light? Did it in original?
Title: Re: Battlescape development
Post by: Daiky on February 15, 2011, 10:39:22 am
Btw, does fire emit light? Did it in original?
Shame on you michal, you call yourself an x-com fan?  ;)
Instead of flares it was sometimes better to take an auto-cannon with incendiary rounds with you on a night mission, especially on terrains like jungle or farm it could be used to both light up areas and burn down cover at the same time.
Title: Re: Battlescape development
Post by: michal on February 15, 2011, 10:42:53 am
Heh, i probably played last time more than 5 years ago :P Even then i wasn't using incendiary rounds :P Don't know why, probably prefered explosions over fire ;)

Anyway it's good to know, i will probably try such "napalm" tactics in jungles when openxcom will be playable ;)
Title: Re: Battlescape development
Post by: Daiky on February 17, 2011, 10:38:56 am
oe oe oe ! A new git build: https://openxcom.ninex.info/git_builds/
Featuring: nothing very impressive really...

The crew on your skyranger gets a few test-items pushed in their hands. And if you click the item you get a cross-hairs cursor to aim :) And if you right-click you cancel the action.
They are not allowed to shoot - just yet :)
Title: Re: Battlescape development
Post by: michal on February 17, 2011, 11:03:23 am
But still, it's step towards killing those bastards sectoids. Our soldiers now have weapons, now they need to learn how to use them :)
Title: Re: Battlescape development
Post by: Yankes on February 18, 2011, 11:28:54 am
oe oe oe ! A new git build: https://openxcom.ninex.info/git_builds/
Featuring: nothing very impressive really...

The crew on your skyranger gets a few test-items pushed in their hands. And if you click the item you get a cross-hairs cursor to aim :) And if you right-click you cancel the action.
They are not allowed to shoot - just yet :)
2011_02_16_2218 version from that link is buged, in misions everything is black. (no light)
Title: Re: Battlescape development
Post by: michal on February 18, 2011, 11:45:07 am
What about openxcom_git_master_2011_02_15_1919 ? Is it working fine?

Edit:

2011_02_16_2218 works for me.
Title: Re: Battlescape development
Post by: Daiky on February 18, 2011, 06:49:16 pm
Could you please give more info when you report a bug, like a screenshot in this case and system you are working on, and also report it in the bug report board? Thanks.
Title: Re: Battlescape development
Post by: Yankes on February 18, 2011, 08:00:44 pm
Could you please give more info when you report a bug, like a screenshot in this case and system you are working on, and also report it in the bug report board? Thanks.
WinXP sp3
some screenshots: https://www.mediafire.com/?p7bx53qa59b3a81
usually day missions have this
Title: Re: Battlescape development
Post by: Daiky on February 19, 2011, 11:02:13 am
hmm, that's very strange stuff, could be a memory issue of some sort, I've never seen it or had a similar report of this before.  ???
I'll guess I'm going to do some code reading to see if there could be possible errors that can cause this.
Title: Re: Battlescape development
Post by: Daiky on February 20, 2011, 10:50:46 pm
meanwhile... I finally got the one-handed and two-handed weapons drawn all right on the soldiers.

Jane looks kinda excited with this big fucking gun in her hands.
Title: Re: Battlescape development
Post by: panther on February 22, 2011, 05:51:22 pm
I love meanwhiles :)
Reminds me of other old classic games too...  ;D
Title: Re: Battlescape development
Post by: Daiky on February 23, 2011, 12:00:57 am
And the first PEW PEW!
Title: Re: Battlescape development
Post by: Volutar on February 23, 2011, 07:18:18 am
Daiky, nice!
But you've got distance of 4 between each projectile particles (when shooting right or left), while there should be 1 (which is 0.5 in terms of loft voxels). I hope you'll fix that shortly and show us real projectiles (of different kind) going from weapon level  :)
If you recall how laser projectile looks - you might notice it looks continuous, without single break.
Title: Re: Battlescape development
Post by: Daiky on February 23, 2011, 10:22:51 am
yeah, I had the particles seperated too much at some point, on purpose, don't recall why I did that, but I have to change that back. :)
btw Volutar, Do you have any idea which bullet trail belongs to which weapons. Also any idea on the correct starting voxel of the bullet? (I guess it depends on stuff like kneeling/direction of looking).

While the looks are there, I got still a lot of work ahead of me:
- Got to finally implement the kneeling button.
- Adjust the bullet starting voxel depending on the stance.
- Line of fire collision detection !!!
- Determination of the target voxel.
- Applying firing accuracy.
- Different bullet sprites.
- Correct z-order of the bullet sprite.
- Bullet shadow.
- The impact damage.
- The impact visual effect.
- Sound effects.
Title: Re: Battlescape development
Post by: Volutar on February 23, 2011, 11:10:29 am
btw Volutar, Do you have any idea which bullet trail belongs to which weapons.
Of course. There is a table with info such as bullet sprite, fire sound id, hit sound id and hit animation type. For each weapon.

Quote
Also any idea on the correct starting voxel of the bullet? (I guess it depends on stuff like kneeling/direction of looking).
Height of unit (table data), kneeling height (table data), current elevation (according tile height unit standing, also table data) used in calculating Z position of fire origin MINUS hardcoded level of chest (I don't remember exact number - it doesn't matter really). X and Y coordinates in voxel space taken from 2 tables (depends on small or large unit) which contain X and Y offsets for each direction.
By the way this calculated "origin" point also used for sight calculation for EVERY unit.
All this info is in https://ufopaedia.org (at least on discussion pages).
Title: Re: Battlescape development
Post by: Daiky on February 23, 2011, 12:25:52 pm
Yeah, the ufopaedia has lots of info. But if it is on the discussion page I think you should double-check every bit of it. Because I have found errors on it too.

For example, there is in the discussion on Line of sight: "Line of Sight takes into account the sighting unit's elevation. Line of Fire doesn't take into account the firing unit's elevation. The dune I was standing on, was blocking my line of fire. [No comment about the target's elevation.]"

This may not be tested very well, or it may be a bug only appearing on certain types of objects (dunes or mountains are sometimes a bit odd).

By the way this calculated "origin" point also used for sight calculation for EVERY unit.
All this info is in https://ufopaedia.org (at least on discussion pages).

on loftemps.dat : "A soldier's head is positioned slightly higher then the barrel of his gun. For this reason, it is possible for him to be able to see an alien (that is, he has a valid "line of sight"), but not shoot it (because he has a blocked "line of fire")."
Title: Re: Battlescape development
Post by: Volutar on February 23, 2011, 04:55:44 pm
Unit elevation should be taken into account when checking LoS or LoF. I really haven't payed attention on what's the difference between originate coordinate setu pfor fire and for sight. It's not a problem of any kind and we really don't care how they did it. We should make it more "bugless" so to speak. And elevation should be taken into account for LoF and for LoS. There is some difficulty with LoS estimation for tiles on other levels (like visible roof of UFO) and we have to make some observations on how it works in original UFO.

Excuse me SupSuper, but here is screenshot of different "bullet" sprites. 11 visual types of it in original UFO, but we can expand it a little, with heavy plasma and plasma pistol longer or shorter trail, and so on.

/firesound / hitsound / hitanimation / weapon
 4 22 1 pistol
 4 22 1 rifle
12 13 1  heavy-cannon
12 13 1 auto-cannon
52 --  - rocket launcher
11 19 2 laser pistol
11 19 2 laser gun
11 19 2 heavy laser
36 --  - psi-amp
18 19 3 heavy plasma
18 19 3 plasma rifle
18 19 3 plasma pistol
53 -- 3 blaster launcher
53 -- -  small launcher
Title: Re: Battlescape development
Post by: Daiky on February 25, 2011, 02:19:43 pm
In case people are trying the daily build, there currently is a bug in the colission detection or the loaded LOFTEMPS data...

edit-
For info:
I made the decision not to have the different LOFTEMP "slices" as different objects in the game engine, but to have a complete 16x16x24 voxel object as an object. So a voxel object (MapModel class) is created with 12 loftemp "slices" and then stored as a 3D model.
Each map object points to it's corresponding model. When loading a terrain a set of unique voxel models in that terrain is compiled. (I used a checksum/hash calculation on voxel data to easely compare voxel models)
As a result a terrain with 100 objects can have 20 models, because a model can be re-used for different objects.

The reason for this is not only because it's easier to work with complete models, but also that the loftemps slices method could -for some objects- be replaced with other, more detailed and complex, complete 16x16x24 models (or bigger). And then I'm especially thinking of units.
But for that a voxel model editor could come in handy :)
Title: Re: Battlescape development
Post by: Volutar on February 25, 2011, 04:35:12 pm
I wonder how are you going to store these voxel objects, either stacked bitmaps or as simple 3d array?
For 16x16x24 3d array will consume 6k of RAM, and stacked bmp will be only 768 bytes.
Considering low-memory ports like for Dingoo I really don't know how good that will be.

If you're hashing whole 3d voxel objects, why don't you hash each layer, for "optimizing" overall 3d object size for mapset?

I admit using solid 3d voxel objects is good idea, if we're aiming for more distinct 3d object representation and doubling resolution, but doubled resolution will be 8x of 3d size! 32x32x48 will be 48kbytes for each object as 3d array. And if there will be 256 of them - it will be 12mbytes!!! Stacked bitmaps will be 6k for single object and 1.5 mbytes for 256 objects.
If you'll make indexed LOFT links for 32x32x48 object (48 integers), it will be 192 bytes long and 48k for array of 256 objects, plus layer data (like original xcom has).

I think dynamically "built" LOFT objects from complete voxel objects (which will be stored in "new" object MCD) will be noticable less memory-consuming by cost of slight delay (probably couple of ms) at battlescape loading for dynamic LOFT table building and voxel objects compressing.
Title: Re: Battlescape development
Post by: Volutar on February 26, 2011, 04:43:39 pm
Top (on sand background) is original xcom. You can see trail is slightly longer, and there is THREE dots at the end, while BOTTOM is latest (Git build 2337) and there is only TWO dots. Also there is strange white dot in "fire" particle. I think you should recheck your data.
Bullet trail looks weird, like being teleporting throu some distance or dropping some of trail particles time to time.
Title: Re: Battlescape development
Post by: Daiky on February 28, 2011, 01:08:38 am
Could you please give more info when you report a bug, like a screenshot in this case and system you are working on, and also report it in the bug report board? Thanks.
WinXP sp3
some screenshots: https://www.mediafire.com/?p7bx53qa59b3a81
usually day missions have this
Hi Yankes, I have located & fixed this bug. So if you take the latest build from the git builds page, you should not see this random black-tiles effect anymore.
Title: Re: Battlescape development
Post by: Daiky on March 01, 2011, 11:03:55 am
Hurray, I can striketrough some of my points.
- Got to finally implement the kneeling button.
- Adjust the bullet starting voxel depending on the stance.
- Line of fire collision detection !!!
- Determination of the target voxel.
- Applying firing accuracy.
- Different bullet sprites.
- Correct z-order of the bullet sprite.
- Bullet shadow.
- The impact damage.
- The impact visual effect.
- Sound effects.

Next thing to do is the impact damage, which is a rather essential part of shooting. You aint gonna kill alien bastards with blanks :)
Title: Re: Battlescape development
Post by: michal on March 01, 2011, 11:50:39 am
Am i the only one to think that openxcom development accelerated recently? :) There are many new features in battlescape, also geoscape isn't worse (purchase, transfers) :)

If such rate will be maintaned i fell that openxcom will be playable (maybe not finished, but playable) in this year :D
Title: Re: Battlescape development
Post by: SupSuper on March 01, 2011, 12:05:55 pm
Am i the only one to think that openxcom development accelerated recently? :) There are many new features in battlescape, also geoscape isn't worse (purchase, transfers) :)

If such rate will be maintaned i fell that openxcom will be playable (maybe not finished, but playable) in this year :D
AI will probably be the hardest feature, everything else is pretty direct. :)
Title: Re: Battlescape development
Post by: michal on March 01, 2011, 12:09:49 pm
Yeah, but even most stupid ai can give game a bit of playability and enjoyment ;)

For now, project is more a tech demo than actual game. When we will be able to finish mission (or die) it will became a game ;)
Title: Re: Battlescape development
Post by: SupSuper on March 01, 2011, 02:05:57 pm
Yeah, but even most stupid ai can give game a bit of playability and enjoyment ;)

For now, project is more a tech demo than actual game. When we will be able to finish mission (or die) it will became a game ;)
Don't be silly, there is no finishing in X-Com, only death. :P
Title: Re: Battlescape development
Post by: Daiky on March 01, 2011, 02:23:39 pm
I'm spending most of my free time on openxcom lately :) It's getting addictive.

Very simple AI can give pleasing results. Same as very complex AI can look stupid :) It's all about perception of the player.
You have two levels of AI: the group level and the unit level. And on these two levels you have a finite state machine.
The group levels on the geoscape seem to be zones on the world: "The North-Africa Group", and they are in state's we all know as "Harvest", "Abduction", "Terror" etc.
The unit levels on the geoscape are the UFO's. The are in state "exploring", "chasing", "fleeing", "going towards a base", "shot down".
The group level on the battlescape is just "aliens"... and sometimes "civilians". Depending on the mission the are in certain state: "attack civilians" or "explore" or "attack xcom" or "retreat".
The unit levels are the aliens, and have states "exploring", "chasing", "fleeing", "dead"....
The units each make decisions to stay in their current state or change state depending on all the input they get from "the world", some scripted stuff, some random stuff....
You could implement it like you did the game states. Each state it's own object.

One thing that I have read in some gamedev book, is that when a units changes state, it is interesting to show this as some kind of emotion to the player, and not just by it's behaviour. This really makes your units look intelligent. An example of this is, when a unit sees you and enters the "aggro-state", it screams. Or if it hears something, it turns it's head towards it... things like that.
Title: Re: Battlescape development
Post by: Daiky on March 01, 2011, 03:23:25 pm
Once you have all this nicely put into objects, you can make crazy combinations like:
After a civilian gets killed by an x-com soldier: set the "civilian group" into state "attack x-com".
And give civilians a melee attack with power 1 :p
"Hey wtf? Stop hitting me! We are on your side!"
Title: Re: Battlescape development
Post by: Daiky on March 01, 2011, 11:49:12 pm
More good news!

Latest build: projectiles now affect terrain !

To play with I have given the first 3 units of the skyranger a heavy cannon, one with armor piercing ammo, one with heavy explosive and one with incendiary ammo.
Have fun!
Note that the AP ammo does not check object armor versus power - it has like unlimited power.
Also note that damage versus units is not yet implemented.

Weapons of mass destruction:
Title: Re: Battlescape development
Post by: Volutar on March 02, 2011, 09:34:00 am
There is two minor fixes you should consider (1st if yours, and 2 is probably SupSuper's).

1) Energy numbers are slightly in wrong place, and should be shifted 1 pixel right.

2) There are two different modes for text drawing functions. Mode A - ordinary colored letters, when every font pixel value just added to font color - *screen=color+letter_val. And mode B (which is used for BattleScape) - when every font pixel value added with x3 value (so called high-contrast mode) - *screen=color+3*letter_val.
Title: Re: Battlescape development
Post by: SupSuper on March 02, 2011, 11:34:29 am
There is two minor fixes you should consider (1st if yours, and 2 is probably SupSuper's).

1) Energy numbers are slightly in wrong place, and should be shifted 1 pixel right.

2) There are two different modes for text drawing functions. Mode A - ordinary colored letters, when every font pixel value just added to font color - *screen=color+letter_val. And mode B (which is used for BattleScape) - when every font pixel value added with x3 value (so called high-contrast mode) - *screen=color+3*letter_val.
I think both are mine. :P And thanks, I knew the Battlescape text was drawn differently but I couldn't figure out exactly how.
Title: Re: Battlescape development
Post by: Yankes on March 05, 2011, 02:47:54 pm
i have another bug. this time with guns :)
when you fire gun when your solder standing on highest point of ramp from Skyranger you will always hit your feet (probably this is some kind of rocket jump :> )
tested on last git build
[ps]
anoter bugs
when i shoot ground couple of times  its disappear and leave black square, then i cant shoot that spot again
when i target my shooter, he shoot i different direction
explosion in ufo dont generate smoke
Title: Re: Battlescape development
Post by: Daiky on March 11, 2011, 03:54:18 pm
Although most bugs in the git build are due to work in progress, anyway thanks for the bug reports.

I'm currently refactoring a few classes and relations. Because I now have some new insights that I didn't have earlier on. For everyone who is interested... read on.

Removing:
UnitSpriteRule - since this data is directly linked to graphics it makes no sense to have it configurable for now, it just complicates things.
MapModel - there is not really an added value to keep track of all individual models of map objects after all, voxel data will be looked up directly in the loftemps data.
Adding:
RuleArmor - holds armor value for different types of armor, including aliens' armor
RuleUnit - holds initial stats and other unit specific data for both xcom and aliens
RuleSoldier - RuleAlien :)
Unit - abstract class that is used as an interface to both Soldier and Alien
Alien - the counterpart of Soldier, but for aliens. It doesn't hold any data, but looks it up in the associated RuleUnit
Changing:
Soldier - implements Unit, although this changes nothing on the geoscape side.
BattleUnit - holds pointer to Unit.

The philosophy behind this construction is driven by the idea that an x-com soldier is a unique entity, existing both outside and on the battlescape. An alien is just a pointer to a ruleset.
The advantage of using the abstract Unit class, is to simplify the usage on the battlescape. For example you want to get a unit's name, you do: unit->getName(); and depending whether it's an Alien or a Soldier, it will call the appropriate function.

Note that BattleUnit is not a descendant of Unit, this is intentional. Otherwise if a Soldier enters a battlescape, the Soldier class should be "morphed" into a BattleSoldier class, this is tricky business and especially hard to maintain - if new attributes are added to the Soldier class. So for each Unit participating in battle a BattleUnit instance is created which holds it's corresponding Unit pointer.

As a rule the Alien class counts for all NPC units: so including civilians. The type of class does not define whether a unit's AI is hostile towards x-com. This is taken care of with a "faction" attribute : friendly, neutral or hostile.
Title: Re: Battlescape development
Post by: liamdawe on March 14, 2011, 11:54:47 am
I am still lurking watching your working, coming along really well mate super job!!
Title: Re: Battlescape development
Post by: Daiky on March 22, 2011, 12:08:39 am
I am still lurking watching your working, coming along really well mate super job!!

Thank you.

Meanwhile I'm on a business trip for work. But at the hotel we have internet, so I can still push stuff I have been working on :)

- Added the basic "unit dies" logic (from direct hit or explosion).
So, units can be hit, but it's just the weapon damage -  front armor which gets subtracted from their HP at the moment. If health reaches 0, the unit dies with appropriate scream sound and animation. The unit however then disappears...

- Turning and walking consume the right amount of timeunits.
I think this one is pretty much finished. I probably need to add the energy functionality next.

- The "end turn" button: add basic end-of-turn logic.
The button will, if in debug mode, allow you to play with the aliens, otherwise it just replenishes your timeunits.

- Added debug mode "d" which reveals map and allows to play alien side.
Title: Re: Battlescape development
Post by: alienjon on March 22, 2011, 12:55:59 am
Quote
Changing:
Soldier - implements Unit, although this changes nothing on the geoscape side.
BattleUnit - holds pointer to Unit.

[...]

Note that BattleUnit is not a descendant of Unit, this is intentional. Otherwise if a Soldier enters a battlescape, the Soldier class should be "morphed" into a BattleSoldier class, this is tricky business and especially hard to maintain - if new attributes are added to the Soldier class. So for each Unit participating in battle a BattleUnit instance is created which holds it's corresponding Unit pointer.

As a rule the Alien class counts for all NPC units: so including civilians. The type of class does not define whether a unit's AI is hostile towards x-com. This is taken care of with a "faction" attribute : friendly, neutral or hostile.

Should a more abstract name be derived from these 2 concepts? (UnitPointer/UnitHandle, Creature<-{Civilian, Alien, Soldier})

I know that the class translation isn't exactly how I described it above, but I feel that the nomenclature is a little confusing (a Civilian is also an Alien?)
Title: Re: Battlescape development
Post by: Daiky on March 24, 2011, 11:10:01 pm
You'll have to see the word "Alien" as "foreigner/stranger/outsider". Or in other words a non-x-com-employee.
Then you see that a civilian also falls under this term :)
Title: Re: Battlescape development
Post by: alienjon on March 24, 2011, 11:18:01 pm
Fair enough  :)
Title: Re: Battlescape development
Post by: Daiky on April 12, 2011, 11:38:23 am
working on:
- the red visible enemy units icons on the right side of the screen
- the red battlescape error message "not enough time units, etc"

The work behind the scenes for these features was already done, so it's a logical step to finish it off now.
Title: Re: Battlescape development
Post by: liamdawe on April 12, 2011, 11:55:56 am
Great work, what is still left to be done until it's finished?
Title: Re: Battlescape development
Post by: Daiky on April 12, 2011, 01:34:39 pm
The action menu is probably my next little project. (the menu that pops up when you click a weapon).
SupSuper agreed to work on the Soldier Equip screen.
And I will implement the throwing trajectory in the mean time.

When that's done, 0.3 probably will be finished.

I think 0.3 is a big step for the battlescape. Probably the only other big piece missing from the battlescape is the AI.
Title: Re: Battlescape development
Post by: michal on April 12, 2011, 01:53:44 pm
I think 0.3 is a big step for the battlescape. Probably the only other big piece missing from the battlescape is the AI.

What about 2x2 units? Won't it require many changes to pathfinding? Or will it be simple?
Title: Re: Battlescape development
Post by: Daiky on April 12, 2011, 03:15:20 pm
I think 0.3 is a big step for the battlescape. Probably the only other big piece missing from the battlescape is the AI.

What about 2x2 units? Won't it require many changes to pathfinding? Or will it be simple?

Not "many" changes, pathfinding for 2x2 units is like pathfinding for 4 units in parallel, the first unit is the master, the other 3 are dummy units.  The master does a step in a certain direction, if the step succeeds, the other 3 units try a step in the same direction, if one of them fails, the step is marked as failed and we try in another direction.
Title: Re: Battlescape development
Post by: liamdawe on April 13, 2011, 11:09:16 am
Will you be doing the AI or will that be sup's job?
Title: Re: Battlescape development
Post by: SupSuper on April 13, 2011, 01:25:24 pm
I'll do the Geoscape AI and he'll do the Battlescape AI.
Title: Re: Battlescape development
Post by: liamdawe on April 13, 2011, 01:32:31 pm
Sweet honestly can't wait for that, it's the biggest thing i am looking forward to :D
Title: Re: Battlescape development
Post by: darko on April 16, 2011, 03:13:37 pm
looks like development extremly slowed down.. nuff said
Title: Re: Battlescape development
Post by: Daiky on April 17, 2011, 12:58:42 am
looks like development extremly slowed down.. nuff said
looks like you don't contribute anything but only negative comments.. nuff said

btw. I just pushed another code change (the visible units buttons), that while I was having appointments with my family and people for renovating my new house, gardening, cooking, having a very demanding job I still do my best to do something for openxcom every day. Research or coding or being on IRC.
Title: Re: Battlescape development
Post by: michal on April 17, 2011, 10:34:39 am
Development is very active. You have to remember that development is not only coding, but also researching (like Daiky said), designing and testing. Everything takes time. If you're not programmer, you can't understand that. Sometimes you have to spend severals hours to write only couple of lines of code.

Also, what is most important is that SupSuper and Daiky have their personal lives, so they can spend only couple of hours per day / per week for openxcom.

They're doing great job devoting their free time for OpenXcom, nuff said.
Title: Re: Battlescape development
Post by: darko on April 17, 2011, 03:57:28 pm
i know whats programming because tried it many times ;)
and happy such provocate post motivated team
sometimes critic even not too objective speed up development
dont be angry on me plz :D
Title: Re: Battlescape development
Post by: liamdawe on April 17, 2011, 05:36:51 pm
i know whats programming because tried it many times ;)
and happy such provocate post motivated team
sometimes critic even not too objective speed up development
dont be angry on me plz :D

You really think your post motivated them? Geez...

Don't listen to stupid posts, you guys are doing a top notch job and i am looking forward to playing with .3 :D
Title: Re: Battlescape development
Post by: SupSuper on April 19, 2011, 02:35:31 pm
looks like development extremly slowed down.. nuff said
(https://i6.photobucket.com/albums/y237/supsuper/OpenXcom/openxcom_dev.png)
Not every development is worth a big fancy detailed post. Don't bother posting if you have nothing to contribute, good or bad.
Title: Re: Battlescape development
Post by: Daiky on April 30, 2011, 07:43:09 pm
- Introducing: ActionMenuItem.
- Add weapon accuracies to RuleItem.
- Fix in the battlescape warnings.
- Fix in the weapon sprite position when firing. (bug found by Volutar)
- Fix big ufo doors opening.
- Ufo doors close at end of turn.
- Implemented autoshot.
- Updated CodeBlocks project file.
- Minor warnings fixed.

The menu colors needs tweaking to get it right. whelp! supsuper?  ???
(autoshot and snapshot I already swapped)
Title: Re: Battlescape development
Post by: Yankes on April 30, 2011, 08:18:04 pm
i found some bugs in battlescape:
a) when you get hit by RL at max blast range you grain hp
b) after geting more than 300 hp in that way, i blasted self using RL and after that solder is still staining even he have 0hp left
c) i cant kill self using rife (after killing blow game start looping hit sequence couple of times )
Title: Re: Battlescape development
Post by: Daiky on April 30, 2011, 08:54:47 pm
Good find Yankes, I was a bit lazy at testing :)

Next build they are fixed.

- Aiming to self results in aiming on the floor (as in original).
- Fixed gaining health bug. (Yankes)
Title: Re: Battlescape development
Post by: michal on May 01, 2011, 01:40:45 pm
Good work :D As usual :)
Title: Re: Battlescape development
Post by: Daiky on May 14, 2011, 03:57:14 pm
- Implemented a parabola throwing trajectory.
- Implemented item shadow when throwing an item.
- Implemented clip ammo size and ammo usage.

but for some reason the automatic build did not work...
Title: Re: Battlescape development
Post by: michal on May 14, 2011, 04:29:50 pm
but for some reason the automatic build did not work...

Server was restarted and i had to restart builder, new build is online:
https://openxcom.ninex.info/git_builds/openxcom_git_master_2011_05_14_1052.zip
Title: Re: Battlescape development
Post by: hsbckb on May 15, 2011, 05:39:52 am
Both of you are so hardworking. Thank you very mych!!
Title: Re: Battlescape development
Post by: Daiky on May 16, 2011, 12:37:38 am
Thanks, I had some free time this weekend, so I finished the whole "throwing items" feature. Only thing still missing is an out of range check.

I implemented throwing to make it feel like the old x-com as much as I could, and improve a little where I could.
The soldier throws in a parabolic trajectory, but depending on the obstacles it chooses the best curvature (or how high the arc is in the middle point).
Openxcom will test 4 curvatures, going from almost straight, which is good when there are no obstacles, to very curved when you want to throw something over a fence or a wall. When you are indoors the bigger curvings will fail, because the arc hits the ceiling.

After the curvature is determined, it will apply a deviation on the two angles (tilt & pan) at which the trajectory starts (using normal distributed number between 0 and max deviation, which depends on the soldiers throwing accuracy (>=100% accuracy will result in a minimum deviation)).
This will result (as with firing) in a range-based accuracy. A very small deviation on a short distance is no issue, but a small deviation in a throwing angle for a long range throw can cause the item to end up one or more tiles off-target.

I remember it was painful when you wanted to throw a live grenade through a window, but you missed and it would hit the wall :)
Title: Re: Battlescape development
Post by: michal on May 16, 2011, 08:00:06 am
It's really good to see that more and more features are finished :)

OpenXcom changes list for 0.3 will be huge :D
Title: Re: Battlescape development
Post by: Daiky on May 16, 2011, 06:36:46 pm
I did also write about the throwing trajectory on my blog, with screenshots:
https://www.daiky.be/2011/05/implementation-of-throwing-trajectory.html
for those interested.
Title: Re: Battlescape development
Post by: darko on May 23, 2011, 03:27:15 pm
Daiky, thumbs up. Looked last dev version, it's already looks cool even without ai and grenades, great work done.   :)
Title: Re: Battlescape development
Post by: Daiky on May 26, 2011, 10:44:25 pm
Thanks darko.
I quickly uploaded a vid for people not wanting to have the trouble of downloading a build and run it, but still want to see what's coming in release 0.3 battlescape :
https://www.youtube.com/watch?v=kF8Z3Sl2Ceo
Title: Re: Battlescape development
Post by: Daiky on June 08, 2011, 09:23:25 am
before people start panicking about the fewer updates on my side... I'm on holiday for 2 weeks... without my c++ compiler :p
Title: Re: Battlescape development
Post by: SupSuper on June 08, 2011, 07:33:37 pm
before people start panicking about the fewer updates on my side... I'm on holiday for 2 weeks... without my c++ compiler :p
How can you live without it! :o
Title: Re: Battlescape development
Post by: hsbckb on June 09, 2011, 12:30:47 am
Daily, enjoy your holiday.
Title: Re: Battlescape development
Post by: liamdawe on June 27, 2011, 08:54:20 pm
Hope the holiday was good, i'm still lurking waiting for this project to mature, loving your work!
Title: Re: Battlescape development
Post by: Daiky on June 30, 2011, 04:13:21 pm
Holiday was excellent. We went to Iceland, an amazing country. I'm currently working on a nice vacation video ;D
Title: Re: Battlescape development
Post by: darko on July 02, 2011, 08:42:41 pm
don't wana be a bad guy here... but will we see any updates from anyone in this month..?  ;D
Title: Re: Battlescape development
Post by: Daiky on July 12, 2011, 02:30:21 pm
ok, I'm slowly getting back into the game... I had no pc for a while, now I have a new PC, was busy installing everything again, so I just got Visual Studio again up and running :) Expect updates within a week.
Title: Re: Battlescape development
Post by: Daiky on July 15, 2011, 03:35:23 pm
updates! :)
Ok, I finished the grenade priming screen and functionality to prime grenades.
Only the colors are still a bit off, it's not my strongest point... I miss SupSuper :p
Title: Re: Battlescape development
Post by: R on July 15, 2011, 04:53:59 pm
Looks good so far.  One question: do the numbers represent turns?  If so should we not lower it? A number range over 10 (perhaps even 5) seems a bit overkill.  ;D
Title: Re: Battlescape development
Post by: Daiky on July 15, 2011, 09:20:29 pm
hi R.
You are right, but the purpose is to stick to the original for now. It does not do any harm to have these big numbers :) Althought it totally makes no sense.

If I would have to re-implement this I would just remove the "set timer" screen entirely.
- after you primed a normal grenade, you can throw it, after the turn is over, the other side gets time to move away and after their turn the grenade explodes.
- after you primed a normal grenade, you can hold it in your hands (to cook a grenade as soldiers call it), end the turn and the next turn you have to throw it and it explodes immediatly after it lands. If you did not throw it this turn, it will explode at the end of turn in your hands. (a warning message is shown first to confirm the end of turn when holding a live grenade)

This last option gives the opportunity to throw a grenade without giving the opponent the chance to dodge. However, there is a risk (if you run out of time-units or the grenade lands bad or you get shot the grenade will explode and maybe hurt team mates) and it requires planning ahead (the alien that is now in a good spot to grenade, mayb not be anymore the next turn).

- after you primed a proximity or heavy explosive, you have 2 turns to place it and run to safety, before it either activates or explodes.
Title: Re: Battlescape development
Post by: Daiky on July 16, 2011, 08:14:21 pm
The set timer screen looks better now :)
And I have added another important screen, the end turn screen:
Title: Re: Battlescape development
Post by: R on July 17, 2011, 09:34:17 pm
Quote
If I would have to re-implement this I would just remove the "set timer" screen entirely.

I would keep the timer for the proximity & HE bombs and for possible future implementations.
Although your priming example looks interesting it will needlessly complicate matters.  I would just let the grenade detonate on impact.

Edit 3: Moved to Suggestions - Ground Elevation
Title: Re: Battlescape development
Post by: Daiky on July 18, 2011, 04:23:00 pm
Let's keep suggestions for the suggestion forums :)

More importantly: For the next milestone I'm currently working on the reaction fire functionality. Which is not really AI, it just is a formula that defines when a unit should reaction fire.

But nevertheless a very interesting feature, because it will -for the first time in openxcom history- allow aliens to automatically open fire on x-com soldiers (and vice versa) :o

Other stuff to expect very soon (next milestone):
- The sectoid "test aliens" will now be equipped with plasma pistols. (otherwise they can't attack - duh)
- A first draft of a score/loose/win screen will be implemented

- minor enhancements like: better line of sight (multiple raycasting between units instead of just 1 line), because it was possible to hide behind objects where in the original you could not hide behind, unit stops walking when new alien spotted, camera follows bullet when it goes out of the screen,...

Without the real AI implemented you already could play a very nice hot-seat battlescape game :) Or if, like myself, you don't find any volounteer, play both x-com and alien side :p

Title: Re: Battlescape development
Post by: Daiky on November 22, 2011, 11:49:57 am
Large unit pathfinding works 90%, large unit drawing works 50%... but still a long long way to go...
Title: Re: Battlescape development
Post by: michal on November 23, 2011, 05:36:18 am
Great work :) Nice to see you back in action :D
Title: Re: Battlescape development
Post by: Daiky on November 27, 2011, 12:49:50 pm
Well, action is a big word :) I'm doing a few things from time to time, especially the more fun stuff, leaving boring things for last :p

Hehe, do you remember these?
Title: Re: Battlescape development
Post by: SupSuper on November 28, 2011, 02:05:19 pm
Well, action is a big word :) I'm doing a few things from time to time, especially the more fun stuff, leaving boring things for last :p
Yeah boring stuff is my job. :P
Hehe, do you remember these?
I remember them but not very fondly. :P Nice work.
Title: Re: Battlescape development
Post by: Daiky on December 01, 2011, 10:45:23 am
Thanks. I have to cheat a bit to get tanks on the screen however, I don't think people will get to see them in the next beta without cheating. Because at the alien side they only appear on terror missions. On the soldier side you can't equip the craft with HWPs yet.
But I think people will have plenty of other things to play with.

I'm planning to implement the medikit, motion scanner and proximity grenade this month, so if all goes well, the battlescape 0.4 is ready before end of year, as promised.

I'm hoping to get a 0.4 beta sneakpreview video on youtube around christmas.
Title: Re: Battlescape development
Post by: hsbckb on December 02, 2011, 01:31:39 am
I have to cheat a bit to get tanks on the screen however, I don't think people will get to see them in the next beta without cheating. Because at the alien side they only appear on terror missions. On the soldier side you can't equip the craft with HWPs yet.
But I think people will have plenty of other things to play with.


Daiky, I suggest to provide a save game file with HWPs and Cybetdisk in the battlescape. Other members can try and test the large unit easier.
Title: Re: Battlescape development
Post by: Daiky on December 02, 2011, 11:23:28 am
That can be arranged.
Title: Re: Battlescape development
Post by: Yankes on December 02, 2011, 03:15:02 pm
or maybe you get free tank in every mission? (aliens too get one :>)
Title: Re: Battlescape development
Post by: Daiky on December 05, 2011, 10:48:31 am
Actually equipping a tank in the skyranger is not that hard, it's just an item, like equipment you add to the skyranger. The item gets converted into a unit at battlescape start.
But there are two special things going on:
- A tank uses up unit slots.
- A tank's ammo is not visible as equipment, however behind the scenes the required amount of ammo is transferred in the skyranger automatically together with the tank.

Giving a free tank is what I already do now for my tests. You just need to take care you don't put more than 10 soldiers in the skyranger, otherwise you get soldiers spawned outside the skyranger due to lack of space inside.
Title: Re: Battlescape development
Post by: Daiky on December 06, 2011, 12:55:57 pm
- class Alien is renamed to GenUnit - which stands for generated unit. Soldiers are units that exist on the geoscape, generated units are created on the battlescape. Those are Aliens, but also Civilians, and also the x-com HWPs. Thus the namechange of the class was needed.

- The medi-kit screen will be developed by gchevallerau

- For people that can not wait to test vehicles in the intermediate build, I will commit some code this week that gives you a free tank/cannon in any mission.
Title: Re: Battlescape development
Post by: hsbckb on December 06, 2011, 01:50:29 pm
- For people that can not wait to test vehicles in the intermediate build, I will commit some code this week that gives you a free tank/cannon in any mission.

This free tank/cannon will be my Christmas Present. Thank You  ;D

How about enemy side i.e. Cyberdisk?
Title: Re: Battlescape development
Post by: gchevallereau on December 12, 2011, 09:31:18 pm
I have found a little regression introduced by large unit support. When startting a mission the battlescape crash during initialization. It doesn't happen when in debug mode(using the graph button). I'm not sure of the best way to fix it, I have just added this:
Code: [Select]
if (part < 0)
{
part = 0;
}

in Map.cpp line 437. After this, no more crash and large unit seems to wrok without any problems
Title: Re: Battlescape development
Post by: Daiky on December 13, 2011, 02:26:06 pm
Thanks. I don't think I tested large units on normal missions yet, only in debug mode. So I should do some more testing. Also there is still things I have to implement: large units should not get fatal wounds, no morale losses, no stun damage... no inventory view, it's "dead body" is not right yet...
Title: Re: Battlescape development
Post by: Yankes on December 13, 2011, 04:50:00 pm
Reaper arent biological? you can fear them and probably stun.
Title: Re: Battlescape development
Post by: Daiky on December 13, 2011, 06:58:51 pm
Probably, I might have explained it wrong. The different resistances to types of damages, morale loss or fatal wounds don't actually have anything to do with large units, now that I think of it. They can be configured independent of each other and for any unit size.
Title: Re: Battlescape development
Post by: gchevallereau on December 13, 2011, 09:05:28 pm
By the way, i have uploaded a video showing some of the 0.4 features here https://www.youtube.com/watch?v=226Yso3XKi8

This was done with the unlimited_ammo test(for laser rifle) and medikit.
Title: Re: Battlescape development
Post by: Daiky on December 14, 2011, 12:55:45 am
A tank equipped with a medikit ! :D Nice to see on video how much work I still have :p
Title: Re: Battlescape development
Post by: Daiky on December 14, 2011, 04:48:36 pm
Reaper arent biological? you can fear them and probably stun.

If a reaper is biological, can it bleed from fatal wounds and can be healed by a medikit? Hmm..
Also, a biological unit, even when it is a "large unit" could probably carry equipment and throw grenades...
So, it seems I have to make a load of flags there, one for each ability I mentioned .

edit:
"Cyberdiscs take damage from Stun Rods and Stun Bombs" - ufopaedia

Title: Re: Battlescape development
Post by: Daiky on December 31, 2011, 07:20:56 pm
Yesterday I added the alien deployment rules, which was on my todo list for a while. I can properly celebrate year's end and new year now :p
Title: Re: Battlescape development
Post by: hsbckb on January 01, 2012, 11:12:22 am
Daiky, Happy New Year!

 Can you tell us more about the deployment rule? Is it more realistic? more similar to that of X-Com?
Title: Re: Battlescape development
Post by: Daiky on January 01, 2012, 11:57:43 am
Happy new year to you too :)

With the "deployment rules" I actually mean that data like: how many aliens and of what ranks and with which weapons will spawn at certain types of UFOs or other missions. I had this data temporarly hardcoded in a rather ugly way. So now it's all neatly described in the famous "ruleset", which will become a text file eventually. So modders can have fun tweaking the game. (or add new UFO types, or give aliens more grenades, or whatever your wishes may be)

The numbers are taken from the original X-Com, so yes, it will be not just similar, but exactly that of X-Com.

My openxcom goals for 2012:
- finish the battlescape
- tweak the battlescape further so it works with Terror From The Deep data
- release my own reworked music & sound FX pack
- ...
Title: Re: Battlescape development
Post by: hsbckb on January 01, 2012, 12:14:31 pm
nice to hear that, especially your 2012 goals.
Title: Re: Battlescape development
Post by: luke83 on January 01, 2012, 12:21:36 pm
Sounds like this next year  of openX is going to be awesome  :D
Title: Re: Battlescape development
Post by: Daiky on January 09, 2012, 12:19:35 pm
I'm going to put a deadline on the battlescape development for myself on august of this year. So don't panic if you see 0.5 features appear in the 0.4 beta release :)
Title: Re: Battlescape development
Post by: michal on January 09, 2012, 12:45:18 pm
I hope you don't want to abandon openxcom after august ;)
Title: Re: Battlescape development
Post by: Daiky on January 09, 2012, 01:10:06 pm
No, I will be certainly around, of course for fixing bugs in my own code, etc... and I guess my work in openxcom is not finished after the battlescape is finished... there is still lots of fun stuff to do... we'll see.
Title: Re: Battlescape development
Post by: Daiky on January 31, 2012, 11:03:33 am
Base defense mission is almost implemented (only missing the logic of the aliens trying to destroy the facilities and actually removing the facilities from the base, and a few other details :p).

I'm planning to continue getting all the mission types working, then looking for a general system of "mission rules".
I know, I work backwards :p
But hey, at least I'm still working on openxcom :p Otherwise it would probably be an abandoned project.

To give you an idea what will be possible by changing only rulesets:
- make the ufo alien base attack a two-part mission
- make the tftd alien base attack a one-part mission
- create other terrain types for terror missions, alien bases, UFO's (the system will choose a random terrain type when multiple types are linked to one mission or one UFO)
- change the size of all maps in all missions except base defense (there is no limit to the map sizes or number of objects on a map, but beware the "alien turn" will take some time if you put thousands of aliens on a map :p )
- change  the number of aliens in all missions, their ranks and what items they carry
-  ...
Title: Re: Battlescape development
Post by: luke83 on January 31, 2012, 12:22:53 pm
 "create other terrain types for terror missions, alien bases, UFO's (the system will choose a random terrain type when multiple types are linked to one mission or one UFO)"
Daiky , you know just what a nerd likes to here ;)

"change  the number of aliens in all missions, their ranks and what items they carry"  QUESTION: Will this include arming civilians?

"But hey, at least I'm still working on openxcom :p Otherwise it would probably be an abandoned project."
I am so glad you have not given up, as we ( the x-com community) NEED a real version of x-com 8).   
Title: Re: Battlescape development
Post by: hsbckb on January 31, 2012, 01:07:26 pm
Base defense mission is almost implemented (only missing the logic of the aliens trying to destroy the facilities and actually removing the facilities from the base, and a few other details :p).



This is what I want to suggest in the forum!!!

Damaged base facilities cost  repair time and repairing fee. This can prevent X-com operative to use something like blaster bomb in their own base. 3D explosion can also make base defense more realistic but the difficulty will increase a lot.
Title: Re: Battlescape development
Post by: Daiky on January 31, 2012, 02:29:48 pm
The trick is to use blaster bombs on the hangars and access lift early in the game, and those are facilities that can not get destroyed. When the aliens get further inside your base you better use more precise weapons and be careful that aliens are not using blaster launchers to destroy your base :p
Title: Re: Battlescape development
Post by: hsbckb on January 31, 2012, 02:40:52 pm
The trick is to use blaster bombs on the hangars and access lift early in the game, and those are facilities that can not get destroyed. When the aliens get further inside your base you better use more precise weapons and be careful that aliens are not using blaster launchers to destroy your base :p

If the hanger is damaged by weapon such as blaster bomb or Grenade,  there should be some "punishment" such as repairing cost,  out of service time (cannot launch aircraft)  for  the facility according to the extent of damage.
Title: Re: Battlescape development
Post by: Daiky on January 31, 2012, 03:11:49 pm
If the hangar would get damaged by grenades, the first thing the aliens will do when they spawn in your hangar is damaging it with grenades :p and you can do nothing about it... wouldn't that be a bit too harsh?
Title: Re: Battlescape development
Post by: Yankes on January 31, 2012, 04:18:09 pm
maybe Alien could destroyed your crafts? Because you leave them in hangars where aliens usually attack :D
Title: Re: Battlescape development
Post by: hsbckb on February 01, 2012, 03:06:01 am
If the hangar would get damaged by grenades, the first thing the aliens will do when they spawn in your hangar is damaging it with grenades :p and you can do nothing about it... wouldn't that be a bit too harsh?
After further consideration, I agree that this will be too harsh.

As the structure of the hanger is not complicated and it will not cost much money or time to repair the facilities in it.
Title: Re: Battlescape development
Post by: moriarty on February 01, 2012, 02:05:56 pm
if I remember correctly, the game explained somewhere that your craft would take off before a base attack... perhaps it would be cooler to actually have them in their respective hangar unless you manually evacuated them. hangars were indestructible to avoid the "orphaned craft" problem, I guess. imagine your base being attacked while your skyranger is still returning from a ground mission... if the hangar is destroyed, it wouldn't be able to land. same thing applies for "repair time" penalties, of course.

I guess a "repair cost" penalty would be fair, though. it would certainly make the base defense more interesting if your troops need to be more careful with explosive ammo of any kind.

Another thing is that in your base defense you should have "civilians" - your scientists and engineers! it would make base defense facilities more valuable - trying to avoid base defense missions, because it endangers your staff.

while we're at it, perhaps the base defense facilities could become more useful if the result wasn't purely dichotomic. what I'm trying to say is: imagine your base is attacked, your plasma defenses hit the battleship several times, but barely fail to destroy it. shouldn't the attackers at least have suffered some casualties? instead they always come at you full strength.

at the same time, if your base defenses shoot the ufo down, it should crash and appear as a geoscape crashed ufo, right?
Title: Re: Battlescape development
Post by: hsbckb on February 01, 2012, 02:17:41 pm


at the same time, if your base defenses shoot the ufo down, it should crash and appear as a geoscape crashed ufo, right?

That sound interesting.
Title: Re: Battlescape development
Post by: luke83 on February 02, 2012, 07:30:57 am
"Another thing is that in your base defence you should have "civilians" - your scientists and engineers! it would make base defense facilities more valuable - trying to avoid base defence missions, because it endangers your staff."

Hey i like the sound of that , i hope someone does some sprites ::)

Picture ADDED . Combat engineer look very similar to the army guy i added earlier but they are different sprites, I think i will finish him so someone can add him into some special mission later on with the army guys.

 What colour should a engineer be when you work in the x-com base , you really don't need camo?

Also the Scientist needs longer sleeves to. ( plus his waste line fixed 0 he looks like he has a big hips  :( )

Feed back anyone?
Title: Re: Battlescape development
Post by: luke83 on February 02, 2012, 08:41:31 am
Looks a little better but i think i should loose the yellow hard hat also ???
Title: Re: Battlescape development
Post by: moriarty on February 02, 2012, 09:45:12 am
Engineers... maybe blue overalls? plus hard hats. as an x-com engineer I would wear one. you never know if something blows up and drops a pile of heavy plasma rifles on your head.

Scientists might look even better with long white coats, but I don't know if that is feasible. white pants might be nicer, too. or perhaps they will look too much like doctors, then?
Title: Re: Battlescape development
Post by: luke83 on February 02, 2012, 10:08:01 am
ok , we can continue our discussion in Gangs and Civ posts.
Title: Re: Battlescape development
Post by: Daiky on February 02, 2012, 12:45:21 pm
Given that your craft are evacuated, I always assumed the scientists and engineers were smart enough to evacuate too... and I found that a good thing, because they would only get in my way.

What I *do* find an added value is some visual feedback in the form of a health bar for each facility in your base. So you can see what is happening and you can react on it, avoiding them getting destroyed. Because now it's just guesswork.
It's not always adding content and adding complexity that makes a game better... ;-) I think our professional game designer bramcor would agree with me, but I don't see him a lot around lately :p
Title: Re: Battlescape development
Post by: luke83 on February 02, 2012, 12:52:07 pm
How do you Evac 100+ Civilians and engineers on a average of 2 sky rangers before the mother-ship lands?  There would surely be a small percentage left wandering around :D
Title: Re: Battlescape development
Post by: kkmic on February 02, 2012, 11:03:34 pm
I always wondered how during base defense missions, you don't know where the aliens are. It seems like X-Com base builders never considered some security measures. Video cameras, motion sensors & such...

Let's get back to development now :D
Title: Re: Battlescape development
Post by: luke83 on February 03, 2012, 08:38:16 am
"Let's get back to development now :D"

Its so hard to stay on topic ::)
Title: Re: Battlescape development
Post by: kkmic on February 03, 2012, 09:50:31 am
Yeah, but we should at least try to :D

On-topic:

Go! Go! Daiky!

 8)
Title: Re: Battlescape development
Post by: luke83 on February 24, 2012, 02:00:01 pm
Any news on when Terror Sites will become active?
Title: Re: Battlescape development
Post by: Daiky on February 24, 2012, 06:16:10 pm
Any news on when Terror Sites will become active?
I still need to add civilians. Terror Sites are your favorite part of the game isn't it? :)
Title: Re: Battlescape development
Post by: luke83 on February 24, 2012, 10:29:52 pm
What makes you say that ::)
Title: Re: Battlescape development
Post by: Daiky on February 26, 2012, 01:11:17 pm
This one is for you luke83 :-)
Skyrangers can now land on rooftops of buildings (it will look for the highest floor tile on 0,0 of the mapblock defined as landingzone, this floortile defines at what level the skyranger should be placed) .
This means for your cities where you have the first 2 levels under ground, the skyranger will properly land on the ground level.
(as you can see, to test here, I defined the tank-station mapblock as a possible landing zone - instead of the skyranger crashing into it, it nicely landed on the rooftop)
(also note: I can't get off the roof with a HWP without a proper ramp  ;D)
Title: Re: Battlescape development
Post by: moriarty on February 26, 2012, 01:19:28 pm
nice, really - but how do you get back up in case you try to flee the battle?  :-\

most buildings do have roof access, but the gas station doesn't. :(

I like it anyway. thumbs up!
Title: Re: Battlescape development
Post by: Daiky on February 26, 2012, 01:35:01 pm
Well, it only has a purpose for mods I guess. Standard mapblocks can not really work with this "feature" :)
Title: Re: Battlescape development
Post by: Yankes on February 26, 2012, 01:54:21 pm
great idea :) only problem would be tanks because you can always limited to roofs with access that you can always get yours solders back.
you can treat this as `hard` mode :) because you cant use tanks without sacrificing them.
Title: Re: Battlescape development
Post by: Conti-k on February 27, 2012, 10:53:34 am
I have a small-ish request/petition...

I've made a house for Farm, but seeing it three time used (often close to each other) is looking kinda ugly (and weird), so I've been thinking about such feature (maybe its already planned?): additional value for each map block in rulesets, for example:

0 = standard map block
1 = unique map block

what this would do...

During terrain generation, if map block with value 1 is used this means that any other map block with the same value can't be picked (including the one that was already used). You could make, for example, 4 unique map blocks, that if appear engine will use only one map block from this "group". This way you can add houses to other maps than Terror missions without turning it into high density urban areas. Expanding further this feature would allow to create all kind of "groups" with defined values: 1, 2, 3, 4, etc. that if will appear, only one map block per group will be used.

--------------------EDIT

I've attached a screenshots composition to illustrate the problem (640x400 in higher res is looking great, isn't?).
Title: Re: Battlescape development
Post by: Volutar on February 27, 2012, 01:27:42 pm
It's just a matter of map composition rules. For the moment they are taken from original ufo1. I hope eventually they become a list of scripts, for any number of additional map types or sub-types.
Title: Re: Battlescape development
Post by: luke83 on February 28, 2012, 10:47:45 am
Thanks Daiky for the update , i couldn't use my new maps without it. Now i just need battlescape finished , a way to add all my buildings into the terror site list and a Shortcut key to start a terror mission instantly , I really don't want much do i  ;)

Seriously take your time mate , There is no rush , i would rather terror sites be DONE WELL , not just DONE :P   Maybe with a option to arm civilians ( HINT, HINT ::) ) 

AS for the issue with the Tanks on a roof , Would 2 sets of stair side by side allow a tank Ramp access?

You, Supsuper and all the other people contributing to OpenX are doing a fantastic job so PLEASE keep up the good work! ;D
Title: Re: Battlescape development
Post by: SupSuper on February 28, 2012, 02:29:35 pm
Technically there is a hidden shortcut battlescape debug key, but I might have to make it a full feature given how common debugging/testing the Battlescape standalone is (and so Daiky doesn't have to wait for my sluggish Geoscape support :P).
Title: Re: Battlescape development
Post by: Daiky on February 29, 2012, 01:25:42 pm
There is not much fun of having a terrorsite without civilians, I will see if I can add them this weekend.
Title: Re: Battlescape development
Post by: Daiky on March 04, 2012, 08:05:26 pm
Farmer looking out of window : "Wife ! Come look at this! There's a big metal ship in our potatofield !"
(had some fun spawning civilians on crash sites) (will not be standard in the original openxcom :p)
Title: Re: Battlescape development
Post by: luke83 on March 05, 2012, 09:10:42 am
Awesome , i was thinking about some farmer sprites. It would be cool later if we could add civilians to any map we want in the future ,define what sprites they are to use and IF they have any weapons or not.
Title: Re: Battlescape development
Post by: Daiky on March 05, 2012, 09:35:29 am
And maybe they speak with text balloons? They give you quests which you can complete and get a reward in money to generate additional income this way ... I'm getting carried away  ;D
Title: Re: Battlescape development
Post by: luke83 on March 05, 2012, 09:52:12 am
 TEXT BUBBLE "i think i soiled myself,  Go to my cupboard and get me some clean underpants"
Title: Re: Battlescape development
Post by: kkmic on March 05, 2012, 11:42:07 am
This is a little bit off-topic but...

VIP rescue anyone? Maybe some important person managed to get into town when the alien terror ship arrived. Bonus points for rescuing him and extra penalty on failure? Some armed bodyguards too?

Title: Re: Battlescape development
Post by: luke83 on March 05, 2012, 11:47:05 am
Yes i have been thinking of the same things for Random missions. I need to get version 1 of my terror maps finished so i can get back to making some more different sprites.
Title: Re: Battlescape development
Post by: luke83 on March 05, 2012, 12:53:29 pm
We must be getting close to version 0.4 , what other features are we waiting on until we hit that milestone ?
Title: Re: Battlescape development
Post by: Conti-k on March 05, 2012, 09:19:34 pm
Would be really nice to add civilians to Farm missions (I'm doing houses for them after all :P).  Magical "true" in options.cfg may do the trick, and will keep purists happy :P
Title: Re: Battlescape development
Post by: Daiky on March 06, 2012, 12:30:42 am
I've enabled the Graph button - instant terror mission in the latest build for the people already wanting to peak around in a terror mission. I will disable it again later.
Use at own risk :p
Title: Re: Battlescape development
Post by: luke83 on March 06, 2012, 10:54:53 am
Use at own risk is correct, when i select graphs the game crashes instantly ;)
Title: Re: Battlescape development
Post by: Daiky on March 06, 2012, 11:04:16 am
I tried a clean installation and the latest git build and works fine with me...
Title: Re: Battlescape development
Post by: luke83 on March 06, 2012, 11:12:16 am
Maybe its my large FRNITURE MCD, or something else i have done over the last  6 months i will start with the original ufo files later and test that , if it works i will change one file at a time :)
Title: Re: Battlescape development
Post by: luke83 on March 06, 2012, 11:38:01 am
Fresh install works , my new maps don't :P

UPDATE:  When i add my Mixed MCD,PCK,TAB file terror map still loads.
I add one of my new maps to the possible mix and aslong as its not used there is no issue. However after 3 working maps, the forth must of used my NEW map and it crashed.

Worth noting is the Aliens love grenades in Terror Sites !  :o  Also your AI is a Bitch , i was just trying to run over the map to find the map blocks i modded as a test and those sectiod and Discs gunned me down everytime. If sectoids and Discs are that bloody hard  i dont want to see what the  mutons are going to do to me 8)

Second Update:
After much testing, the  MCD data is fine, see attached Disco road , as soon as a added my NEW ( 3 levels of underground )road Map file  the game crashes everytime. Daiky is there something else missing to allow multi levels to work?
Title: Re: Battlescape development
Post by: Conti-k on March 06, 2012, 01:15:29 pm
I'm guessing it's a WIP feature, but I'd like share some thoughts about AI after one month I've spent on testing OpenXcom.

- AI is throwing grenades like a mad (at least during terror missions). Nothing is safe, including... Aliens! Awesome! I'm HUGE fan of battlefield chaos, and unpredictable situations.

- AI sometimes (correct placement on the map) is trying to kill units inside of crafts (gaps roof/floor <==> walls original design flaw?), but it's wasting TUs only.

- AI way too much is doing nothing. It can stand next to my unit for a few turns without any reaction, or is moving back and forth, making it super easy to kill. Reaction fire on my units movement seems to work better than AI's actions during its turn.

-----------------------EDIT

Of course, it doesn't happen all the time. But sometimes AI is simply standing, and waiting to be killed, even if has my units few tiles away, and could successfully kill them. Unpredictable AI is super cool, but "idling" happens too often.
Title: Re: Battlescape development
Post by: Daiky on March 06, 2012, 03:04:19 pm
luke83: mind that your soldiers are rookies on their first mission - try to run around in plain field on a terror site with noob units and no armor in the original game... it will hurt ;) Soon the rulesets are externalized and then I suggest you to modify all armor to 999 and test your maps without casualties ;)

If you think the game crashes with one of your maps, and looks like a bug in the game, I can have a look at it if you send me your maps.

Conti-k, I know those 3 issues you mention and eventually I'll hope to get around polishing the AI a bit more later on, but I've put it a bit lower on my list of todo.
Title: Re: Battlescape development
Post by: Conti-k on March 06, 2012, 07:03:35 pm
@ luke83

Save, and load game - Sectoids will lost weapons. Dunno about Cyberdisks though.

Conti-k, I know those 3 issues you mention

No, no, no. Throwing grenades like a mad isn't an issue! :P Don't change that. It's great that Aliens are actually using grenades. I was happy seeing grenades often used against civilians (terror must look like a terror 8) ). Plus it produces great effects, like killing own dudes by accident (shit like this should happen on the battlefield). But if you think this isn't good then you may put some conditions how often throwing will occur, for example, certain races (like Mutons) may use grenades more often than other ones (like Ethereals). Aggression, or Intelligence may be used as conditions to determine a chance of throwing grenade as well.

and eventually I'll hope to get around polishing the AI a bit more later on, but I've put it a bit lower on my list of todo.

Of course. There's no reason to be hurry with it. I'm just trying to give some constructive feedback.
Title: Re: Battlescape development
Post by: luke83 on March 06, 2012, 08:17:28 pm
I love the grenade mad aliens , for the first time in many years the terror mission was actually terrifying ;D
Title: Re: Battlescape development
Post by: Daiky on March 25, 2012, 01:09:03 pm
Wanted to note that from tomorrow I'm on holiday for a week, so if you write me a PM and I don't answer within a week you don't have to panic ;-)
Title: Re: Battlescape development
Post by: michal on June 26, 2012, 01:51:24 pm
Daiky, what's next in your plans? After you did basic salvaging?

( I'm asking here, cause i think it's more proper thread for talking about battlescape development ;) )
Title: Re: Battlescape development
Post by: Daiky on June 27, 2012, 12:24:41 pm
I recently found a copy of the book "Art of Game design": https://artofgamedesign.com/
it's really a great book, so in my free time I'm going to read that.

And other than that I'll just play openxcom a bit and see what is missing and then implement that missing part. I'm going to check if personal armor works in battlescape, I think not. So that might be next.
Title: Re: Battlescape development
Post by: michal on June 27, 2012, 12:40:50 pm
As for missing parts, maybe it would be nice to have somewhere (on wiki?) described working / missing features?
For example items:
ItemBattlescapeResearchManufactureUfopaedia
Laser pistolYesYesYesYes
Personal armourYesNoNoNo

Battlescape features:
FeatureImplemented
ShootingYes
DyingYes
LiftsNo
Psi controlNo

Intersecption features:
FeatureImplemented
Shooting UFOYes
Shooting X-com interceptorNo

etc

Requires much work to describe everything. Also requires updating of such lists / tables. On the bright side everyone could know how far OpenXcom project is advanced.
Title: Re: Battlescape development
Post by: Daiky on June 27, 2012, 01:23:25 pm
Hmm, nice it is.

But, all the people in the entire openxcom development team already normally keep changelog.txt up to date. I think I forgot to do it the last time. Hope I don't get spanked by the project manager :p

But seriously, I thought that file was an list of what is in a current release, isn't creating another table of it not double work? Also, we don't know a detailed list of what is to-do.
Title: Re: Battlescape development
Post by: michal on June 27, 2012, 01:37:06 pm
changelog.txt is mostly useful for creating release notes for every new version. What i've suggested is mostly for showing actual implementation status, so it's some kind of mix of changelog.txt with roadmap from main site in more condensed form ;)

Anyway, it probably would be hard to maintain - like changelog.txt ;)
Title: Re: Battlescape development
Post by: Daiky on June 29, 2012, 05:27:54 pm
That's a project leader's job and I'm a programmer here :p
I'd love to do the project lead for some opensource project maybe in the future. Or a combination project lead/game designer.
Title: Re: Battlescape development
Post by: michal on June 29, 2012, 10:07:22 pm
Maybe SupSuper would let you to be OpenXcom co-leader? ;)
Title: Re: Battlescape development
Post by: Daiky on June 29, 2012, 11:20:03 pm
nah, a project of my own I mean :)
Title: Re: Battlescape development
Post by: moriarty on June 29, 2012, 11:22:10 pm
will there be a vote? I'd like to see OpenMasterOfMagic :D
Title: Re: Battlescape development
Post by: luke83 on June 30, 2012, 12:20:02 am
master of orion 2, the other guy doing this looks like he has stopped :(
https://openmoo2.org/en/

What am i saying, finish openxcom first  ;)
Title: Re: Battlescape development
Post by: michal on June 30, 2012, 07:29:46 am
Daiky, do you have any idea for your own project?
Title: Re: Battlescape development
Post by: hsbckb on June 30, 2012, 08:52:32 am
Is it another remake or a new game?
Title: Re: Battlescape development
Post by: Daiky on June 30, 2012, 11:00:12 am
I have no idea.
Title: Re: Battlescape development
Post by: luke83 on June 30, 2012, 11:17:26 am
Daiky, when can we expect to see all the aliens in game? Any thoughts?
Title: Re: Battlescape development
Post by: Zharik1999 on June 30, 2012, 09:12:38 pm
Or even floaters? I know they will bring a lot of bugs. We have even floating sectoids but I really can't wait to enjoy playing against floaters. :)
Title: Re: Battlescape development
Post by: Daiky on July 01, 2012, 12:14:10 am
floaters are in the game already, but there is no "story" in the geoscape to trigger them, it's hardcoded to sectoids now. When the geoscape stuff is implemented, the rest will probably be ready too.
Title: Re: Battlescape development
Post by: luke83 on July 01, 2012, 12:41:42 am
cool , so what are you planning next? Are all map types done yet? Maybe some Armed Civilians  ?::)
Title: Re: Battlescape development
Post by: Daiky on July 01, 2012, 12:45:42 am
I recently found a copy of the book "Art of Game design": https://artofgamedesign.com/
it's really a great book, so in my free time I'm going to read that.

And other than that I'll just play openxcom a bit and see what is missing and then implement that missing part. I'm going to check if personal armor works in battlescape, I think not. So that might be next.
Doesn't armed civilians work already? I never tried, I don't know what happens when you put a weapon in a civilians' hands :p Probably doesn't work.
Title: Re: Battlescape development
Post by: luke83 on July 01, 2012, 01:20:12 am
They work when there xcom solders but i have never tried to make normal civilians armed, i assumed there would be some special rules required within the Ruleset not to mention some AI upgrades ::) Download a sprite set and let me know :P
Title: Re: Battlescape development
Post by: moriarty on July 01, 2012, 01:26:18 am
do the civilians have arm sprites for holding weapons?
Title: Re: Battlescape development
Post by: luke83 on July 01, 2012, 06:02:38 am
my civilians do, i reworked the x-com solder sprites to handle them, i just need to tell  openxcom to use them somehow
Title: Re: Battlescape development
Post by: Daiky on July 01, 2012, 10:47:18 am
damn, personal armor already does work perfectly in battlescape :) I'll implement the destruction of items on the ground by explosions today.
Title: Re: Battlescape development
Post by: hsbckb on July 01, 2012, 10:53:35 am
damn, personal armor already does work perfectly in battlescape :) I'll implement the destruction of items on the ground by explosions today.

How about unconscious soldier killed by fire?
Title: Re: Battlescape development
Post by: Daiky on July 01, 2012, 12:42:30 pm
according to ufopaedia items, uncluding corpses don't take damage from fire.
Title: Re: Battlescape development
Post by: moriarty on July 01, 2012, 12:50:25 pm
that's true for the original, but should it really be that way?  ::)

IMHO, unconscious soldiers taking no damage from fire is a design flaw, and should be corrected... they should also be able to receive stun damage, and explosions shouldn't affect them as items, but as soldiers/aliens.

heavily armored guy falls unconscious from a stun bomb, simple grenade goes off and completely wipes him off the face of the earth (or mars, for that matter ;D )?
seriously?
Title: Re: Battlescape development
Post by: Daiky on July 01, 2012, 01:31:01 pm
I wouldn't know if it's a bug or intentional, lets move it to the suggestions forum?
In openxcom bugs are fixed, but the "rules" should not be changed, unless it's optional.
Title: Re: Battlescape development
Post by: Daiky on July 04, 2012, 11:12:35 am
My Battlescape TODO-list for this month in the order it will be implemented. We'll see how far I get :p

items:
- psi-amp
- melee weapon
- mind probe

alien life forms drawing:
(there is certainly an overlap between some of them)
- floater
- reaper
- snakeman
- chryssalid
- zombie
- muton
- celatid
- silacoid
- sectopod

ai:
- psi attack
- melee attack
- smarter grenade throwing
- smarter blaster launching
- take cover

alien life forms special abilities:
- reaper bite (probably just a melee attack)
- Chryssalid/Zombie mechanics
- Celatid acid spit
- Silacoid ground burn

missions:
- alien base
- mars

- bugfixes
- suggestions
Title: Re: Battlescape development
Post by: michal on July 04, 2012, 11:54:10 am
Cool :) Lot of work for one month, but also lot of new features :)
Title: Re: Battlescape development
Post by: luke83 on July 04, 2012, 12:10:32 pm
If you get all that done in 1 month i will send you a Gift as a thankyou :P
Title: Re: Battlescape development
Post by: Zharik1999 on July 04, 2012, 01:46:06 pm
Oh, if you complete it in one month I will send you all my games because I won't need them any more! :D
Title: Re: Battlescape development
Post by: michal on July 04, 2012, 01:57:55 pm
Lot's of prizes already ;) Daiky, what do you think? Challenge accepted? ;)

Edit: Daiky, if you will send me your paypal account i will send you couple bucks for beer if you manage to do it :D
Title: Re: Battlescape development
Post by: Daiky on July 04, 2012, 02:54:01 pm
Let me first think how I will explain this at home
Title: Re: Battlescape development
Post by: luke83 on July 04, 2012, 10:10:22 pm
Its easy , Hey Wife , I need to i ignore all my other duties around the house for a month so i can program  openxcom instead ,then people from around the world will send me heaps of useless junk :P
Title: Re: Battlescape development
Post by: pmprog on July 05, 2012, 04:40:30 pm
My Battlescape TODO-list for this month in the order it will be implemented. We'll see how far I get :p

Looks good. Anything you want me to have a gander at in particular without treading on your toes?
Title: Re: Battlescape development
Post by: Daiky on July 06, 2012, 03:02:59 pm
If you want a challenge, you can write the drawing routine for the Sectopod :p
Here are the frames:
https://www.ufopaedia.org/index.php?title=X_ROB.PCK
It's like putting together a puzzle.
Title: Re: Battlescape development
Post by: Volutar on July 06, 2012, 03:06:19 pm
But there is another way besides trial-and-error. But who ever wanted easier way, huh? :)
Title: Re: Battlescape development
Post by: pmprog on July 06, 2012, 04:04:13 pm
If you want a challenge, you can write the drawing routine for the Sectopod :p
Here are the frames:
https://www.ufopaedia.org/index.php?title=X_ROB.PCK
It's like putting together a puzzle.

Sure, I'll take a look.

Are there any tools to view the contents of PCK available? All the ones I can find are broken links. Just so I can get a better look at the pieces.
Title: Re: Battlescape development
Post by: moriarty on July 06, 2012, 04:38:38 pm
https://openxcommods.weebly.com/pckview.html (https://openxcommods.weebly.com/pckview.html)

you will find that pckview comes in several versions, some of which work better than others. for me, on win7, the one that comes with mapview appears to work best:

https://openxcommods.weebly.com/uploads/1/1/8/4/11849982/dashivas_mapview.zip (https://openxcommods.weebly.com/uploads/1/1/8/4/11849982/dashivas_mapview.zip)
Title: Re: Battlescape development
Post by: pmprog on July 06, 2012, 04:48:20 pm
you will find that pckview comes in several versions, some of which work better than others. for me, on win7, the one that comes with mapview appears to work best:

Ta muchly
Title: Re: Battlescape development
Post by: pmprog on July 06, 2012, 05:51:29 pm
If you want a challenge, you can write the drawing routine for the Sectopod :p

Pull request sent to SupSuper's git with the new draw function  ;)
Title: Re: Battlescape development
Post by: Daiky on July 06, 2012, 06:04:28 pm
wow, that's fast ;D Feel free to do more draw routines if you want. I will be looking at the items and ai lists this weekend.
Title: Re: Battlescape development
Post by: michal on July 06, 2012, 06:04:42 pm
That was fast ;)
Title: Re: Battlescape development
Post by: pmprog on July 06, 2012, 06:22:58 pm
Hokeydoke, I'll see what I can fit in. I want to start looking at building a Pandora (https://www.openpandora.org/) version of OpenXCOM this weekend too; and I've got the usual chores to do around the house  :'(

Edit: The Reaper uses the same draw method as the Sectopod
Title: Re: Battlescape development
Post by: pmprog on July 07, 2012, 01:45:19 pm
alien life forms drawing:
(there is certainly an overlap between some of them)
- floater
- reaper
- snakeman
- chryssalid
- zombie
- muton
- celatid
- silacoid
- sectopod

A quick update:

Cyberdisc -  drawRoutine3()
Floater - drawRoutine1()
Reaper - drawRoutine5()
Zombie - drawRoutine4() - However, death animation is 18 frames, not 3
Ethereal - drawRoutine4()
Sectopod - drawRoutine5()

Snakeman - drawRoutine6() - Currently WIP

Sectoid - To investigate
Chryssalid - To investigate
Muton -To investigate
Celatid -To investigate
Silacoid - To investigate


And a quick question: STATUS_FALLING - It's used in the Floater draw routine to indicate death/unconscious. However, I never did any special code in drawRoutine5() for the Sectopod, but it died using the correct animation(??) Is that status actually the dying status?
Title: Re: Battlescape development
Post by: moriarty on July 07, 2012, 04:13:06 pm
my best guess is that the floater uses STATUS_FALLING when he's shot down while above ground level...?
Title: Re: Battlescape development
Post by: pmprog on July 08, 2012, 11:03:59 am
https://www.youtube.com/watch?v=-MBsG8RUdXQ

Need to fix up the arms, and double check they look right when holding weapons too

BTW - I added a function called getWeaponHand() so it can be shared between all unit drawing functions that render weapons
https://github.com/pmprog/OpenXcom/commit/a3d3dc74b412abf532e4ad0729d61eb251ec3f11
Title: Re: Battlescape development
Post by: Daiky on July 08, 2012, 09:32:18 pm
STATUS_FALLING is the dieing animation, used for both dieing or falling unconscious, hence the name

Great work so far by the way. I've done de mind probe and working on the psi-amp. But the week-end was way to short :p
Title: Re: Battlescape development
Post by: pmprog on July 09, 2012, 12:09:33 am
STATUS_FALLING is the dieing animation, used for both dieing or falling unconscious, hence the name
Thought so, but am confused on why the sectopod dies properly when I don't handle that code  :D

Great work so far by the way. I've done de mind probe and working on the psi-amp. But the week-end was way to short :p
Good stuff. I'm afraid I didn't get to finish the arms off. I'll see how I am for time this week  :)
Title: Re: Battlescape development
Post by: Daiky on July 11, 2012, 11:35:38 am
Funny mind control stuff : mind control a sectoid and walk him inside the skyranger, then takeoff... I guess the game should handle this as a live captured alien?
(I did not manage to test it in the original game)
Title: Re: Battlescape development
Post by: michal on July 11, 2012, 12:02:07 pm
What if that sectoid will free from mind control during flight and kill some x-com soldiers?
Title: Re: Battlescape development
Post by: luke83 on July 11, 2012, 12:04:27 pm
"What if that sectoid will free from mind control during flight and kill some x-com soldiers?"Then the armed soldiers that survived the last mission would handle it.

Option B : customisable ships like apocalypse :P
Title: Re: Battlescape development
Post by: Daiky on July 11, 2012, 12:29:57 pm
those are not options :p
What it currently does is that it just is a missing alien, not counted in the debriefing score. Which I think is what happens too if you do this in the original game.
An alien or soldier under mind control when game ends, those are counted as missing, no matter where they are.

What could be an option is that a check is done if there are (mindcontrolled or not) aliens inside your craft and you are not allowed to take-off before you killed/stunned the alien.
Title: Re: Battlescape development
Post by: luke83 on July 11, 2012, 01:08:30 pm
So no Apocalypse Mods then , Man i really need to learn how to code :P

I think its fine for you to mind control a alien and IF he is back on your ship you get the points.. At the same time i should be able to force civilians back to my ship for there own protection also ( sorry wrong thread for suggestion)
Title: Re: Battlescape development
Post by: Amunak on July 11, 2012, 02:56:13 pm
I think that you should get points (and "live" aliens) for any mind-controlled and stunned alien on the map.
Title: Re: Battlescape development
Post by: nullzero on July 13, 2012, 11:43:18 pm
I think that you should get points (and "live" aliens) for any mind-controlled and stunned alien on the map.

+1 for that.

Once you find the last alien and successfuly mind control it, the game is pratically over anyway!
Title: Re: Battlescape development
Post by: pmprog on July 14, 2012, 07:20:57 pm
Here's the current version of my Snakemen renderer

https://youtu.be/s3fsrf3hS7o

I still need to fix the weapon and arm positions.

There's also two three bizarre graphical glitches, that I don't know how to fix:

1. When walking "up" (in relation to the screen/camera), an extra "line" is drawn for a couple of frames
2. Walking "up/right" with a building directly to the left causes the arms to glitch
3. Also getting a weird graphic glitch when shooting : https://youtu.be/zDETcStXUJA ; Again, not quite sure why this is happening

Git Fork : https://github.com/pmprog/OpenXcom
Title: Re: Battlescape development
Post by: Daiky on July 15, 2012, 12:22:52 am
hmm, I don't know where those glitches come from either.

Maybe interesting to know, but the way I started with the rendering of units was to look at the functions that UFO2000 uses, you'll find them here:
https://ufo2000.svn.sourceforge.net/svnroot/ufo2000/trunk/src/skin.cpp
There is a Skin::draw_snakeman()

However I think you don't need that anymore :)
Title: Re: Battlescape development
Post by: Daiky on July 16, 2012, 04:32:13 pm
so, quick status update:
- psionics are in (panic / mind control), however not sure if mind control will already behave perfectly all the time, probably not.
- mind probe is in

I feel like doing the alien base mission next... and together with pmprog getting as much aliens done... some more AI... and then BIIIG holiday for me  ;D
Title: Re: Battlescape development
Post by: pmprog on July 16, 2012, 05:55:12 pm
so, quick status update:
- psionics are in (panic / mind control), however not sure if mind control will already behave perfectly all the time, probably not.
- mind probe is in
Good job!

Should have some time tonight when I get home; so I'll run over my Snakeman code and look at recloning the git for my changes
Title: Re: Battlescape development
Post by: Volutar on July 16, 2012, 06:15:07 pm
Concerning unit rendering: You can practice trial&error or refer to other's trial&error (ufo2000 wasn't even sure about values they've programmed), or refer to original, 100% correct data. It's your choice.
Title: Re: Battlescape development
Post by: Daiky on July 16, 2012, 08:13:39 pm
or refer to original, 100% correct data. It's your choice.
You mean you got the exact data for all units? Or going from screenshots?
Title: Re: Battlescape development
Post by: Volutar on July 16, 2012, 08:25:39 pm
Quote
You mean you got the exact data for all units?
Strange question:) Exact data, and don't you doubt!
Title: Re: Battlescape development
Post by: pmprog on July 16, 2012, 09:19:51 pm
Strange question:) Exact data, and don't you doubt!
Not really all that strange, I've never seen any about. Care to share the data? Would help tremendously
Title: Re: Battlescape development
Post by: Volutar on July 16, 2012, 09:26:51 pm
Not really all that strange, I've never seen any about. Care to share the data? Would help tremendously
Sure, I'm often on the IRC.
Title: Re: Battlescape development
Post by: Volutar on July 17, 2012, 01:52:27 pm
Does anyone saw Celatid's spitting animation and green acid blob flying by parabola?
Not me :)
I think this spitting animation MUST be implemented. Though there's a problem with projectile sprite - it's sprite#24 from celatid.pck, and probably will require of throwing procedure update.
Title: Re: Battlescape development
Post by: Daiky on July 17, 2012, 02:11:45 pm
interesting :) I don't remember if I have seen them spitting, but since the graphics are there, we will certainly use them.

It seems it will require a new state "prepare for shooting", which is a little animation right before the moment the actual projectile is launched?

edit: oh, and what happens after that spit animation? It is on the ground then, does it jump back into the air?
Title: Re: Battlescape development
Post by: Volutar on July 17, 2012, 02:49:41 pm
Celatids are spitting (throwing) acid blobs with weight of 10 (in xcom weight units), with weapon sound=48. Strangely but animation is blocked (they're using bullet animation). Right arm weapon idx=38.

Daiky, yeah, indeed it seems to be using pre-shooting animation. And about animation - noone've saw how it ment to be looking. But i suppose it either jump to air, or play backward animation from some of the pre-ground sprites (while projectile flying in the air). I think 1st approach will fit "jerky" oldschool xcom style pretty nice :) 2nd is too complicated.
Title: Re: Battlescape development
Post by: Volutar on September 18, 2012, 01:27:10 pm
So what's up with new unit drawing functions?
Title: Re: Battlescape development
Post by: Daiky on September 18, 2012, 08:43:50 pm
I feel like doing the alien base mission next... and together with pmprog getting as much aliens done... some more AI... and then BIIIG holiday for me  ;D
Still on big holiday :p But I still feel like doing the alien base mission next. Perhaps this week.
Title: Re: Battlescape development
Post by: Volutar on September 19, 2012, 06:04:15 am
So it seems you mixed something in your schedule :) ... and pmprog as well.
Title: Re: Battlescape development
Post by: pmprog on September 23, 2012, 06:03:12 pm
I've been away for the last week (birthday). I can't even remember where I got up to  :( I need to find some time to get back into this
Title: Re: Battlescape development
Post by: Daiky on September 23, 2012, 08:49:47 pm
Rough version of alien base was implemented this week. It probably be finished next week.
Title: Re: Battlescape development
Post by: Fenyő on October 13, 2012, 01:08:49 am
Hi!

I want to present you a new feature, which i just implemented to the Battlescape. :)
More information about the feature can be read HERE (https://openxcom.org/forum/index.php/topic,655.msg6212.html#msg6212).

I've attached the files as a ZIP.
If you compare these 5 files with the originals, you can see the difference.

It was a real-hard work, due to two idiotic coding schemes used in OpenXcom project:
"Opening brackets - this: { - always lined up in their own lines."
"Spaces after commas, operators, and between actual parameters of a method"
The whole OpenXcom sourcecode is totally unreadable because of these! (and when a tab character is showed as 8 space-characters)

I have forced myself (that was even harder) to also follow these coding schemes when making my code addition.
However, maybe somewhere some spaces may still exist on the beginning of some lines, because i usually don't use tab characters for indenting. (instead 2 spaces)
So you may check it if its OK, and fix if not.

The operation of the code is good, and hopefully bug-less. :)
I've tested it many-many times. (many hours during development)

PLEASE! SupSuper, or Daiky! Please add these code to the official OpenXcom codebase! This is a great UI feature, a real improvement!!

PLEASE!
Title: Re: Battlescape development
Post by: Fenyő on October 13, 2012, 01:33:21 am
Oh, and i almost forgotten:

This feature does not offend the turn-to feature, which is also used with RIGHT-BUTTON.
The difference is made by the fact of moving.
No move -> Its usual, not scrolling.
Moving when Right-button pressed -> scrolling. (and not turning when released, of course :) )
Title: Re: Battlescape development
Post by: Daiky on October 13, 2012, 01:48:45 am
I'll check it out, thanks

edit: and it seems to be working fine, it's added to the code base  :)
Title: Re: Battlescape development
Post by: Fenyő on October 13, 2012, 08:58:54 am
edit: and it seems to be working fine, it's added to the code base  :)
Excellent! Thank you!!
Oh, and by the way, this code doesn't have any issues with aiming mode!

Now that you added my code to the codebase, if i check it from browser, now i see some lines in the code where are spaces left on the beginning of some lines, screwing up indenting on those points...
I've told you to check indenting.. :)
Title: Re: Battlescape development
Post by: Fenyő on October 13, 2012, 03:07:03 pm
Here, I present you the "Left-Mouse-Scrolling on the MINIMAP" feature (https://openxcom.org/forum/index.php/topic,655.msg6238.html#msg6238)! :)

Daiky!  Please check it, and if its OK, then please commit it in the code base.

Edit:
Oh, and the "right-click closing the minimap" feature is still present, i just put that to mouse-released condition. :)

And the moving with mouse-move is a little fast, i know, since one pixel move of the mouse corresponds to one tile move on the map.
I tried to slow it down by dividing the offset with CELL_WIDTH and CELL_HEIGHT, but the result is not good, this way it can not react to a lot of small movements, and the moving is very laggy.
Title: Re: Battlescape development
Post by: moriarty on October 16, 2012, 10:21:47 pm
I like the idea of a mouse scrolling method for the battlescape, that's certainly something that has been long missing. :) to me, however, your way seems counter-intuitive: for mouse-scrolling I would always assume that it works as though you are grabbing the landscape and pulling into a direction by moving. your way is exactly the other way around: you hold the mouse, and when you move the mouse, the landscape is moving into the opposite direction. this behavior is more like the middle-mouse-button-directional-scroll function that you can find in adobe pdf viewer and most browsers (you know the one where a circular "anchor" with four arrows appears where your pointer was, and when you move away from that "anchor", the image starts scrolling in that direction?).

for me, it would feel more logical if the landscape moved as if you were dragging it. just my gut, though.
Title: Re: Battlescape development
Post by: luke83 on October 17, 2012, 08:21:53 am
Maybe we can have a "Invert" switch in the configuration, that way everyone can have what feels natural to them..
Title: Re: Battlescape development
Post by: kkmic on October 17, 2012, 11:40:15 am
It was a real-hard work, due to two idiotic coding schemes used in OpenXcom project:
"Opening brackets - this: { - always lined up in their own lines."
"Spaces after commas, operators, and between actual parameters of a method"
The whole OpenXcom sourcecode is totally unreadable because of these! (and when a tab character is showed as 8 space-characters)

This is a known OXC "issue" :)
Title: Re: Battlescape development
Post by: pmprog on October 17, 2012, 11:46:07 am
I disagree with the coding scheme being called idiotic; it's not, it's preference...

I always put brackets on seperate lines, unless I'm doing an "} else {", I will space between my brackets (only function call ones though) and after commas too.
Title: Re: Battlescape development
Post by: Daiky on October 17, 2012, 12:40:22 pm
This is a known OXC issue :)
There is no issue. Openxcom uses the international ISO standard of indenting and spacing, which is by default the style if you start a project with Visual Studio.
Let's not start a coding style war here... I started this thread to update you from time to time with the battlescape development progress.
Title: Re: Battlescape development
Post by: michal on October 17, 2012, 01:06:41 pm
Let's not start a coding style war here... I started this thread to update you from time to time with the battlescape development progress.

Agree, let's not steal this topic. So, Daiky - what's up? ;) What's next for battlescape? Stop playing XCom and return to coding OpenXcom ;)
Title: Re: Battlescape development
Post by: Daiky on October 17, 2012, 02:56:08 pm
What's next for battlescape?
I think the alien base mission was already rather complete, it needs some finishing in the way the map modules are glued together, and I think how the items are spawned. Items are now on 1 single stack like in the skyranger, but in an alien base mission, in the original game items on the ground are on different places, if I am not mistaken. I don't know yet what kind of logic is behind the items on the ground in alien base missions...
Title: Re: Battlescape development
Post by: SupSuper on October 17, 2012, 03:03:20 pm
It was a real-hard work, due to two idiotic coding schemes used in OpenXcom project:
"Opening brackets - this: { - always lined up in their own lines."
"Spaces after commas, operators, and between actual parameters of a method"
The whole OpenXcom sourcecode is totally unreadable because of these! (and when a tab character is showed as 8 space-characters)
When you start your own project, you get to dictate your own coding style. ;)

Anyways it's a non-issue since there's plenty of tools to automatically apply coding styles (eg. Artistic Style (https://astyle.sourceforge.net/)), so you can just convert the project to your favorite convention, do your stuff and restore it back when you're done. Everybody wins. :)
Title: Re: Battlescape development
Post by: Daiky on October 17, 2012, 08:34:07 pm
Today I celebrate my 2 years with openxcom, it was October 17, 2010 when I first presented the little community we had those days with a screenshot of the battlescape. One day later I presented SupSuper with a 1787 lines long patch file, which contained the earliest battlescape: it loaded a map and you could scroll around. Everyone was excited about that back then :)
Go back to page 1 of this thread if you want to get that feeling again :)
Title: Re: Battlescape development
Post by: luke83 on October 17, 2012, 08:49:45 pm
Today I celebrate my 2 years with openxcom, it was October 17, 2010 when I first presented the little community we had those days with a screenshot of the battlescape. One day later I presented SupSuper with a 1787 lines long patch file, which contained the earliest battlescape: it loaded a map and you could scroll around. Everyone was excited about that back then :)
Go back to page 1 of this thread if you want to get that feeling again :)

Congratulations - you ( and Supsuper also) are doing a great job
Title: Re: Battlescape development
Post by: Daiky on October 17, 2012, 09:49:05 pm
A quick guide to digging hallways (corridors) between base (alien and xcom) modules:
1) check if we are not at the end of the map and there is a module nextdoors (in xcom bases there can be places filled with dirt)
2) remove 3 tiles of excess dirt and walls
3) place two new walls on the sides of our hallway
4) finish it off with a nice corner
do this for both north-south and east-west hallways
Title: Re: Battlescape development
Post by: SupSuper on October 17, 2012, 09:59:33 pm
Today I celebrate my 2 years with openxcom, it was October 17, 2010 when I first presented the little community we had those days with a screenshot of the battlescape. One day later I presented SupSuper with a 1787 lines long patch file, which contained the earliest battlescape: it loaded a map and you could scroll around. Everyone was excited about that back then :)
Go back to page 1 of this thread if you want to get that feeling again :)
Ha I remember that feeling. The feeling when I had no clue what to do about the Battlescape and oh gawd everyone is gonna find out how incompetent I actually am and this will never fly and... then you showed up! ;) To many more years of successful development!

It's a shame I never remembered to write down the exact date I started working on OpenXcom, before version control et all, or we could celebrate that too. Earliest I could find was a VC2005 project file last changed February 2009.
Title: Re: Battlescape development
Post by: pmprog on October 17, 2012, 10:38:29 pm
I just remember I was about to volunteer, then Daiky sent me his first draft of a battlescape design doc, and I was like "w00t?". You've done a great job! A much better job than I would have done too.

And a general congratulations to everyone who has made OpenXCOM what it is today. I'm impressed, and very jelous and also a little sad (that I failed to contribute more than I have)
Title: Re: Battlescape development
Post by: Fenyő on October 18, 2012, 09:10:28 pm
I like the idea of a mouse scrolling method for the battlescape, that's certainly something that has been long missing. :) to me, however, your way seems counter-intuitive: for mouse-scrolling I would always assume that it works as though you are grabbing the landscape and pulling into a direction by moving. your way is exactly the other way around: you hold the mouse, and when you move the mouse, the landscape is moving into the opposite direction.
Actually it shows you the place where you move the mouse. :)
This is the way OpenTTD also works! (and i've got the idea primarily from TTD/OpenTTD)

Maybe we can have a "Invert" switch in the configuration, that way everyone can have what feels natural to them..
That's an other good idea!!
And it will be implemented i think. (if not nowadays by me, then later someone else)

I disagree with the coding scheme ...  it's preference...
Not for me...
It considerably slows down my work.

ISO standard of indenting and spacing,
Just for curiosity, could you please give me a reference, where it is officially stated, that this indenting and spacing is the ISO? (i haven't found any)

which is by default the style if you start a project with Visual Studio.
That's the first thing i change by loading back my configuration after an install.

Anyways it's a non-issue since there's plenty of tools to automatically apply coding styles (eg. Artistic Style (https://astyle.sourceforge.net/)), so you can just convert the project to your favorite convention, do your stuff and restore it back when you're done. Everybody wins. :)
Wow! Long time i planned to make such a thing to avoid these situations. Its good to know, that somebody already done this!
Thanks for the link!

Today I celebrate my 2 years with openxcom, it was October 17, 2010 when I first presented the little community we had those days with a screenshot of the battlescape. One day later I presented SupSuper with a 1787 lines long patch file, which contained the earliest battlescape: it loaded a map and you could scroll around. Everyone was excited about that back then :)
Go back to page 1 of this thread if you want to get that feeling again :)
Congratulations  ;)
Title: Re: Battlescape development
Post by: d2uriel on October 18, 2012, 09:46:42 pm
fenyo1 - there's an edit option for your posts. Posting 6 times in a row looks kind of silly...
Title: Re: Battlescape development
Post by: Fenyő on October 18, 2012, 10:43:18 pm
fenyo1 - there's an edit option for your posts. Posting 6 times in a row looks kind of silly...
Yeah, but it is simpler. (editing, and a lot of copy&paste we're talking about)
Title: Re: Battlescape development
Post by: Daiky on October 18, 2012, 11:47:06 pm
since fenyo1 has been on the forum,  I spend whole nights scrolling through his 1-line posts,  it explains why I don't have time left to code :p
Title: Re: Battlescape development
Post by: Fenyő on October 21, 2012, 08:06:46 pm
I've just made a Pull-request with my new invention:  :)

New feature: Can prime a grenade on mission pre-equip (Inventory view) with a right-click

It only works on mission start.

EDIT:
:D
I was just about to implement showing soldier weight in inventory view (like in UFOextender), but i had to realize that soldiers weighting, TU-penalties by weight, they are completely unimplemented yet! :D
Title: Re: Battlescape development
Post by: Fenyő on October 22, 2012, 04:23:28 pm
SupSuper!

I think there is no reason to the implementation named "- Added Battlescape camera position to saves.", if the game centers the currently selected unit anyways. (after game-load) :)
Title: Re: Battlescape development
Post by: SupSuper on October 22, 2012, 05:04:22 pm
SupSuper!

I think there is no reason to the implementation named "- Added Battlescape camera position to saves.", if the game centers the currently selected unit anyways. (after game-load) :)
Hmm really? I remember the camera often ended up somewhere random after loads, and it'd be handy for all the battlescape stuff where the camera ends up focused on something completely unrelated. I'll wait for Daiky's opinion on it.
Title: Re: Battlescape development
Post by: kkmic on October 22, 2012, 05:10:52 pm
I'd say you should save the camera position. After all, it is a "saved" game, right?
Title: Re: Battlescape development
Post by: Fenyő on October 22, 2012, 05:13:03 pm
I'd say you should save the camera position. After all, it is a "saved" game, right?
It is already saved. :)
The problem is the game does not use it on load-back, when an X-COM unit is selected.
Title: Re: Battlescape development
Post by: kkmic on October 22, 2012, 05:17:16 pm
I see your point.

Hmmm..... tough decision.

So if there is a unit selected, the camera focuses on it on load, and if there is none, the camera saved position is used?
Title: Re: Battlescape development
Post by: Fenyő on October 22, 2012, 05:44:36 pm
At least it should. :)
I've just made a quick test with no unit selected, in this case it puts the camera to [0,0]. :)
Title: Re: Battlescape development
Post by: Fenyő on October 22, 2012, 09:03:26 pm
With the newest updates (GIT-build 2012_10_22_1842) the camera in Battlescape is placed to [0,0] also if unit is selected. (when quitting OpenXcom and relaunch it again)
Title: Re: Battlescape development
Post by: SupSuper on October 22, 2012, 09:28:52 pm
Ugh screw it I'll just get rid of it and Daiky can look into it himself if he wants.
Title: Re: Battlescape development
Post by: Daiky on October 22, 2012, 09:42:31 pm
I'll sure have a look at it before 1.0 releases
Title: Re: Battlescape development
Post by: Fenyő on October 22, 2012, 09:44:04 pm
before 1.0 releases
:D
Title: Re: Battlescape development
Post by: pmprog on October 24, 2012, 10:39:59 am
Urm, when I was updating my source code I kinda forgot to keep the Snakemen draw rountine?!  :(

If I get chance tonight, I'll have another pop at it
Title: Re: Battlescape development
Post by: Daiky on October 31, 2012, 12:06:15 pm
I'm currently busy merging in Warboy's battlescape work into openxcom, starting with all the aliens we are still missing. It goes well so far, I'm however not committing anything yet, I don't want to keep SupSuper from wrapping up his 0.4.5 version
Title: Re: Battlescape development
Post by: pmprog on October 31, 2012, 12:42:02 pm
Good stuff. I wasn't getting very far with it anyway  :(
Title: Re: Battlescape development
Post by: Volutar on October 31, 2012, 12:44:22 pm
intrersting thing, that info from original xcom (on unit drawing) was kinda ignored. that's how it work. well, copy'n'paste rules
Title: Re: Battlescape development
Post by: luke83 on October 31, 2012, 12:46:01 pm
I'm currently busy merging in Warboy's battlescape work into openxcom, starting with all the aliens we are still missing. It goes well so far, I'm however not committing anything yet, I don't want to keep SupSuper from wrapping up his 0.4.5 version

0.45 , we must be getting close to  0.5 with all the features being worked on :P
Title: Re: Battlescape development
Post by: Warboy1982 on October 31, 2012, 02:51:34 pm
if you're going to merge that code, you should be aware that there's a bug with the soldier/muton drawing routine. (routine0?)
when a unit "falls" (ie: there is no tile under it) it counts as flying and tries to use the flying legs. mutons do not have these entries in their .pck file, so a workaround is in order. my fix was to pack the muton pck file with 8 extra blank tiles representing the flying legs.

also, mutons won't render properly unless you set their "drawmethod" to 1. this is just a flag i added to their ruleset so i could tell whether it was a muton or not from inside the code, in hindsight i suppose the same flag could be used to set whether or not to use flying legs.

anyway, just a heads up.

also: holy crap you're including my code to the master? that's awesome! colour me flattered.
Title: Re: Battlescape development
Post by: Volutar on October 31, 2012, 03:47:49 pm
Actually there is no "flying" state for falling units. At all. Falling units are always treated as standing. "Flying" legs are enabled only for flying state of xcom flying power suit, if there's no ground beneath.
Title: Re: Battlescape development
Post by: Warboy1982 on October 31, 2012, 04:16:23 pm
well, all i'm saying is, i managed to crash it on a muton mission, and the stacktrace showed it was trying to blit the legs, and the unit's movement state was MT_FLYING,
no idea what caused it, but i had the same issue with the police. padding out the pck file seems to have resolved it in both cases, but this is the wrong solution.
i can't say for sure what the circumstances were, because the units weren't visible at the time. whatever the case, i just thought i ought to mention it.
Title: Re: Battlescape development
Post by: Volutar on October 31, 2012, 05:12:31 pm
I guess that happened because unit animation state is screwed. Some bugs in "unit_walk" function or how it called.
Title: Re: Battlescape development
Post by: Daiky on October 31, 2012, 05:41:29 pm
Thanks for mentioning. It's just a matter of checking if the unit has the ability to fly or not, if not: never try to draw these "flying legs", that should fix it. I wouldn't mess around with the movement state, because it controls other stuff too.

edit: hmm, how come it isn't crashing for other non-flying units using drawing routine 0? (sectoids, overalls, personal armor,...)
Title: Re: Battlescape development
Post by: Warboy1982 on October 31, 2012, 07:01:03 pm
if it passes your tests then i'll assume i just did something silly, or the problem was fixed upstream.

this is why i don't make pull requests and leave it to the professionals.
Title: Re: Battlescape development
Post by: luke83 on November 03, 2012, 11:08:41 am
Daiky , are the Mutons supported yet , i just found a feature of gimp i have been trying to find for 12 months ( replace Colour A with Colour B ) and just did a quick test using Mutons, they still don't match the guy on the start up movie...YET, but i really want a Flying variety and  these Red Suits may become them one day.

Update , Black/Grey Mutons look pretty cool also , these ones will most likely become my Flying unit oneday.

Title: Re: Battlescape development
Post by: Daiky on November 03, 2012, 12:28:38 pm
every alien is in, at least in my sandbox, I didn't commit yet, as some things are not finished, like silacoid burning ground
Title: Re: Battlescape development
Post by: Daiky on November 05, 2012, 11:34:05 am
... and the celatid spit. This nasty alien causes a lot of trouble
Title: Re: Battlescape development
Post by: Warboy1982 on November 06, 2012, 08:39:30 am
using the throw calculation for the trajectory works, and the plasma projectile sprite can stand in for the green blob in the pck (for now) but you gotta make sure the throw calculation checks the tile below the source of the projectile as well, or stairs/ramps cause crashes, i wouldn't worry about the pre-spit drop-to-ground animation, it wasn't in the original, so we can live without it until we make a "pre-fire" state for it.

just my two cents.
Title: Re: Battlescape development
Post by: Daiky on November 06, 2012, 12:26:52 pm
yup, it works now. I did a few things differently as in your branch: I introduced two unit variables for the zombie/chryssalid handling (I think you wrote something like that in your comments as a todo), so they are not hardcoded to the units "chryssalid" and "zombie".
Also the celatid spit will become a variable "arcTrajectory" which can be used for any weapon. (if you set this to true on the rocket launcher, you got a grenade launcher ;) )
I merged your melee AI, which seems to work OK. I also merged in a few other bits, like the number of aliens depending on difficulty level.
Title: Re: Battlescape development
Post by: Daiky on November 09, 2012, 09:18:31 pm
A lot of code, like the drawing routines of the additional units, from Warboy is implemented. It should include chryssalids, zombies, celatid, silacoid,...
Also the new A* pathfinding algorithm from karvanit (https://github.com/SupSuper/OpenXcom/pull/158) has been implemented.
Thanks guys. We are getting closer to a fully working (hopefully soon bugfree) battlescape... :)


edit: I believe the chryssalids are currently making a lot of noise :p I'm working on it.
Title: Re: Battlescape development
Post by: Warboy1982 on November 09, 2012, 11:38:16 pm
glad to see you included the left handedness/dual wielding stuff too :D
Title: Re: Battlescape development
Post by: moriarty on November 10, 2012, 12:52:07 am
kinda off-topic or at least off-recent-topic: I just tried the "inverted" RMB-scrolling for the first time, and now I see why this feels odd to you all: it IS odd, the way it is now.

the way I was thinking about it would have involved the cursor moving with the landscape, truly "dragging" it.

the problem with the way it works now (in both "normal" and "inverted" mode) is that this implementation introduces a mouse movement that isn't parallel to the cursor movement, which will always lead to a break in "calibration", which means it forces you to lift the mouse up and re-position it to have a comfortable interface again.
Title: Re: Battlescape development
Post by: Daiky on November 10, 2012, 11:23:14 am
moriarty, it probably is this topic you were looking for: https://openxcom.org/forum/index.php/topic,655.0.html
(it's fenyo's mouse scrolling pull request)

I'm also more in favor of "map dragging" instead of "camera panning", and I think map dragging is more standard (in all modern games RTS games, in google maps and every other normal map application and every touchscreen game I know...). So eventually I'll probably put that in too, together with a "smooth camera movement" option. That will introduce a smooth movement of te camera when following a bullet, together with a subtile inertia, so the camera movement doesn't suddenly stop or starts, like when you drag and suddenly release slightly ramps down to a stop.
It are these small UI things people are used to in modern games and apps and that makes games that don't have them feel "cheap" to some people.
Title: Re: Battlescape development
Post by: moriarty on November 10, 2012, 12:46:11 pm
ah, thanks, yes, I couldn't find that one... my bad.

I like your plans, especially the smooth bullet following camera. it's those little touches that make openxcom so much better than the original :)
Title: Re: Battlescape development
Post by: Fenyő on November 16, 2012, 07:23:40 am
@moriarty: I've just finished the implementing what you've missed:
Changed: RMB Scroll's Invert mode now works as in Adobe Reader ("map dragging")

its in the PR.
Title: Re: Battlescape development
Post by: Fenyő on November 19, 2012, 03:03:46 pm
@moriarty: Have you tried the new invert mode? What is your opinion?
Title: Re: Battlescape development
Post by: moriarty on November 29, 2012, 08:18:58 pm
Didn't have much time lately... I just tried it and it looks good and feels right. thank you!
Title: Re: Battlescape development
Post by: moriarty on November 29, 2012, 09:58:17 pm
actually, just tried it some more, and found one issue :)

if you move your cursor to the edge of the screen (or window if playing windowed), the game starts its usual edge-scrolling! so if for example you want to scroll to the right, you "grab" something on the right-hand side of the screen and "drag" to the left, but once you reach the edge it starts scrolling to the left, because you hit the left edge!

I think there are two possible fixes for this:

1) disable the edge-scrolling mechanism while holding right mouse button (scrolling should continue beyond the edges of the screen, then.)

2) invert the edge-scrolling mechanism while  "battleScrollButton: [whatever]" is pressed AND "battleScrollButtonInvertMode" is "inverted"


btw, I think you should change that "battleScrollButtonInvertMode" to accept "true" and "false" as options, to have it consistent with the other "switches" in the config file, don't you think? maybe call it "battleScrollButtonModeInverted" instead, defaulting to "false".
Title: Re: Battlescape development
Post by: Fenyő on November 30, 2012, 02:02:04 am
if you move your cursor to the edge of the screen (or window if playing windowed), the game starts its usual edge-scrolling! so if for example you want to scroll to the right, you "grab" something on the right-hand side of the screen and "drag" to the left, but once you reach the edge it starts scrolling to the left, because you hit the left edge!
Yeah, i noticed that too. That's a downside of the inverted mode. :)

I think there are two possible fixes for this:

1) disable the edge-scrolling mechanism while holding right mouse button (scrolling should continue beyond the edges of the screen, then.)
I prefer this one. :)
You just need to set the conventional scroll to manual, this way the scrolling near the edges are activated only by a left click.
...At least in original X-Com, OpenXcom now does not make a difference between manual and auto scroll modes. (i think the manual is just not yet implemented :) )

2) invert the edge-scrolling mechanism while  "battleScrollButton: [whatever]" is pressed AND "battleScrollButtonInvertMode" is "inverted"
I don't see the point in this.
A condition (auto-scroll near the edges ONLY if Right(/Mid)-button is not in pressed state) to the auto-scroll should have more sense, i think.

btw, I think you should change that "battleScrollButtonInvertMode" to accept "true" and "false" as options, to have it consistent with the other "switches" in the config file, don't you think? maybe call it "battleScrollButtonModeInverted" instead, defaulting to "false".
Maybe. :)
Originally i thought it is better to have special values which are related to the option, (they express the thing better, more clearly to the user) this is why i didn't make it a boolean.

Others? What do you think? Do you guys also vote to change it to boolean?
Title: Re: Battlescape development
Post by: Daiky on December 17, 2012, 05:47:22 pm
See, you can walk on Mars in coveralls perfectly fine :)
Title: Re: Battlescape development
Post by: pmprog on December 17, 2012, 05:52:37 pm
Awesome! Good work! I look forward to start my Let's Play game
Title: Re: Battlescape development
Post by: michal on December 18, 2012, 09:35:04 am
It's one small step for x-com soldier, but one giant leap for OpenXcom community.
Title: Re: Battlescape development
Post by: pmprog on December 19, 2012, 02:07:16 pm
I've just seen a push for Mars battles. Is that the game completable?
Title: Re: Battlescape development
Post by: Warboy1982 on December 19, 2012, 08:14:50 pm
it is now.
Title: Re: Battlescape development
Post by: pmprog on December 20, 2012, 01:32:29 am
Awesome! Have to get set up to start my Interactive Let's Play :)
Title: Re: Battlescape development
Post by: Daiky on January 08, 2013, 04:44:24 pm
It seems some people are saving their game during battle, I can advice to save and load as much as possible during geoscape only, and try to be a man and don't save/load during battle :p

But anyhow, for those people that still insist to save during battle, I'm (again) (thinking of) saving the battlescape terrain in a binary way.
Because of a current battlescape savegame, that's let's say 18000 lines, there are 12000 lines for the terrain only. It's a bit crazy to have it described in plain text. It's a waste of CPU time and Harddisk space and serves no real purpose, as it's almost as difficult to manually edit as it would be a binary blob.

So I've decided on the width of the fields, they are unsigned and as follows: 32bit for the index, (8bits for the terrain ID + 16 bits for the map data id ) x 4 terrain objects, 8 bits for smoke, 8 bits for fire, 8 bits for discovered flag (room for 4 player and 4 alien discovered flags, if that ever might be of any use)

On top of that the "nodelink" concept will be thrown in the bin. The distance between nodes and whether or not they can be reached are calculated on the fly - the precalculated values are nowhere used, but they take up 1500 lines in the savegame file and a bunch of useless objects in memory.

But in the mean time, save/load as much as possible in geoscape only  ;)
Title: Re: Battlescape development
Post by: pmprog on January 08, 2013, 04:56:19 pm
I save when my episode is over - maybe I should just make 3 parters if necessary  ;)

I do agree that load/save times really need to be improved, so anything you can do would be great
Title: Re: Battlescape development
Post by: SupSuper on January 08, 2013, 08:11:06 pm
Did you see the previous discussions regarding load/save? They had some interesting ideas (eg. only save non-default values, don't save blanks/nulls/empty/etc):

https://openxcom.org/forum/index.php/topic,799.0.html
https://openxcom.org/forum/index.php/topic,758.15.html

Also I've been informed that the newest yaml-cpp version is incompatible with OpenXcom as they've changed to a new better API. For now we can stick to the old one, but at some point we'll have to rewrite it all... I can already see the sheer excitement in your face. :P
Title: Re: Battlescape development
Post by: Daiky on January 08, 2013, 11:16:43 pm
Alienfoods' code change has been already implemented by Warboy in the master branch. My savegame with alienfoods' improvement is now 422kb and using my binary method further reduced to 161kb + the save/load time is reduced even more, because instead of a yaml key/value pair for each tile, the binary blob with all tiles is just 1 key/value pair.
Title: Re: Battlescape development
Post by: Volutar on January 09, 2013, 08:35:37 am
Very nice. Having map(tile) data in text format was insane. Daiky, I suppose unit/object/route data is still text? And map data is some single "huge blob" encoded in something like UUE or base64?
Title: Re: Battlescape development
Post by: Daiky on January 09, 2013, 10:46:57 am
The rest is still text, but they are a lot smaller. The yaml library automatically encodes binary to base64.

edit: having lots of troubles getting it working however. I'm not very experienced with binary, for example how to convert a series of unsigned char * to int's or vice versa. I'm doing things like buffer[ptr] + buffer[ptr+1] << 8 + buffer[ptr+2] << 16 + buffer[ptr+3] << 24 ... don't know if it's best practice. The version I currently have is constantly crashing on loading, so there must be things wrong.
Title: Re: Battlescape development
Post by: Yankes on January 10, 2013, 07:16:49 pm
The rest is still text, but they are a lot smaller. The yaml library automatically encodes binary to base64.

edit: having lots of troubles getting it working however. I'm not very experienced with binary, for example how to convert a series of unsigned char * to int's or vice versa. I'm doing things like buffer[ptr] + buffer[ptr+1] << 8 + buffer[ptr+2] << 16 + buffer[ptr+3] << 24 ... don't know if it's best practice. The version I currently have is constantly crashing on loading, so there must be things wrong.
try this
Code: [Select]
buffer[ptr] + (buffer[ptr+1] << 8) + (buffer[ptr+2] << 16) + (buffer[ptr+3] << 24)and remember
Code: [Select]
std::cout<< a + 5 << std::endl;use same operator :>
Title: Re: Battlescape development
Post by: hmaon on January 10, 2013, 08:43:45 pm
try this
Code: [Select]
buffer[ptr] + (buffer[ptr+1] << 8) + (buffer[ptr+2] << 16) + (buffer[ptr+3] << 24)

try also
Code: [Select]
*((int*) (buffer+ptr))or
Code: [Select]
*((int*) &(buffer[ptr]))
That is, assuming the number is always in native endianness. The code with the shifts and adds assumes a little-endian integer.

edit: Also, if you use the shifts and adds code, make sure buffer is declared unsigned char*. Otherwise you will have trouble.

Test code:
Code: [Select]
#include<stdio.h>
#include<stdlib.h>

int main()
{
    unsigned char buffer[] = {0xff, 0x7f, 0, 0};
    char caveat[] = {0xff, 0x7f, 0, 0};
    int ptr = 0;

    printf("%d\n", *((int*) (buffer+ptr)));
    printf("%d\n", buffer[ptr] + (buffer[ptr+1] << 8) + (buffer[ptr+2] << 16) + (buffer[ptr+3] << 24));
    printf("%d\n", caveat[ptr] + (caveat[ptr+1] << 8) + (caveat[ptr+2] << 16) + (caveat[ptr+3] << 24));
}

output:
Code: [Select]
32767
32767
32511
Title: Re: Battlescape development
Post by: Daiky on January 10, 2013, 09:30:56 pm
thanks for the hint.
So if you save a file and transfer it to a system with other endianness and try to load it there, that'll not work with that casting/pointer thing. So I prefer the one with the shifts, so you convert using same endianness?
Title: Re: Battlescape development
Post by: hmaon on January 10, 2013, 11:03:48 pm
thanks for the hint.
So if you save a file and transfer it to a system with other endianness and try to load it there, that'll not work with that casting/pointer thing. So I prefer the one with the shifts, so you convert using same endianness?

Yeah. Just sure you're writing the integers for saving also using shifts and in the same order, of course.

Another way to make code endianness agnostic is with the htonl() and ntohl() functions, which may be faster and easier to read. Network byte order is big-endian but the byte swap can be implemented using one bswap instruction on x86 instead of four shifts. Also, the one 32-bit read from memory is likely to be faster than reading 8 bytes individually.

So,
Code: [Select]
i = ntohl(*((int*) (buffer+ptr)));
and the write operation:
Code: [Select]
*((int*) (buffer+ptr)) = htonl(i);

It's not a big deal though, I guess.
Title: Re: Battlescape development
Post by: SupSuper on January 11, 2013, 09:54:43 pm
Btw SDL has built-in functions to deal with endianness: https://www.libsdl.org/intro.en/usingendian.html
Title: Re: Battlescape development
Post by: Daiky on January 11, 2013, 10:00:11 pm
I've put this little project on hold until we move to the new yaml cpp API I think, because I fail to see how the loading from binary nodes automatically base64 decodes using the old API. The saving (and base64 encoding) works fine, but the at loading I'm stuck.
Title: Re: Battlescape development
Post by: Amunak on January 22, 2013, 06:12:20 pm
I'd suggest just using save file compression instead of using binary. You could edit it freely if you want, but it won't take up too  much space. There would also preferably be a switch to turn the compression on or off and the game would be able to read both compressed and uncompressed save files. Dwarf Fortress does it this way and it works nice.
Title: Re: Battlescape development
Post by: Volutar on January 22, 2013, 06:45:47 pm
Compression wont help, because yaml loading of 100500 lines of numbers, even if they would be compressed, is very slow.
Title: Re: Battlescape development
Post by: hmaon on February 10, 2013, 11:33:39 pm
I made the binary saves work. Part of the problem was that YAML doesn't seem to actually implement base64 decoding. I had to rip some code out of libb64. Another problem was some confusion when saving 32-bit -1 to an unsigned 16-bit int and then reading it back as 65535. Good times.

Here's the code: https://github.com/hmaon/OpenXcom/tree/binary_saves

I've made a pull request.
Title: Re: Battlescape development
Post by: Volutar on February 13, 2013, 01:38:51 pm
I've faced with IMHO bad battlescape/basescape dimentions naming.
Like:
X = _width
Y = _length
Z = _height

I'm asking for permission to rename them into
X = _Xsize
Y = _Ysize
Z = _Zsize

In sake of better understandability and readability.
so getLength() will be renamed to getYSize()
getLength is actually nonsense in terms of 3d object.
Title: Re: Battlescape development
Post by: Daiky on February 14, 2013, 11:10:59 am
It's a matter of preference imo, both are used. In fact in 3D modelling tools, like 3D studio max, when creating a box for example, you are asked to enter width/length/height. Because you use these words daily when defining the size of objects, it should be familiar terms.

I don't think it's the most urgent problem in openxcom at the moment, better we spend our valuable time (our _Tsize?) in fixing horrible things like aliens seeing and shooting through the roof of the Skyranger... I was kinda shocked during the last stream, I've never seen that happen before.
Title: Re: Battlescape development
Post by: Volutar on February 14, 2013, 12:11:35 pm
Daiky, there's a hole in skyranger's cabin. And that could (and most probably) happened in xcom1 too. You cannot fix that without fixing MCD files.
voxel22 is slice of level 22 (2nd level, z=20).
from save "losholes" given by warboy.
First person view of what Etherial have saw is on FPSlook.jpg

See, we can do nothing about it. This bug is xcom1 legacy. If you didn't see how this happened before - it doesn't mean it was never happened.
Title: Re: Battlescape development
Post by: Daiky on February 14, 2013, 01:12:51 pm
Volutar, thanks for clarify that one up :) It must have been something like that.
We probably have to make the discussion of openxcom providing patches to data files active again.
Title: Re: Battlescape development
Post by: Volutar on February 14, 2013, 01:16:06 pm
By searching for cause of this "bug" I've made an eye-shot.
In debugging purpose it could be quite helpful.
Title: Re: Battlescape development
Post by: pmprog on February 14, 2013, 01:31:04 pm
Are those FPS shots something you've added into the battlescape code? or an external util that loads a save game?
Title: Re: Battlescape development
Post by: michal on February 14, 2013, 01:57:33 pm
Looks like it's waiting to be merged ;)

https://github.com/SupSuper/OpenXcom/pull/305
Title: Re: Battlescape development
Post by: moriarty on February 14, 2013, 03:36:51 pm
very cool... :) that's a very useful tool for tracking down LOS/LOF problems. nice work!
Title: Re: Battlescape development
Post by: Volutar on February 14, 2013, 04:32:20 pm
moriarty, but not terrain-based, since there is no voxel tracing. for terrain "discovery" tile "stoplos" flag used. that's all.
Title: Re: Battlescape development
Post by: moriarty on February 14, 2013, 04:41:41 pm
I'm not sure I get that:
are you saying that for terrain, there's no LOS voxel tracing?
instead the game uses some other algorithm to check if the terrain between a unit and another tile is "in the way"?

what about unit discovery? does the game check for "true" (voxel-based) LOS?

what happens when a hill tile has been destroyed? does it still block LOS?
Title: Re: Battlescape development
Post by: Volutar on February 14, 2013, 05:04:03 pm
unit-unit los/lof is always voxel-based. terrain fov calculation uses tile-based "scan".
Title: Re: Battlescape development
Post by: SupSuper on February 14, 2013, 06:51:52 pm
Volutar, thanks for clarify that one up :) It must have been something like that.
We probably have to make the discussion of openxcom providing patches to data files active again.
I have no problem with people making fixed version of the data files (just make it separate from the binary release). After all people have been patching the original (https://www.strategycore.co.uk/files/ufo-enemy-unknown/patches/) for ages. It's just me and Warboy found out those patches have their own bugs... so, you know, if anyone actually manages to fix the bugs without introducing new ones, I'm totally all for it. :P
Title: Re: Battlescape development
Post by: Volutar on February 14, 2013, 11:22:20 pm
It's clearly seen that there are 2 large holes in skyranger cockpit (it's view from inside). And Jade's case could easily happen in xcom1 as well. It probably did happen, but stood unnoticed. Condition is - farm/terror city and high building with stair to roof at south of skyranger.
Jade was very lucky to pick certain conditions in openxcom.
Title: Re: Battlescape development
Post by: Volutar on February 15, 2013, 05:36:55 am
That's how fixed PLANE.MCD looks like:
Title: Re: Battlescape development
Post by: kkmic on February 15, 2013, 03:18:25 pm
How do we patch the original data files without altering them? Is there support in OXC for some kind of dynamic patches?
Title: Re: Battlescape development
Post by: Volutar on February 15, 2013, 06:58:05 pm
You have to alter them in order to avoid this bug. It's bug of Microprose, or Gollop, or whoever... but not ours.
Title: Re: Battlescape development
Post by: moriarty on February 15, 2013, 09:45:12 pm
would it be possible to "externalize" parts of the files in question? I believe the error is in loftemps.dat (https://www.ufopaedia.org/index.php?title=LOFTEMPS), which is a conglomerate of 16x16 pixel/voxel "images". so perhaps we could provide corrected images that are used if present? so that if there are external LOF templates for the skyranger, the game uses those instead of the original ones?

(because I don't think we can "fix" the files and host them, for the same reasons that we cannot host the original game.)


as for the diagonally-touching-objects LOS "holes": wouldn't it be possible to make openxcom automatically fill those gaps? something like "IF loftemp voxels touch diagonally THEN pretend there's another voxel between them"?
Title: Re: Battlescape development
Post by: Volutar on February 15, 2013, 10:01:19 pm
i've attached fixed plane.mcd. so answer is no. problem is not in loftemps.
and there are no diagonal gaps and holes in openxcom. long ago.
Title: Re: Battlescape development
Post by: moriarty on February 15, 2013, 10:06:59 pm
ah, now I see. of course you are right. are there more mcd files with major bugs in them? the supply ship has a hole, so that makes two. any others? because I think providing a very small number of altered files may be ok, like an "unofficial patch", but if it turns out that we have to fix all of the ships, that would be like hosting a major portion of a copyrighted game :(
Title: Re: Battlescape development
Post by: luke83 on February 15, 2013, 11:00:39 pm
StratergyCore already hosts a number of xcom Bug fixes , you just need to uploaded them somewhere also to keep it separate from OXC, obviously i suggest the Mod site as it keeps the main project safe :P  maybe we add a vanilla patch page?
Title: Re: Battlescape development
Post by: Warboy1982 on February 16, 2013, 06:35:32 pm
AVOID the strategycore combo patch!
it contains AT LEAST one garbled tileset, and causes numerous problems.

the files i CAN recommend are:
https://www.strategycore.co.uk/files/desert-map-fix/ (https://www.strategycore.co.uk/files/desert-map-fix/)
https://www.strategycore.co.uk/files/general-stores-routes-fix/ (https://www.strategycore.co.uk/files/general-stores-routes-fix/)
https://www.strategycore.co.uk/files/access-lift-routes-fix/ (https://www.strategycore.co.uk/files/access-lift-routes-fix/)
https://www.strategycore.co.uk/files/lightning-mcd-and-lof-fix/ (https://www.strategycore.co.uk/files/lightning-mcd-and-lof-fix/)
https://www.strategycore.co.uk/files/mountainous-mcd-fix/ (https://www.strategycore.co.uk/files/mountainous-mcd-fix/)
https://www.strategycore.co.uk/files/ubits-mcd-fix/ (https://www.strategycore.co.uk/files/ubits-mcd-fix/)
https://www.strategycore.co.uk/files/terror-ship-routes-fix/ (https://www.strategycore.co.uk/files/terror-ship-routes-fix/)

i couldn't find a fix that contained JUST the supply ship, so i made my own.
https://dl.dropbox.com/u/47596892/UFO_170.rar (https://dl.dropbox.com/u/47596892/UFO_170.rar)

and of course, volutar's fix for the holes in the skyranger.
https://openxcom.org/forum/index.php?action=dlattach;topic=87.0;attach=4493 (https://openxcom.org/forum/index.php?action=dlattach;topic=87.0;attach=4493)
Title: Re: Battlescape development
Post by: darkestaxe on March 24, 2013, 10:30:46 pm
If we create a patch that contains all the fixed original x-com data files needed for use with open x-com compiled into one file it could be hosted anywhere by anyone, aka strategycore. We could call it OXC_Original_Data_Fix.rar or OpenXcom_Data_Patch.zip and Readme.txt would tell users to overwrite files in the Data folder, then special thanks to (everyone who created the fixed files).
Title: Re: Battlescape development
Post by: AMX on April 02, 2013, 02:19:31 pm
AVOID the strategycore combo patch!
it contains AT LEAST one garbled tileset, and causes numerous problems.
Could you list these problems, so Zombie can fix them?
He already knows about the broken tileset and the Skyranger LOF issue.
Title: Re: Battlescape development
Post by: Warboy1982 on April 02, 2013, 04:30:04 pm
most of the problems it causes (for me) are related to the introduction of "new" tiles that have no equivalent in the vanilla tileset, more specifically, in the farm tileset, floor tiles 76, 77, 79 and 80, which appears in Culta17.
the problem arises when i, with vanilla data, try to load someone's bug report save with their modified data, and hit a wall, because they're incompatible, also i notice MANY of the tilesets (like the stables) we know and love have been removed for whatever reason.

the DESERT01 tileset is a "landing zone", and should be flat, not a pyramid, this caused me problems in the original as well as in openXCom.

going over the patch notes... it seems like you may have had a modified set of CULTA/DESERT data from the outset, because i can't see any mention of replacing any existing tilesets. this makes me suspect XcomUtil as the source of our woes, as i'm fairly certain that had some replacement tilesets for those 2 specific map sets.
Title: Re: Battlescape development
Post by: AMX on April 02, 2013, 06:36:13 pm
I see.
I'll shuttle that over to the thread on strategycore.
Title: Re: Battlescape development
Post by: Daiky on May 19, 2013, 01:17:09 pm
The terrain selection part of the battlescape generation is now unhardcoded and moved to the ruleset. Finally.

It works like this:
It will first look for a terrain linked to the mission type and use that one if found.
Otherwise it will take the globe texture and looks up a terrain that has that globe texture in it's list of textures. If hemisphere is defined on the terrain (-1:northern +1:southern) that will have to match the hemisphere taken from the latitude of the UFO.
Next it will look for "shade" defined on mission type, if not found it will use shade from globe position.

So you can now make your own bananafarm terrain which is the farm terrain for the southern hemisphere with matching crops taken from the JUNGLE dataset... or so. Anyway, it's another small step towards TFTD and more moddability. Let me know if any issues appear as a result of this change
Title: Re: Battlescape development
Post by: Warboy1982 on May 20, 2013, 12:11:28 am
snuck this in while no one was looking: (https://github.com/SupSuper/OpenXcom/commit/297a25c4dbf8ca737d0a88344bbda58bbb3bd149)
Title: Re: Battlescape development
Post by: kkmic on May 20, 2013, 12:14:59 am
The terrain selection part of the battlescape generation is now unhardcoded and moved to the ruleset. [...] it's another small step towards TFTD and more moddability.

Cool!
Title: Re: Battlescape development
Post by: winterheart on May 20, 2013, 08:40:39 am
snuck this in while no one was looking: (https://github.com/SupSuper/OpenXcom/commit/297a25c4dbf8ca737d0a88344bbda58bbb3bd149)

Nice. It is possible show number of required TUs while hovering cursor over terrain (like in Jagged Alliance 2)?
Title: Re: Battlescape development
Post by: Volutar on May 20, 2013, 09:50:52 am
Before hovering numbers, hovering path should be implemented (with some delay for exmaple). It is possible.
Title: Re: Battlescape development
Post by: pmprog on May 20, 2013, 10:45:03 am
Or could just display the number of TUs when the path preview becomes active; then if and when an auto-path-preview hover goes in, the TUs will be available too ;)
Title: Re: Battlescape development
Post by: 54x on May 25, 2013, 01:43:48 am
So the yellow is for movement that can't be completed with the current shot reservation?

If so that's pretty neat. Also, thanks for using a different enough hue for colourblindness- I usually can't tell green from yellow in some games where they use very bright greens and yellows.
Title: Re: Battlescape development
Post by: Warboy1982 on January 26, 2014, 06:40:09 pm
gonna start updating this a bit, as it seems to have stagnated.

so: recent feature additions:

Aliens will now shoot at and destroy base modules if left unchecked. fully destroyed base modules will be removed from the base at the end of battle. any facilities that become disconnected from the access lift will also be destroyed. any destroyed modules will have their contents destroyed as well, not including personnel.
for map makers: for a facility to be considered "destructible" by the engine, it must have an "object" on the top floor whose MCD has byte 60 set. go here (https://www.ufopaedia.org/index.php?title=MCD#Structure) for more information on what this means if you're unsure.

Range Based Accuracy has been renamed to UFO Extender Accuracy, and has been brought back in-line with the original method. the major difference is that i've set the values on a per-weapon basis rather than a global variable for all weapons. i've also expanded on this a little to provide a "minimum effective distance" that works much the same way, except in reverse: the closer the target beyond the minimum range, the higher the accuracy penalty.
the minimum and aimed shot ranges will come into effect regardless of whether the setting is enabled. by default these ranges are 0 and 200 respectively, so with default settings, nothing will change, but should you decide to add a modded item that DOES have these defined as real values, you will get the intended effect. (i have sniper rifles and shotguns in mind)
if you're having trouble understanding exactly what all these numbers mean, UFO extender accuracy comes with a real-time accuracy display on your aiming cursor, so you can easily get an idea of the in-game effects.
Title: Re: Battlescape development
Post by: Tarvis on January 27, 2014, 05:49:06 am
I like the change, but whew, that's harsh! Couldn't it be something where disconnected modules become turned into a build queue with 0 time to complete? That way you get them back as soon as the connecting module is rebuilt. It doesn't make much sense to completely destroy a large section just because it got blocked off. (especially since aliens spawn in the access lift so might be inclined to destroy that first)

So I know you said personnel are kept, but what happens? Do you then have more personnel than you are technically able to handle? Will this not cause problems elsewhere?

What about equipped items? Will those be magically lost at the end of the battle if you lose all storage modules?
Title: Re: Battlescape development
Post by: Warboy1982 on January 27, 2014, 06:33:11 am
items aren't destroyed, your storage merely goes into overflow, and any incoming item transfers end up at the dead letter office.
the same happens with personnel regarding living quarters; you go into overflow, and any incoming scientist or engineer transfers go to the dead letter office.

if your workshop is destroyed, you will have engineers taken off projects until the number still assigned is equal to the left over amount of space available. if this causes 0 engineers on a given project, that project will be lost. the same goes for laboratories and psi training facilities.

if you lose a hangar, you also lose the craft contained within it. all the items at your base will be represented on the battlescape, and recovered at the end. so whether you lose them or not depends entirely on what happens in the course of the battle.

the access lift cannot be destroyed by any means. it contains no objects on the second floor with byte 60, and it cannot become disconnected from itself. hangars, living quarters, storage modules, and probably a couple of others likewise lack any "integral" objects, and as such cannot be directly destroyed by aliens. (disconnection rules still apply though)
Title: Re: Battlescape development
Post by: Tarvis on January 27, 2014, 07:13:36 am
I see. Also, I hadn't realized this was actually a vanilla game mechanic (it never happened to me!) so that is interesting.
Title: Re: Battlescape development
Post by: Warboy1982 on January 27, 2014, 08:48:19 am
I see. Also, I hadn't realized this was actually a vanilla game mechanic (it never happened to me!) so that is interesting.

hence why this was added despite the current feature freeze. ;)
Title: Re: Battlescape development
Post by: kkmic on January 27, 2014, 09:01:44 am
for a facility to be considered "destructible" by the engine, it must have an "object" on the top floor whose MCD has byte 60 set.

Why only on the top floor? To make them harder to reach by the aliens?
Title: Re: Battlescape development
Post by: Align on January 27, 2014, 01:05:15 pm
and any incoming item transfers end up at the dead letter office.
Does this mean that from the player perspective they're lost forever?

It's neat to see the accuracy by the crosshair now, but I'm not sure what exactly it means.
I fired a laser rifle at a spot just barely at 0% range, and one of the six shots ended up hitting the wall there, so I'm guessing we have a cone of fire determined by the accuracy of the weapon and soldier, allowing a theoretical chance of hitting no matter what, whereas >0% accuracy gives a chance to hit directly, ignoring the usual cone of fire rule?
Title: Re: Battlescape development
Post by: redv on January 27, 2014, 05:33:46 pm
It's neat to see the accuracy by the crosshair now, but I'm not sure what exactly it means.

For calculation of shooting, uses two different algorithms. One of them used for calculating trajectory of hit. Second of them used for calculating trajectory of miss. But, even if was selected second algorithm, you still have the chance to hit (yes, I'm not mistaken)))

This number not shows you real probability of hitting. This number just shows you chance to selection the first algorithm.

Your real chance to hit significantly higher.
Title: Re: Battlescape development
Post by: SupSuper on January 27, 2014, 06:24:02 pm
Why only on the top floor? To make them harder to reach by the aliens?
It's just how the facility maps are designed, the bottom floor is just corridors, the top floor has the actual facility. See here for more details: https://www.ufopaedia.org/index.php?title=Base_Defense#Destruction_Of_Base_Facilities
Title: Re: [MAPS] New Terror Mission Map Blocks
Post by: Shoes on April 10, 2014, 07:04:27 pm
it refers to a unit type, rank is defined by that. also, what sailors? we only have males and females here in ufo defense.
i merely added the capacity to define the civilians according to the terrain set.

I was wondering if that definition would go into the ruleset or be accessible some how. I am always thinking about my stat tracking mod ;p Perhaps it would tell you how many sailors and fat cats you killed, instead of a blank "civilian"
Title: Re: Battlescape development
Post by: Warboy1982 on April 10, 2014, 08:50:53 pm
if you need one for your mod, just mod it in, i don't understand what the issue is.
Title: Re: Battlescape development
Post by: Warboy1982 on July 03, 2014, 08:20:59 pm
well, i'm making progress, i have palettes loading in properly for the battlescape, units showing up (with thanks to ando for taking care of the sprite routines), the random terrain sets are all locked and loaded, (roughly 50% of terrains overall) i still need to fix up the background of the battlescape so it's not black, and the battlescape UI isn't exactly perfect. but we're getting there!
here are some screen grabs to tide you over.
Title: Re: Battlescape development
Post by: Angelus_EV on July 03, 2014, 08:37:08 pm
WOW!! great!
Title: Re: Battlescape development
Post by: davide on July 04, 2014, 11:31:36 am
OpenTFTD will be
a vanilla Open TFTD or
a hybrid game or
both ?

I ask that because I am near to convert all TFTD .PCK to use UFO battlescape palette
(I wish a hybrid game)

If you have resolved the multiple pallette problem by code
this work is useless therefore I can address other features that i like.

Thank you for all your efforts
 :-*
Title: Re: Battlescape development
Post by: Warboy1982 on July 04, 2014, 11:44:59 am
i'm only concerned with vanilla. it uses the standard TFTD palette. converting them is probably still worthwhile if you want a hybrid since we only use one palette at a time in the battlescape, i believe yankes is working on some 24bpp stuff that may address that issue but i'm not qualified to comment on that.
Title: Re: Battlescape development
Post by: AndO3131 on July 04, 2014, 12:18:20 pm
Quote
If you have resolved the multiple pallette problem by code
this work is useless therefore I can address other features that i like.

You can safely address other features. Multiple palette problem has been resolved (for example https://openxcom.org/forum/index.php?topic=1312.msg12223#msg12223 (https://openxcom.org/forum/index.php?topic=1312.msg12223#msg12223), https://openxcom.org/forum/index.php?topic=1312.msg12632#msg12632 (https://openxcom.org/forum/index.php?topic=1312.msg12632#msg12632) or https://openxcom.org/forum/index.php?topic=1312.msg12665#msg12665 (https://openxcom.org/forum/index.php?topic=1312.msg12665#msg12665)), although it's not in oficial github branch.
Title: Re: Battlescape development
Post by: Falko on July 04, 2014, 12:49:28 pm
these example posts have their one year anniversary
soooo do you say:
dont work on conversion because ..
some day .. perhaps .. we can use multiple palettes
some day .. perhaps .. we can use 32bit images
in the very near future .. we can use multiple palettes
in the very near future .. we can use 32bit images

Title: Re: Battlescape development
Post by: AndO3131 on July 04, 2014, 05:08:20 pm
We can use 32bit images now in battlescape and ufopedia using code from https://github.com/AndO3131/OpenXcom/tree/32bit_Surface_Support (https://github.com/AndO3131/OpenXcom/tree/32bit_Surface_Support).
When new resource structure will be coded in, multiple palette images may also be used with code from this branch (I'll keep it updated).
Title: Re: Battlescape development
Post by: Jstank on July 04, 2014, 10:14:15 pm
I was thinking it would be neat if when you finished the battle scape portion could you possibly add a TFTD map to the New battle screen in a nightly build?
Title: Re: Battlescape development
Post by: Warboy1982 on July 04, 2014, 10:20:57 pm
you'd need a complete ruleset for that, and i haven't even decided which research tree to run with yet.
Title: Re: Battlescape development
Post by: darkestaxe on July 06, 2014, 09:11:05 am
you'd need a complete ruleset for that, and i haven't even decided which research tree to run with yet.

I'd recommend just using the tree on the ufopedia site for the default treeUfopedia TFTD reaserch tree (https://www.ufopaedia.org/index.php?title=Research_%28TFTD%29). That way you'll be able to look at the pretty picture while your writing the ruleset. Also when people go to ufopedia to look up what they need to get Ion-Armor they'll get the right info without anyone having to correct or expand the article.

And since just about anyone can modify the tech tree in OXC, let some bored moron that isn't doing C++ engine stuff make all the versions they want. Maybe later on when there's a bunch of good techtree versions we can have a menu selector for them.
Title: Re: Battlescape development
Post by: Warboy1982 on July 06, 2014, 12:20:19 pm
problem with that tech tree is that it's the one that has the bugs
Title: Re: Battlescape development
Post by: Hobbes on July 06, 2014, 07:47:24 pm
problem with that tech tree is that it's the one that has the bugs

The one I've attached is for TFTD v2.