EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#781 Posted 22 July 2009 - 06:39 AM
Yesterday I tried making one of my actors change palette via a random chance. Sounds easy right? - just use ifnd or randvar?
Well here's the problem, I've used these within "eventloadactor" so it happens before the actor is alerted (as that'll look stupid seeing my actor change colour before your eyes) but then I noticed something which ruins everything - the randvar / ifrnd / basically the random number generater isn't very random at all.
The EXACT same actor will always be the different coloured one. In my test map, in the 3rd room, the actor near the back wall will ALWAYS be the coloured one!
No matter how many times I restarted the map or even restart the game the random number generator makes that actor the coloured one.
I don't know much about random number generators but from this I could assume that its a series of numbers that are fixed into the source code and the game just moves along these numbers every tic or once a number has been called and it starts at the first number upon map fully load.
Unfortunately this makes things predictable and have noticed this in the past but shrugged it off as super coninsidence but now it sticks out and its ruining my "random encounter" of this colour change.
Is there anyway around this by using some other form of "random numbering" or / and are there plans to make this generator more random? Perhaps not have it restart upon each map and let it continue where it left off? Have it start active right from the first intro movie since its not humanly possible to run through the movies and start a game at the exact tic of a second each time, or have it start a number ahead based on the seconds and milli seconds of the computer's clock or something.
Again, I don't know anything about random number generators so I don't know if anything can be done or if anyone actually wants to do anything about it.
It would be really helpful and fun to not have things set so fixed for something meant to be random.
This post has been edited by Chip: 22 July 2009 - 06:45 AM
#782 Posted 22 July 2009 - 11:32 AM
I don't know what you could do. Maybe you can use that feature that gets your personal computer day/time? =P
#783 Posted 22 July 2009 - 11:38 AM
#784 Posted 22 July 2009 - 12:16 PM
network: ERROR: Two players have the same random ID! network: ERROR: Please restart the game to generate new IDs. ...closing socket...
and is there a way to stop it from happening?
#785 Posted 22 July 2009 - 12:35 PM
Chip, on Jul 22 2009, 10:39 AM, said:
Yesterday I tried making one of my actors change palette via a random chance. Sounds easy right? - just use ifnd or randvar?
Well here's the problem, I've used these within "eventloadactor" so it happens before the actor is alerted (as that'll look stupid seeing my actor change colour before your eyes) but then I noticed something which ruins everything - the randvar / ifrnd / basically the random number generater isn't very random at all.
The EXACT same actor will always be the different coloured one. In my test map, in the 3rd room, the actor near the back wall will ALWAYS be the coloured one!
No matter how many times I restarted the map or even restart the game the random number generator makes that actor the coloured one.
I don't know much about random number generators but from this I could assume that its a series of numbers that are fixed into the source code and the game just moves along these numbers every tic or once a number has been called and it starts at the first number upon map fully load.
Unfortunately this makes things predictable and have noticed this in the past but shrugged it off as super coninsidence but now it sticks out and its ruining my "random encounter" of this colour change.
Is there anyway around this by using some other form of "random numbering" or / and are there plans to make this generator more random? Perhaps not have it restart upon each map and let it continue where it left off? Have it start active right from the first intro movie since its not humanly possible to run through the movies and start a game at the exact tic of a second each time, or have it start a number ahead based on the seconds and milli seconds of the computer's clock or something.
Again, I don't know anything about random number generators so I don't know if anything can be done or if anyone actually wants to do anything about it.
It would be really helpful and fun to not have things set so fixed for something meant to be random.
I don't know if this will help you like it did me, but I sorta noticed this behavior some times ago because I have certain things in my mod that are also semi-randomized. If I recall, the following bit of code was given to be by Hunter_rus back on 3DR about 1-2 years ago.
I put this at the end of EVENT_ENTERLEVEL
ifmultiplayer break // De-Pseudo gamevar TMP 0 131072 readgamevar numruns addvar numruns 1 andvar numruns 65535 setvarvar TMP numruns xorvar TMP 43690 whilevarn TMP 0 { ifrnd 1 { } subvar TMP 1 } savegamevar numruns
It will require those vars like TMP, numruns, etc. The most important thing is the "ifrnd 1 { }" part. It saves the "numruns" var and I assume it makes the number generator cycle a few times at startup of a map depending on the amount of times you've played a map or game. So try it out for a while and see if it helps. o.o
Also, if you use the DNCOORDS cheat, you'll see a value with the coordinates called "SEED" and you'll notice it's always changing. I'm sure that's the psuedo-random number generator in action.
This post has been edited by Lord Misfit: 22 July 2009 - 12:38 PM
#786 Posted 23 July 2009 - 07:10 AM
Quote
That's basically what I thought up today at work - randvar a number and save it out of the game (using that save to external file command which i read about some time ago) and use that to randvar pointless times equal to number number written (so it jumps up the RNG a few times) after which re-write that saved number for next time.
I was hoping there was a better and more practical solution but thanks guys
This post has been edited by Chip: 23 July 2009 - 07:11 AM
#787 Posted 23 July 2009 - 05:12 PM
There is one nice detail that mappers use to do, making a narrow sector with maskwalls and dropping down the ceiling with parallax can be usefull for good looking fences or gates, even 3d looking doors if you also parallax the floor. Well, this isnt working in polymer, and instead a these maskwalls seem to go all along the sector until the top and or down. Alejandro Glavic´s maps, Roch series, some maps of mine and many others have make use of this trick (in Fusion TC redux the railways use it), so i think it´s worth to be fixed.
Also, Dukeplus´s disable model feature isnt working.
#788 Posted 24 July 2009 - 03:49 AM
#789 Posted 24 July 2009 - 04:00 AM
Shadow Warrior has a GRP file that has ART files, try renaming that one and using it with Mapster
#790 Posted 24 July 2009 - 04:10 AM
http://www.proasm.co.../SwpBuild12.zip
SwpBuild is a Build editor for JFSW using SWP
#791 Posted 24 July 2009 - 04:17 AM
#793 Posted 24 July 2009 - 05:20 AM
I really like Mapster32, it makes things so easy on duke3d maps. Shadow Warrior looks like it will work, but it looks like it will need a names.h file of its own. So I will use the swpbuild for now. Thanks!
#795 Posted 24 July 2009 - 05:36 PM
It'd just be nice to be able to see what each of your lights is (very roughly) covering at a glance, which could probably help pinpoint potential issues with overlapping lights.
This post has been edited by Sobek: 24 July 2009 - 05:46 PM
#796 Posted 24 July 2009 - 05:37 PM
Captain Awesome, on Jul 25 2009, 01:30 PM, said:
Also works for Tek War if you change the palette's of course.
#797 Posted 28 July 2009 - 01:38 AM
if your trying to make this possible that is friggen amazing, that is just too cool plagman and terminx you rock and very hard at that *thumbs up*
oh that RoR stuff no longer glitches in mapster too, just awsome
This post has been edited by DanM: 28 July 2009 - 01:40 AM
#798 Posted 28 July 2009 - 05:19 AM
A command or variable to turn off the hardcoded behaviour of specific weapons, mainly pipebombs and tripbombs. Is this possible? (I tried to code my own weapon as a replacement of tripbombs, but there are too many annoying bugs which I have no idea how to fix)
#799 Posted 28 July 2009 - 09:34 AM
XThX2, on Jul 28 2009, 06:19 AM, said:
A command or variable to turn off the hardcoded behaviour of specific weapons, mainly pipebombs and tripbombs. Is this possible? (I tried to code my own weapon as a replacement of tripbombs, but there are too many annoying bugs which I have no idea how to fix)
If you set the tripbomb or pipebomb weapons workslike values to, say, the rpg, doesn't that effectively kill their hardcoded quirks?
#800 Posted 28 July 2009 - 11:52 AM
#801 Posted 28 July 2009 - 11:55 AM
XThX2, on Jul 28 2009, 06:19 AM, said:
A command or variable to turn off the hardcoded behaviour of specific weapons, mainly pipebombs and tripbombs. Is this possible? (I tried to code my own weapon as a replacement of tripbombs, but there are too many annoying bugs which I have no idea how to fix)
When I started this thread it was supposed to be about Polymer, but it seems like it's becoming the random shit thread.
The wiki entry I wrote about weaponx_workslike is not entirely accurate. For example, if you change the workslike of weapon 8 to 2, it will "fire" even if away from a wall (so it doesn't just change the appearance). You can make any weapon slot do anything you want by changing the weaponx variables and adding your own code to processinput or the player actor or wherever is appropriate.
If you think about it, your request is almost meaningless. All the weapon behavior (the actors spawned by them are another story) is hardcoded, and what EDuke32 allows us to do is override that hardcoded behavior. If you want to "turn off" the hardcoded behavior of a weapon, all you have to do is prevent it from firing by canceling EVENT_FIRE or setting kickback_pic to 0, and then code your own weapon that doesn't use the hardcoded system.
This post has been edited by DeeperThought: 28 July 2009 - 12:09 PM
#802 Posted 28 July 2009 - 12:41 PM
Why shoehorn all this technology in an old engine? I'm not playing Duke to make my eyes bleed with the ecstasy of modern graphics. If you want better lighting, why not create some Duke mods for the Quake series' engines? Seems to kind of cheese up the original experience and introduce more performance overhead (and bugs).
There's always a push to "modernize" old games and bring them "into the 21st century!!!" I don't want to sound like an old fart, but sometimes I wish "21st century" games would act a little more 20th century, because it's all graphics achievement and 0% gameplay. I'd rather see new levels than dynamic lighting. That, or I'd rather see some sweet Duke mods made inside other engines -- maybe it would be more fun and productive?
#803 Posted 28 July 2009 - 12:49 PM
This is not about "bringing it into the 21st century!!!" but to give mappers more possibilities to make good looking stuff. A casual gamer like what you seem to come across as might not grasp that but anyone else would tell you dynamic lighting as opposed to manual sector lighting is a good thing. The only problem with it in Eduke32 is that apparently the dynamic lighting requires quite a strong machine.
#804 Posted 28 July 2009 - 01:20 PM
mydsic4, on Jul 28 2009, 09:41 PM, said:
Why shoehorn all this technology in an old engine?
The answer should be obvious : because it's fun for those who do it.
Unlike many community driven projects all this eduke32/HRP/DukePlus stuff is done for the fun of it, not for kudos or a better world.
mydsic4, on Jul 28 2009, 09:41 PM, said:
Being an old fart myself (older than most of the forum members for sure) I really appreciate all those efforts that keep my Duke experience alive and evolving. I'm no die-hard old school gamer because I prefer the HRP - but most newer games lack this special comic style atmosphere and gameplay. Since the DPCBP update I even plan on buying a new graphics card to play it with polymer at acceptable framerates. :-)
While I'd prefer to see more new maps, too, I can understand that it might be more fun to create and code cool things like Naferia's Reign or Sonic3D although those will attract way fewer players than a good new map I suppose.
This post has been edited by LeoD: 28 July 2009 - 02:53 PM
#806 Posted 28 July 2009 - 02:51 PM
This post has been edited by LeoD: 28 July 2009 - 02:57 PM
#807 Posted 28 July 2009 - 03:26 PM
mydsic4, on Jul 28 2009, 01:41 PM, said:
Because we want to work on and mess with Duke source ports, not make some cheesy Quake mod. EDuke32 exists to allow everyone who wants to enjoy good old Duke3D to do so, and also to create a free platform for people to fairly easily create their own custom games quickly and easily with sweet results.
Quote
Your statements are pretty contradictory. We just wanna allow dedicated fans and new followers to do more with Duke than they ever could before. I'm not sure why you'd prefer the imitation (Duke brought to another engine as a mod) over the real thing (a modern engine brought to Duke).
So, back on topic... anyone still having trouble compiling current svn with MinGW?
#808 Posted 28 July 2009 - 03:37 PM
LeoD, on Jul 28 2009, 05:20 PM, said:
XD! On that note, NR will have it's own [unique] maps eventually, and I can't say I'd know about Sonic3D since that's not my mod. But it's nice to know there's another person I don't know well. who cares some about my dinky old mod.
But in some seriousness to who was talking about modding Duke in Quake or something like that, there's also the issue of legality. People have come here talking about Duke mods for Half-Life and a few other non-BUILD engine games, and they are generally not received too well here because 3DR tends to get moody with people who use the Duke license in another engine [despite currently not having a development team, it's still a legal entity and they can give you trouble for it]. This is another reason EDuke32 is good to have with all the updates to both coding and graphics.
While I'll admit I don't play EDuke32 for the HRP/Polymost/Polymer right now [half due to my crappy computer and lack of income to upgrade], it's coding system is what I perfer, as I am a modder and to a degree a mapper by heart. Look at it like this. You don't HAVE to use the extra graphics engines just to play EDuke32. Those can be left off and you can stay in 8-bit mode. Although... not all people can be pleased I guess. o.o
EDIT: Oh, and sorry to knock off topic there TX, so I'll agree and say we should get back on the real topic here now.
This post has been edited by Lord Misfit: 28 July 2009 - 03:39 PM
#809 Posted 28 July 2009 - 05:11 PM
The Commander, on Jul 24 2009, 10:37 PM, said:
I never noticed this before, or maybe because it´s new. Tryed all the build games i know of and all them worked TekWar, Witchaven, Fate, PowerSlave, Lameduke (didnt try Blood either SW). It´s pretty cool how the colours theme change according to the map version and you can see a short message ¨map version 3´ sort of. This is easily one of the best features i found in mapster3d, and i´m sure it also can save the map keeping the orignal format (right?). Another feature i would add is recognizing .dat files or other .grp files when you press F in the load map menu.
EDIT: Tekwar for some reason had a mess with the colours in 3d mode, this is weird because the folder includes the pallete.dat.
This post has been edited by Gambini: 28 July 2009 - 05:13 PM
#810 Posted 28 July 2009 - 08:01 PM
I noticed that with the HRP water texture, each frame is defined seperately, which is fine as it's only 3 frames. But my animations (some walls with flashing red alert stuff, and my own water animation) are often 10-20 frames in length, making it far more simple and easy to use animtilerange and dummytilerange to define them. I tried creating my own water normal map and applying it to the HRP water and it worked fine, so I know it's not an issue with my normal maps... All I can guess is that something about the animtilerange command is making it ignore normals, or just consider their def lines as erroneous.
*edit* Here is an example of the defs for my water animation;
dummytilerange 9948 9963 52 52 texture 9948 { pal 0 { file "highres/textures/water/1.png" } nocompress } normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 } texture 9949 { pal 0 { file "highres/textures/water/2.png" } nocompress } normal { file "highres/textures/water/2n.png" parallaxbias 0.3 parallaxscale 0.3 } **and so on down to tile 16, number 9963** animtilerange 9948 9963 3 2 }
I then tried;
dummytilerange 9948 9963 52 52 texture 9948 { pal 0 { file "highres/textures/water/1.png" } nocompress } **tiles 2 - 15** texture 9963 { pal 0 { file "highres/textures/water/16.png" } nocompress } animtilerange 9948 9963 3 2 normal { file "highres/textures/water/1n.png" parallaxbias 0.3 parallaxscale 0.3 } }
On that last code, I also tried moving the normal file ABOVE the animtilerange command, so it was directly below the last tile number, 9963 - still no go. Admittedly with this last bit of code I was just reaching and trying ANYTHING to make it work.
I hope I've just missed something stupidly obvious here...
This post has been edited by Sobek: 28 July 2009 - 08:09 PM