[Helixhorned]

Fox, on 06 February 2013 - 06:47 PM, said:

Phew, I am facing some trouble with events called multiple times. First of all, the events are run is reverse order

That can be explained by the way they're implemented. When an endevent is encountered but the event was already defined previsouly, a JUMP instruction that points to the beginning of the old one is placed at the end of the new one. So yes, events defined later run earlier. [NOTE: jump shouldn't really be used by user CON code.]

Quote

onevent EVENT_SPAWN
  ifactor PIGCOP
    spritepal 21
endevent

onevent EVENT_SPAWN
  ifactor PIGCOP
  ifspawnedby RECON
    spritepal 22
endevent

The intended effect would be that Pig Cops would have palette 21, except those spawned by a Recon Patrol Vehicle which would have palette 22. However this is not what actually happens, instead all Pig Cops would have palette 21 because the first onevent is called later.

That code seems pretty artificial to me, and just having that logic in one "ifactor PIGCOP" branch in EVENT_SPAWN is much more readable IMO. The way I see it, event chaining is mainly a mechanism to allow modules to define independent behavior for a particular event. For example because each module needs EVENT_SPAWN for their custom actors.

Quote

The second problem is with the break command, which run across all the multiple onevent. Example below:

  onevent EVENT_SPAWN
    ifactor PIGCOP
      spritepal 21
  endevent

  onevent EVENT_SPAWN
    ifactor PIGCOP
      break
  endevent

This sample code is meant to make all Pig Cops have palette 21, but nothing will happen because of the break command in the second onevent. And I don't think this should happen, since when used in a state the break command only affects the code of the state.

Now this is interesting, and it can also be explained by what was said above: the two EVENT_SPAWN parts effectively become one block of code. I kind of agree that the expected behavior for break is "jump to end of event" (i.e. what is called "return" in most imperative programming languages). Shall we say that for now, "if a break is used inside an event that is multiply defined, the behavior is undefined"? (That is, one should not rely on it stay the same in the future.)

[Fox]

Helixhorned, on 07 February 2013 - 03:16 AM, said:

