stoppelhopser

one more thing. In this manual Oxygen 2 - Manual they say "Map this face in UV editor". I´m asking myself whether they mean mapping the texture on the face or the "Planar mapping" function in UV editor...

Hi everyone, I know there are already a couple of topics around but none of them covered my actual question: How does an UV based texture help me when it comes to mapping in O2? a) Didn´t find any mapping button in the UV editor (well, won´t deny I´m too stupid to find it ) b) Unwrapping in O2 would only help if one could rewrap after mapping. I´m looking for answers in regard of texturing soldier models properly but it seems with complex models like those unwrapping is not a very useful method. Any comments anyone?

Trying to make my question clearer: Lets say I had a txture that was created from a perfect UV map where all faces are perfectly planar. Now I want to actually map this texture to the model in any of the views in O2. I would have the perspective view on the faces again and a planar texture doesnt really help because the texture would stretch along the faces I don´t look at plainly again. Does that make it more understandable? I´m looking for something like: 'Unwrap structure..' + Map (Ctrl+B) + 'Rewrap structure' (<-which doesn't exist) I am beginning to believe there is no such thing and that UV mapping is what I always work around by rotating and taking screenshots of the model in the 3D window...

hi everyone, we´ve just released patch1.01 for the mod: Lib_patch1.01.exe also we finished our Mod-Reference website. it provides detailed information for all the addons useful for missions and scripting: Liberation1941-45 Mod Reference

often on our models it is not only the shoulder boards that make the rank. maybe it would be a nice feature to be able to set the ranks freely, but on the other hand in missions how often do you really see the rank insignia on a unit...

@OFPCAT: thanks, i collect all bug reports and pass them on @oldy41: ...and i already thought it´s only my comp that lags but seriously: i guess that in some missions the vast number of scripts that run in the background summarize and give the cpu a busy time. this is an issue to be veryfied... @sim: there´s a reason to it: behind that reference is a system i am still working on. it consists of a client application that reads config files (.cpp, .bin or from a pbo) and collects the information you can see on the webpage from them. the app then can write out the information into different file types (.csv, .html, .xml). the other part is a web-application based on a database for the info and the web-frontend that you see. being short in time currently i only managed to finish the .csv output of the client for the mod release. once the .html output is done there will be a downloadable version of the reference. once the whole system is finished i want to provide it to the community for other modgroups to use it. the web-frontend is held easily skinnable to match the mods "corporate design".

the campaign will come in probably russian, english and german. a downloadable addonref is in planning

btw. i forgot a small list of changes for the patch: Fixed: - intro - bugs with shadows on some models of german infantry and german weapons - bugs with weapon models - bug with OpelKapiten's passenger position - bug with T34 models - bug with pak36 crew - bugs with course machine gun. Now it is available on pz3E, pz3E late, pz4 and T34 - some minor bugs Added: - German language in stringtable.csv - 2 single missions

guys, this drives me nuts... i made some custom ammobox models which i wanna put into an opel blitz ammo truck. so far that works. i checked the original config and found: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class CfgNonAIVehicles { ... class ProxyAmmoInTruck{...}; class ProxyAmmo_Bedna_In : ProxyAmmoInTruck { model="ammo_bedna_in"; }; ... }; i applied this to my truck. the ammobox models are set up just like the "ammo_bedna_in" model, regarding lods n stuff... the models show up ingame, so the proxies work. BUT: i checked the original ural and truck5t models, which have the ProxyAmmo_Bedna_In thing. you see the ammoboxes in O2, but not ingame. no wonder (i thought), as these proxies are all part of the namedselection "ammo", which is hiddenSelection in the config. now i did the same, but my ammoboxes still show ingame... one thing i noticed: the name of the model is not(!) the one given in the "model=" property in the code above! it says "ammo_bedna_in", but in data3d.pbo, the model is called "bedna_ammo_in"... bedna and ammo swapped and this is about the only difference i can find to my way of implementation. if i swap around the name of my proxy model, it isn´t found, just as i expected. i just can´t believe that the name has anything to with the way the proxy is handled ingame... any ideas?

thanks! although it didn´t help much i know about the cfgmodels thing... and i can tell you what the cfgNonAiVehicles does: as you might know you can define a model-proxy like this: proxy:\MyAddon\modelname. but i found out if you do so, the proxy behaves like the ammo proxies of the ural: model is never shown. if you name the proxy like: proxy:stp_ammobox then ofp expects either one of: - the model "stp_ammobox" is located in data3d.pbo - there is a "class Proxystp_ammo" in CfgNonAIVehicles with "model =" property giving the path to your model option one always hides the model. my option always shows it...

just found out i forgot something: the proxy thing for "bedna_ammo_in" is correct, because the proxies in the ural model have the same name and thus refer to the "bedna_ammo_in" model in data3d.pbo . but this still leaves the fact that the proxy-classes in the config have the names swapped. because the interesting thing is that the "ammo" selection also includes the ammo-marking on the side of the truck. ingame, you do not see the ammoboxes, but the marking, on the ural reammo. i´m pretty lost just now

well the only thing i would consider ok is to ask BIS for permission to sell cd-roms with huge addon packs. e.g. there seem still many users out there using slow connects and for those it could be quite hard to download a 200-300mb addon pack from one of the bigger mod groups. so if they had the opportunity to buy the thing on cd for like $10 or so, the price mainly covering the effort to make the cd and to ship it, plus maybe $1 for helping to maintain the mod´s webspace or so, this would go ok without hurting anyone. you could still download the stuff for free... but sth. like: "get this new m16a2 addon for only $4,95" would definately be out of the question... but... if i could earn enough money by selling addons to make a living, i´d be doin nothing else and probably come up with a new final addon release once a week .

you must still specify the right path to the soundfiles, e.g.: class ge1 { name = "ge1"; sound[] = {"\Sounds\george1.ogg", db-5, 1.0}; titles[] = { 0, $STRD_V03v4 }; other that many may assume, sounds don´t necessarily have to go into the Sounds folder... something like: sound[] = {"\audio\missionvoices\ge1\george1.ogg", db-5, 1.0}; should also work...

hi everyone, i´ve written a tool to create documentation of addons as a html website. the background (and reason to post this in this category) is that often when you make missions with unofficial addons you need to know classnames of weapons, magazines and units (e.g. for filling ammo boxes a.s.o) the tool i wrote analizes the config.cpp and creates a html-file with tables for units and weapons found including all necessary information. it is targeted at both, addon makers and users, to make usage of addons more handy. if an addon maker would distribute such a file with his addon(s) i think this would be of great use for people who use the addon(s). release version is designated v.1.0, but i found a couple of bugs which are mainly based on the fact that even though the configs are c++-like, the syntax rules are not that strict, so parsing is a bit complicated. i tested it on several configs, but i always find new ways of how people write their configs. if someone finds this tool useful i would be greatful for tests and bug reports. a documentation on how to use the prog and a sample output-file are included in the zip distribution, which you can get here: Liberation 1941-45 tool downloads i am still adding more features, but for now it already does (mostly  ) what it is supposed to... greetz stoppel

seems i forgot the words "it" and "properties" somewhere above

not takin anything offensive ;) well, i wouldn´t know what type of database you mean... still you´d have to fill somehow.. well, you´re right about the description... i wouldn´t know what the all mean in detail (e.g. i am still tryin to find out about that ffCount thingy ). but that would be about the only advantage i´d see... the other prob i see in using an original class is that you should always use the topmost class, since many addon makers (including me) add properties to base classes that are not in the base class but more on top, just to redefine them. so this would either blow up the config due to properties written to the file that use the standard values, or you would have to make each property selectable. this wouldn´t be the problem, as the tree view supports this, but i think it would not help the user if from 100 properties he would have to select 50 and then he would still have to enter the values... a simple datasheet explaining all properties appropriately going with a text editor would be much more effective i guess... and, as you said, addons are alot of work, too, and foremost i´m making addons for the liberation mod ;)

