Jump to content
The Dark Mod Forums

7318

Member
  • Posts

    167
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by 7318

  1. Zombie posting again... can't this or something similar be implemented in the idtech4 rendering engine?
  2. in DoomRadiant if you stretched a patch mesh (pmesh) but you elected a "normal" projection in the texture settings of the pmesh you would end up with the texture un-stretched, a completely planar projection of the uv's of the stretched pmesh over the texture plane, with DarkRadian though, if you stretch the pmesh you always get a stretched uv's that result in a stretched texture. is there a way to get the planar projection while stretching the pmesh?
  3. I created a *.game file and DR doesn't ignore it. maybe some values are hard-coded?
  4. yeah and both accounts didn't respond, we've tried to contact him with no luck. another way would be to recreate a similar code inspired in his, and distribute the new code under GPL
  5. the thing is that the water physics mod, that it's available the liquid physics code doesn't specify if the actual code is GPL or not, it has nothing to do with the sdk licence because it has nothing to do with Id, it's actually Lloyid's own creation. since it doesn't have any licence, the only thing we can say is that it's authorship is by Lloyd. we don't know if Lloyd allowed it to be copied or changed, and re-distributed (although the fact the he allowed web-pages to distribute the code and the mod without them paying them, already allows for redistribution. but can we change it? can we redistribute the code without the mod? those are questions that remain to be answered. Motorsep and I thought that we could redistribute the code as GPL, and if Lloyd had any trouble then he might contact us. would you see any problem with this?
  6. Hi, I'm Biel Bestué, and I've been trying to contact Lloyd for his liquid physics code. there is another lad that goes by the name of Motorsep (he is the mastermind behind Steel Storm a GPL game made with a Quake1 engine port), he also has tried to contact Lloyd for this code. We intend to release the liquid code as GPL, but since we weren't unable to contact him, we've though of contact you guys, is the liquid physics code GPL in your amazing mod/game? and would you see any trouble from me extracting that part of the code from yours and release it as GPL? all credit given of course! my take on mods, is that I like to create GPL code infrastructure so other people can use it, as a way to give the oportunity for the people to test, play, and change innovations in the idtech4 / BFG engine, as well as grow from it. and liquid physics seems to be another chance to release one of such things.
  7. first I got to say that I don't know the map you're referring to, I don't know how is done in this map but... if you trigger THE SAME local portal sky you should always get the same local portal sky starting point (in fact this is the point of the local portal sky) obviously, if you trigger ANOTHER local portal sky you'll get a different starting point (that is a different starting point for every local portal sky entity) let me add that you're not limited to one local portal sky per map unlike global portal sky where you are. also, I've tested the changes that we discussed in the PM, I've tried them in Doom3 and they work ok, my testmap runs ok. and works correctly.
  8. I'm sorry but unless you've changed it, I think you were wrong in your description: Local portal sky when triggered always starts in the place you set the entity, it still follows you like any other portal sky but the point of start that is taken as a reference when triggered is that of the local_portalSky entity that you set in the level editor. so you essentially control where does the local portal sky starts. This is not the case with the Global portal sky entity: the point of start of that kind of portal sky is taken once in the beginning of the map, it keeps following the player, even when you have another kind of portal sky active, so you can always return to it and it will always maintain the parallax correctly since the beginning of the map.
  9. Sotha this smells like scaling issues, try to change the "scale" in the portalsky entity, the default is 16, the movement of the portlasky entity replicates the player's divided by "scale"
  10. another sound that I've ever found strange was those step sounds in the video, the recording was made with way too much intentionality, the way to record steps is to walk at least three steps and save the recording of the middle step which is the least intentional of the three, that way the steps sound more realistic and unintentional, also the volume of the step sound is way too loud
  11. great, I've compiled it, and it works. Shouldn't those two packages be added to the list of required packages?
  12. excuse me, but my skyportal code mimics the skyportal code of half life 2. please don't confuse others on what my code might do, just try it, you'll see that the same thing you pointed in your half life 2 video you posted happens in my testbox, a part of the central column is done with the real dimensions in the map, but the topmost part is done at a 16th of the size in the skyportal part of the area and they match all the movement correctly (movement of the player and bob movement of the player) with my implementation you have 3 portal skies system, a general system, a local system and the old ROE implementation (which is still the default ) so my code will never break any pre-existing maps that use the old system! why do you refuse to test it out and see it with your own eyes!? is just a simple mod that you can test in doom3! no need to install anything special download it here: https://github.com/BielBdeLuna/portalSky/blob/master/portalSky.v1.2.7z?raw=true (save the file in link instead of entering it)
  13. I'm trying to compile DR in Ubuntu 13.4 .configure informed that a package named "ftgl" was missing (maybe this "ftgl" should be stated as the required packages in the package list in the README after adding this package i tried .configure again and i got the following error: .... checking for the Boost unit_test_framework library... no configure: error: cannot find the flags to link with Boost unit_test_framework any idea on how to solve this?
  14. I've posted the code and the "mod" at GitHub check it out here: https://github.com/B...eLuna/portalSky
  15. Read carefully what I said in D3W! the change in the engine is a two-line change (in order to make the engine capable of recognize a second material name as portalSky material, with a much organized, clean and recognizable name than the one in ROE) now, of course there's also changes in the *.dll/*.os which are not two-liners! And yes, you can copy the player position via scripting, but my method is less costly to the end-user because it gets compiled in the game code, and also doesn't have accumulative errors like the scripting method does. also the position of the player (and it's rotation) isn't what you get in scripting, when you run, jump, or land after jumping, you won't have those movements and rotations that the player performs in the portalSky. The "mod" comes with a test map (the one in the video) that displays the three types of portalSkies, it also features the two textures for portalSkies (ROES's and mine) if you don't make the change in the engine, and you only make the game code change you'll get an error with my texture (it should be rendered black) but you can still enjoy ROE's. ROE portalSky method is still there, if you don't add anything special to your map, your portalSkies will perform as ROE's, so it's fully backward compatible with them. my GitHub repository is here: https://github.com/BielBdeLuna/portalSky
  16. portal skies with much better control in this old thread: http://forums.thedarkmod.com/topic/13442-implementing-3d-skyboxes-that-follow-the-player/page__st__50
  17. implementing it to the engine is only a two line code change, because this is mainly a *.dll / *.os change, the change in the engine allows you to have a more organized material for portalskies instead of the strange material for them you have a new "portalsky material" at "editor/portalsky" much more cleaner an easier to understand. there shouldn't be any map break because i haven't changed anything from the original portalsky code from d3xp go ahead add it to TDM
  18. hey I got a testmap in the mod. you can test it. open my mod (open doom, select my mod from the list, open this mod) and type "testmap skies" in the console
  19. unless mantle doesn't use the SingleView function (that I don't think it won't) it should work, one thing is define the player movments the other where it gets rendered. those are two separated processes.
  20. but it can be played as any doom3 mod, it's got all the needed files to play it in windows now. so if he can play TDM he should eb able to play it the same. to test the testmap there is no need for implmentation in TDM, just open it as any other mod in doom3... oh well... I hope other people don't have that much problems to test it. guys do you have any input on this?
  21. I don't get it Baddcog, why so dissmisive on my work? you're mixing things with TDM and my work wich it doesn't have anything to do with TDM at the moment. in my map the box stays matched what are you talking about? are you talking about my test map? there are three portalSkies activated with tirgger_multiples in the map. the point of this testmap is showing the new diferent beheviours for the portalSkies, have you checked my map for real? in my testmap you should only see mismatch with the classic portalsky (the one with the wraith in it) the ones that contain a revenant and the archville, those are the global portalSky and the local portalSky, yo will see that in both cases the movement of the player including the bobbing movement, or the jumping movmenet all match consistently for every frame. isn't this right?
×
×
  • Create New...