OpenXcom Forum
OpenXcom => Suggestions => Topic started by: moriarty on July 20, 2012, 09:48:20 pm
-
in order to make openxcom again just a little bit better and modder-friendly than the original, it would be nice to have the bullet/projectile sprites in a more... accessible... way.
(for those that - like me - didn't know yet: xcom has a rather clever way of dealing with the projectiles. they consist of a row of 3x3 pixel sprites, which are simply lined up on the flight path like pearls on a string. that way they look fine regardless of the direction of travel. see https://www.strategycore.co.uk/forums/topic/9869-openxcom-mods/ (https://www.strategycore.co.uk/forums/topic/9869-openxcom-mods/) for more info.)
instead of loading them from the hardcoded arrays directly ripped from the xcom executables, it would be nice to have them as image files like the one Bomb Bloke posted in the strategycore thread above - if possible, even separated: one image file per projectile type. that way we could replace them one by one or add new ones in a very simple way.
what do you say? developers? possible? perhaps even easy? I would be willing to provide the necessary image files separated by bullet type with appropriate names. :)
-
You could leave the originals as is (hard coded ) but allow custom projectiles to be added within the Ruleset and attaching a custom graphic file, Just a thought ::)
-
Moriarty, eh... referring to Bomb Bloke, and forgetting who found all this...
Before thinkin of this openxcom must get easily added new weapon/ammo types. So unhardcodinc bullet sprites is slightly premature idea for the moment. Thanks.
-
Volutar, I am sorry, I did not mean to imply that it was anyone but you who found this. I was merely referring to the picture in the abovementioned thread as being posted by bomb bloke.
as for the idea being premature, I disagree. of course it would also be nice to have an easy way of adding weapons and ammo, as I am sure is planned for the future.
BUT: right now, if somebody were to try and start making new weapons, the only way of testing new weapon and projectile sprites is to modify/replace the existing ones. for that it would be nice to have openxcom load the sprites from something a little bit more accessible than the hardcoded arrays.
at least add an option to load them from external arrays? anything better accessible than having to change something in the source code would be nice. pretty please? :)
-
"So unhardcodinc bullet sprites is slightly premature idea for the moment." I am with Moriarty , If we want to encourage modders to start working with OpenXcom we need too know that options are on the horizons . It is no different to me asking about having the Transport ship land on levels above level 1 for my terror map, it was a interesting concept that Daiky decided to add for me and it makes openxcom different to the UFO EXTENDERS that are still being activity worked on.
Openxcom needs to be the Version of choice for modders and we don't want to re-direct the current schedule, we are more looking to know that something will be supported before we spend Hours making the mods.
-
before asking these question, you should track all data and links from bullet sprite though weapon->bullet-sprite/ammo->bullet-sprite assignment to weapon data/sprites/battlescape/tech.tree and think of how this could possible be done and is it even feasible in current stage? This subject is too complex to get it right now or in the nearest future. By externalizing those arrays you will ease modifying current, and won't add any moddability to project. Altering current graphics can't be really called "modding". It's just an artistic excersices for those who can't do anything else. What for? Just for fun, maybe?
See, there is no way to add new weapon. Not graphically, nor in logically. So I suggest to forget it before 1.0.
-
Well Wiki Says "Modding is a slang expression that is derived from the verb "modify". Modding refers to the act of modifying hardware, software, or virtually anything else, to perform a function not originally conceived or intended by the designer. The term modding is often used within the computer game community, particularly in regard to creating new or altered content and sharing that via the web"
Sorry if i am not as Smart as you Volutar , i make my living as a Tradesman not a IT wizard, So yes maybe i cant do anything else. Moriary did the right thing and asked in the Suggestion forums, and all he asking for is a Guideline as to how to move forward with his plans for Openxcom and IF it will be possible in the near future. I have done work making Armed Civilians with no way to test them, as such i have been forced to hold off on doing the last 3 sets until i know they will make it into my game oneday.
Yes we are in the early stages of Openxcom and we too want Openxcom to Hit version 1.0 , but there is no reason why we cant start working on our "artistic exercises" because God knows we cant do anything else.
-
before asking these question, you should track all data and links from bullet sprite though weapon->bullet-sprite/ammo->bullet-sprite assignment to weapon data/sprites/battlescape/tech.tree and think of how this could possible be done and is it even feasible in current stage?
I am not a programmer. That's why I asked if it was possible.
This subject is too complex to get it right now or in the nearest future.
so the answer is no. that's a pity.
By externalizing those arrays you will ease modifying current, and won't add any moddability to project.
I wholeheartedly disagree. In order to make these resources moddable, they will need to be unhardcoded sooner or later. How else would you add new bullet sprites at all?
Altering current graphics can't be really called "modding". It's just an artistic excersices for those who can't do anything else. What for? Just for fun, maybe?
Oh well, I'll just go back to my artistic exercises then. You do realise that "modding" is short for "modifying", though? anything you change is a mod. no matter how small and insignificant it may be in your eyes.
See, there is no way to add new weapon. Not graphically, nor in logically. So I suggest to forget it before 1.0.
please explain to me what you mean by that? right now there's no way to add another weapon, true, but at least we can modify existing ones. but in order to completely replace them by something different, projectile sprites are the remaining bottleneck. so it is only logical that I ask.
are you saying that the way openxcom is done, it will never be possible to add weapons? if that were true, it would be downright stupid.
I hope that in the future we will be able to mod a lot of stuff without the necessity of modifying the source code. If you need mad programming skillz to make changes, it's not modding friendly. I guess it all comes down to what you want it to be.
-
I hope openxcom will get an ability to get absolutely mad weapons and fancy tech tree branches... But for the moment getting bullet sprites modified without any new weapons is unnecessary.
About getting current weapon altered. Okay, that's reasonable to demand externalizing of bullets, BUT, as far as I remember, openxcom claimed to be 99.9% original until 1.0.
The only reason to make such altering possible BEFORE 1.0 is to give people ability to experiment and try different combinations which probably will be added after 1.0. And to get people involved into project, and not to forget about it (which I see is most probably)
Frankly speaking, I think adding new weapons or alien races will be almost impossible even after 1.0, just because yaml config is not a best option to make mods. And most probably without "mad skillz" in programming you won't be able add new weapon even after 1.0. This game cannot be "mod friendly" just because of its "hardcoded" nature. If you want to get xcom-like game which will be really mod-friendly, it should be rewritten from scratch as scripted game. LUA, python, javascript, or whatever. And before writing it, game-paradigm and game-design should be developed. Just not to get into dead end "opps, we wont be able to give people modding this"
-
You can already add new tech trees and new weapons. But not *mad* ones, but you can add perfectly fine things like stun grenades, or a rocket launcher with a "3-rockets-clip" and auto-shot mode... as long as it stays within the combinations of existing weapon features.
Bullet sprites are not the only little sprites that are hardcoded, there is this little arrow above the selected soldier, there are these little icons that represent crafts/bases on the geoscape,.... they'll probably get all unhardcoded at some point.
-
Thank you volutar and daiky, you restored my hopes and faith in openxcom. :)
So, with that cleared up, what's going to be your most probable method of externalization? Arrays as text files? .bmp? .pck? One projectile per file or all in one? Or as-of-yet-completely-undecided?
-
The thing is, currently those projectile particles are limited to 3x3, and with "particle list" (which have only 36 variants AFAIR). Size limit will make projectiles too small when resolution grows. So I suppose it should be text config with every projectile listed as string of "bmp" files and spaces between particles (with 640x480 you will have to make 2 times more particle sprites just to get same projectile length in battle). So particle images would be quite reusable for different projectiles. There is another way - single "bmp" for each projectile. For example 96x3. Vertical size also applied as particle size X inside of this image. So 96x3 image will be decoded as 32 particles of size 3x3. But in this case you'll have to fill every single particle in the string with images including "spaces".
-
I like the last way. file is identified by name, height of file defines size of square particle. height needs to be an odd number so that it can be centered. width of the image file could even be arbitrary - it needs to be a multiple of the height, but you could make a single-pixel bullet without trail by supplying a 1x1 image, or a continuous wide laser beam by making it 300x3 solid red.
that said, are all bullets the same speed? globally defined by setting the bullet speed in the battlescape options? it might be interesting to add weapon-specific modifiers to really make laser "beams" that strike almost instantaneously! of course, that challenges the engine by forcing it to draw a lot of frames in quick succession...
-
I don't see why these particles cannot have even height. Do you think it's really matter when projectile image is slightly shifted (by half pixel)? You won't see any difference, except for this projectile with even size should have 2x2 core, not 1x1, thus will look slightly unusual, though okay for hires.
-
I think for higher resolutions it should be okay, but in 320x200 if it is off-center by even one pixel, it might look odd.
Then again, I guess if it doesn't matter in terms of programming it, then it doesn't matter. The artists can then choose which looks better.
-
The thing is - there is no loader for other than spk/scr/pck/dat files... Though it's possible to use pck/dat files for them. But this is not very modify-friendly.
-
well, I guess we can live with .pck for the time being, since we have to work with that format anyway. If we later add support for other file formats, we can update this as well. :)
-
Well, I bet externalizing projectile particles in that way can be done quite quickly. It doesn't require alot of work. Though if you will be creating surfaces for every single particle of every projectile, no matter empty or exactly the same as others, you will get memory consumption grow. There might be a redundant data for each sdl surface (i don't actually know), but best option for such thing when using OpenGL - is texture atlas (I 'm not sure if there is similar entity in SDL), but it will require extra pixels between particles, just not to get hard edges when zooming in.
These projectile template images are named entities (referenced from some config like BULLET_RIFLE=/data/img/bullet1.pck) and refereced in item section as "projectile" property (like projectile=BULLET_RIFLE).
-
There is no particularly special reason why the hardcoded graphics are that way, besides the weird grey area of whether they count as "distributing copyrighted graphics", though probably nobody cares...
I'd just rather externalize them when all the graphics are more open for modding, because I'm sure people won't just want to play with bullet sprites, but everything else. :P
Edit: Anyways don't feel like all your hard work is going to waste, we do try to accommodate as much as we can from the community, even if we don't always reply to everything with immediate solutions. Sometimes some things are simple enough that we can quickly add them in to please you, like the maps with high levels, inventory sprites without helmets, etc. Other things take a lot more time or we'd rather invest in implementing them properly rather than just quick hacks, like complete graphics replacements and such. OpenXcom's end goal is to be fairly moddable, even if not 200% "scripted game" moddable, but at least enough to keep most of the community happy. :)
-
*snip* but you can add perfectly fine things like stun grenades, or a rocket launcher with a "3-rockets-clip" and auto-shot mode... as long as it stays within the combinations of existing weapon features.
*Mad, Evil laugh echoes while explosions happen everywhere...*
This remake keeps getting better and better every topic I read. 8)
-
*invokes threadcromantic powers*
so guess what i'm working on today?
here's a clue:
-
Rainbow guns? :)
-
well i needed SOME proof of concept :P
-
I like Rainbow ammo , its very pretty ;D
-
oooh, so we can finally make that nyan-nyan-cat-launcher! woohoo!
no, seriously, this is great!
while you're at it, might it be possible to add adjustable bullet speeds?
EDIT: I just tried it, and it actually works! woohoo! that is to say, I expected it to work, but I didn't expect me to be able to actually work with it :D
anyway, playing around I noticed two things:
1) we need another damage type defined: Stun Damage that is not AOE damage (think rubber bullets, or, as I tried to create, sonic pistol for selectively incapacitating at a distance)
2) the "new battle" setup behaves weirdly: all additional items added by custom rulesets are automatically loaded onto the transport with a quantity of 100. is that defined in the ruleset somewhere? with all the new stuff, setting up a "new battle" becomes increasingly tedious. maybe a "unload all"-button would also help?
-
while you're at it, might it be possible to add adjustable bullet speeds?
done.
1) we need another damage type defined: Stun Damage that is not AOE damage (think rubber bullets, or, as I tried to create, sonic pistol for selectively incapacitating at a distance)
simply define a blastradius of 0
2) the "new battle" setup behaves weirdly: all additional items added by custom rulesets are automatically loaded onto the transport with a quantity of 100. is that defined in the ruleset somewhere? with all the new stuff, setting up a "new battle" becomes increasingly tedious. maybe a "unload all"-button would also help?
that's what right click is for ;)
i did clamp it to between 0 and 100 because it goes out of range for new items. i've added some better handling for this.
-
:P :P that's still one right click per new item. :P :P
Will defining a blast radius of 0 automatically turn off the explosion animation? Because I modified a weapon without a blast radius, and setting damage to "stun" resulted in stun explosions ???
-
from the ruleset:
# blastRadius: How big of an explosion does this cause? 0 for none. (int) (default -1, meaning "use formula")
(plus if you grab the latest git build, that problem with new items goes away.)
-
perfect ;D ;D
-
I like this idea just because I would like to change the color of rifle rounds from pink to gray, so I don't think this necessarily has anything to do with adding or moding weapons. It could just mean changing projectile appearances easily. I would also consider changing lasers to purple as violet is a stronger wave length of light and could conceptually make better weapons. Not sure why red is so common but if you have ever used a green laser pointer instead of a red one you can see that it is a significantly less fussy on that side of the light spectrum, but I am just weird that way.
-
I guess lasers are traditionally depicted red because the first commercially available lasers were red, simply because that was technically easiest to achieve. that being said, the most powerful laser frequencies would be violet (even ultraviolet), or at least more blueish, you are right. maybe blue lasers? geeks love blue lasers. :D :D