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...

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, 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?

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

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

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

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?

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...

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 ;)