[NOTE: jump shouldn't really be used by user CON code.]

What do you mean? That I should not be opening an event multiple times, or that it's a sort of a mistake of Eduke?

Helixhorned, on 07 February 2013 - 03:16 AM, said:

That code seems pretty artificial to me

Fox, on 06 February 2013 - 06:47 PM, said:

for example:

You guessed it. But believe me, I have some pratical use for an event being opened multiple times.

Since the code is normally written from the top to the bottom, I think it's just natural to have the first event called first.

Helixhorned, on 07 February 2013 - 03:16 AM, said:

Shall we say that for now, "if a break is used inside an event that is multiply defined, the behavior is undefined"? (That is, one should not rely on it stay the same in the future.)

Ehh, since it is a basic function (like "else") can't it be fixed?

[Helixhorned]

Fox, on 07 February 2013 - 04:26 AM, said:

What do you mean? That I should not be opening an event multiple times, or that it's a sort of a mistake of Eduke?

I mean that jump should be avoided when writing CON code. There are some legitimate uses for what other languages call "goto" when jumping to error handling code forwards, but loops (=backward jumps) should be written using the available looping constructs: whilevarn or whilevarvarn.

Quote

Ehh, since it is a basic function (like "else") can't it be fixed?

Not immediately.

[Fox]

Well, I never really ever used the command jump, so that is not a problem for me.

[Mblackwell]

I'm not really sure how it's at all natural to not have your same actor called from multiple instances of an event?

I mean, for readability as well as the general logic of your code it doesn't seem to make much sense and it can potentially be a lot more lines of code depending on what you need done.

onevent EVENT_SPAWN
  ifactor PIGCOP
    spritepal 21
endevent

onevent EVENT_SPAWN
  ifactor PIGCOP
  ifspawnedby RECON
    spritepal 22
endevent

vs

onevent EVENT_SPAWN
    ifactor PIGCOP
    {
        ifspawnedby RECON
            spritepal 22
        else
            spritepal 21
    }
endevent

The above happens to be 9 lines just as before, but for each further EVENT_SPAWN you'll need an additional 3 lines (onevent EVENT_SPAWN - ifactor PIGCOP - endevent) along with whatever other if conditions you put in place. And all for code that logically should be happening before the actor is executing the rest of its code so it all fits together anyway.

[Plagman]

Keep in mind multiple event definitions are pretty important for stuff like mutators. We can't have stuff break or act weird just because you append a small CON mod using break in an event; it shouldn't need to have any knowledge of who else defined the event and what instructions they used inside it. If this is hard to get right, then it should just be an error to call break from any event, and I suspect that would be unacceptable.

[Fox]

Mblackwell, on 07 February 2013 - 07:26 AM, said:

I'm not really sure how it's at all natural to not have your same actor called from multiple instances of an event?

I mean, for readability as well as the general logic of your code it doesn't seem to make much sense and it can potentially be a lot more lines of code depending on what you need done.

onevent EVENT_SPAWN
  ifactor PIGCOP
    spritepal 21
endevent

onevent EVENT_SPAWN
  ifactor PIGCOP
  ifspawnedby RECON
    spritepal 22
endevent

vs

onevent EVENT_SPAWN
    ifactor PIGCOP
    {
        ifspawnedby RECON
            spritepal 22
        else
            spritepal 21
    }
endevent

The above happens to be 9 lines just as before, but for each further EVENT_SPAWN you'll need an additional 3 lines (onevent EVENT_SPAWN - ifactor PIGCOP - endevent) along with whatever other if conditions you put in place. And all for code that logically should be happening before the actor is executing the rest of its code so it all fits together anyway.

It is just an example. It doesn't need to make sense.

[Mblackwell]

Plagman, on 07 February 2013 - 10:00 AM, said:

Keep in mind multiple event definitions are pretty important for stuff like mutators. We can't have stuff break or act weird just because you append a small CON mod using break in an event; it shouldn't need to have any knowledge of who else defined the event and what instructions they used inside it. If this is hard to get right, then it should just be an error to call break from any event, and I suspect that would be unacceptable.

Break usually means "do not execute the following code block(s)". For the given example there's no real context other than perhaps order of operations. Unless we can specify that there's really not going to be a good way to do non-additive mutators.

[MusicallyInspired]

Got a problem with polymer on my laptop. My laptop is a decent build with a NVidia GeForce GT 550M 2GB video device. Polymer works fine and smoothly except for spotlights. In Mapster and ingame the spotlights don't show up at all. If I do 'restartvid' in the console the spotlight will appear for a splitsecond before disappearing again (also, I've noticed that it does not cast a shadow). I'm not sure if this was ever a problem before or not as I don't remember if I ever saw an ingame spotlight on my laptop or not. I guess I just assumed it would work. I'm already running the latest driver so that's not the problem. Any suggestions? I've tried the latest snapshot as well as the 64-bit build that was posted a little while back. No change. I'm not sure why it's not working as it's a decent NVidia card and NVidia is supposed to the best compatible device for polymer, right?

The eduke32.log file displays these lines of messages every time I typed in 'restartvid' if it means anything:

Quote

Initializing Polymer subsystem...
PR : Board loaded.
PR : FBO #1 initialization failed.
PR : FBO #2 initialization failed.
PR : FBO #3 initialization failed.
PR : FBO #4 initialization failed.
PR : FBO #5 initialization failed.
PR : Initialization complete in 180 ms.

[Fox]

I requested this before, but I think it is worth to mention it again. Is it possible to display the player start position as a sprite in Mapster?

What it looks like now:




What it could be like:

[Hendricks266]

Perhaps this could be implemented in a.m32?

[Fox]

How weird, I figured out there is a small bug with setgamepalette.

onevent EVENT_DISPLAYROOMS
  setplayer[THISACTOR].heat_on 1
  setgamepalette 0
  setplayer[THISACTOR].heat_on 0
endevent

By setting the game palette to zero, the game was supposed to display always display it regardless of the condition. However, because I changed the value of heat_on the palette is reset to 1 if the player is underwater and using Night Vision Goggles at the same time.

This is not a big issue, I have fixed the problems I was having by simply changing the order of the code... but I think it should at least be mentioned.

[Gambini]

Question: Is it possible that some TROR construction that works in Sofware, works in Polymost and obviously works in Polymer on a rig with a Nvidia video card, when tested in another computer with an ATI video card only works in Polymer and Software?