@hardrock experienced guys? in what? call me arrogant but don´t think me rude... i consider myself quite experienced and maybe that´s the reason why i haven´t thought about writing a config editor... well, i actually did, but skipped the idea... the thing is: there´s addon makers out there working on all kinds of addons. now such a tool would only be complete if it offers config creation for all those types of addons... weapons, ammo, vehicles, ui, animations... just to name a few... now a config mainly consists of attribute-value pairs defining your addon. what would you imagine the user-interface of a config creator to look like? provide an input field for each possible value of each possible addon class? the "All" class in cfgVehicles alone has ~150 properties and you never know which ones are needed for a particular addon and which are not... now if you consider that each line in the config would demand at least 3 lines of code in the program to write, you can imagine why i think it´s not a good idea

yo thanks and it seems you´re the only one

hi, i wrote a new audio converter. this is a replacement for my wssutilizer, which was a front end to make use of the wwscod and wwsdec dos utilities more handy. now i implemented the conversion algorithms directly into the program, which makes use more easy and safe. you can get it on my site in the modding section. currently i´m working on an extended version, which will have more features including prelistening of sounds and wav to ogg conversion as well as auto trimming sounds by removing leading and trailing zeros. it´s all done apart from ogg conversion, so release might be soon.

yes.. wav file format is more complex, requyring a couple of function calls to reach the data. wss skips that crap and holds mainly the format description and data.

@Hellfish6: i use it mainly for addon-sound creation, so i thought the modding section would suit it more.. but you´re the boss @redface: music and environment sounds are usually large soundfiles, so a conversion to ogg saves alot of disk space. on the other hand, ofp must decode these sounds first, you cannot play them directly. this reduces performance. wss allows the fastest access to the sounddata for ofp, thus all small auiofiles are best to be wss.

hi, i wrote a new audio converter. this is a replacement for my wssutilizer, which was a front end to make use of the wwscod and wwsdec dos utilities more handy. now i implemented the conversion algorithms directly into the program, which makes use more easy and safe. you can get it on my site in the modding section. currently i´m working on an extended version, which will have more features including prelistening of sounds and wav to ogg conversion as well as auto trimming sounds by removing leading and trailing zeros. it´s all done apart from ogg conversion, so release might be soon.

i guess they will also use ogg in flashpoint2, because this is a free to use codec. but you should consider that wss is the most performant file format for ofp, except music and environments. ogg files need to be decompressed by the game engine, thus lowering performance. but to keep long audiofiles small, it is the format of choice for music.

i guess they will also use ogg in flashpoint2, because this is a free to use codec. but you should consider that wss is the most performant file format for ofp, except music and environments. ogg files need to be decompressed by the game engine, thus lowering performance. but to keep long audiofiles small, it is the format of choice for music.

hm, that´s really strange. i looked at a config i wrote for an addon, and except that i put the file path in hyphans it´s all the same and it works... class CfgSounds { sounds[]={DX_CutWireSnd}; class DX_CutWireSnd { sound[]={"\DX_wire\snd\cutwire",1,1}; name = "DX_CutWireSnd"; titles[] = { }; }; }; in the script i use _unit say "DX_CutWireSnd". on the other hand i use a wss file instead of ogg... but that doesnt seem to be the problem since playsound works for you... maybe try to code your sound declaration like i did and try again. i am pretty sure this shouldn´t be the matter, but who knows...