Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - osd_daedalus

Pages: [1] 2
Programming / Re: Problem in Compile
« on: May 31, 2020, 01:20:37 pm »
Looking on yaml-cpp it have this function from yaml-cpp-0.5.3 onward, you probably have some older version

That's why... KDE neon linux repositories are sitll distributing yaml-cpp 0.5.2. I just need to do some manual updates and I'm OK again  :)

Programming / Re: Problem in Compile
« on: May 27, 2020, 09:04:58 pm »
Something changed in one of latest commits...

Code: [Select]
deda@neon:~/Coding/OpenXcom/build$ git pull
Already up to date.
deda@neon:~/Coding/OpenXcom/build$ make clean
deda@neon:~/Coding/OpenXcom/build$ cmake .
-- OpenGL libraries: /usr/lib/x86_64-linux-gnu/;/usr/lib/x86_64-linux-gnu/
-- PKG_DEPS_LDFLAGS: -lSDL;-lz;-lSDL_image;-lSDL;-lSDL_gfx;-lSDL;-lSDL_mixer;-lSDL;-lyaml-cpp;/usr/lib/x86_64-linux-gnu/;/usr/lib/x86_64-linux-gnu/;dl
-- doxygen: /usr/bin/doxygen
-- Configuring done
-- Generating done
-- Build files have been written to: /home/deda/Coding/OpenXcom/build
deda@neon:~/Coding/OpenXcom/build$ make
[  0%] Building C object src/CMakeFiles/openxcom.dir/__/libs/miniz/miniz.c.o
[  0%] Building CXX object src/CMakeFiles/openxcom.dir/lodepng.cpp.o
[  1%] Building CXX object src/CMakeFiles/openxcom.dir/main.cpp.o
[  1%] Building CXX object src/CMakeFiles/openxcom.dir/md5.cpp.o
[  1%] Building CXX object src/CMakeFiles/openxcom.dir/Basescape/BaseInfoState.cpp.o
In file included from /home/deda/Coding/OpenXcom/src/Basescape/BaseInfoState.cpp:24:0:
/home/deda/Coding/OpenXcom/src/Basescape/../Mod/Mod.h: In constructor ‘OpenXcom::LoadRuleException::LoadRuleException(const string&, const YAML::Node&, const string&)’:
/home/deda/Coding/OpenXcom/src/Basescape/../Mod/Mod.h:127:189: error: ‘const class YAML::Node’ has no member named ‘Mark’
 ode, const std::string& message) : Exception{ "Error for '" + parent + "': " + message + " at line " + std::to_string(node.Mark().line)}
/home/deda/Coding/OpenXcom/src/Basescape/../Mod/Mod.h:127:201: error: no matching function for call to ‘OpenXcom::Exception::Exception(<brace-enclosed initializer list>)’
 e, const std::string& message) : Exception{ "Error for '" + parent + "': " + message + " at line " + std::to_string(node.Mark().line)}
In file included from /home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Script.h:31:0,
                 from /home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/Soldier.h:24,
                 from /home/deda/Coding/OpenXcom/src/Basescape/../Engine/State.h:23,
                 from /home/deda/Coding/OpenXcom/src/Basescape/BaseInfoState.h:20,
                 from /home/deda/Coding/OpenXcom/src/Basescape/BaseInfoState.cpp:19:
/home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Exception.h:33:2: note: candidate: OpenXcom::Exception::Exception(const string&)
  Exception(const std::string &msg);
/home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Exception.h:33:2: note:   conversion of argument 1 would be ill-formed:
/home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Exception.h:30:7: note: candidate: OpenXcom::Exception::Exception(const OpenXcom::Exception&)
 class Exception : public std::runtime_error
/home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Exception.h:30:7: note:   conversion of argument 1 would be ill-formed:
/home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Exception.h:30:7: note: candidate: OpenXcom::Exception::Exception(OpenXcom::Exception&&)
/home/deda/Coding/OpenXcom/src/Basescape/../Engine/../Savegame/../Engine/Exception.h:30:7: note:   conversion of argument 1 would be ill-formed:
src/CMakeFiles/openxcom.dir/build.make:158: recipe for target 'src/CMakeFiles/openxcom.dir/Basescape/BaseInfoState.cpp.o' failed
make[2]: *** [src/CMakeFiles/openxcom.dir/Basescape/BaseInfoState.cpp.o] Error 1
CMakeFiles/Makefile2:135: recipe for target 'src/CMakeFiles/openxcom.dir/all' failed
make[1]: *** [src/CMakeFiles/openxcom.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

No clue on what could I do...  maybe do I have to install a new required library?

Help / Weapon/item graphics: how do you do?
« on: May 23, 2020, 08:12:19 pm »
I would like to know what is your preferred method to create new graphics, BigOBs, ecc.
Do you create sprites from scratch? Do you downscale from photos / ecc ?

I'm a quite bad graphic designer, but I'm attempting to do some items for OXCE. My biggest issue is, if I start from a big image and downscale, the entire image turns to a blurry blob no matter which interpolation I select. Maybe should I consider to transform to vectorial image and then reconvert to raster?
Let me know! Thank you  :D

Tools / Re: HandOb maker
« on: May 13, 2020, 07:17:07 pm »

I could put a save button for the BigOb, but the problem is that it would screw up the palette. So I'm not sure it would be of much use.

Right, makes sense.

I still haven't understood the Advanced Options - 3d profile function, could you please explain me about?  :)

Going technical, instead:

- bugreport: if you click "Find Center" while you haven't still loaded a BigOb, the application will crash due to a null reference

- I have noticed in the code there is the assembly System.Deployment in References, which is not implemented in Mono, but the application will work flawlessly anyway: are there lines of code using it? I tried to remove it from the References and still works.

Tools / Re: HandOb maker
« on: May 12, 2020, 06:58:58 pm »
lol. Love the guy in the doorway :)