I know TROR is unsuported by Polymost. But I made a relatively simple construction that worked all three ways here, and when sent to this other guy he showed me some really ugly HOM screenshots. The only thing of why we think this could happen is the brand of our video cards.

[Fox]

I dunno, but I think it can't possible relate to the video card. The ROR glitches have something to do with the order which the render draw sectors. Polymer on the other hand make the levels entirely 3D, so ROR is not a problem.

[Mike Norvak]

Gambini, on 12 February 2013 - 10:17 AM, said:

Question: Is it possible that some TROR construction that works in Sofware, works in Polymost and obviously works in Polymer on a rig with a Nvidia video card, when tested in another computer with an ATI video card only works in Polymer and Software?

I know TROR is unsuported by Polymost. But I made a relatively simple construction that worked all three ways here, and when sent to this other guy he showed me some really ugly HOM screenshots. The only thing of why we think this could happen is the brand of our video cards.

Mhhh I remember having exactly the same problem while working on Metropolitan Starlight, The Big Cheese show me some ugly HOM TROR while I specially designed the area for Polymost and it looked good on my end... So finally we decided to make the map only Polymer playable.
Plagman must know.

[Gambini]

I´ve asked a couple of guys. They all had either HOM or glitches. It seems that you and me are the only ones able to see it. Interesting thing, if this trivia could be solved, it could be safe to say that TROR works on all three renderers at least to some degree.

[Plagman]

Hmm, that doesn't sound right to me. Nothing should be vendor specific in the core rendering. I don't understand why this would happen, except if Polymost TROR maybe relies on some non-conformant GL behavior which different drivers would then be free to interpret as they please.

[Gambini]

Well maybe I didn´t mention that one of the guys i sent the test map had an Nvidia video card. Which is even more confusing. Funny thing is that this is also unaltered depending of the Eduke32 snapshot being used.

I´m willing to take care of all tests needed (as long as it´s something I can do) in order to find where this difference comes from. Come to think of how much this would benefit Eduke32 to have TROR working on all renderers. And being the situation that it seems to work in some systems, we would not be that far of achieving it.

[Fox]

I don't think it is possible, since the glitches in classic mode have something to do with the order which sectors are draw. In other words, fixing it would be related to the shape of the sectors in question.

[Gambini]

You don´t understand. In my computer TROR on Polymost looks as good as it looks on Software. There area some minor glitches, but they happen to be exactly the same ones that Sofware show. All the people that I sent my test map to, found it terribly glitchy on Polymost. Now Norvak comes and says he had the exact same problem.

This is not sorcery. There has to be something to do in order to make all the rest see what I see.

[Plagman]

Are you 100% certain they're using the same exact version are you?

[Gambini]

At least this first guy yes. because i sent him my exe after he told me about the issue. He ran the map with the exe file i sent, and in what i believe was an identical folder because we are working on something togheter and therefore we have a common folder´s arrange.

The other guys, i didnt ask. But they are active users. And I myself have tried with older versions, a couple of them, and the no-problem stood there. I even took the map off this folder and tried it in my vanilla duke folder with a much older snapshot (from august of last year i think). Still the same.

Just take this example, to take away some speculation (since the map of discussion isnt released). I can wander around the whole Retailation map by loke in Polymost and i dont see a damn glitch. Parkade instead, looks quite glitched.

[Mark]

If you want another tester let me know. I have time right now to look at it.

[Gambini]

Thanks but the "map" i sent to the testers is just a room with an island TROR sector inside. It is much better as a "benchmark" to use Retailation by Loke http://msdn.duke4.ne...retaliation.php

So could look at it either in Mapster or ingame, using Polymost, and see what happens!

[Mark]

The only glitch I noticed was the top half of the pool area fickered to black a little bit from certain angles. Nothing real bad.

[Fox]

How the heck could I possible re-work the weapon of choice order? I mean, I wanted to add 4 more "weapons" in the list.

[Gambini]

So no further investigations are going to be made regarding the TROR polymost compatibility? Helix hasnt ever expressed himself about the subject.

[Plagman]

Well, to reiterate, Polymost is known to not support all TROR constructs, but it should do so consistently across different machines. Can you do the following?

• Post your test map
  
• Ask your tester to take a shot of the glitched area
  
• Have him post his full log
  
• Do the same thing yourself

[Gambini]

Yes sir! I Here is the attached map. Then this is my log:

