OpenXcom Forum
OpenXcom => Open Feedback => Topic started by: Agent-HotChocolate on September 20, 2019, 09:32:53 pm
-
Spent the past week playing.
GOOD JOB GUYS MAKING THIS.
This is how XCOM should have been.
Im still learning the game it still feels different compared to Collectors Edition.
-
Yes, UFO: Enemy Unknown (X-COM: UFO Defense) might be the best ever tactical(+strategical) game created by humans,
and open xcom project makes it x2 more fun to play than old clunky controls.
Thank you guys forever 8)
-
I dont know what exaclty what you have played in the past of the old XCOM´s.
When you are finished with UFO, try TFTD. It is harder.
Then, when you have had alot of shitpants moments in TFTD and still could manage to win TFTD, take a look into the mod "The World of Terrifiying Silence" - "TWoTS".
It offers more shitpants moments. ;)
No, really. TWoTS is amazing. I´m just ~30 hours into it.
-
I've played just the first UFO - that is "UFO: Enemy Unknown" (in USA renamed to "X-COM: UFO Defense") in DOS afair.
The biggest problem with it, by todays standards, was the UI, especially the mouse.
EDIT: and the bugs, I think smoke-tiles-limit bug might be the worst as it disabled entire strategy against most deadly alien attacks: the strategy to shut down EVERYTHING 111!!!!1 in smoke bombs.
Was so very annoying to point the correct unit/tile and not missclick on the one next to it (AFAIR it was lacking a mouse cursor too in most modes, just showing the selection, not how close you are to border of jumping to next one besides it).
Was so fantastic game back then, and still I wouldn't say I see any today that really is so in-depth.
Only thing making it better would be:
- more tactical AI, building real good plans
- collapse terrain (as in UFO-3 / Apocalypse) along with, of course, bigger dimensions, and more variant, maps
EDIT
- getting like 1 or 2 more alien types (back in the day) would be nice too, though I wouldn't say it was a "problem" especially back then
-
We can (and do) make new terrains and bigger battlescape.
AI is serious business. A few small but significant improvements have been done by Otto Hartenstein 23 in the OXCE fork, used by most big mods. The most important one is the sniper/spotter system, which allows enemy units to coordinate fire better. But nobody has yet appeared to really improve the AI on a larger scale, as it's a very ambitious task, and all devs already have their hands full with other updates.
Collapsing terrain is perhaps the most challenging, as it would probably require redoing all maps, both vanilla and custom.
-
Collapsing terrain is perhaps the most challenging, as it would probably require redoing all maps, both vanilla and custom.
If someone codes in the requirements for that i would be more than happy to do my fair share of maps :P I am picturing this as a 3rd map file for each mapset, something we could add through Mapview2 would be fantastic. You would want a global variable in game to turn it off though for a Vanilla Experience.
-
i gave a shot at coding in falling terrain (not really collapsing so it would look ruined). Unfortunately i haven't had a chance to see it in action yet ... but things like lamposts should just go thud down a level. And haybales should fall to the ground. I guess it could look quite comic, but hey ...
It doesn't handle stuff like big trees though. That's where the code would have to get pretty wild, with possibly some extra vars in the MCDs
/idk
-
Very interesting, kevL!
Luke's idea for a third file sounds fine, as it wouldn't conflict with vanilla - no .GRV file means no effect. But as kevL said, it gets really complicated with anything less straightforward than a lamp post, and I have only a limited idea on how it would work. For example, would there be material types? If yes, then it's more of a terrain value than maps...
-
luke and I shot a few messages back & forth about this. We both seemed to center on the idea that the .grv file might have data that connects specific parts to other specific parts on the (specific) Map, as well as perhaps "load-bearing" and "load-transfer" values ...
-
luke and I shot a few messages back & forth about this. We both seemed to center on the idea that the .grv file might have data that connects specific parts to other specific parts on the (specific) Map, as well as perhaps "load-bearing" and "load-transfer" values ...
I'm not sure what it means, but if you mean that all stresses and such would have to be done by the mapper completely by hand, for each block, then... well, sorry, no way...
-
maybe, maybe not (the possibility of some sort of prefabs crossed my mind)
-
What's the problem with starting just with LOF voxels and going from there?
There would be decisions to be had on what shear strength do a wall or a wall joint have - as in how long a wall can hang.
But that can be decided later.
And floors can be hanldled in a DF-like fashion for a start - if it isn't 4-way connected to at least another tile, it falls.
-
I'm not sure what it means, but if you mean that all stresses and such would have to be done by the mapper completely by hand, for each block, then... well, sorry, no way...
Doing it at the MCD Level and apply a support strength to each item sounds like the easy solution but im sure some building configurations wont standup by default if we take that approach. My thought was to do it on a Mapblock level and just flag a few items around the Map as "load bearing" and show area around each "load bearing item" to show how much that enitity is supporting. To me if i only had to flag 8 items per map block this way it doesnt seam like a huge amount of work to be honest, the vanilla Urban set would be done in like 30mins.
Now maths & coding are NOT my things so i will stay out of the details of how you handle it ( as there are plenty of smarter people on here than me) but let me know when your ready to test as im happy to help at that level :)
-
Doing it at the MCD Level and apply a support strength to each item sounds like the easy solution but im sure some building configurations wont standup by default if we take that approach.
Yes, most likely. Still, I'd rather slightly modify some blocks to prevent auto-collapse (just a column here or there) than make another, harder ROUTES.
My thought was to do it on a Mapblock level and just flag a few items around the Map as "load bearing" and show area around each "load bearing item" to show how much that enitity is supporting. To me if i only had to flag 8 items per map block this way it doesnt seam like a huge amount of work to be honest, the vanilla Urban set would be done in like 30mins.
Yeah, but I have several thousand blocks... :)
Now maths & coding are NOT my things so i will stay out of the details of how you handle it ( as there are plenty of smarter people on here than me) but let me know when your ready to test as im happy to help at that level :)
I have no idea how to do that wither, so it's easy for me to throw around "suggestions". But it still sounds most attractive for me to make the change in two places: terrain (to define basic characteristics of a tile) and maps (to refine the forces for a given case, such as, what should be "glued together" and what shouldn't).
-
I was thinking, we could automatically support all existing maps - as in step 2:
1) for each tile we check tiles around to decide:
a) is this tile supported by the one below it (e.g. mountain-top on the earth fill, or tree-top on tree-trunk)
b) if not, then it must be hanging on tiles around it (e.g. a floor tile on other floor tiles around)
most interesting is case B.
On each such tile, we calculate how much support it has. I guess it could be "radiating" from tiles (A), is further away from support then less of it.
Consider floor tiles, on 1st floor (above 0-th ground floor) in e.g. the farm building.
The ones near edge (near wall) are strongly support, the ones in middle are less.
2) When loading a map in battlescape, one-time do following calculations:
For each tile we assume that the support it has now, is the right support for it; and further assume at least 50% of current value is needed for that tile in that place to hang.
We save that value for this tile.
And that should be it.
Of course, still new maps might customise this setting and save support-needed value for each tile, or set it to be e.g. 1..100% of current value (to make certain floors very fragile).
During battlescape, when some tiles are destroyed, we re-check all tiles around (in worst case scane the entire map, but that can be optimised a lot, later).
As walls around that floor are destroyed, support is lessen, and if it falls below 50% of what it was then tile drops off.
As for case (A), simply if the tile below it is gone, then we this one also drops.
Depending on tile type, after falling it might remain (e.g. earth-filled block), or might be removed and instead smoke generated (falling floor tile shatters and is gone) or perhaps changed into object "rubble" sometimes (would be hidden from map and from inventory screen).
-
To my layman eyes this sounds like a pretty good solution for when no specific data is available. Like, any maps made before. These default values should probably be average or something.
-
Only problem would be that it would "crash" current maps if not done properly, and I do not mean QTD but celling falling on your solders on first turn.
-
lol
we gonna need sound fx
-
Only problem would be that it would "crash" current maps if not done properly, and I do not mean QTD but celling falling on your solders on first turn.
Exactly, that's why I said that the default support value (when no data is present) should be average. Which means, fairly high across the board.
-
What are your thoughts on units stepping on damaged or partially supported floor tiles with open space below?
1. Would they have a chance of falling through?
2. Depending on their weight maybe?
3. Would armor weight modifiers affect this?
4. If the floor tile was on fire, would that increase the chance of falling through?
5. What if they are flying units?
6. Does it matter if they have legs like a soldier in flying armor or if they always fly or hover like a cyberdisc?
My thoughts:
1. yes
2. definately
3. extra weight yes, negative weight depends on technology servo assist like a loader suit no, antigrav yes
4. definately
5. floor tile should have a smaller chance of collapse, unit won't fall through
6. flying units that contact the floor should have a small chance of floor tile collapse, hovering units probably not although something like a jet pack probably should have a small chance of causing collapse.
There probably should be a threshold weight below which lighter units can't cause a collapse and increasing odds for collapse the more the unit is above the threshold weight. The threshold weight would be defined per tile type and modified by amount of support it has. For example, the threshold weight for a ufo roof tile next to the hole caused by an engine explosion would be much higher than that of a damaged wooden floor tile next to a hole caused by an alien grenade.
Some random thoughts:
Consider a heavy unit crossing a frozen pond. Does it have a chance of falling through the ice?
Consider soft terrain like quicksand. Can a unit fall in and get stuck?
Edit:
There should probably be a modifier at the battle level in order to account for environmental effects such as underwater or off-world terrain.
-
If someone codes in the requirements for that i would be more than happy to do my fair share of maps :P I am picturing this as a 3rd map file for each mapset, something we could add through Mapview2 would be fantastic. You would want a global variable in game to turn it off though for a Vanilla Experience.
today it look be better if you make mb when you sent interceptor to fight near ufo and set view to "Stormovik: Su-25 Soviet Attack Fighter" 1990 and it turn it new way! Thanks for.