does he tip over when he shoots ...

lol, luckly (or sadly?) there isn't a knockback/recoil system that kicks your guys back as far as I know...

I tried to play a bit with the code, but just increasing the upper limits will return strange results, mainly handobs going out of boundaries. I guess many tweaks are needed for OpenApoc compatibility or anyway just to load bigger images which should be then auto-shrinked to fit the 32x48 box.

I have a question: there are buttons to flip/rotate the BigOb, could be possible to save these transform results on the BigOb image? I know it's out of purpose, but could save in some cases a step to return to image manipulation program to do the same thing there.

Tools / Re: HandOb maker
« on: May 11, 2020, 08:47:51 pm »
You should put it on Github/similar, so we can report bugs, fork it and do pull requests  ;D

I see a lot of potential on this program...

Maybe not yet units from paperdoll sprite (I see it quite complicated and maybe would require more variables i.e. define  skeleton nodes), and maybe not yet HWPs, but I bet it can  work for particles too. I am thinking about new projectiles, rockets, energy blobs ecc...

About sprite size, I'd like the program to allow larger sprites too.
Looking forward for updates! And very very thank you, you just made me willingly to create items and I have no experience on this!

Ooook... I promise if I do new things, they'll go on Resources.
But i have to do that... (maybe I got carried away with the Big...)

Tools / Re: HandOb maker
« on: May 11, 2020, 01:18:27 am »
Just to report some feedback...

I got some old sprite from Galactic weapon set from UFO2000, adjusted with Gimp, used HandObMaker to get HandOb and FloorOb by playing with options, lost my mind on palettes (btw thank you Meridian and ohartenstein23) and...
Not bad result, isn't it?  :)

Have you loaded your source into Github / other repository with versioning system? I'd be happy to attempt to contribute to the code, or at least to report bugs (I got various crashes for "out of index")

ADD: by request, here's the bigOb/FloorOb/HandOb of that weapon. I'm uploading also the original Floor/HandObs from UFO2000 for comparison.
Disclaimer: if you are going to use them for a project, being it a UFO2000 derivative, it's under GNU GPL v2. *
* to check if sprites are on same license.

Tools / Re: HandOb maker
« on: May 05, 2020, 12:44:03 am »
Give this guy a Uber-Ethereal shroud and stick this thread!
Bravo, well appreciated! :-D

Just for the chronicles... sources will compile and run on Linux with mono, as long as mono-vbnc is installed, but will crash as you try to export FloorOb/HandOb.

EDIT: giving it a try again, it crashed while using resources from old UFO2000 assets (many of them are oversized according to your tool). I tried again on XComFiles resources and it works like a charm :D
So... yes, it works on Linux :D

The X-Com Files / Re: Alien Key decyphering
« on: January 22, 2020, 09:35:13 pm »
Just looked at your savefile (I had the same doubt some days ago, and asked in discord channel), and you still miss some crucial clues to unlock the alien decryption key.

Hint: continue exploring the hybrid arc...

Detailed (spoiler):
looks like you miss a live human clone to capture (hybrid mission), and to discover something interesting in the secret hybrid clinic missions. Once you get both you can unlock the other alien infiltration methods in research. 

Tools / Re: MAPVIEW upgrade
« on: October 07, 2019, 11:58:35 pm »

must resist urge to delete Windows™

Just make a dual boot Windows/Linux. Or install Virtualbox and create a Linux virtual machine.
There is no real reason you have to trash Windows over Linux, but it's an experience I really suggest.

(and I had also a tri-boot Win/Linux/Hackintosh, but I deleted the latter)

Just... I wish there is a Windows.Forms designer working for Linux.

Can I ask you a question... did you have

Code: [Select]
//#define __Mono__

defined (uncommented) for that last Mono build? Because if we don't need #define __Mono__ i'd like to take it out of the code.
at the top of the TopView.cs file

Nope, just git-pull and built. Wonders of Mono trying to do .NET work!

Wait a sec... trying to do right now...

ADD: find in attachment what happens if I uncomment the #define. Eeeek! DELETE IT!!!

Tools / Re: MAPVIEW upgrade
« on: October 07, 2019, 07:30:08 pm »
That looks like... different from your screenshot.
Looks like good!

Tools / Re: MAPVIEW upgrade
« on: October 06, 2019, 04:09:36 pm »
hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]

'tsTools' is the toolstrip we're talkin' about

/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.

That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.

Tools / Re: MAPVIEW upgrade
« on: October 06, 2019, 12:18:35 pm »

first just drag& drop the toolstrip to the top while running Mapview.

Looks like "that" is the issue...
Although very old, I checked and looks like still true: you cannot drag&drop toolstrips in Mono.

So... nothing to do that way. I'm going to look for another workaround...

Tools / Re: MAPVIEW upgrade
« on: October 05, 2019, 12:08:55 pm »

well... was much difficult than I expected... I looked at Rembrandt() and Picasso(), but I have thought it was just a matter of interpolation.

Going to testing: now Mono builds behave liks Windows builds. Well done!

Maybe I could manage to dock that toolstrip, and find a better Copy icon, it is so blended with the background it's almost transparent!

Tools / Re: MAPVIEW upgrade
« on: October 05, 2019, 12:32:10 am »

black backgrounds? i had't heard about that yet

check the screenshot attached :)
The top windows are on Windows, the bottom ones on Linux with Mono.

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so

Code: [Select]
    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView. The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.

i've got another project that's been on hold, i think i'm going to bang my head against that for a while :) But if you need a hint or tip on mapview's inner workings just ask,

I can't guarantee, but I'll gladly attempt to work on it :)

Pages: [1] 2