EDuke32 2.0.0devel r3492 
Compiled Feb 16 2013 10:56:08
Using C:/Juegos/DUKE/ for game data
Windows XP Service Pack 3 (build 5.1.2600)
Initialized nedmalloc
Initializing DirectDraw...
Searching for game data...
Using "DUKE3D.GRP" as main game data file.
Compiling: GAME.CON (151190 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
GAME.CON: In actor `ORGANTIC':
GAME.CON:3967: warning: found `else' with no `if'.
GAME.CON: In state `pigshootenemystate':
GAME.CON:5890: warning: found `else' with no `if'.
Found 2 warning(s), 0 error(s).
Resizing code buffer to 16189*4 bytes
Relocating compiled code from to 0x7fb40010 to 0x890be88
Script compiled in 37ms, 16181*4b, version 1.4+
2006/11264 labels, 322/2048 variables, 2/512 arrays
125 quotes, 207 actors
Initialized 24.0M cache
RTS file "DUKE.RTS" was not found
Initializing OSD...
Switching kb layout from 0000040A to 00000409
Initializing DirectInput...
  - Enumerating attached game controllers
  - No game controllers found
Uninitializing DirectInput...
Executing "settings.cfg"
Executing "autoexec.cfg"
Setting video mode 1280x1024 (8-bit windowed)
Initializing music...
Initializing sound... 96 voices, 2 channels, 16-bit 44100 Hz
Cache time: 80ms
E1L8: USER MAP
Setting video mode 1280x1024 (32-bit windowed)
OpenGL Information:
 Version:  3.3.0
 Vendor:   NVIDIA Corporation
 Renderer: GeForce 9600 GT/PCIe/SSE2
Opened "textures" as cache file
Rendering method changed to polygonal OpenGL
Saved screenshot to duke0000.png
SCREEN SAVED
 
Wrote eduke32.cfg
Wrote settings.cfg
Uninitializing DirectDraw...

and here an screenshot of how it looks:



Now it will take a time for my tester to come back with his log. but in the meantime one of them already sent shots:



Gonna come with the tester´s log back later.

Attached File(s)

•  trortest.rar (2.74K)
  Number of downloads: 593

[Gambini]

And here is the log of another of my testers. He also took shots but no need to post them, the glitches flick back and forth but they all look more or less the same.

EDuke32 2.0.0devel r3105
Compiled Oct 31 2012 08:20:59
Application parameters: -game_dir extclut 
Using E:/Games/Duke3D (Old)/Editor/ for game data
Using extclut/ for game data
Windows 7 Service Pack 1 (build 6.1.7601)
Initialized nedmalloc
Initializing DirectDraw...
Searching for game data...
Using E:/Games/Duke3D (Old)/Editor/extclut/ for game data
Using "DUKE3D.GRP" as main game data file.
Compiling: GAME.CON (151190 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
GAME.CON: In actor `ORGANTIC':
GAME.CON:3967: warning: found `else' with no `if'.
GAME.CON: In state `pigshootenemystate':
GAME.CON:5890: warning: found `else' with no `if'.
Found 2 warning(s), 0 error(s).
Resizing code buffer to 16189*4 bytes
Script compiled in 55ms, 16181*4b, version 1.4+
2006/11264 labels, 322/2048 variables
125 quotes, 207 actors
Initialized 24.0M cache
RTS file "DUKE.RTS" was not found
Initializing OSD...
Switching kb layout from 00000809 to D0010809
Initializing DirectInput...
  - Enumerating attached game controllers
  - No game controllers found
Uninitializing DirectInput...
Executing "settings.cfg"
Disabling desktop composition...
Setting video mode 1920x1080 (32-bit fullscreen)
Enabling ATI FBO color attachment workaround.
OpenGL Information:
 Version:  4.2.11931 Compatibility Profile Context
 Vendor:   ATI Technologies Inc.
 Renderer: AMD Radeon HD 6900 Series
Opened "extclut/textures" as cache file
Initializing music...
Initializing sound... 32 voices, 2 channels, 16-bit 44100 Hz
Cache time: 53ms
E1L8: USER MAP
 
Wrote eduke32.cfg
Wrote settings.cfg
Uninitializing DirectDraw...

It makes no difference whether a new or old snapshot it used seems. Also these testers own ATIs and Nvidias, so discard the GPU compatibility thing,